8 ms·

This is neat but kinda useless without some written analysis. I am not a crypto expert so the graphs mean little to me.

by HeXetic 11y ago

justizin 11y ago
I think your comment eats to the heart of what's been happening of late. You shouldn't need to be a crypto expert to know what Forward Secrecy or ECDHE are, at least. Anyone who might ever configure a webserver should be learning about this stuff.
- yuhong 11y ago
  I remember https://twitter.com/nestsupport/status/606246459822997505 https://twitter.com/nestsupport/status/606246459822997505 and other similar tweets days after I reported the 768-bit DHE problem to Google security. (affected server was https://transport01-rts10-iad01.transport.home.nest.com https://transport01-rts10-iad01.transport.home.nest.com)
- acqq 11y ago
  I'm glad that at least you find the graphs obvious, as I have a bunch of questions. What are security pros and cons of using or not using GCM? And which browser uses which settings of these displayed by default? How can we interpret the percentages? What are the percentages anyway? It's hard to see them from all these graphs. Actually, I don't care about the peak-hour times when I just need to know the percentages. And in which time zone is the time scale at all? Thanks in advance.
  - kpcyrd 11y ago
    disclaimer: no crypto expert. There's a concept of authenticated encryption, so your connection isn't just confident, you're also making sure nobody tampered with the content. There are multiple ways to assure that. There is a RFC for EtM in TLS: https://tools.ietf.org/html/rfc7366 https://tools.ietf.org/html/rfc7366 This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC- then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years. That also describes MtE. GCM in itself is already authenticated so it skirts the migration issue.
  - tptacek 11y ago
    GCM is "authenticated encryption". That means that it's a cipher construction that provides both confidentiality and integrity, in one hermetically sealed capsule. Most legacy crypto (and most of the crypto in TLS) provides integrity checking as a separate operation; it will, for instance, take confidentiality from AES-CBC, and authentication from (say) HMAC-SHA1. This works fine, but requires that implementations do joinery between the cipher and the MAC. Every iteration of TLS prior to the version that began providing authenticated encryption (of which GCM is the only widely compatible option) has gotten this joinery wrong. There are workarounds for the resultant bugs, but it's better, when possible, to enable the version of TLS that enables GCM, and prefer the GCM ciphersuites.
    - amenghra 11y ago
      Besides not having to deal with the joinery, GCM is sometimes chosen for perf reasons (smaller output, cpu support, etc).
      - chetanahuja 11y ago
        "Besides not having to deal with the joinery, GCM is sometimes chosen for perf reasons " Although going by this, https://www.imperialviolet.org/2013/10/07/chacha20.html https://www.imperialviolet.org/2013/10/07/chacha20.html AES-GCM has performance issue when it comes to software implementations. The reason chrome added ChaCha20+Poly1305 as an option in chrome (when talking to google services). Now, it basically comes down to hardware support and it's not yet near universal in the current install base of mobile devices (all the myriad arm cpus floating around in the world).
        tptacek 11y ago
        It performs OK in software, but a fast pure-software implementation requires secret-dependent table lookups, which creates a hard-to-mask side channel.
    - iso8859-1 11y ago
      You almost imply that GCM is the only authenticated encryption. People should know that it is just one of them, but it is the one that circumvents patents and is really reasonably fast.

This is neat but kinda useless without some written analysis. I am not a crypto expert so the graphs mean little to me.

by HeXetic 11y ago

This is neat but kinda useless without some written analysis. I am not a crypto expert so the graphs mean little to me.

I think your comment eats to the heart of what's been happening of late. You shouldn't need to be a crypto expert to know what Forward Secrecy or ECDHE are, at least. Anyone who might ever configure a webserver should be learning about this stuff.

yuhong 11y ago
I remember https://twitter.com/nestsupport/status/606246459822997505 https://twitter.com/nestsupport/status/606246459822997505 and other similar tweets days after I reported the 768-bit DHE problem to Google security. (affected server was https://transport01-rts10-iad01.transport.home.nest.com https://transport01-rts10-iad01.transport.home.nest.com)
acqq 11y ago
I'm glad that at least you find the graphs obvious, as I have a bunch of questions. What are security pros and cons of using or not using GCM? And which browser uses which settings of these displayed by default? How can we interpret the percentages? What are the percentages anyway? It's hard to see them from all these graphs. Actually, I don't care about the peak-hour times when I just need to know the percentages. And in which time zone is the time scale at all? Thanks in advance.
- kpcyrd 11y ago
  disclaimer: no crypto expert. There's a concept of authenticated encryption, so your connection isn't just confident, you're also making sure nobody tampered with the content. There are multiple ways to assure that. There is a RFC for EtM in TLS: https://tools.ietf.org/html/rfc7366 https://tools.ietf.org/html/rfc7366 This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC- then-encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years. That also describes MtE. GCM in itself is already authenticated so it skirts the migration issue.
- tptacek 11y ago
  GCM is "authenticated encryption". That means that it's a cipher construction that provides both confidentiality and integrity, in one hermetically sealed capsule. Most legacy crypto (and most of the crypto in TLS) provides integrity checking as a separate operation; it will, for instance, take confidentiality from AES-CBC, and authentication from (say) HMAC-SHA1. This works fine, but requires that implementations do joinery between the cipher and the MAC. Every iteration of TLS prior to the version that began providing authenticated encryption (of which GCM is the only widely compatible option) has gotten this joinery wrong. There are workarounds for the resultant bugs, but it's better, when possible, to enable the version of TLS that enables GCM, and prefer the GCM ciphersuites.
  - amenghra 11y ago
    Besides not having to deal with the joinery, GCM is sometimes chosen for perf reasons (smaller output, cpu support, etc).
    - chetanahuja 11y ago
      "Besides not having to deal with the joinery, GCM is sometimes chosen for perf reasons " Although going by this, https://www.imperialviolet.org/2013/10/07/chacha20.html https://www.imperialviolet.org/2013/10/07/chacha20.html AES-GCM has performance issue when it comes to software implementations. The reason chrome added ChaCha20+Poly1305 as an option in chrome (when talking to google services). Now, it basically comes down to hardware support and it's not yet near universal in the current install base of mobile devices (all the myriad arm cpus floating around in the world).
      - tptacek 11y ago
        It performs OK in software, but a fast pure-software implementation requires secret-dependent table lookups, which creates a hard-to-mask side channel.
  - iso8859-1 11y ago
    You almost imply that GCM is the only authenticated encryption. People should know that it is just one of them, but it is the one that circumvents patents and is really reasonably fast.