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