[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    [CFRG] =?gb2312?b?u9i4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlydGYtY2Zy?= =?gb2312?b?Zy1kZXQtc2lncy13aXRoLW5v
From:       Niu Danny <dannyniu () hotmail ! com>
Date:       2024-03-22 1:20:08
Message-ID: OS3P286MB1920D7341476F9D391E80D2DC1312 () OS3P286MB1920 ! JPNP286 ! PROD ! OUTLOOK ! COM
[Download RAW message or body]

I don't think the name change is needed.

Think about it this way: if you change the name of the signing algorithm, then that's \
the verifying algorithm supposed to be called?

We can call the schemes deterministic-EdDSA and hedged-EdDSA - these qualifiers are \
descriptive enough already. Also for the use case, we can borrow the experience with \
the NIST draft for Dilithium and SPHINCS+, just set Z to all-zero when using the \
deterministic variant.

________________________________________
·¢¼þÈË: CFRG <cfrg-bounces@irtf.org> ´ú±í Simon Josefsson \
<simon=40josefsson.org@dmarc.ietf.org> ·¢ËÍʱ¼ä: 2024Äê3Ô 22ÈÕ 00:54
ÊÕ¼þÈË: John Mattsson
³­ËÍ: cfrg@ietf.org
Ö÷Ìâ: Re: [CFRG] I-D Action: draft-irtf-cfrg-det-sigs-with-noise-03.txt

John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> writes:

> Hi,
> We have just uploaded version -03 of Hedged ECDSA and EdDSA Signatures.

This still uses the approach to modify RFC 8032 instead of introducing
new primitives with new separate names.  I believe this will cause
confusion: will an implementation of 'Ed25519' behave per RFC 8032 or
your document?  It seems clear that the suggested changes here are not
applicable to all use-cases, and the changes may be undesirable to many
use-cases.

How about modifying your document to introduce new primitives HEd25519,
HEd25519ph, HEd25519ctx in parallel to existing primitives Ed25519,
Ed25519ph, Ed25519ctx?  Same for 448.

I suggested using names REd* for this earlier, so essentially this is
the same request but use the new term 'Hedged' instead of 'Randomized'.
I feel the term 'Hedged' is not the best term, as it conveys the notion
of a value judgement, but using any distinct name is better than
re-using the same name to mean two different things.

Btw, maybe this could go into a RFC 8032bis instead, fixing other
erratas on the way.

/Simon
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://mailman.irtf.org/mailman/listinfo/cfrg


[prev in list] [next in list] [prev in thread] [next in thread]