Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 5 April 2017 at 15:11, Ian Goldberg  wrote:

> I believe the danger Alec was wanting to avoid was that someone (not the
> onion service owner) could take an existing onion address, bump the
> version number (which wouldn't change the vanity beginning of the
> address), and upload the very same descriptor to the resulting blinded
> address (under the new version number).  Then the modified address would
> work just like the original.
>


In a nutshell, yes.

I've been having a discussion with Taylor Campbell off-list, and I wrote:

   - *… let me try something on you: *
   -
*The year is 2019.  *
   -
*What would _you_ do  *
   -
*in order to surface to the user  *
   -
*that the onion address in front of them,  *
   -
*one with a given public key which they've previously used and trusted
   before *
   -
*such that the leftmost 32 bytes, base32 encoded, are familiar to them,  *
   -
*is actually a downgraded version-2 format of address *
   -
*against which a bug is being exploited by (say) the FBI *
   -
*rather than the more secure version-3 form which they were expecting and
   had previously used, *
   -
*when all of the information pertinent to versions and checksums is at the
   right-hand-end of the encoded address? *
   - *This is basically where I am coming from.*
   -
*My thinking: Make it brittle. Mix the version (etc) into the represented
   form so that if one messes with a single bit, one perceptibly impacts the
   entire string representation of the onion address. How would you attack
   this? *


...and also:


> *do we want to be teaching users that:*
> *--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5c5bc5, and*
> *--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5d5bc5**...are
> actually the same thing, but if and only if they differ in the N-5'th
> character?*



...and:


> *… up front I'll just say that my perspective of this class of threat
> comes from observations like *
> *a) people are creative, and if you give them malleability they will use
> it to create onion addresses including embedded "poop-emoji" and the like.*
> *b) people generalise, so that having learned that $SOME_CHARACTER in an
> onion address is malleable, they will assume that most/all of them are and
> subsequently fall for phishing attacks.**c) people are, as a group, given
> the entire Tor prop224 ecosystem, infinitely more creative than I can be at
> finding ways to exploit it, therefore it makes sense to screw down the
> crypto to present as small an attack surface as possible.*



...and:


> *An old programmer maxim is that one should provide for Zero, One, or an
> Infinite number of any resource.  *
> *Since we do not desire an infinite number of representations of an onion
> address (per Roger) - and zero would not be useful, we should shoot for
> one, and only one.**Not a cryptographic argument, but I think it's a
> human one.  :-)*


There's a lot more, but I don't want to bury folk with a huge multi-message
e-mail exchange; plus there is a lot of useful context "up-thread".  :-)



> As mentioned elsewhere in the thread, this is solved if that descriptor
> contains (under the signature by the "master" onion key) the actual
> onion address you were expected to use to get there.  Does it?  If so,
> I think we don't have to worry about this problem at all.


I hope it does.  That sounds very much like what I expect to see in other
network stacks.  :-)

-a

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Wed, Apr 05, 2017 at 10:02:07AM -0400, David Goulet wrote:
> Another thing about this I just thought of. This AONT construction seems wise
> to use. But it's still not entirely clear to me why we need a 1bit version
> field. Taking this:
> 
> base64( AONT( pubkey || 0x ) || version)
> 
> If the version is 1 byte, then only the end of the address can be mangled with
> and if it is, the tor client won't be able to fetch the descriptor because of
> how the URL is constructed (correct version number is needed).
> 
> So I really don't see the phishing attack here being successful at all...?
> 
> Can you enlighten what attack we are trying to avoid here that we require a
> 1bit version field?

I believe the danger Alec was wanting to avoid was that someone (not the
onion service owner) could take an existing onion address, bump the
version number (which wouldn't change the vanity beginning of the
address), and upload the very same descriptor to the resulting blinded
address (under the new version number).  Then the modified address would
work just like the original.

As mentioned elsewhere in the thread, this is solved if that descriptor
contains (under the signature by the "master" onion key) the actual
onion address you were expected to use to get there.  Does it?  If so,
I think we don't have to worry about this problem at all.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[David Goulet]

On 05 Apr (09:50:38), David Goulet wrote:
> On 27 Mar (04:58:34), Ian Goldberg wrote:
> > On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote:
> > > > To add an aside from a discussion with Teor: the entire "version" field
> > > > could be reduced to a single - probably "zero" - bit, in a manner 
> > > > perhaps
> > > > similar to the distinctions between Class-A, Class-B, Class-C... 
> > > > addresses
> > > > in old IPv4.
> > > > 
> > > > Thus: if the first bit in the address is zero, then there is no version,
> > > > and we are at version 0 of the format
> > > > 
> > > > If the first bit is one, we are using v1+ of the format and all bets are
> > > > off, except that the obvious thing then to do is count the number of 
> > > > 1-bits
> > > > (up to some limit) and declare that to be version number.  Once we're 
> > > > up to
> > > > 3 or 4 or 7 or 8 one-bits, then shift version encoding totally.
> > > > 
> > > > Teor will correct me if I misquote him, but the advantage here was:
> > > > 
> > > > a) the version number is 1 bit, ie: small, for the forseeable / if we 
> > > > get
> > > > it right
> > > > 
> > > > b) in pursuit of smallness, we could maybe dump the hash in favour of a
> > > > AONT + eyeballs, which would give back a bunch of extra bits
> > > > 
> > > > result: shorter addresses, happier users.
> > > 
> > > You indeed do not require a checksum under an AONT, but you do require
> > > redundancy if you want to catch typos.  Something like
> > > 
> > > base64( AONT( pubkey || 0x ) || version)
> > > 
> > > is fine.  If you want "version" to be a single bit, then the AONT would
> > > have to operate on non-full bytes, which is a bit (ha!) annoying, but
> > > not terrible.  In that case, "0x" would actually be 15 bits of 0,
> > > and version would be 1 bit.  This would only save 1.4 base32 characters,
> > > though.  If you took off some more bits of the redundancy (down to 8
> > > bits?), you would be able to shave one more base32 char.  And indeed, if
> > > you make the redunancy just a single byte of 0x00, then the extra 0-bit
> > > for the "version" actually fits neatly in the one leftover bit of the
> > > base32 encoding, I think, so the AONT is back to working on full bytes.
> > > 
> > > But is a single byte of redundancy enough?  It will let through one out
> > > of every 256 typos.  (I thought we had spec'd 2 bytes for the checkcum
> > > now, but maybe I misremember?  I'm also assuming we're using a simple
> > > 256-bit encoding of the pubkey, rather than something more complex that
> > > saves ~3 bits.)
> > > 
> > > (Heading to the airport.)
> > 
> > OK, here are the details of this variant of the proposal.  Onion
> > addresses are 54 characters in this variant, and the typo-resistance is
> > 13 bits (1/8192 typos are not caught).
> > 
> > Encoding:
> > 
> > raw is a 34-byte array.  Put the ed25519 key into raw[0..31] and 0x
> > into raw[32..33].  Note that there are really only 13 bits of 0's for
> > redundancy, plus the 0 bit for the version, plus 2 unused bits in
> > raw[32..33].
> > 
> > Do the AONT.  Here G is a hash function mapping 16-byte inputs to
> > 18-byte outputs, and H is a hash function mapping 18-byte inputs to
> > 16-byte outputs.  Reasonable implementations would be something like:
> > 
> > G(input) = SHA3-256("Prop224Gv0" || input)[0..17]
> > H(input) = SHA3-256("Prop224Hv0" || input)[0..15]
> > 
> > raw[16..33] ^= G(raw[0..15])
> > # Clear the last few bits, since we really only want 13 bits of redundancy
> > raw[33] &= 0xf8
> > raw[0..15] ^= H(raw[16..33])
> > 
> > Then base32-encode raw[0..33].  The 56-character result will always end
> > in "a=" (the two unused bits at the end of raw[33]), so just remove that
> > part.
> > 
> > Decoding:
> > 
> > Base32-decode the received address into raw[0..33].  Depending on your
> > base32 decoder, you may have to stick the "a=" at the end of the address
> > first.  The low two bits were unused; be sure the base32 decoder sets
> > them to 0.  The next lowest bit (raw[33] & 0x04) is the version bit.
> > Ensure that (raw[33] & 0x04 == 0); if not, this is a different address
> > format version you don't understand.
> 
> I do understand the problem (I think) with the version field being longer than
> a single bit but it kind of causes some problem on the engineering and
> protocol side. Here is why:
> 
> The current plan is to put the HS protocol version in the address because when
> we fetch the descriptor from an HSDir, we use an URL that is on the form of
> "/tor/hs//" where  is the blinded key.

Another thing about this I just thought of. This AONT construction seems wise
to use. But it's still not entirely clear to me why we need a 1bit version
field. Taking this:

base64( AONT( pubkey || 0x ) || version)

If the version is 1 byte, then only the end of the address can be mangled with
and if it is, the tor client won't be able to fetch the descriptor because of
how the URL is constructed (correct 

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[David Goulet]

On 27 Mar (04:58:34), Ian Goldberg wrote:
> On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote:
> > > To add an aside from a discussion with Teor: the entire "version" field
> > > could be reduced to a single - probably "zero" - bit, in a manner perhaps
> > > similar to the distinctions between Class-A, Class-B, Class-C... addresses
> > > in old IPv4.
> > > 
> > > Thus: if the first bit in the address is zero, then there is no version,
> > > and we are at version 0 of the format
> > > 
> > > If the first bit is one, we are using v1+ of the format and all bets are
> > > off, except that the obvious thing then to do is count the number of 
> > > 1-bits
> > > (up to some limit) and declare that to be version number.  Once we're up 
> > > to
> > > 3 or 4 or 7 or 8 one-bits, then shift version encoding totally.
> > > 
> > > Teor will correct me if I misquote him, but the advantage here was:
> > > 
> > > a) the version number is 1 bit, ie: small, for the forseeable / if we get
> > > it right
> > > 
> > > b) in pursuit of smallness, we could maybe dump the hash in favour of a
> > > AONT + eyeballs, which would give back a bunch of extra bits
> > > 
> > > result: shorter addresses, happier users.
> > 
> > You indeed do not require a checksum under an AONT, but you do require
> > redundancy if you want to catch typos.  Something like
> > 
> > base64( AONT( pubkey || 0x ) || version)
> > 
> > is fine.  If you want "version" to be a single bit, then the AONT would
> > have to operate on non-full bytes, which is a bit (ha!) annoying, but
> > not terrible.  In that case, "0x" would actually be 15 bits of 0,
> > and version would be 1 bit.  This would only save 1.4 base32 characters,
> > though.  If you took off some more bits of the redundancy (down to 8
> > bits?), you would be able to shave one more base32 char.  And indeed, if
> > you make the redunancy just a single byte of 0x00, then the extra 0-bit
> > for the "version" actually fits neatly in the one leftover bit of the
> > base32 encoding, I think, so the AONT is back to working on full bytes.
> > 
> > But is a single byte of redundancy enough?  It will let through one out
> > of every 256 typos.  (I thought we had spec'd 2 bytes for the checkcum
> > now, but maybe I misremember?  I'm also assuming we're using a simple
> > 256-bit encoding of the pubkey, rather than something more complex that
> > saves ~3 bits.)
> > 
> > (Heading to the airport.)
> 
> OK, here are the details of this variant of the proposal.  Onion
> addresses are 54 characters in this variant, and the typo-resistance is
> 13 bits (1/8192 typos are not caught).
> 
> Encoding:
> 
> raw is a 34-byte array.  Put the ed25519 key into raw[0..31] and 0x
> into raw[32..33].  Note that there are really only 13 bits of 0's for
> redundancy, plus the 0 bit for the version, plus 2 unused bits in
> raw[32..33].
> 
> Do the AONT.  Here G is a hash function mapping 16-byte inputs to
> 18-byte outputs, and H is a hash function mapping 18-byte inputs to
> 16-byte outputs.  Reasonable implementations would be something like:
> 
> G(input) = SHA3-256("Prop224Gv0" || input)[0..17]
> H(input) = SHA3-256("Prop224Hv0" || input)[0..15]
> 
> raw[16..33] ^= G(raw[0..15])
> # Clear the last few bits, since we really only want 13 bits of redundancy
> raw[33] &= 0xf8
> raw[0..15] ^= H(raw[16..33])
> 
> Then base32-encode raw[0..33].  The 56-character result will always end
> in "a=" (the two unused bits at the end of raw[33]), so just remove that
> part.
> 
> Decoding:
> 
> Base32-decode the received address into raw[0..33].  Depending on your
> base32 decoder, you may have to stick the "a=" at the end of the address
> first.  The low two bits were unused; be sure the base32 decoder sets
> them to 0.  The next lowest bit (raw[33] & 0x04) is the version bit.
> Ensure that (raw[33] & 0x04 == 0); if not, this is a different address
> format version you don't understand.

I do understand the problem (I think) with the version field being longer than
a single bit but it kind of causes some problem on the engineering and
protocol side. Here is why:

The current plan is to put the HS protocol version in the address because when
we fetch the descriptor from an HSDir, we use an URL that is on the form of
"/tor/hs//" where  is the blinded key.

The reason we put the version number in the URL like the in the above is
because we might NOT use a 32 bytes key in future version when looking up the
descriptor so the version tells us what  is. Second, imagine a world in few
years where we have v3, v4 and v5 all living happily together and the
addresses are all 54 characters. On the client side, it would be really not
good that we do a fetch for all possible version and see which one works thus
having the version in the address prevents that.

I get that the solution to "which version to look up" with this proposed
change is that if v3 address, the version bit is 0, else if that bit is 1, try
decode v4. Then repeat 

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Taylor R Campbell]

> Date: Sun, 26 Mar 2017 14:24:41 +0200
> From: Alec Muffett 
> 
> 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.

T3. Adversary
(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, 
  -> With or without AONT, this confusion is already excluded by
 base32 encoding.
(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
 Google.)

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
future readers.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Roger Dingledine]

On Mon, Apr 03, 2017 at 10:48:26AM -0400, Ian Goldberg wrote:
> The other thing to remember is that didn't we already say that
> 
> facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion
> 
> and
> 
> face-book-gbiy-eqv3-ebtj-nlnt-wyvj-oa2n-7rvp-nnar-yd4a.onion
> 
> will mean the same thing?

Did we? I admit that I haven't been paying enough attention to anything
lately, but last I checked, we thought that was a terrible idea because
people can make a bunch of different versions of the address, and use
them as tracking mechanisms for users. (For example, I put two versions
of the same address on my two different pages, and now when somebody goes
to that onion address, I can distinguish which page they came from. In
the extreme versions of this idea, I give a unique version of my address
to the target, and then I can spot him when he uses it.)

Ultimately the problem is that the browser is too good at giving away
the hostname that it thinks it's going to -- in various headers, in
cross-site isolation, etc etc.

So, if we have indeed decided to allow many versions of format for
onion addresses, I hope we thought through this attack and decided it
was worth it. :)

--Roger

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

Following the Layer-2 Addressing analogy means that Ian, here:


> If the daily descriptor uploaded to the point
>> Hash(onionaddr, dailyrand) contained Hash(onionaddr, dailyrand) *in* it
>> (and is signed by the master onion privkey, of course), then tor
>> could/should check that it reached that location through the "right"
>> onion address.
>
>
…has essentially just invented what Solaris (for one) calls "IP Strict
Destination Multihoming":

  http://www.informit.com/articles/article.aspx?p=101138=4

-a :-)


-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 3 April 2017 at 16:59, Ian Goldberg  wrote:

> How about this, though: I know that Tor doesn't want to be in the business
> > of site reputation, but what if (eg) Protonmail offers a Onion "Safe
> > Browsing" extension some day, of known-bad Onions for malware reasons?


> That's a quite good motivating example, thanks!


#Yay; I'm also thinking of other plugins (in the cleartext world,
HTTPSEverywhere is the best example) which provide value to the user by
mechanically mutating URIs which match some canonical DNS domain name;
because Onion addresses are more like Layer-2 addresses*, development of
similar plugins benefits greatly from enforced "canonicality" (sp?) than is
necessary for equally-functional DNS equivalents; there is no means to
"group" three disparate Onion addresses together just-because they are all
owned by (say: Facebook), and if each address has 8 possible
representations then that's 24 rules to match against...


> There's quite a gulf between stripping hyphens from a candidate onion
> > address and doing strcmp(), versus either drilling into the candidate
> > address to compute the alternative forms to check against the blacklist,
> or
> > even requiring the blacklist to be 8x larger?
>
> Yes, that's true.  I'm definitely in favour of the "multiply by L (the
> order of the group) and check that you get the identity element; error
> with 'malformed address' if you don't" to get rid of the torsion point
> problem.
>

I heard that and AMS and it sounds a fabulous idea, although I am still too
much of an EC noob to appreciate it fully. :-)


If the daily descriptor uploaded to the point
> Hash(onionaddr, dailyrand) contained Hash(onionaddr, dailyrand) *in* it
> (and is signed by the master onion privkey, of course), then tor
> could/should check that it reached that location through the "right"
> onion address.
>

That sounds great, and I think it sounds an appropriate response, but again
I am a Prop224 and EC noob. :-)

I would like, for two paragraph, to go entirely off-piste and ask a
possibly irrelevant and probably wrong-headed question:

/* BEGIN PROBABLY WRONG SECTION */
I view Onions as Layer-2 addresses, and one popular attack on Ethernet
Layer 2 is ARP-spoofing.  Imagine $STATE_ACTOR exfiltrates the private key
material from $ONIONSITE and wants to silently and partially MITM the
existing site without wholesale owning or tampering with it. Can they make
any benefit from multiple ("hardware MAC-address") keys colliding to one
address? Is there any greater benefit to $STATE_ACTOR from this than (say)
publishing lots of fake/extra introduction points for $ONIONSITE and using
those to interpose themselves into communications?
/* END PROBABLY WRONG SECTION */


I'm afraid the details of what's in that daily descriptor are not in my
> brain at the moment.  Does it contain its own (daily blinded) name under
> the signature?
>

  George?

  -a

--
* Layer-2 analogy: https://twitter.com/AlecMuffett/status/802161730591793152


-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Mon, Apr 03, 2017 at 04:40:52PM +0100, Alec Muffett wrote:
> On 3 Apr 2017 3:48 p.m., "Ian Goldberg"  wrote:
> 
> The other thing to remember is that didn't we already say that
> 
> facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion
> 
> and
> 
> face-book-gbiy-eqv3-ebtj-nlnt-wyvj-oa2n-7rvp-nnar-yd4a.onion
> 
> will mean the same thing?  So we're already past the "one (st)ring to
> rule them all" point?
> 
> 
> That's a great point, and I'm definitely interested and in favour of
> readability.
> 
> How about this, though: I know that Tor doesn't want to be in the business
> of site reputation, but what if (eg) Protonmail offers a Onion "Safe
> Browsing" extension some day, of known-bad Onions for malware reasons?

That's a quite good motivating example, thanks!

> There's quite a gulf between stripping hyphens from a candidate onion
> address and doing strcmp(), versus either drilling into the candidate
> address to compute the alternative forms to check against the blacklist, or
> even requiring the blacklist to be 8x larger?

Yes, that's true.  I'm definitely in favour of the "multiply by L (the
order of the group) and check that you get the identity element; error
with 'malformed address' if you don't" to get rid of the torsion point
problem.

If the daily descriptor uploaded to the point
Hash(onionaddr, dailyrand) contained Hash(onionaddr, dailyrand) *in* it
(and is signed by the master onion privkey, of course), then tor
could/should check that it reached that location through the "right"
onion address.

I'm afraid the details of what's in that daily descriptor are not in my
brain at the moment.  Does it contain its own (daily blinded) name under
the signature?

   - Ian
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 3 Apr 2017 3:48 p.m., "Ian Goldberg"  wrote:

The other thing to remember is that didn't we already say that

facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion

and

face-book-gbiy-eqv3-ebtj-nlnt-wyvj-oa2n-7rvp-nnar-yd4a.onion

will mean the same thing?  So we're already past the "one (st)ring to
rule them all" point?


That's a great point, and I'm definitely interested and in favour of
readability.

How about this, though: I know that Tor doesn't want to be in the business
of site reputation, but what if (eg) Protonmail offers a Onion "Safe
Browsing" extension some day, of known-bad Onions for malware reasons?

There's quite a gulf between stripping hyphens from a candidate onion
address and doing strcmp(), versus either drilling into the candidate
address to compute the alternative forms to check against the blacklist, or
even requiring the blacklist to be 8x larger?

-a
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 3 April 2017 at 13:04, George Kadianakis  wrote:

> I'm calling it weird because I'm not sure how an
> attacker can profit from being able to provide two addresses that
> correspond to the same key, but I can probably come up with a few
> scenarios if I think about it.


Hi George!

I'll agree it's a weird edge case :-)

I think the reason my spider-sense is tingling is because years of cleaning
up after intrusions has taught me that sysadmins and human beings are very
bad at non-canonical address formats, especially where they combine them
with either blacklisting, or else case-statements-with-default-conditions.

If one creates scope for saying "the address is .onion but you can
actually use .onion or .onion which are equivalent" - then
someone will somehow leverage that either a) for hackery, or b) for social
engineering.

Compare:

* http://01770001
* http://2130706433
* http://0177.0.0.1  <- this one tends to surprise people
* http://127.0.0.1

…and the sort of fun shenanigans that can be done with those "equivalent
forms"

People who've been trained not to type [X] into their browser, might be
convinced to type [X']

It's a lot easier for people to cope with there being one-and-only-one
viable form for any given hostname or address-representation.

-a

 --
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Mon, Apr 03, 2017 at 03:04:47PM +0300, George Kadianakis wrote:
> Hey people,
> 
> thanks for the R here. I'm currently trying to balance the tradeoffs
> here and decide whether to go ahead and implement this feature.
> 
> My main worry is the extra complexity this brings to our address
> encoding/decoding process and to our speficication, as well as when
> explaining the scheme to people.
> 
> Other than that, this seems like a reasonable improvement for a weird
> phishing scenario. I'm calling it weird because I'm not sure how an
> attacker can profit from being able to provide two addresses that
> correspond to the same key, but I can probably come up with a few
> scenarios if I think about it. Furthermore, this solution assumes a
> sloppy victim that does a partial spot-check (if the victim verified the
> whole address this design would make no difference).
> 
> BTW, isn't this phishing threat also possible in bitcoin (which is also
> using a 4-byte checksum that can be bruteforced)? Have there been any
> attacks of this nature?
> 
> Anyhow my first intuition is to just do this, as it seems like an
> improvement and it's probably not a huge amount of work. It can probably
> be done pretty cleanly if we abstract away the whole AONT construction
> and the custom-ish base32 encoding/decoding. I'm just worrying about
> putting more stuff in our already overloaded development bucket.
> 
> Is there a name for this AONT construction btw?

As my student Nik noticed, this isn't *technically* an AONT, since
diffusion only happens "to the left", but that's where we want to
randomize things if any bit of the address changes.

But if we're down to just pubkey + checksum + *1 bit of version*, then
I'm not totally sold on the point of the AONT, since there are exactly 0
bits that can be twiddled while not changing the pubkey.  *Note*: this
is assuming that if we ever change the version number, *then* we do an
AONT or something so that version 0 and version 1 addresses that have
the same pubkey end up looking totally different (at least at the left
end).
-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[George Kadianakis]

Ian Goldberg  writes:

> On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote:
>> > To add an aside from a discussion with Teor: the entire "version" field
>> > could be reduced to a single - probably "zero" - bit, in a manner perhaps
>> > similar to the distinctions between Class-A, Class-B, Class-C... addresses
>> > in old IPv4.
>> > 
>> > Thus: if the first bit in the address is zero, then there is no version,
>> > and we are at version 0 of the format
>> > 
>> > If the first bit is one, we are using v1+ of the format and all bets are
>> > off, except that the obvious thing then to do is count the number of 1-bits
>> > (up to some limit) and declare that to be version number.  Once we're up to
>> > 3 or 4 or 7 or 8 one-bits, then shift version encoding totally.
>> > 
>> > Teor will correct me if I misquote him, but the advantage here was:
>> > 
>> > a) the version number is 1 bit, ie: small, for the forseeable / if we get
>> > it right
>> > 
>> > b) in pursuit of smallness, we could maybe dump the hash in favour of a
>> > AONT + eyeballs, which would give back a bunch of extra bits
>> > 
>> > result: shorter addresses, happier users.
>> 
>> You indeed do not require a checksum under an AONT, but you do require
>> redundancy if you want to catch typos.  Something like
>> 
>> base64( AONT( pubkey || 0x ) || version)
>> 
>> is fine.  If you want "version" to be a single bit, then the AONT would
>> have to operate on non-full bytes, which is a bit (ha!) annoying, but
>> not terrible.  In that case, "0x" would actually be 15 bits of 0,
>> and version would be 1 bit.  This would only save 1.4 base32 characters,
>> though.  If you took off some more bits of the redundancy (down to 8
>> bits?), you would be able to shave one more base32 char.  And indeed, if
>> you make the redunancy just a single byte of 0x00, then the extra 0-bit
>> for the "version" actually fits neatly in the one leftover bit of the
>> base32 encoding, I think, so the AONT is back to working on full bytes.
>> 
>> But is a single byte of redundancy enough?  It will let through one out
>> of every 256 typos.  (I thought we had spec'd 2 bytes for the checkcum
>> now, but maybe I misremember?  I'm also assuming we're using a simple
>> 256-bit encoding of the pubkey, rather than something more complex that
>> saves ~3 bits.)
>> 
>> (Heading to the airport.)
>
> OK, here are the details of this variant of the proposal.  Onion
> addresses are 54 characters in this variant, and the typo-resistance is
> 13 bits (1/8192 typos are not caught).
>
> Encoding:
>
> raw is a 34-byte array.  Put the ed25519 key into raw[0..31] and 0x
> into raw[32..33].  Note that there are really only 13 bits of 0's for
> redundancy, plus the 0 bit for the version, plus 2 unused bits in
> raw[32..33].
>
> Do the AONT.  Here G is a hash function mapping 16-byte inputs to
> 18-byte outputs, and H is a hash function mapping 18-byte inputs to
> 16-byte outputs.  Reasonable implementations would be something like:
>
> G(input) = SHA3-256("Prop224Gv0" || input)[0..17]
> H(input) = SHA3-256("Prop224Hv0" || input)[0..15]
>
> raw[16..33] ^= G(raw[0..15])
> # Clear the last few bits, since we really only want 13 bits of redundancy
> raw[33] &= 0xf8
> raw[0..15] ^= H(raw[16..33])
>
> Then base32-encode raw[0..33].  The 56-character result will always end
> in "a=" (the two unused bits at the end of raw[33]), so just remove that
> part.
>
> Decoding:
>
> Base32-decode the received address into raw[0..33].  Depending on your
> base32 decoder, you may have to stick the "a=" at the end of the address
> first.  The low two bits were unused; be sure the base32 decoder sets
> them to 0.  The next lowest bit (raw[33] & 0x04) is the version bit.
> Ensure that (raw[33] & 0x04 == 0); if not, this is a different address
> format version you don't understand.
>
> Undo the AONT:
>
> raw[0..15] ^= H(raw[16..33])
> raw[16..33] ^= G(raw[0..15])
> # Clear the last few bits, as above
> raw[33] &= 0xf8
>
> Check the redundancy by ensuring that raw[32..33] = 0x.  If not,
> there was a typo in the address.  (Note again that since we explicitly
> cleared the low 3 bits of raw[33], there are really only 13 bits of
> checking here.)
>
> raw[0..31] is then the pubkey suitable for use in Ed25519.  As before
> (and independently of the AONT stuff), you could sanity-check it to make
> sure that (a) it is not the identity element, and (b) L times it *is*
> the identity element.  (L is the order of the Ed25519 group.)  Checking
> (a) is important; checking (b) isn't strictly necessary for the reasons
> given before, but is still a sensible thing to do.  If you don't check
> (b), you actually have to check in (a) that the pubkey isn't one of 8
> bad values, not just the identity.  So just go ahead and check (b) to
> rest easier. ;-)
>
>
> This version contains two calls to SHA3, as opposed to the one such call
> in the non-AONT (but including a checksum) version.  The 

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote:
> > To add an aside from a discussion with Teor: the entire "version" field
> > could be reduced to a single - probably "zero" - bit, in a manner perhaps
> > similar to the distinctions between Class-A, Class-B, Class-C... addresses
> > in old IPv4.
> > 
> > Thus: if the first bit in the address is zero, then there is no version,
> > and we are at version 0 of the format
> > 
> > If the first bit is one, we are using v1+ of the format and all bets are
> > off, except that the obvious thing then to do is count the number of 1-bits
> > (up to some limit) and declare that to be version number.  Once we're up to
> > 3 or 4 or 7 or 8 one-bits, then shift version encoding totally.
> > 
> > Teor will correct me if I misquote him, but the advantage here was:
> > 
> > a) the version number is 1 bit, ie: small, for the forseeable / if we get
> > it right
> > 
> > b) in pursuit of smallness, we could maybe dump the hash in favour of a
> > AONT + eyeballs, which would give back a bunch of extra bits
> > 
> > result: shorter addresses, happier users.
> 
> You indeed do not require a checksum under an AONT, but you do require
> redundancy if you want to catch typos.  Something like
> 
> base64( AONT( pubkey || 0x ) || version)
> 
> is fine.  If you want "version" to be a single bit, then the AONT would
> have to operate on non-full bytes, which is a bit (ha!) annoying, but
> not terrible.  In that case, "0x" would actually be 15 bits of 0,
> and version would be 1 bit.  This would only save 1.4 base32 characters,
> though.  If you took off some more bits of the redundancy (down to 8
> bits?), you would be able to shave one more base32 char.  And indeed, if
> you make the redunancy just a single byte of 0x00, then the extra 0-bit
> for the "version" actually fits neatly in the one leftover bit of the
> base32 encoding, I think, so the AONT is back to working on full bytes.
> 
> But is a single byte of redundancy enough?  It will let through one out
> of every 256 typos.  (I thought we had spec'd 2 bytes for the checkcum
> now, but maybe I misremember?  I'm also assuming we're using a simple
> 256-bit encoding of the pubkey, rather than something more complex that
> saves ~3 bits.)
> 
> (Heading to the airport.)

OK, here are the details of this variant of the proposal.  Onion
addresses are 54 characters in this variant, and the typo-resistance is
13 bits (1/8192 typos are not caught).

Encoding:

raw is a 34-byte array.  Put the ed25519 key into raw[0..31] and 0x
into raw[32..33].  Note that there are really only 13 bits of 0's for
redundancy, plus the 0 bit for the version, plus 2 unused bits in
raw[32..33].

Do the AONT.  Here G is a hash function mapping 16-byte inputs to
18-byte outputs, and H is a hash function mapping 18-byte inputs to
16-byte outputs.  Reasonable implementations would be something like:

G(input) = SHA3-256("Prop224Gv0" || input)[0..17]
H(input) = SHA3-256("Prop224Hv0" || input)[0..15]

raw[16..33] ^= G(raw[0..15])
# Clear the last few bits, since we really only want 13 bits of redundancy
raw[33] &= 0xf8
raw[0..15] ^= H(raw[16..33])

Then base32-encode raw[0..33].  The 56-character result will always end
in "a=" (the two unused bits at the end of raw[33]), so just remove that
part.

Decoding:

Base32-decode the received address into raw[0..33].  Depending on your
base32 decoder, you may have to stick the "a=" at the end of the address
first.  The low two bits were unused; be sure the base32 decoder sets
them to 0.  The next lowest bit (raw[33] & 0x04) is the version bit.
Ensure that (raw[33] & 0x04 == 0); if not, this is a different address
format version you don't understand.

Undo the AONT:

raw[0..15] ^= H(raw[16..33])
raw[16..33] ^= G(raw[0..15])
# Clear the last few bits, as above
raw[33] &= 0xf8

Check the redundancy by ensuring that raw[32..33] = 0x.  If not,
there was a typo in the address.  (Note again that since we explicitly
cleared the low 3 bits of raw[33], there are really only 13 bits of
checking here.)

raw[0..31] is then the pubkey suitable for use in Ed25519.  As before
(and independently of the AONT stuff), you could sanity-check it to make
sure that (a) it is not the identity element, and (b) L times it *is*
the identity element.  (L is the order of the Ed25519 group.)  Checking
(a) is important; checking (b) isn't strictly necessary for the reasons
given before, but is still a sensible thing to do.  If you don't check
(b), you actually have to check in (a) that the pubkey isn't one of 8
bad values, not just the identity.  So just go ahead and check (b) to
rest easier. ;-)


This version contains two calls to SHA3, as opposed to the one such call
in the non-AONT (but including a checksum) version.  The benefit is
Alec's (and others') desire that there cannot be any bits an attacker
could twiddle that would leave both the key the same and the address
looking OK to somone who just spot-checks say the 

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Mon, Mar 27, 2017 at 12:27:33AM +0200, Alec Muffett wrote:
> >
> > We could leave the version field outside the AONT, though, but commit to
> > changing the paramaters of the AONT (in particular, the domain
> > separation constant?) if we change the version number, so that an
> > adversary changing the version number to "2" would just cause the client
> > to throw an error (before version 2 exists) or be an invalid address
> > (after version 2 exists)?
> 
> 
> To add an aside from a discussion with Teor: the entire "version" field
> could be reduced to a single - probably "zero" - bit, in a manner perhaps
> similar to the distinctions between Class-A, Class-B, Class-C... addresses
> in old IPv4.
> 
> Thus: if the first bit in the address is zero, then there is no version,
> and we are at version 0 of the format
> 
> If the first bit is one, we are using v1+ of the format and all bets are
> off, except that the obvious thing then to do is count the number of 1-bits
> (up to some limit) and declare that to be version number.  Once we're up to
> 3 or 4 or 7 or 8 one-bits, then shift version encoding totally.
> 
> Teor will correct me if I misquote him, but the advantage here was:
> 
> a) the version number is 1 bit, ie: small, for the forseeable / if we get
> it right
> 
> b) in pursuit of smallness, we could maybe dump the hash in favour of a
> AONT + eyeballs, which would give back a bunch of extra bits
> 
> result: shorter addresses, happier users.

You indeed do not require a checksum under an AONT, but you do require
redundancy if you want to catch typos.  Something like

base64( AONT( pubkey || 0x ) || version)

is fine.  If you want "version" to be a single bit, then the AONT would
have to operate on non-full bytes, which is a bit (ha!) annoying, but
not terrible.  In that case, "0x" would actually be 15 bits of 0,
and version would be 1 bit.  This would only save 1.4 base32 characters,
though.  If you took off some more bits of the redundancy (down to 8
bits?), you would be able to shave one more base32 char.  And indeed, if
you make the redunancy just a single byte of 0x00, then the extra 0-bit
for the "version" actually fits neatly in the one leftover bit of the
base32 encoding, I think, so the AONT is back to working on full bytes.

But is a single byte of redundancy enough?  It will let through one out
of every 256 typos.  (I thought we had spec'd 2 bytes for the checkcum
now, but maybe I misremember?  I'm also assuming we're using a simple
256-bit encoding of the pubkey, rather than something more complex that
saves ~3 bits.)

(Heading to the airport.)
-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

>
> We could leave the version field outside the AONT, though, but commit to
> changing the paramaters of the AONT (in particular, the domain
> separation constant?) if we change the version number, so that an
> adversary changing the version number to "2" would just cause the client
> to throw an error (before version 2 exists) or be an invalid address
> (after version 2 exists)?


To add an aside from a discussion with Teor: the entire "version" field
could be reduced to a single - probably "zero" - bit, in a manner perhaps
similar to the distinctions between Class-A, Class-B, Class-C... addresses
in old IPv4.

Thus: if the first bit in the address is zero, then there is no version,
and we are at version 0 of the format

If the first bit is one, we are using v1+ of the format and all bets are
off, except that the obvious thing then to do is count the number of 1-bits
(up to some limit) and declare that to be version number.  Once we're up to
3 or 4 or 7 or 8 one-bits, then shift version encoding totally.

Teor will correct me if I misquote him, but the advantage here was:

a) the version number is 1 bit, ie: small, for the forseeable / if we get
it right

b) in pursuit of smallness, we could maybe dump the hash in favour of a
AONT + eyeballs, which would give back a bunch of extra bits

result: shorter addresses, happier users.

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Sun, Mar 26, 2017 at 04:19:58PM -0400, Ian Goldberg wrote:
> On Sun, Mar 26, 2017 at 02:24:41PM +0200, Alec Muffett wrote:
> > Hi,
> > 
> > So: a bunch of us were discussing Prop224 Onion addresses, and their
> > UX-malleability.
> > 
> > Specifically: that there are small bit fields in the current Prop224 Onion
> > Address schema (eg: version, and other future structure?) which can be
> > tweaked or amended without otherwise changing the functionality of the
> > address, or without much changing what the user sees in the (say) browser
> > address bar.
> > 
> > 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.
> > 
> > We discussed the existing "hash the public key before base-32 encoding"
> > approach, but hashing breaks the prop224 key blinding.
> > 
> > Ian Goldberg - thank you Ian - offered this attractive solution: apply a
> > *reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion
> > Address, prior to Base32 Encoding.
> > 
> > This way, even a single-bit mutation of (say) version number will have a
> > "diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and
> > being reversible so as not to impact the rest of Prop224.
> > 
> > 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?
> 
> One thing I thought of later is that, assuming the version field is
> "under" the AONT, then there is *no* visible version field in the final
> address, so you would have to commit to "For any possible future onion
> address of this fixed length, the first thing you have to do to decode
> it is this particular AONT."  This seems a bit suboptimal to me.  And
> since the version field basically *is* the tweakable field in the
> current prop224 addresses, maybe this actually isn't so useful after
> all for this version of the spec?



We could leave the version field outside the AONT, though, but commit to
changing the paramaters of the AONT (in particular, the domain
separation constant?) if we change the version number, so that an
adversary changing the version number to "2" would just cause the client
to throw an error (before version 2 exists) or be an invalid address
(after version 2 exists)?

Then the address would look something like:

base32( AONT_1( pubkey || checksum ) || version=0x01 )

where AONT_1 is an unkeyed invertible function from 34(?)-byte strings
to 34(?)-byte strings.

(Of course, then all addresses would end in "b", or something like
that.)


-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Sun, Mar 26, 2017 at 02:24:41PM +0200, Alec Muffett wrote:
> Hi,
> 
> So: a bunch of us were discussing Prop224 Onion addresses, and their
> UX-malleability.
> 
> Specifically: that there are small bit fields in the current Prop224 Onion
> Address schema (eg: version, and other future structure?) which can be
> tweaked or amended without otherwise changing the functionality of the
> address, or without much changing what the user sees in the (say) browser
> address bar.
> 
> 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.
> 
> We discussed the existing "hash the public key before base-32 encoding"
> approach, but hashing breaks the prop224 key blinding.
> 
> Ian Goldberg - thank you Ian - offered this attractive solution: apply a
> *reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion
> Address, prior to Base32 Encoding.
> 
> This way, even a single-bit mutation of (say) version number will have a
> "diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and
> being reversible so as not to impact the rest of Prop224.
> 
> 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?

One thing I thought of later is that, assuming the version field is
"under" the AONT, then there is *no* visible version field in the final
address, so you would have to commit to "For any possible future onion
address of this fixed length, the first thing you have to do to decode
it is this particular AONT."  This seems a bit suboptimal to me.  And
since the version field basically *is* the tweakable field in the
current prop224 addresses, maybe this actually isn't so useful after
all for this version of the spec?
-- 
Ian Goldberg
Professor and University Research Chair
Cheriton School of Computer Science
University of Waterloo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

Hi,

So: a bunch of us were discussing Prop224 Onion addresses, and their
UX-malleability.

Specifically: that there are small bit fields in the current Prop224 Onion
Address schema (eg: version, and other future structure?) which can be
tweaked or amended without otherwise changing the functionality of the
address, or without much changing what the user sees in the (say) browser
address bar.

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.

We discussed the existing "hash the public key before base-32 encoding"
approach, but hashing breaks the prop224 key blinding.

Ian Goldberg - thank you Ian - offered this attractive solution: apply a
*reversible* "All Or Nothing Transform" (AONT) to the entire Prop224 Onion
Address, prior to Base32 Encoding.

This way, even a single-bit mutation of (say) version number will have a
"diffusion" effect, impacting ~ N/2 of the bits whilst having O(1) cost and
being reversible so as not to impact the rest of Prop224.

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?

- alec

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev