I'm trying to gauge interest on the IRTF's CFRG mailing list regarding collaborating on a draft for a standard Ed25519 hierarchical derivation / key blinding scheme:
https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA
The post makes several mentions of Tor's work in the space in regard to the next-generation hidden services design.
I think it'd be great if Tor were to collaborate on the design of such a scheme and adopt it for the new hidden services design. I see a lot of convergent evolution in this space and think it would be great if there were a single standard everyone could implement.
Even if you don't, I think there are some ideas from similar schemes Tor should fold back into its own design, particularly in regard to how certain bits of the private scalar are "clamped". Some discussion of that here:
https://moderncrypto.org/mail-archive/curves/2017/000862.html
tl;dr: clamp the third highest bit of the root scalar to zero (in addition to the bits normally clamped in the non-canonical Ed25519 private scalar), and use 224-bit child scalars.
On Mar 21, 2017 9:47 PM, "Tony Arcieri" bascule@gmail.com wrote:
I'm trying to gauge interest on the IRTF's CFRG mailing list regarding collaborating on a draft for a standard Ed25519 hierarchical derivation / key blinding scheme:
https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA
The post makes several mentions of Tor's work in the space in regard to the next-generation hidden services design.
I think it'd be great if Tor were to collaborate on the design of such a scheme and adopt it for the new hidden services design. I see a lot of convergent evolution in this space and think it would be great if there were a single standard everyone could implement.
Even if you don't, I think there are some ideas from similar schemes Tor should fold back into its own design, particularly in regard to how certain bits of the private scalar are "clamped". Some discussion of that here:
https://moderncrypto.org/mail-archive/curves/2017/000862.html
tl;dr: clamp the third highest bit of the root scalar to zero (in addition to the bits normally clamped in the non-canonical Ed25519 private scalar), and use 224-bit child scalars.
On Wed, Mar 22, 2017 at 6:15 AM, Nick Mathewson nickm@torproject.org wrote:
Hi! I guess we could keep an eye on the process, though I don't know that I'd have much to contribute myself: I'm more of a crypto consumer than a crypto generator. Maybe one of the developers who knows crypto better can join in here?
The main notable points of discussion so far have all been around preserving Ed25519's original "clamping" invariants. I didn't see any discussion of this in the current Tor spec.
As for adoption: we're on track to deploy next generation hidden services some time this year, ideally in the next 4 or 5 months, so the window to converge on a common system is small by standards-body standards.
Yeah, that's a blink of an eye in the IETF timescale. However, I think if you incorporate some feedback into your current design and do end up shipping it before a draft standard undergoes the requisite bikeshedding, the "running code" aspect of Tor using it in the wild will probably help the standard converge around whatever you ship. Worked out for Ed25519 itself, anyway.
On Wed, Mar 22, 2017 at 12:07 PM, Tony Arcieri bascule@gmail.com wrote:
On Wed, Mar 22, 2017 at 6:15 AM, Nick Mathewson nickm@torproject.org wrote:
Hi! I guess we could keep an eye on the process, though I don't know that I'd have much to contribute myself: I'm more of a crypto consumer than a crypto generator. Maybe one of the developers who knows crypto better can join in here?
The main notable points of discussion so far have all been around preserving Ed25519's original "clamping" invariants. I didn't see any discussion of this in the current Tor spec.
As for adoption: we're on track to deploy next generation hidden services some time this year, ideally in the next 4 or 5 months, so the window to converge on a common system is small by standards-body standards.
Yeah, that's a blink of an eye in the IETF timescale. However, I think if you incorporate some feedback into your current design and do end up shipping it before a draft standard undergoes the requisite bikeshedding, the "running code" aspect of Tor using it in the wild will probably help the standard converge around whatever you ship. Worked out for Ed25519 itself, anyway.
Fair enough. My understanding right now is that a bunch of us think this solution looks promising, and will probably be what we build, unless it turns out to be bad or someone comes up with something even better. https://moderncrypto.org/mail-archive/curves/2017/000866.html
Henry, Isis, Ian, George: Would one of you like to join in on the the CFRG thread about this? I'm not sure I'm enough of a cryptographer to be a good advocate here.
Tony Arcieri bascule@gmail.com writes:
I'm trying to gauge interest on the IRTF's CFRG mailing list regarding collaborating on a draft for a standard Ed25519 hierarchical derivation / key blinding scheme:
https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA
The post makes several mentions of Tor's work in the space in regard to the next-generation hidden services design.
I think it'd be great if Tor were to collaborate on the design of such a scheme and adopt it for the new hidden services design. I see a lot of convergent evolution in this space and think it would be great if there were a single standard everyone could implement.
Even if you don't, I think there are some ideas from similar schemes Tor should fold back into its own design, particularly in regard to how certain bits of the private scalar are "clamped". Some discussion of that here:
https://moderncrypto.org/mail-archive/curves/2017/000862.html
tl;dr: clamp the third highest bit of the root scalar to zero (in addition to the bits normally clamped in the non-canonical Ed25519 private scalar), and use 224-bit child scalars.
An update:
After lots of discussions in the Amsterdam Tor meeting, the following approach was suggested for cleansing keys of their torsion components that is more friendly towards hierarchical key-derivation schemes: https://moderncrypto.org/mail-archive/curves/2017/000866.html
However, my current intuition is to just not do this for hidden service ed25519 blinded keys. Those keys are only used for signing descriptors which should be safe to do, and we don't plan to use them for D-H any time soon. If we or some crazy app EVER decides to use those ephemeral keys for key exchange, we would need to use a special DH function that kills the tensor component of keys before using them, as suggested by Trevor here: https://moderncrypto.org/mail-archive/curves/2017/000874.html
Please let me know if you think this is not a good idea!
On Wed, Apr 12, 2017 at 05:57:00PM +0300, George Kadianakis wrote:
An update:
After lots of discussions in the Amsterdam Tor meeting, the following approach was suggested for cleansing keys of their torsion components that is more friendly towards hierarchical key-derivation schemes: https://moderncrypto.org/mail-archive/curves/2017/000866.html
However, my current intuition is to just not do this for hidden service ed25519 blinded keys. Those keys are only used for signing descriptors which should be safe to do, and we don't plan to use them for D-H any time soon. If we or some crazy app EVER decides to use those ephemeral keys for key exchange, we would need to use a special DH function that kills the tensor component of keys before using them, as suggested by Trevor here: https://moderncrypto.org/mail-archive/curves/2017/000874.html
Please let me know if you think this is not a good idea!
You're correct that you don't need to do anything special for signatures, since you created the key yourself.
For DH, the torsion-safe representative method was meant to be a replacement for the "special DH function" you point to at the end of your message. The win of TSR is that, if no one's doing anything dastardly, you get the *same answer* as a regular unmodified DH, but any attempt at a malicious component to a received DH value is silently zeroed out, at basically no extra cost. The method you cite above also has basically no extra cost, but produces a *different* answer, so everyone has to upgrade at once if you've got an already-deployed system. (Which we don't, to be sure.) The method of "explicitly check for a torsion component and fail if there is one" does produce the same answer as plain DH, but has about double the cost of plain DH (though there are some tricks to cut that down a bit).
- Ian
-
George Kadianakis -
Ian Goldberg -
Nick Mathewson -
Nick Mathewson -
Tony Arcieri