[tahoe-dev] [pycryptopp] #46: Add combined AES+XSalsa20 cipher module

[pycryptopp]

#46: Add combined AES+XSalsa20 cipher module
------------------------+---------------------------------------------------
Reporter:  randombit    |           Owner:  dragonxue
    Type:  enhancement  |          Status:  new      
Priority:  major        |         Version:  0.5.19   
Keywords:  xsalsa20     |   Launchpad Bug:           
------------------------+---------------------------------------------------
 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).

-- 
Ticket URL: <http://allmydata.org/trac/pycryptopp/ticket/46>
pycryptopp <http://allmydata.org/trac/pycryptopp>
Python bindings for the Crypto++ library