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

pycryptopp trac at tahoe-lafs.org
Sun Dec 4 02:32:24 UTC 2011


#46: Add combined AES+XSalsa20 cipher module
------------------------+---------------------------
Reporter:  randombit    |          Owner:  dragonxue
    Type:  enhancement  |         Status:  new
Priority:  major        |      Milestone:
 Version:  0.5.19       |     Resolution:
Keywords:  xsalsa20     |  Launchpad Bug:
------------------------+---------------------------

Comment (by davidsarah):

 Re comment:2,
 * I would not worry at all about related-key attacks. Anything using HKDF
 to generate keys is not vulnerable to them, period. I take the point about
 reputation and blow a big >raspberry< at it -- any loss of reputation
 resulting from related-key attacks would be likely to apply to AES in
 general, not specifically AES-256.
 * The difference between 128-bit and 256-bit keys does actually matter to
 security (especially "100-year security" against multi-target and low-
 success-probability attacks). See Bernstein's
 [http://cr.yp.to/snuffle/bruteforce-20050425.pdf Understanding brute
 force] paper, which makes a pretty strong argument in favour of 256-bit
 (or at least longer than 128-bit) keys.
 * It might seem unlikely that any brute-force attacks would be feasible
 given the cascade with XSalsa20, but it's not implausible that the shorter
 key length, or just as importantly the lower number of rounds, could help
 an attack that also took advantage of a weakness in XSalsa20 or AES.
 * I don't think that the performance difference between 10 and 14 rounds
 should be a determining factor for this decision.

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



More information about the tahoe-lafs-trac-stream mailing list