4 ms·

"Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes. This represents a 16% reduction of the TLS n

"Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes. This represents a 16% reduction of the TLS network overhead incurred when using older ciphersuites such as RC4-SHA or AES-SHA." Does that mean 25B->21B per-packet overhead? What percentage overhead are TLS headers?

agl 13y ago
Yes, vs RC4-SHA. There's always five bytes of record header: the record type, u16 length and u16 version. (The version is basically a waste.) For AES-CBC there's an average of 8 bytes of padding (half the block size). For AES-GCM there's eight bytes of wasted nonce because of FIPS concerns that appear to have been groundless. Then there's the MAC: 20 bytes for HMAC-SHA1 or 16 for GCM or Poly1305.
- tptacek 13y ago
  If you were designing a new transport to replace TLS, would you build a flexible record layer protocol to run it on top of, in the sense that TLS provides?
  - agl 13y ago
    I'd likely say that the records are AEAD ciphertext and let the AEAD decide on what that means. But as for allowing handshake messages, alert messages etc to mix with application data, no. (See the QUIC design as an example: https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...)
userbinator 13y ago
> Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes I'm puzzled why a shorter MAC would be considered a good thing in a security application - because theoretically, a 20-byte MAC gives roughly 4 billion times the space of a 16-byte one. It's like shortening an encryption key - hasn't the trend been toward making them longer and thus more resistant to attack?
- tptacek 13y ago
  Simpler security proof, higher guaranteed security with a shorter MAC.
  - riffraff 13y ago
    could explain this in a longer way? Considering the HMAC subset of MAC, the final value of the function should be of the same length of the base hash function. So i.e. hmac-sha256 would be longer than hmac-sha1, but I don't understand why the latter would be simpler to check and of higher security. Or do you mean that Poly1305 is all three (simpler, more secure, shorter mac) compared to the HMAC family?
- tveita 13y ago
  A difference between encryption keys and MACs is that MACs do not become weaker as the attacker gains more computing power, except by making bruteforcing the authentication key easier, which does not depend on the length of the tag. The attacker is limited by the amount of messages your system can process. Another difference is that old communication is not at risk. As soon as the client and server is upgraded, they are secure, as opposed to encryption where attackers may still recover sensitive information from things that were encrypted years ago. So it doesn't need the same degree of future proofing. So while a 80-bit encryption key is on the weak end of the spectrum, even 80 bits of security is pretty conservative for a MAC.

agl 13y ago

Yes, vs RC4-SHA. There's always five bytes of record header: the record type, u16 length and u16 version. (The version is basically a waste.) For AES-CBC there's an average of 8 bytes of padding (half the block size). For AES-GCM there's eight bytes of wasted nonce because of FIPS concerns that appear to have been groundless. Then there's the MAC: 20 bytes for HMAC-SHA1 or 16 for GCM or Poly1305.

tptacek 13y ago
If you were designing a new transport to replace TLS, would you build a flexible record layer protocol to run it on top of, in the sense that TLS provides?
- agl 13y ago
  I'd likely say that the records are AEAD ciphertext and let the AEAD decide on what that means. But as for allowing handshake messages, alert messages etc to mix with application data, no. (See the QUIC design as an example: https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH...)

userbinator 13y ago

> Poly1305 also saves network bandwidth, since its output is only 16 bytes compared to HMAC-SHA1, which is 20 bytes I'm puzzled why a shorter MAC would be considered a good thing in a security application - because theoretically, a 20-byte MAC gives roughly 4 billion times the space of a 16-byte one. It's like shortening an encryption key - hasn't the trend been toward making them longer and thus more resistant to attack?

tptacek 13y ago
Simpler security proof, higher guaranteed security with a shorter MAC.
- riffraff 13y ago
  could explain this in a longer way? Considering the HMAC subset of MAC, the final value of the function should be of the same length of the base hash function. So i.e. hmac-sha256 would be longer than hmac-sha1, but I don't understand why the latter would be simpler to check and of higher security. Or do you mean that Poly1305 is all three (simpler, more secure, shorter mac) compared to the HMAC family?
tveita 13y ago
A difference between encryption keys and MACs is that MACs do not become weaker as the attacker gains more computing power, except by making bruteforcing the authentication key easier, which does not depend on the length of the tag. The attacker is limited by the amount of messages your system can process. Another difference is that old communication is not at risk. As soon as the client and server is upgraded, they are secure, as opposed to encryption where attackers may still recover sensitive information from things that were encrypted years ago. So it doesn't need the same degree of future proofing. So while a 80-bit encryption key is on the weak end of the spectrum, even 80 bits of security is pretty conservative for a MAC.