[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
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
More information about the Curves
mailing list