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


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:

Unencrypted Page

We suggest you use an encrypted connection for browsing this site, please pick a mirror from the following list: www1 | www4

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:

Lock Icon Encrypted Page

You are viewing this page using an encrypted connection. If you bookmark this page or send it's address in an email you might want to use the un-encrypted address of this page.

If you recieved an warning about an untrusted root certificate please install the CAcert root certificate, for more information see the security page.

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.

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.


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

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:

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. smile
  • Twofish is known for being fast.
  • Twofish is faster than AES with 256-bit keys, but slower than AES with 128-bit keys


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.

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

-- 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
Topic attachments
I Attachment Action Size Date Who Comment
lock_icon.gifgif lock_icon.gif manage 918 bytes 11 Dec 2004 - 23:46 UnknownUser Lock Icon
serpentcase.pdfpdf serpentcase.pdf manage 65 K 16 Feb 2005 - 00:59 UnknownUser The Case for Serpent
wisa2004.pdfpdf wisa2004.pdf manage 71 K 16 Feb 2005 - 00:25 UnknownUser Encrypted Watermarks and Linux Laptop Security
Topic revision: r29 - 11 Jan 2006, MicahA
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback