Add combined AES+XSalsa20 cipher module

[randombit]

For preserving confidentiality in the event of a break in AES, we want to combine AES (256 bit, CTR mode) with XSalsa20. This will simply process the message with both in sequence; it doesn't matter which order they are applied in, as both are effectively key stream generators, so AES-CTR(XSalsa20(m)) == XSalsa20(AES-CTR(m)).

This requires us to have 512 bits worth of key material, because both AES-256 and XSalsa20 use 256 bit keys, plus 320 bits of initialization vector data (128 for AES and 192 for XSalsa20).

Long keys are problematic for usability reasons (a longer key requires a longer capability string, and 256 bits is about as long as we can reasonably make them), so we'll want to instead derive both AES and XSalsa20 keys from a 256 bit input using a strong KDF. We'll use HKDF for this purpose. Thus, the overall construction that will be exported from pycryptopp will look like this:

AES_plus_XSalsa20(m, masterkey_256, iv):

hkdf = HKDF(masterkey_256)
aes_key_256 = hkdf.make(32)
xsalsa_key_256 = hkdf.make(32)

(aes_iv,xsalsa_iv) = split iv into 128 + 192 bit pieces

aes_encrypted = AES_CTR(m, aes_key_256, aes_iv)
xsalsa_encrypted = XSalsa20(aes_encrypted, xsalsa_key_256, xsalsa_iv)
return xsalsa_encrypted

Practically speaking, it appears that at the moment Tahoe does not use the ability to set an IV except for sequential access into the stream, otherwise always using an IV of all zeros (this is fine because the keys are generated randomly or via content hashing, and thus will always differ, except in the case that you are encrypting identically messages in which case you'll get identical ciphertext, which is a desirable property). We'll have to make some modifications there when it comes time to implement XSalsa20+AES decryption, because XSalsa20's IV is merely a diversification parameter, the counter exists elsewhere in the state (it can be modified in Crypto++ by calling SeekToIteration?).

This is part of the Tahoe-LAFS ​One Hundred Year Cryptography project.

[xueyu]

cipher of combiner python version

[xueyu]

test of cipher combiner

[xueyu]

cipher combiner c++ cpp file

[xueyu]

cipher combiner c++ python wrapper

[xueyu]

cipher combiner c++ patch

[xueyu]

ciphercomb.cpp, ciphercomb.hpp and ciphercomb.py are cipher combiner c++ implementation and are wrapped with python.
ciphercombiner.py are python implementation
a different between the two is that in c++ version, the key serves as ikm of hkdf, then generate combiner key. In python version, the key can indepently generated.
a little sorry is that it seems that the patch contain some conflicts information when I used "darcs record".

[zooko]

Here are some reasons why I might prefer AES-128, copied from IRC. Dcoder is Samuel Neves.

<Dcoder> what's the rational for using AES128 instead of AES256 in the
	 combined cipher thing?					        [11:26]
<Dcoder> i see that the orignal ticket,
	 http://tahoe-lafs.org/trac/pycryptopp/ticket/46, still says AES256
<zooko> Dcoder: I'm concerned about CPU usage on ARM.
<zooko> :-/
<zooko> I guess what I *really* want is super optimized ARM implementation of
	AES and XSalsa20 and SHA-256. But also, XSalsa20⊕AES-128 should be at
	least as secure as AES-256				        [11:36]
<zooko> and also, related-key-weirdness, not that I actually care because
	Tahoe-LAFS definitely doesn't allow related keys, but if AES-256
	starts getting a worse reputation than AES-128 because of that then
	that becomes something we have to explain--why we're not vulnerable to
	that.
<zooko> Dcoder: what do you think?				        [11:37]
<Dcoder> zooko: i do not disagree				        [11:46]
<Dcoder> i was just curious because of the incongruence between tickets

I think the next step on this issue of AES-256 vs. AES-128 is to benchmark XSalsa20⊕AES-128 compared to XSalsa20⊕AES-256 on an ARM system. François Deppierraz has kindly offered us the use of his ARM NAS box for that purpose -- anybody who wants to run benchmarks on it just ask François for ssh access.