[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