Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

On 5 April 2017 at 15:11, Ian Goldberg <iang@xxxxxxxxxxxxxxx> wrote:

I believe the danger Alec was wanting to avoid was that someone (not the
onion service owner) could take an existing onion address, bump the
version number (which wouldn't change the vanity beginning of the
address), and upload the very same descriptor to the resulting blinded
address (under the new version number). Then the modified address would
work just like the original.

In a nutshell, yes.

I've been having a discussion with Taylor Campbell off-list, and I wrote:

… let me try something on you:
The year is 2019.
What would _you_ do
in order to surface to the user
that the onion address in front of them,
one with a given public key which they've previously used and trusted before
such that the leftmost 32 bytes, base32 encoded, are familiar to them,
is actually a downgraded version-2 format of address
against which a bug is being exploited by (say) the FBI
rather than the more secure version-3 form which they were expecting and had previously used,
when all of the information pertinent to versions and checksums is at the right-hand-end of the encoded address?
This is basically where I am coming from.
My thinking: Make it brittle. Mix the version (etc) into the represented form so that if one messes with a single bit, one perceptibly impacts the entire string representation of the onion address. How would you attack this?

...and also:

do we want to be teaching users that:
--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5c5bc5, and
--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5d5bc5
...are actually the same thing, but if and only if they differ in the N-5'th character?

...and:

… up front I'll just say that my perspective of this class of threat comes from observations like
a) people are creative, and if you give them malleability they will use it to create onion addresses including embedded "poop-emoji" and the like.
b) people generalise, so that having learned that $SOME_CHARACTER in an onion address is malleable, they will assume that most/all of them are and subsequently fall for phishing attacks.
c) people are, as a group, given the entire Tor prop224 ecosystem, infinitely more creative than I can be at finding ways to exploit it, therefore it makes sense to screw down the crypto to present as small an attack surface as possible.

...and:

An old programmer maxim is that one should provide for Zero, One, or an Infinite number of any resource.
Since we do not desire an infinite number of representations of an onion address (per Roger) - and zero would not be useful, we should shoot for one, and only one.
Not a cryptographic argument, but I think it's a human one. :-)

There's a lot more, but I don't want to bury folk with a huge multi-message e-mail exchange; plus there is a lot of useful context "up-thread". :-)

As mentioned elsewhere in the thread, this is solved if that descriptor
contains (under the signature by the "master" onion key) the actual
onion address you were expected to use to get there. Does it? If so,
I think we don't have to worry about this problem at all.

I hope it does. That sounds very much like what I expect to see in other network stacks. :-)

-a

http://dropsafe.crypticide.com/aboutalecm