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 …
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...
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.
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!
"Forward secrecy' protects data for the long term"
Except from Google's prying advertisement-potential email scanners!
But should we trust...
Something written by a guy called Adam "Langley" ?
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.
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.
- Product round-up Ten excellent FREE PC apps to brighten your Windows
- Review Tough Banana Pi: a Raspberry Pi for colour-blind diehards
- Product round-up Ten Mac freeware apps for your new Apple baby
- Analysis Pity the poor Windows developer: The tools for desktop development are in disarray
- Product round-up The Glorious Resolution: Feast your eyes on 5 HiDPI laptops