Better password protections in Chrome
The cryptography behind this is done very well so that Google does not ever see even your hashed password, or know if there was a breached password detected. What Google does see is a hash-prefix of your username, to narrow down the encrypted data set of compromised credentials being returned to your Chrome instance.<p>Here’s what happens. Your instance of Chrome hashes your username and password and encrypts that value with an ephemeral key which doesn’t leave Chrome, <i>Kc</i><p>Google gets the encrypted cred-hash and applies a second round of encryption with a key only known to Google, <i>Kg</i>. They return the doubly-encrypted cred-hash, and also return 256 candidates encrypted with just <i>Kg</i> for you to compare against, those 256 candidates are selected based on a clear-text 3 byte prefix that Chrome also sends them.<p>When Chrome gets the results back, it decrypts the cred-hash using <i>Kc</i> which results in the cred-hash now being encrypted only with <i>Kg</i>; coincidentally this is the same exact key used to encrypt the candidates, allowing Chrome to do a simple byte-compare to see if there’s a match between your cred-hash and the encrypted breach candidates.<p>The cool part is the encryption operation is basically communicative. You can add your layer of encryption first, send the value to Google, they add their encryption and you get the double-encrypted blob back, and then you remove your encryption to end up with a plaintext encrypted just with Google’s key, even though Google never saw the plaintext, and you never saw their key.<p>This trick allows your browser, and only your browser, to compare your cred-hash against the breached cred-hashes while all the data you are comparing is actually encrypted with a secret key held by Google that never leaves Google’s server.<p>The only information leak is the 3-byte hash prefix to identify the slice of the comparison set. This is definitely not nothing, but perhaps it is a reasonable trade-off.