[tor-dev] Proposition: Applying an AONT to Prop224 addresses?
Taylor R Campbell
campbell+tor-dev at mumble.net
Mon Apr 3 18:43:50 UTC 2017
> Date: Sun, 26 Mar 2017 14:24:41 +0200
> From: Alec Muffett <alec.muffett at gmail.com>
> This is a point of significant concern because of issues like phishing and
> passing-off - by analogy: t0rpr0ject.0rg versus torproject.org - and other
> games that can be played with a prop224 address now, or in future, to game
> user experience.
> The result would be onion addresses which are less "tamperable" / more
> deterministic, that closer to one-and-only-one published onion address will
> correspond to an onion endpoint.
> What does the panel think?
What is the threat model an AONT defends against here, and what
security properties do we aim to provide against that threat?
Here are a few candidates. Suppose I own 0123456789deadbeef2.onion,
where 2 is the onion version number.
T1. Adversary does not know 0123456789deadbeef2.onion but controls all
onion service directories.
(SP1) Adversary can't discover 0123456789deadbeef2.onion or thereby
distinguish descriptors for 0123456789deadbeef2.onion from other
descriptors simply by controlling what is in the directories.
-> With or without AONT, since the onion service descriptors are
encrypted, the adversary can't learn their content anyway.
T2. Adversary knows 0123456789deadbeef2.onion and controls all Tor
nodes except for the onion service server and client.
(SP2) Adversary cannot impersonate 0123456789deadbeef2.onion.
-> With or without AONT, adversary can't make onion descriptor
signatures that are verified by the 0123456789deadbeef2.onion
key unless they have broken Ed25519.
(SP3) Adversary cannot impersonate 0123456789deadbeefN.onion for any N
*other* than 2.
-> With or without AONT, if the signature on the onion
descriptor always covers the complete .onion address,
including the version number, the adversary can't do this
without also being able to forge signatures for
0123456789deadbeef2.onion anyway and thus break Ed25519.
(SP4) Adversary cannot DoS 0123456789deadbeef2.onion.
-> With or without AONT, if adversary knows legitimate .onion
address key, they can already remove any onion descriptors
with signatures verified by the .onion address key, even if
the signatures are decrypted. So we can't provide this
security property anyway as long as the adversary knows the
legitimate .onion address.
(a) knows 0123456789deadbeef2.onion,
(b) can spend compute to find a private key whose public key has
some chosen bits, and
(c) can submit descriptors to onion directories.
(SP5) Adversary cannot match all except replacement of l by 1, o by 0, &c.
-> With or without AONT, this confusion is already excluded by
(SP6) Adversary cannot match all except long enough suffix.
-> Finding priv to fix prefix of Ed25519_priv2pub(priv) || cksum
is almost surely just as hard as finding priv to fix prefix
of AONT(Ed25519_priv2pub(priv) || cksum || version) or any
other arrangement of cksum and version.
(This assumes the AONT has low AT cost to evaluate -- but if
you choose an AONT with high AT cost, that will severely
penalize legitimate users of onion services, and also limit
vanity onions to major corporations like Facebook and
So what security properties does an AONT give against what threat
models? I'm probably missing something obvious here, but I expect it
will be helpful to articulate exactly what function it serves, for
More information about the tor-dev