<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 April 2017 at 15:11, Ian Goldberg <span dir="ltr"><<a href="mailto:iang@cs.uwaterloo.ca" target="_blank">iang@cs.uwaterloo.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I believe the danger Alec was wanting to avoid was that someone (not the<br>
onion service owner) could take an existing onion address, bump the<br>
version number (which wouldn't change the vanity beginning of the<br>
address), and upload the very same descriptor to the resulting blinded<br>
address (under the new version number).  Then the modified address would<br>
work just like the original.<br></blockquote><div><br></div><div><br></div><div>In a nutshell, yes. </div><div><br></div><div>I've been having a discussion with Taylor Campbell off-list, and I wrote:</div><div><div class="gmail_extra" style="font-size:12.8px"><ul><li><i style="font-size:12.8px">… let me try something on you: </i><br></li><li style="margin-left:15px"><i>The year is 2019. <br></i></li><li style="margin-left:15px"><i>What would _you_ do <br></i></li><li style="margin-left:15px"><i>in order to surface to the user <br></i></li><li style="margin-left:15px"><i>that the onion address in front of them, <br></i></li><li style="margin-left:15px"><i>one with a given public key which they've previously used and trusted before<br></i></li><li style="margin-left:15px"><i>such that the leftmost 32 bytes, base32 encoded, are familiar to them, <br></i></li><li style="margin-left:15px"><i>is actually a downgraded version-2 format of address<br></i></li><li style="margin-left:15px"><i>against which a bug is being exploited by (say) the FBI<br></i></li><li style="margin-left:15px"><i>rather than the more secure version-3 form which they were expecting and had previously used,<br></i></li><li style="margin-left:15px"><i>when all of the information pertinent to versions and checksums is at the right-hand-end of the encoded address?<br></i></li><li><i style="font-size:12.8px">This is basically where I am coming from.</i><br></li><li><i style="font-size:12.8px"><div class="gmail_extra" style="font-size:12.8px"><div class="gmail_extra">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. <i style="font-size:12.8px"><div class="gmail_extra" style="font-size:12.8px;display:inline"><div class="gmail_extra" style="display:inline"><i style="font-size:12.8px"><div class="gmail_extra" style="font-size:12.8px;display:inline">How would you attack this?</div></i></div></div></i></div></div><div class="gmail-yj6qo gmail-ajU" style="font-size:12.8px"></div></i></li></ul></div></div><div><br></div><div>...and also:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><i>do we want to be teaching users that:<br></i><i>--- eh2tndsmiher4dqv266z5ii2xkt6br<wbr>x2llwliq3jim233e5c5bc5, and<br></i><i>--- eh2tndsmiher4dqv266z5ii2xkt6br<wbr>x2llwliq3jim233e5d5bc5<br></i><i>...are actually the same thing, but if and only if they differ in the N-5'th character?</i></blockquote></div><div><br></div><div><br></div><div>...and:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><i>… up front I'll just say that my perspective of this class of threat comes from observations like <br></i><i>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.<br></i><i>b) people generalise, so that having learned that <font face="monospace, monospace">$SOME_CHARACTER</font> in an onion address is malleable, they will assume that most/all of them are and subsequently fall for phishing attacks.<br></i><i>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.</i></blockquote><div><br></div><div><br></div><span class="gmail-im" style="font-size:12.8px"></span></div><div>...and:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><i>An old programmer maxim is that one should provide for Zero, One, or an Infinite number of any resource.  <br></i><i>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.<br></i><i>Not a cryptographic argument, but I think it's a human one.  :-)</i></blockquote><div class="gmail-yj6qo gmail-ajU" style="font-size:12.8px"></div></div><div><br></div><div>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".  :-)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As mentioned elsewhere in the thread, this is solved if that descriptor<br>
contains (under the signature by the "master" onion key) the actual<br>
onion address you were expected to use to get there.  Does it?  If so,<br>
I think we don't have to worry about this problem at all.</blockquote><div><br></div><div>I hope it does.  That sounds very much like what I expect to see in other network stacks.  :-)</div><div><br></div><div>    -a </div></div><div><br></div>-- <br><div class="gmail_signature"><a href="http://dropsafe.crypticide.com/aboutalecm" target="_blank">http://dropsafe.crypticide.com/aboutalecm</a><br></div>
</div></div>