Ian Goldberg iang@cs.uwaterloo.ca writes:
On Mon, Apr 03, 2017 at 04:40:52PM +0100, Alec Muffett wrote:
On 3 Apr 2017 3:48 p.m., "Ian Goldberg" iang@cs.uwaterloo.ca wrote:
The other thing to remember is that didn't we already say that
facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion
and
face-book-gbiy-eqv3-ebtj-nlnt-wyvj-oa2n-7rvp-nnar-yd4a.onion
will mean the same thing? So we're already past the "one (st)ring to rule them all" point?
That's a great point, and I'm definitely interested and in favour of readability.
How about this, though: I know that Tor doesn't want to be in the business of site reputation, but what if (eg) Protonmail offers a Onion "Safe Browsing" extension some day, of known-bad Onions for malware reasons?
That's a quite good motivating example, thanks!
There's quite a gulf between stripping hyphens from a candidate onion address and doing strcmp(), versus either drilling into the candidate address to compute the alternative forms to check against the blacklist, or even requiring the blacklist to be 8x larger?
Yes, that's true. I'm definitely in favour of the "multiply by L (the order of the group) and check that you get the identity element; error with 'malformed address' if you don't" to get rid of the torsion point problem.
Hello again,
this is the second subthread of the AONT thread that grew too big for its own good, and it's about ed25519.
The topic of this subthread is the above ed25519 verification of onion addresses that Ian suggested a few times already.
So the idea is that before you use an onionaddress (as a client or whatever), you should extract its ed25519 pubkey and multiply it by the group order and make sure you get back the identity element to ensure that there are no torsion components to the key.
I'm pretty weak on crypto so I have some questions about this defence:
- Why are we doing this? Are we doing this because if we allow torsion components in the keys, someone could basically create multiple equivalent keys for each legit ed25519 key, using the Z/8Z torsion scalar as the tweak?
Or is the reason to defend against small subgroup attacks? I think not, because from my understanding these attacks mainly apply to DH protocols which is not what we are doing with onion addresses.
- Is this something that we should be doing for _any_ received ed25519 ever, even in other parts of the protocol?
- Should we do this verification also for received x25519 (DH) keys? It seems like RFC7748 is instead suggesting we ensure that the DH output is not all-zeroes. Are these two defences equivalent for our purposes?
Thanks for the help :)
(Also, please let me know if there are any other action items from the AONT thread that I missed.)