4 ms·
why not use a library that does TLS with an AEAD cipher, like AES-GCM? Some possible reasons: * lack of confidence in TLS's design and designers (for example,
by ctz 14y ago
why not use a library that does TLS with an AEAD cipher, like AES-GCM?
Some possible reasons:
* lack of confidence in TLS's design and designers (for example, TLS1.2 still allows compression and fails to counsel against its use).
* TLS has far too many options. I want a secure channel. I don't want a secure channel toolkit.
* TLS tends to be paired with a broken and discredited root-of-trust infrastructure (which often gives the misleading impression that TLS itself was broken).
(nb. I don't have any evidence that the AEAD TLS1.2 ciphersuites are broken, I'm playing devil's advocate here.)
Regarding your 'new cryptosystems' point: I agree, and its completely and frustratingly hopeless. But that's why the world needs a decent secure channel standard with good security bounds, and no knobs on the side which break confidentiality or integrity, and no backwards-insecurity ability.
- tptacek 14y ago* You should have even less confidence in new cryptosystems. * Downthread, I suggested that TLS doesn't have as many extraneous options as it appears. * If you can specify AES-GCM, it is even easier to specify not using default CA roots. * Using an AEAD cipher removes crypto logic from the SSL protocol (the order of operations and message formatting for getting a block cipher to work with a hash-based MAC) and moves it into the block cipher mode, which (unlike TLS) is NIST-standardized.
- deleted 14y ago[deleted]
- wiredfool 14y agoIs there a problem with the body content of an http response being compressed, or is it mainly a header thing?
- Daniel_Newby 14y agoThere can be if a secret is on the same page as text under the attacker's control. The attacker can run a hidden JavaScript reload attack on the page, the fiddle with the text under their control until compression is maximized.