[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[teor]

> On 26 Jan 2017, at 09:59, Arlo Breault <arlo at torproject.org> wrote:
> 
> 
>> On Jan 24, 2017, at 4:27 AM, George Kadianakis <desnacked at riseup.net> wrote:
>> 
>> onion_address = base32(pubkey || checksum || version)
>> checksum = SHA3(".onion checksum" || pubkey || version)
> 
> Any reason not to have the order of,
> pubkey || checksum || version
> be the same in both?

Yes: ".onion checksum" is not the same as checksum.

>> checksum = SHA3(".onion checksum" || pubkey || version)

Is the standard H(UNIQUE_PREFIX || DATA) construct that resists
hash reuse and rainbow table attacks. ".onion checksum" represents the
bytes from an ASCII-encoded literal string.

Putting those bytes later in the hash opens us up to hash reuse attacks
where the key or version bytes are made to match the prefix from another
hash.

(Every time we do SHA3(... || pubkey || ...) in the hidden service
protocol, we want a prefix that is static and unique, so people can't
use hashes from one part of the protocol to spoof hashes in another part
of the protocol.)

>> 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.)

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170126/28df6eb5/attachment.sig>