Opened at 2010-08-09T00:11:18Z
Last modified at 2013-09-11T03:41:35Z
#46 new enhancement
Add combined AES+XSalsa20 cipher module — at Initial Version
Reported by: | randombit | Owned by: | dragonxue |
---|---|---|---|
Priority: | major | Milestone: | 0.7.0 |
Version: | 0.5.19 | Keywords: | xsalsa20 aes combiner design-review-needed |
Cc: | lloyd@…, davidsarah | Launchpad Bug: |
Description
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?).
cipher of combiner python version