[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses
On Sun, Mar 26, 2017 at 09:27:37PM +1100, teor wrote:
>
> > On 26 Jan 2017, at 10:19, teor <teor2345@xxxxxxxxx> 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev