On 1/27/2014, 10:08 AM, Richard Newman wrote:
* SHA256 is 256 bits, i.e. 256 / 8 = 32 bytes long. I interpret the server's "32
characters long" to mean the resulting string, so we have 16 bytes to work with, and
therefore SHA256 is not trivially usable. (I don't know an obviously secure way to take
a 32 bit hash and generate a 16 bit hash from it.) We could bump the server to allow for
32 bytes.
Bear in mind that this is only used to do node assignment based on client-side
changes; the primary concerns are that the hash differs (consistently) when the
user's key changes, and that it can't be used to attack their key. As such, I
would imagine that truncation here is fine, no? We're not really worried about
collisions.
I said "obviously correct". It's certainly not obvious to me that
taking the first 16 bytes of a 32 byte hash is a reasonable thing to do.
I'm not really worried about collisions, but I don't touch crypto
primitives without motivation :)
* 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.
Yeah.
* It's irritating to include emailUTF8, since this is Yet Another Place for
email case normalization to bite us.
Just lowercase (and normalize, I presume) the email address. It's not being
used as an identifier here, and we don't allow multiple case variants of an
account. Again, just needs to consistently change the output if the input
changes.
Lower-casing unicode email addresses on clients scares me. We're
consistently taking a server-returned alternate email address as
canonical to avoid specifying what lowercasing means per client.
Nick
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
