Re: [Cfrg] Fwd: I-D Action: draft-turner-thecurve25519function-00.txt

[Tanja Lange <[e-mail]>]

Dear Robert,
> Section 3:
> 
> * The draft correctly specifies that the high bit must be discarded,
> but does not mention that that differs from the specification in the
> Curve25519 paper, and does not explain the reasons for that difference
> (resistance to implementation fingerprinting, and forward
> compatibility with point formats which preserve the sign bit for use
> in other protocols).  It should do both, so that the RFC won't be
> ‘corrected’ to match the paper when someone else notices that
> difference five or more years from now.
> 
The paper specifies that the x value is an integer between 0 and p-1. 
It does not specify what to do if the sent value does not adhere to 
this format. On the math side, there is no attack from accepting 
DH inputs which do not match this format, but for specifications
I want a defined format.

The text specifies that s[31] is minimal; the representation is
unique.

> * The draft correctly specifies that implementations must produce
> outputs less than the field order p, but does not explicitly state
> that implementations must accept inputs which are greater than or
> equal to p (and silently reduce them mod p).
> 
Why would you do this? If the DH input is >=2^255-19 then it was
not generated according to the specification and should be rejected.

If you want to have the ambiguity of having multiple representations
for inputs (which I would recommend against) there is still no need 
to reduce modulo p. The computation could start from the unreduced
value and give the same result.

Do you see any benefit in having non-unique representations? Any 
problems with rejecting malformed inputs?

All the best
	Tanja