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? Ryan _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
