> On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin >> After some thinking, I still like the "state-preserving" construct >> that's equivalent to the current MD5 code. Yes, we could just do >> siphash(current_cpu || per_cpu_counter, global_key), but it's nice to >> preserve a bit more. >> >> It requires library support from the SipHash code to return the full >> SipHash state, but I hope that's a fair thing to ask for. This is not a good idea. If I understand correctly, the idea here is to just keep around SipHash's internal state variables, and chain them over to the next call, sort of like how md5_transform with the current code works on the same scratch space. There has been no security analysis in the literature on this use of the primitive, and I have no confidence that this is a secure use of the function. Unless somebody can point me toward a paper I missed or a comment from a real cryptographer about the specifics of SipHash, I think I'm right to admonish against this dangerous road. Let's talk about constructions. And let's only decide on a construction that we're actually equipped to analyze. Let's definitely not talk about making our own primitives, or retrofitting nice primitive's internals into our own Frankenstein. Alternatively, if I'm wrong, please send me an eprint/arXiv link to a paper that discusses this use of SipHash. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
