lsd0001

LSD0001: GNU Name System
Log | Files | Refs | README

commit dd1fd4190c37b8181fe71579a7316f3b6d8a2032
parent 47300a16e5cb219bfdf8a19f1d4d042d3a349ae7
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Sat, 19 Feb 2022 18:25:17 +0100

link, wording

Diffstat:
Mdraft-schanzen-gns.xml | 7++++---
1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml @@ -2346,9 +2346,10 @@ NICK: john (Supplemental) This is an unconventional choice, as ECDSA is usually used with other curves. However, standardized ECDSA curves are problematic for a range of reasons described in - the Curve25519 and EdDSA papers. Using EdDSA directly is also + the Curve25519 and EdDSA papers <xref target="ed25519"/>. + Using EdDSA directly is also not possible, as a hash function is used on the private key which - destroys the linearity that the GNU Name System depends upon. + destroys the linearity that the key blinding in GNS depends upon. We are not aware of anyone suggesting that using Ed25519 instead of another common curve of similar size would lower the security of ECDSA. GNS uses 256-bit curves because that way the encoded (public) @@ -2829,7 +2830,7 @@ Purpose | Name | References | Comment </reference> --> - <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"> + <reference anchor="ed25519" target="https://ed25519.cr.yp.to/ed25519-20110926.pdf"> <front> <title>High-Speed High-Security Signatures</title> <author initials="D." surname="Bernstein" fullname="Daniel Bernstein">