Key Strenghtening

[boyska]

At the moment we are just using plain gpg symmetrical encryption. We should use something stronger: good examples are bcrypt, PDBKF2 or scrypt. Tomb should support some of this, and keyfiles should have a "header" for key stretching operation (algorithm, parameters, salt).

Specifications

• It MUST have a --kdf option to choose kdf method (bcrypt, pbkdf2, scrypt)
• There must be a method to pass parameters to kdf methods. Something like --kdf pbkdf:2.5 (meaning that the iteration count must be on around 2.5 seconds)
• It would be nice being able to chain kdf methods: this way you can combine the stableness of pbkdf2 with the cool features of scrypt, without worrying too much of a buggy implementation. Something like --kdf pbkdf2,scrypt or even --kdf pbkdf2:2.5,scrypt (that is, passing parameters)

[davinerd]

On 30/07/2012 11:16, BoySka wrote:

At the moment we are just using plain gpg symmetrical encryption. We should use something stronger: good examples are bcrypt, PDBKF2 or scrypt. Tomb should support some of this, and keyfiles should have a "header" for key stretching operation (algorithm, parameters, salt).

Can you explain this? I'm not aware of any of these topics.

Anathema

+--------------------------------------------------------------------+	GPG/PGP KeyID: 0F26965C available on http://pgpkeys.mit.edu:11371/		Fingerprint: F808 18A2 2E7D 6E7A 7A18 4062 0AA3 7BF2 0F26 965C
http://www.msack.org
https://tboxes.tracciabi.li/anathema

+--------------------------------------------------------------------+

[boyska]

Key strenghtening is, basically, getting the password that the user typed, running some higly-expensive function to get a new password, and use that one. This is to make bruteforcing more expensive. The problem is: some hashing functions are expensive on a CPU, but cheap on specialized hardware. (for example running MD5 1000 times is not that useful). Anyway, anything would be better than what we have now. I did experiments on my computer, and guessing passwords with GPG is too cheap: if the password is not that difficult, it will be revealed even with a CPU.

Especially scrypt is very good, since it is memory-based, to make it more expensive (memory is less scalable than processing): see https://www.tarsnap.com/scrypt/scrypt-slides.pdf for slides: the last part has a nice table that shows how much better scrypt is believed to be estimating attack costs. Or see https://www.tarsnap.com/scrypt/scrypt.pdf for the complete paper.

They also released a tool, but unfortunately it directly encodes, and the only simple, usable tool to do just the stretching part is this https://github.com/pbhogan/scrypt ruby library.

I am now trying to patch the original source code to make it even do just key strenghtening, so that I can plug it into tomb. That seems simple, but I seem to have done a buggy implementation. I'll investigate further.

[boyska]

OK, I implemented it. I like how the generic "header" for keyfiles went, so give your opinion on that, first of all. (note that --kdf scrypt will NOT work on your computer unless you install https://github.com/boyska/scrypt/tree/onlystretch ). If, however, there is consensus on its usage, we can consider copying it into tomb.

[boyska]

while scrypt is nice and is probably the most paranoid solution, pbkdf2 is certainly most tested, included in openssl, and so is less probable to create security bugs :)

that's why I made a little utility that just depends on libssl/libcrypto, to be included in tomb, to do kdf using pbkdf2.

That is, I included a kdf/ directory with C tools especially designed for tomb (though they are quite general purpose). This will be simple to deploy (no dependency on esoteric packages) and effective.

[jaromil]

First of all: this is an awesome feature. Thanks Boyska.

It also looks mature enough. KDF support is in Debian testing, hence soon in Debian stable.

I will start to look into merging this into master.

[boyska]

If so, please have a look at my rel1.3 branch; it has others (minor, but good I think) commits about kdf; especially, it has more tests, can compile with --without-gcrypt if you are on an old machine (we love old machines!), has tests (we love tests!) and there is some example of try-always block (see #84 for why we need it)

[jaromil]

looks very good. merged without big problems. thanks for contributing so much to this release!