On 1/27/2014, 12:24 PM, Brian Warner wrote:
On Jan 27, 2014, at 8:08 AM, Richard Newman <[email protected]> wrote:
As such, I would imagine that truncation here is fine, no? We're not really
worried about collisions.
Truncating a good cryptographic hash function is safe, as long as you're still
happy with the remaining length. 16 bytes is enough to avoid accidental
collisions until we get to like 2^64 users, at which point we'll have bigger
problems to worry about, like the storage servers collapsing into a black hole.
* We don't want to give an oracle to testing kB, but we pretty much have to in
order for clients to get the comparison they need. We're not going to do a
zero-knowledge proof here.
kB is full-size and random. Yeah, an oracle lets someone do offline guesses,
but they'll need 2^256-ish guesses to succeed. So no worries there either.
OK, based on warner's input I suggest we go with the much simpler
BASE64URLSAFE(FIRST-16-BYTES(SHA256(kB)))
If I read what warner says correctly, the key-space for kB is large
enough that we don't need to salt with the email address. This makes
life a good deal simpler for clients.
Comments?
Nick
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
