Missing description of ED25519-V3 private key format in rend-spec-v3.txt

changed milestone to %Tor: 0.3.5.x-final

added component::core tor/tor milestone::Tor: 0.3.5.x-final priority::medium resolution::fixed reviewer::asn severity::normal status::closed tor-spec type::defect labels

Trac:
patch

patch to torspec.git

Trac:
Status: new to needs_review

Trac:
Milestone: N/A to Tor: 0.3.5.x-final

Trac:
Reviewer: N/A to asn

LGTM!

See https://github.com/torproject/torspec/pull/36 for a PR of Riastradh's patch.

Also inlining a very useful IRC log in case this comes up in the future:

<+asn> Riastradh: hello
<+asn> Riastradh: im reading #28123
-zwiebelbot:#tor-dev- tor#28123: Missing description of ED25519-V3 private key format in rend-spec-v3.txt - [needs_review] - https://bugs.torproject.org/28123
<+asn> Riastradh: thx for documenting the current behavior
<+asn> Riastradh: did you encounter issues using add_onion with ur own ed25519 keys?
<+asn> or what made you write this patch?
< Riastradh> asn: Yep, that's right.
< Riastradh> asn: https://mumble.net/~campbell/hg/ucspi-onion/
<+asn> Riastradh: do you think the current behavior makes sense?
<+asn> it does seem like exposing our messy internals to the world.
< Riastradh> The oniongen1 tool generates the key offline.

< Riastradh> asn: I don't have strong feelings about it.  If you need to
             do arithmetic on the scalar, then obviously you can't pass
             around a seed from which the scalar is derived by SHA-512.
             And Tor does need to do some arithmetic on scalars -- but
             maybe not for the long-term Ed25519 private keys per se.

<+asn> hm ok 
<+asn> i need to read again how the ed25519 privkey format works, and how our own format works.
< Riastradh> The other cost to using (scalar, prf key) rather than (seed, pub key) is that you need to do another scalar multiplication every time you load (scalar, prf key) if you want to 
             make signatures with it, because computing signatures involves the public key.
<+asn> Riastradh: ack
<+asn> thx for the feedback
<+asn> i will finish up review tomorrow. not much brain atm.
< Riastradh> Here's the quick summary: signing requires scalar a, PRF key h, and pub key A = a*P, where P is the standard base point, to compute s = r + H(R, A, m)*a where r = H(h, m).
< Riastradh> The ed25519-ref code uses (seed, A), and to make a signature derives (a, h) = SHA512(seed).
< Riastradh> Tor uses (a, h), and to make a signature derives A = a*P.
< Riastradh> If you need to derive a key pair (a', h, A') from (a, h, A) by arithmetic on a' (which carries over to A'), you can't use a seed because you have no hope of finding the seed' 
             such that (a', h) = SHA512(seed').
< Riastradh> What RFC 8032 calls a `private key' is just the 32-byte seed, so a lot of implementations will probably work with that.  https://tools.ietf.org/html/rfc8032#section-3.2
< Riastradh> But conversely it probably isn't hard to adapt them to work with (a, h) instead.
< Riastradh> asn: Shall I copy this up into he ticket for reference when you have replenished brain?
< Riastradh> into the ticket
< > asn, Riastradh: outsider here, but give some insight, standard Go ed25519 keys could not be used because they were seed + pub key (ref 
            https://stackoverflow.com/questions/44810708/ed25519-public-result-is-different and https://github.com/cretz/bine/blob/master/torutil/ed25519/ed25519.go)
< > so I used my own there which works fine w/ add_onion...as for storage to disk, I juse pem-formatted the private key

Trac:
Status: needs_review to merge_ready

Merged. Thanks!

Trac:
Status: merge_ready to closed
Keywords: N/A deleted, tor-spec added
Resolution: N/A to fixed

closed

moved to tpo/core/tor#28123 (closed)

Missing description of ED25519-V3 private key format in rend-spec-v3.txt

Child items ...

Activity