On Mon, 2015-11-02 at 23:54 -0800, Colm MacCárthaigh wrote: > * I think the statement "can be implemented easily without being > vulnerable to software side-channel attacks" is too strong, unless > one wants to really litigate what "software side-channels are". > Unless I'm mistaken, as a stream cipher ChaCha20 is *more* vulnerable > to a class of size-based side-channels than a block cipher would be. > A simple form of attack would be to monitor connections to wikipedia > and identify which pages a user is browsing; from observing just the > size of requests and responses [*] it's pretty easy for an attacker > to (offline) create a graph of HTML page sizes and the sizes of the > images they load and then (in real time) to correlate things such > that they can uniquely identify the page loaded. This attack is > feasible with both stream and block ciphers, but it is far easier > with a stream cipher. Similarly, the compressed map tiles attack that > shows where an online maps user is browsing is much more effective > with a stream cipher. [http://blog.ioactive.com/2012/02/ssl-traffic > -analysis-on-google-maps.html]
I agree that protecting the length of the communicated data is important, but there is nothing specific to this cipher. All modern TLS ciphers today are stream ciphers (i.e., AES-GCM and AES-CCM (*)), so they offer the same protection as chacha20 with respect to hiding the length. Maybe we should add a note about that in the security considerations. regards, Nikos (*). More specifically their mode is a stream cipher mode _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls