[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