#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?).

Change History (7)

Changed at 2010-08-09T15:46:34Z by xueyu

cipher of combiner python version

Changed at 2010-08-09T15:47:19Z by xueyu

test of cipher combiner

Changed at 2010-08-09T16:14:18Z by xueyu

Changed at 2010-08-11T14:25:04Z by xueyu

cipher combiner c++ cpp file

Changed at 2010-08-11T14:25:15Z by xueyu

Changed at 2010-08-11T14:25:38Z by xueyu

cipher combiner c++ python wrapper

Changed at 2010-08-11T14:26:16Z by xueyu

cipher combiner c++ patch

Note: See TracTickets for help on using tickets.