4 ms·

I'm assuming it's similar to the haveibeenpwned pwned passwords API? https://haveibeenpwned.com/API/v3#PwnedPasswords https://haveibeenpwned.com/API/v3#PwnedPa

I'm assuming it's similar to the haveibeenpwned pwned passwords API? https://haveibeenpwned.com/API/v3#PwnedPasswords https://haveibeenpwned.com/API/v3#PwnedPasswords

Shank 7y ago
It...appears to be so? The infographic states that they "send a strongly hashed and encrypted copy of your username and password to Google." They explicitly mention that the username, not the password, is sent with a 3-byte hash prefix. They make no mention of prefixing the password in the infographic. In the linked paper where they discuss the tradeoffs and take blinding into consideration. They note that the protocol is that a client calls CreateRequest(u, p) which creates a Req that is then sent explicitly to Google. It appears to me that they consider the merits of sending a hash-prefixed password, but do not make it explicitly clear that the final solution sends a hash-prefixed password. I think that they would want to explicitly say that only a partial hash is sent to Google, if that were the case?
- geogriffin 7y ago
  > ... do not make it explicitly clear that the final solution sends a hash-prefixed password I'm not sure if you're actually talking about something else, but the paper says: "Post-canonicalization, the server calculates a computationally expensive hash of both the canonical username and credential password... This 2-byte prefix—while leaking some bits of password material—provides the client with k-anonymity over the universe of all username and password pairs." IOW, the 3-byte hash prefix sent is of the username and password concatenated. (Note that Google seems to have added another byte to the prefix versus the paper).
  - Reelin 7y ago
    To add to this, hashed username-password material is leaked only by the first variant described in the paper. The second variant described only leaks hashed username material. They reportedly used the first variant during testing but have now switched to the second variant. They indeed appear to have increased the prefix from 2 to 3 bytes. This makes logistical sense though - with 4 billion items, a 2 byte address yields ~61k items per bucket (and thus sent to the client per request) while a 3 byte address yields only ~240 on average.

I'm assuming it's similar to the haveibeenpwned pwned passwords API? https://haveibeenpwned.com/API/v3#PwnedPasswords https://haveibeenpwned.com/API/v3#PwnedPasswords

Shank 7y ago

It...appears to be so? The infographic states that they "send a strongly hashed and encrypted copy of your username and password to Google." They explicitly mention that the username, not the password, is sent with a 3-byte hash prefix. They make no mention of prefixing the password in the infographic. In the linked paper where they discuss the tradeoffs and take blinding into consideration. They note that the protocol is that a client calls CreateRequest(u, p) which creates a Req that is then sent explicitly to Google. It appears to me that they consider the merits of sending a hash-prefixed password, but do not make it explicitly clear that the final solution sends a hash-prefixed password. I think that they would want to explicitly say that only a partial hash is sent to Google, if that were the case?

geogriffin 7y ago
> ... do not make it explicitly clear that the final solution sends a hash-prefixed password I'm not sure if you're actually talking about something else, but the paper says: "Post-canonicalization, the server calculates a computationally expensive hash of both the canonical username and credential password... This 2-byte prefix—while leaking some bits of password material—provides the client with k-anonymity over the universe of all username and password pairs." IOW, the 3-byte hash prefix sent is of the username and password concatenated. (Note that Google seems to have added another byte to the prefix versus the paper).
- Reelin 7y ago
  To add to this, hashed username-password material is leaked only by the first variant described in the paper. The second variant described only leaks hashed username material. They reportedly used the first variant during testing but have now switched to the second variant. They indeed appear to have increased the prefix from 2 to 3 bytes. This makes logistical sense though - with 4 billion items, a 2 byte address yields ~61k items per bucket (and thus sent to the client per request) while a 3 byte address yields only ~240 on average.