[tor-dev] Action items wrt ed25519 onion address verification in prop224 (was Re: Proposition: Applying an AONT to Prop224 addresses?)

[George Kadianakis]

Ian Goldberg <iang at 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 at 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.)