On 1/27/2014, 11:56 AM, Ryan Kelly wrote:
On 28/01/2014 5:28 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".
You said "obviously secure", which is kinda the same thing ;P
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 :)
Yeah, fair.
Bumping the server size limit seems to be the most straightforward approach.
Yeah, if we needs to then we needs to. How big do you want it, in
b64urlsafe chars?
It's 4/3 * 32 bytes, which is awkward. We could also just go for 64
chars and agree to hex-encode, which at least is easy to work with :)
Let's wait until some of the other crypto folks have weighed in on
SHA256 vs. HKDF before bumping the server.
Nick
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
