On 26-06-2014 00:37, Trevor Perrin wrote: > * Goldilocks uses envelope-MAC for the nonce, Ed25519 doesn't care > about length extension. I can't think of a reason length extension > matters? > > * Seems like it would be more traditional for nonce derivation to pad > the secret key out to a full SHA512 block (128 bytes), HMAC-style.
I was under the impression that envelope-MAC, by definition, required at least the prefix to be block-sized [1]. But the message should also be padded to block-size, to avoid some largely impractical attacks that result from the suffix key possibly overlapping into 2 separate blocks. [2, Section 6] has a good overview on the history and padding issues of envelope-MAC. I don't think any of this has much relevance to the nonce generation setting. Neither does length extension: if we are able to mount a length-extension attack, we must already have some way to recover the nonce (that is, the SHA-512 state), a far more devastating attack. [1] G. Tsudik. "Message Authentication with One-Way Hash Functions", 1992, https://www.ics.uci.edu/~gts/pubs.html [2] N. Koblitz and A. Menezes, " Another Look at Security Theorems for 1-Key Nested MACs", 2013, http://eprint.iacr.org/2013/248 _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
