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:
https://security.stackexchange.com/questions/25375/why-not-use-larger-cipher-keys/25392#25392
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
https://security.stackexchange.com/questions/25393/openssl-blowfish-key-limited-to-256-bits/25405#25405
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.
Janos
