[curves] Generating nonces for Schnorr signatures

Samuel Neves sneves at dei.uc.pt
Wed Jun 25 17:56:00 PDT 2014

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

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,

More information about the Curves mailing list