On Jan 27, 2014, at 12:29 PM, Nick Alexander <[email protected]> wrote:
> 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))) > +1, let's do it. -chris > 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 _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
