On 5 April 2017 at 15:11, Ian Goldberg <i...@cs.uwaterloo.ca> 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