> On 20 Sep 2017, at 00:44, George Kadianakis <desnacked@xxxxxxxxxx> wrote: > > Legacy RENDEZVOUS1 cells are bigger than the prop224 ones. The prop224 > spec suggests we pad the new cells so that they look similar in size to > the legacy ones. > > ... > > The suggestion is to pad the prop224 cells to 168 bytes using random data. > > Would that work? My main question is whether the g^y part of the legacy > cell has any distinguishers that could distinguish it from random data. > It's encoded using OpenSSL's BN_bn2bin() and it's a 1024 bit DH public > key. Are there any algebraic or openssl structure distinguishers we > should be worrying about, or is random data sufficient to mask it out? What's the threat model here? I ask because regardless of whether the RENDEZVOUS1 cell plaintext is distinguishable between v2 and v3, the rend point can distinguish v2 and v3 using this one neat trick: * if the service extends using TAP, the protocol is v2 * if the service extends using ntor, the protocol is v3 v2 and v3 are also distinguishable in these cases: * intro points, using the client extend * Tor2web and single onion services, except that they connect directly, then do a TAP or ntor handshake. That said, if you want to make v3 and future (v4+) rend protocols indistinguishable, then it might be a good idea to pad the entire cell with random bytes. That allows future protocols to add fields safely, as long as they are encrypted in a way that is indistinguishable from random. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev