Encryption Ideas for IMC UK
Some idea that are being developed following the
, see also the UkHostingComparisons
for discussion about where to host the box(s).
The following proposal was proposed to imc-uk-process on 11 Dec 2004
One problem we have at the moment with only https for the
admin interface is that there is not enough encrypted
browsing traffic to obscure who is uploading stuff.
One way of addressing this (which works with the existing
set up of mirrors and doesn't require us to switch to
using squid) is to:
1. Set up as many mirrors as possible running https, there are currently two, more are needed, see: UkMirror
2. A box on the site in one of the margins, which has this when you view
the page with an un-encrypted connection, this has now been done and deployed on the site
We suggest you use an encrypted connection for browsing this site, please pick a mirror from the following list: www1
Please install the CAcert root certificate
to verify the authenticity of the site, for more information see the security page
And this when the connection is encrypted:
3. Make one of the the https sites listed the publishing server in order to generate some extra browsing traffic for it so that it becomes hard to detect the uploads from the downloads from the actions of admins. This will be done once the new server is depoyed, the current publishing server is not up to it bandwidth or load wise.
4. For all sites on the new server have redirects on port 80 to direct traffic to the port 443 https interface.
We should also encourage users of the site to use Tor
as suggested to imc-uk-tech
See also i2p
Intergrate with Encypted P2P
Curremtly all @indymedia.org email uses TLS with CAcert
certificates, see: CaCertSsl
, but this isn't the case with @indymedia.org.uk UkEmail
Encrypting the filesystem would make it harder to retrieve data by seizing hard disks. We could encrypt the whole hard disk or perhaps just encrypt some partitions.
dm-crypt, cryptoloop & loop-aes
There are three basic implementations of encrypted filesystems on GNU/Linux: cryptoloop, loop-aes and dm-crypt. Cryptoloop is the earlier implementation, dm-crypt the later and "better" one. DM-crypt should be faster and is the preferred implementation now. It is in the Linux kernel as of 2.6.5. It is supported "out-of-the-box" more or less, in Debian, Fedora, and probably others. loop-aes is another option, but is not standard and difficult to set up. But loop-aes may be more secure than dm-crypt.
- The "new standard" for Linux filesystem encryption
- Tools readily available for Debian, Fedora, and probably distros
- Reasonably easy to set up
Loop-aes is not susceptible to the same attacks that dm-crypt is susceptible to because it uses ESSIV (so watermarking is not an issue), but the chart [[http://clemens.endorphin.org/LinuxHDEncSettings] seems to say that ESSIV is susceptible to other problems. Loop-aes might benchmark faster than dmcrypt.
- Difficult to set up
- Not part of Linux kernel, nor are userland tools in most distros
- Requires lots of patches (e.g. to loopback module), specialized mount & other tools
- Possibly faster than dm-crypt
- loop-aes is apparently not vuln to some of the attacks dm-crypt is vuln to (such as watermarking?)
- Uses only ESSIV
Linux Kernel Crypto Algorithms
DM-crypt can use any of the encryption algorithms in the kernel. As of 2.6.10 they are:
benchmarks using dm-crypt
- aes - Rijndael (AES) Cipher Algorithm
- anubis - Anubis Cryptographic Algorithm
- arc4 - ARC4 Cipher Algorithm
- blowfish - Blowfish Cipher Algorithm
- cast5 - Cast5 Cipher Algorithm
- cast6 - Cast6 Cipher Algorithm
- crc32c - CRC32c (Castagnoli) calculations wrapper for lib/crc32c
- crypto_null - Null Cryptographic Algorithms
- deflate - Deflate Compression Algorithm for IPCOMP
- des - DES & Triple DES EDE Cipher Algorithms
- khazad - Khazad Cryptographic Algorithm
- md4 - MD4 Message Digest Algorithm
- md5 - MD5 Message Digest Algorithm
- michael_mic - Michael MIC
- serpent - Serpent and tnepres (kerneli compatible serpent reversed) Cipher Algorithm
- sha256 - SHA256 Secure Hash Algorithm
- sha512 - SHA-512 and SHA-384 Secure Hash Algorithms
- tea - TEA & XTEA Cryptographic Algorithms
- twofish - Twofish Cipher Algorithm
- wp512 - Whirlpool Message Digest Algorithm
The "best" CryptoFS Algorithms
The most likely candidates for a cryptofs would be AES (Rijndael), twofish, or Serpent.
"During the AES process, everyone agreed that Rijndael was the risky choice, Serpent was the conservative choice, and Twofish was in the middle." -Bruce Schneier
Details on these implementations:
The Advanced Encryption Standard selected by the US Government for their encryption needs. The govt had a "crypto contest"
and the Rijndael algorithm won, thus becoming the Standard. It is often the default algorithm used by GNU/Linux crypto programs.
- AES requires more processing power as key size increases
- AES is faster than Twofish at 128-bit keys, but slower than Twofish with 256-bit keys
Came in second place in the "crypto contest".
Twofish was one of the 5 AES finalists. One if it's designers was Bruce Schneier
who is about as famous as you can get as a crypto guru.
- Twofish is known for being fast.
- Twofish is faster than AES with 256-bit keys, but slower than AES with 128-bit keys
It looks like a new way to manage keys is coming: LUKS - Linux Unified Key Setup
If you want to change the passphrase, you have to re-encrypt the partition (on loop-aes this is not
required). This means you have to copy the files to some other partition, re-encrypt the parition, then copy everything back. There are some alpha-ish tools that do this "on-the-fly", but if the process croaks in the middle (e.g. crashes, loses power, whatever), you're fucked.
EncryptedFS on other Operating Systems
- GBDE: GEOM Based Disk Encryption
- Requires kernel recompilation
- 128-bit AES in CBC mode
- "NOTICE: Please be aware that this code has not yet received much review and analysis by qualified cryptographers and therefore should be considered a slightly suspect experimental facility."
- "We cannot at this point guarantee that the on-disk format will not change in response to reviews or bug-fixes, so potential users are advised to be prepared that dump(8)/restore(8) based migrations may be called for in the future."
- Uses CGD, which is a stock part of NetBSD
- NetBSD Manual: The cryptographic device driver
- aes, blowfish, & 3des in CBC mode
- Possibly the best encrypted fs implementation available for Free unixes
- Paper comparing CGD to other cryptoFS implementations
- Can change passphrase without re-encrypting disk
- Can use remote keyserver for unattended booting (though what happens if the keyserver is taken...)
- Uses "iterated salted key generation" to counter dictionary attacks (apparently the only implementation that offers protection against dictionary attacks)
-- problem i see with this is that a law agency may enforce the revelation of a password, which may involve the detention of one or more key holders. (-- JamesCox
- 06 Dec 2004)
-- yes, but then we at least know that they've physically compromised the system and we'll /who/ actually has the fukn gear... (jebba)
-- have a look at http://www.freenet.org.nz/phonebook/
which details deniable encryption:
* Deniable Encryption technology supplements conventional encryption approaches with a crucial feature - a structure which permits the owner (at his/her discretion) to disclose decryption keys for only non-sensitive (or faked replacements of sensitive) information, in such a way as to deprive an attacker or interrogator of any way of determining whether or not the interviewee is fully complying with decryption demands. As such, this technology is valuable in environments where people can be placed under high pressure (legal, military or other) to disclose decryption keys. (micah)
Details are now on the UkHardwareComparisons page
A hardware crypto accelerator have been suggested like the Soekris Engineering vpn1401 and vpn1411
and it has also been pointed out that the VIA C3 processor
is a lot better for crypto, see some VIA PadLock ACE benchmarks
. However that 1Ghz chips don't have the ACE stuff and the mini-tix boards with the 1.2Ghz chips don't have i/o shields that fit 1U cases...
Also the VIA C7 is due in 2005
and it will add RSA encryption (with Montgomery Multiplier support) and Secure Hashing (SHA-1 and SHA-256) acceleration to the hardwired security-oriented functionality the current C3 chips already provide
(--jebba notes that the vpn1401 doesn't have a Linux driver--it has stagnated since 2002. Also the VIA stuff looks like it requires a bit of patching...)
- 15 Feb 2005 - Basically wrote cryptoFS section (note, I know next to nil about cryptography--I'm merely a googler...)
- 21 Feb 2005 - Added info about non-Linux cryptoFS implementations