[tahoe-lafs-trac-stream] [pycryptopp] #46: Add combined AES+XSalsa20 cipher module

[pycryptopp]

#46: Add combined AES+XSalsa20 cipher module
-------------------------------------------------+-------------------------
Reporter:  randombit                             |          Owner:
    Type:  enhancement                           |  from_pycon
Priority:  major                                 |         Status:  new
 Version:  0.5.19                                |      Milestone:  0.7.0
Keywords:  xsalsa20 aes combiner design-review-  |     Resolution:
  needed                                         |  Launchpad Bug:
-------------------------------------------------+-------------------------
Description changed by zooko:

Old 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).
>
> This is part of the Tahoe-LAFS [https://tahoe-lafs.org/trac/tahoe-
> lafs/wiki/OneHundredYearCryptography One Hundred Year Cryptography]
> project.

New 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).

 This is part of the Tahoe-LAFS [//trac/tahoe-
 lafs/wiki/OneHundredYearCryptography One Hundred Year Cryptography]
 project.

 This is to be used for Tahoe-LAFS ticket https://tahoe-lafs.org/trac
 /tahoe-lafs/ticket/1164

--

-- 
Ticket URL: <https://tahoe-lafs.org/trac/pycryptopp/ticket/46#comment:19>
pycryptopp <https://tahoe-lafs.org/trac/pycryptopp>