[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses
Ian Goldberg
iang at cs.uwaterloo.ca
Sun Mar 26 10:41:53 UTC 2017
On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote:
>
> > On 26 Jan 2017, at 10:19, teor <teor2345 at gmail.com> wrote:
> >
> >>> onion_address = base32(pubkey || checksum || version)
> >
> > Is the order in which the address is encoded once the checksum is
> > calculated. checksum represents (the first two bytes of) the result of
> > the SHA3 hash.
> >
> > We put pubkey first so that humans can distinguish addresses.
> > (We could put checksum first, but that's non-standard.)
>
> I just talked with some people who run a large onion site.
>
> They asked if we can put the checksum at the front of the encoded
> address.
>
> This makes phishing with different bit(s) in the tail of the address
> much harder. (That is, searching for a matching prefix for an existing
> address is much harder if the checksum changes the first two characters
> unpredictably. People ignore the checksum if it's at the end.)
Wait; why is searching for a matching checksum at the beginning harder
than searching for a matching pubkey? When trying to collide an onion
address, the pubkey is essentially random, as is the checksum.
--
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
More information about the tor-dev
mailing list