Encryption Ideas for IMC UK

Some idea that are being developed following the MirServerMeeting20041203, see also the UkHostingComparisons for discussion about where to host the box(s).

Web

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:

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.

Tor

We should also encourage users of the site to use Tor as suggested to imc-uk-tech.

See also i2p.

Intergrate with Encypted P2P

http://freenetproject.org/

http://archives.lists.indymedia.org/mir-coders/2003-November/001172.html

Email

Curremtly all @indymedia.org email uses TLS with CAcert certificates, see: CaCertSsl, but this isn't the case with @indymedia.org.uk UkEmail

Filesystem

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.

Linux Implementations

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.

cryptoloop

• The "old" Linux way to do things. Is deprecated by dm-crypt.
• cryptoloop is vulnerable to watermarking attacks: Encrypted Watermarks and Linux Laptop Security

dm-crypt

dm-crypt wiki

• The "new standard" for Linux filesystem encryption
• Tools readily available for Debian, Fedora, and probably distros
• Reasonably easy to set up

dm-crypt attacks

• Default dmc-crypt may be susceptible to watermarking attacks - Linux hard disk encryption settings
• Encrypted Watermarks and Linux Laptop Security. If ESSIV is used instead of IV (the default), watermarking can be defeated.
• IV & ESSIV are vuln to "data modification leak".
• Vuln to bit-flipping attacks?
• Note: There is a patch to get around these attacks. VERIFYINFO (LRW ?)
• ESSIV patch

loop-aes

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:

• 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

benchmarks benchmarks using dm-crypt

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:

AES

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

Serpent

Came in second place in the "crypto contest".

• Serpent is considered the "safer" and "more conservative" than AES.
• Serpent doesn't require more processing time as key size increases
• Serpent may require more processing power than Twofish/AES (A Performance Comparison of the Five AES Finalists)

Links:

• Serpent home page
• The Case for Serpent

Twofish

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

Benchmarks

• non-RAID benchmarks
• RAID benchmarks

Misc Notes

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.

Links

• Linux Crypto Mailing List
• Block Cipher Modes of Operation
• Encrypted-Root-Filesystem-HOWTO
• Encrypted Partitions using dm-crypt (riseup).
• See also the Fedora News Loopback Encrypted Filesystem instructions.
• some notes on the boum wiki
• discussion about this on imc-tech

EncryptedFS on other Operating Systems

FreeBSD

• 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."

OpenBSD

• Natively uses vnd (Vnode Disk Driver)
• Blowfish only cipher (still true?)
• OpenBSD Encrypted Virtual Filesystem Mini-HOWTO
• A port of NetBSD's CGD was made around version 3.2, but it isn't maintained

NetBSD

• 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)

Comments

-- 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)

Hardware

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...)

-- JebbaJebba - 15 Feb 2005 - Basically wrote cryptoFS section (note, I know next to nil about cryptography--I'm merely a googler...)

-- JebbaJebba - 21 Feb 2005 - Added info about non-Linux cryptoFS implementations