On Mon, Oct 14, 2013 at 6:16 AM, Pieter Hintjens <[email protected]> wrote:
> Nonetheless, I used MD5. The assertion is that collisions do not > matter here. I may be wrong. > Collisions definitely matter here. What you're specifically worried about is second preimage resistance, that is: given m, find m' such that H(m) == H(m'). This will allow you to reuse an existing (valid) digital signature for a forged certificate. It is known not just academically, but in practice, that MD5 does NOT have this property. See specifically how an MD5 collision was used by the Flame worm: http://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf > SHA512 generates a 64-byte hash. That is not usable as a human > readable signature. We could use SHA1 then, but it's not secure. While SHA1 has known weaknesses, MD5 alone should simply not be used anymore when security matters (although HMAC-MD5 is arguably ok). If you're looking at the hash functions in libsodium, I'd recommend SHA256 (which has no known weaknesses) or Blake2b. SHA256 has nearly ubiquitous support. Blake2b supports variable length output without fear of cycles (and therefore collisions) which could arise through naive hash truncation. I need to dig into your certificate format. I've only scanned over your post. So far it looks similar to mine, but with capital letters ;) Glad to see an ABNF grammar! -- Tony Arcieri
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
