back to article Google mail crypto tweak makes eavesdropping harder

Google engineers have enhanced the encryption offered in Gmail, Google Docs, and other services to protect users against retroactive attacks that allow hackers to decrypt communications months or years after they were sent. The feature, a type of key-establishment protocol known as forward secrecy, ensures that each online …


This topic is closed for new posts.
  1. dssf


    Despite my railing and harping and winging away about other security matters of google, this, I think is pretty neat.

    And, now, dastardly, as I thnk about it: imagine intentionally breaking down communications into to 3 minute chunks, sending one word at a time, but after breaking a session. The sender and receiver may have all they time in the world to play games. The MITM, however, may have to (if a state power) coerce google to effectively bridge those streams. But, that'll force the conversation of: "Then, what the HELL is all this FOR, if we have to keep two-track security and insecuri...."

    Ummm, oh, wait...

  2. david 12 Silver badge

    Server loading

    The computation load on the google servers is due to re-negotiation of session keys.

    Are they planning to give each user a different key, but force each user to use the same session longer? That would be a vast benefit to Google, but possibly a step backwards for user security.

    Every user a different public key, good.

    Every user a longer session, bad.

    Clear benifit for Google, unclear benefit for users.

  3. Xavier Serret

    TLS Session tikets invalidate Perfect Forward Security (PFS)

    This looks like classical case in security: Solving problem A by moving it to B, with identical consequences and challenges.

    It is obvious session tickets decryption keys must cached (long) term and shared between servers! In fine this means that some short of Master key (or its derivatives) must be kept long term.

    Then master key (or derivatives) can be used then to decrypt old tickets, therefore breaking PFS benefits.

    Unless more about the session tickets is disclosed Google cannot boast any real security benefit on this change!

  4. Anonymous Coward
    Anonymous Coward

    "Forward secrecy' protects data for the long term"

    Except from Google's prying advertisement-potential email scanners!

    1. Anonymous Coward
      Anonymous Coward

      But should we trust...

      Something written by a guy called Adam "Langley" ?

  5. PyLETS

    Correction: session keys secret and symmetric not public asymmetric

    "The feature, a type of key-establishment protocol known as forward secrecy, ensures that each online session is encrypted with a different public key and that corresponding private keys are never kept in long-term storage."

    The purpose of the Diffie Hellman protocol is to establish a secret symmetric session key between 2 ends of a communication link, lets call them Alice and Bob. Alice and Bob still need to sign something as part of the session initiation stage with their own asymmetric secret keys which the other can decrypt with the corresponding public keys so Alice can verify Bob's identity and Bob can identify Alice's, which defeats a man in the middle attack.

    Once a DH symmetric key and endpoint identity has been established , the symmetric session key can be used to encrypt and decrypt everything for the duration of the session and can then be securely deleted at both ends.

    Knowledge of an asymmetric secret key after the session is of no use in recovering the deleted session key so previous recorded sessions are still protected. This knowledge could be used to compromise the owner of the compromised asymmetric private key in future sessions by impersonation and MITM attack, with Eve creating simultaneous sessions to Alice and Bob and knowing both DH session keys, pretending to Alice she is Bob and pretending to Bob she is Alice. But if both authenticate each other prior to communication occurring, Eve would need to know the secret asymmetric keys of both Alice and Bob.

  6. Another Cowardlyman


    This is very interesting. RIM used DH-EC for bridge communication between a Blackberry phone and a Playbook tablet over bluetooth. If Google set this up correctly, it could be a strong solution considering the size of the target on their backs.

    The only thing I wonder about is if the US tells them to either drop it or re-design it for eavesdropping because like someone said above, it would make eavesdropping pretty difficult. Unless the RSA key they have can give the keys it will sign up in an automated fashion.

    I need some scotch to wrap my head around this one.

This topic is closed for new posts.

Other stories you might like