In the section 3.2 recipient tests there is discussion about checking
that the public key 32-octet string will have last byte in such way
that high-order bit of it is not set.
If this is property of the func(d, G) for curve25519, and curve448,
how can we ever get public values having that bit
Hi,
I support adopting this document.
Regards,
Valery Smyslov.
Greetings. There was some general interest in having a standard way to
modern elliptic curves for ephemeral key exchange. Please respond in
this thread whether or no you think this document is a good start on
that work, and
On Aug 26, 2015, at 9:33 AM, Yaron Sheffer yaronf.i...@gmail.com wrote:
In the section 3.2 recipient tests there is discussion about checking
that the public key 32-octet string will have last byte in such way
that high-order bit of it is not set.
If this is property of the func(d, G)
Of interest to this WG. This is an individual submission, not a WG item,
so comments should be sent as described in the announcement.
Forwarded message:
From: The IESG iesg-secret...@ietf.org
To: IETF-Announce ietf-annou...@ietf.org
Subject: Last Call: draft-kivinen-ipsecme-oob-pubkey-11.txt
A new Request for Comments is now available in online RFC libraries.
RFC 7619
Title: The NULL Authentication Method in
the Internet Key Exchange Protocol Version
2 (IKEv2)
Author: V. Smyslov, P. Wouters
