Ian Goldberg iang@cs.uwaterloo.ca writes:
On Mon, Apr 03, 2017 at 02:53:17PM +0100, Alec Muffett wrote:
On 3 April 2017 at 13:04, George Kadianakis desnacked@riseup.net 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 <foo>.onion but you can actually use <foo'>.onion or <foo''>.onion which are equivalent" - then someone will somehow leverage that either a) for hackery, or b) for social engineering.
Compare:
- http://017700000001
- 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.
But as I said to Alec in AMS, anyone on the internet can register "facebook.mydomain.com" and have the A record point to the same thing as facebook.com. So there are always alternate names for any given website. TLS, of course, is designed to protect against these shenanigans.
Hey,
sorry for the slow responses to this thread. Got lots of post-meeting backlog to handle, and I'm also working on the various ed25519 stuff.
Specifically, I'm now working on the suggested check of multiplying any received curve25519 point with the group order and ensuring the result is the identity element.
Prop224 *also* (mostly) protects against these shenanigans, because even if there were two onion addresses that resolved to the same pubkey, the daily blinded version incorporates the original onion address (not just the pubkey, right? *Right?*), so the alternate address-with-same-pubkey won't actually point anywhere. However, an adversary can upload a descriptor there; I'm not sure what the implications of that are just now.
Actually, I *don't* think that the blind factor of the derived key incorporates the actual onion address. Citing the proposal:
Let the basepoint be written as B. Assume B has prime order l, so lB=0. Let a master keypair be written as (a,A), where a is the private key and A is the public key (A=aB)
To derive the key for a nonce N and an optional secret s, compute the blinding factor h as H(A | s, B, N), and let:
Perhaps we can add another component to h as follows: h = H(A, s, B, N, ONIONADDRESS) where ONIONADDRESS is a string representation of the service's onion address.
I think this code is already implemented, but this might be worth fixing anyhow. I'll make a ticket.
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?
I don't think we have actually decided on such a feature yet. It was suggested but the tradeoffs are not clearly skewed to the "let's do it" direction.
Cheers!