On Mon, Apr 03, 2017 at 03:04:47PM +0300, George Kadianakis wrote: > Hey people, > > thanks for the R&D 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