Dear piler-users,

I'm writing to you about the encryption that piler uses. tl;dr: piler is switching from Blowfish 128 bit to AES 256 bit encryption. It's a bit long and technical to some degree, but please read it through to get the whole picture, and understand there's no need to be
afraid of.

Piler uses Blowfish encryption CBC mode. The piler.conf file has a parameter for the initalization vector (iv) required for CBC. Later I've fixed the code that iv is empty by default.

No matter if iv is set to a fix value or it's empty (as it is nowadays by default) it allows some room for an attacker to draw some conclusions and try to guess the contents of the encrypted files. Fortunately it's
not that bad as it may sound.

Firstly, the attacker needs to have physical access to the stored files in /var/piler/store directories. Normally nobody has such access other than root and the piler user. Then piler compresses the data before encrypting it which offers some redundancy to mitigate such (theoretical) attacks.

Frank Schmirler who reported the issue also provided a patch to improve the encryption. The idea is to prepend a random block of data read from /dev/urandom to beginning of the real data to render such attempts ineffective. Then when the file is retrieved from the archive piler checks if such a junk data block exists and if so it discards it. It's completely transparent and backward compatible. The patch is already on the master branch.

However, there's more. The Blowfish encryption algorithm was developed in ~1993, so you might say it's a bit out of date. However when the piler project started I've picked a time tested solution which I believe that Blowfish was and still is. The algorithm offers the encryption key up to 448 bits (=56 bytes), which is plenty
for a symmetric encryption algorithm.

The below article explains that even a 256 bit key is more than enough to render any brute force attack ineffective. A quote from Bruce Schneier's Applied Cryptography book:

So the piler.key is 448-bit long, and even a 256 bit key would be plenty. But what if you had only a 128-bit encryption key? Would it be still enough? The trouble is that the openssl implementation of Blowfish is limited to 128 bit by default, see
for more.

I was unaware of this behaviour of openssl until a few days ago when Frank educated me on the matter. Before panicking
please consider that a commenter at the above link says that

"Above 128 bits in unnecessary. With 128 bits there are 2^128 possible keys, divided by 100 billion tests per second (which would require a formidable GPU farm) and it would take someone 7.8*10^9 times the age of the universe to crack
it (about 10^20 years)."

So even if piler is limited to a 128-bit encryption key instead of the possible 448-bit, I personally still believe that there's no reason to panic and drop your archive. Frank thinks, and I agree with him that Blowfish will not become insecure in the near future. However, an email archive should last for a long time, and over the decades I cannot make any promises
or guarantee that 128 bit will be enough till the end of the world.

So I've switched from Blowfish 128-bit to AES-256 bit. This time openssl truly delivers a 256 bit encryption. The patch I made uses Blowfish encryption to decrypt legacy emails in the archive. However, every new email is encrypted with AES-256. The piler id has also changed. It starts with 40000..... for Blowfish encrypted emails, however it starts as 5000.... to indicate that it's an AES-256 encrypted email, and piler decrypts it using the appropriate method figured from the file name. Again, this patch is also on the master branch, and it's backward compatible. You may (and in fact must) keep piler.key
as it is.

Modern CPUs have hardware accelerators for AES-256, and it may run up to 50% faster than Blowfish, so the switch is worth even from a cpu performance perspective, though I believe that Blowfish is not a bottleneck at all during the processing
of emails.

Again, I thank Frank Schmirler for bringing this issue to my attention, and providing hints and even patches to alleviate the problem.

Let me know your opinions on the matter. I also invited Frank to comment and share his thought, too on the mailing list.


Reply via email to