>>> * 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. There seems to be some scholarship on the matter: http://csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf (albeit for 'stronger' uses than we're putting this to), but novelty mere days before a deadline doesn't seem like a great plan. Bumping the server size limit seems to be the most straightforward approach. > 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. Also fair. We do definitely have the user's canonical email address by this point, at least, so we don't have to do anything but use that if we wish. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
