[proposal] X-Client-State header for Sync relaunch
nalexander at mozilla.com
Mon Jan 27 12:02:46 PST 2014
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.
More information about the Sync-dev