Padding prop224 REND1 cells to blend them with legacy cells
Hello Ian, (and other cryptographers on the list) here is a quick question which you might be able to answer super fast: 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. Here is how the legacy ones look like: RC Rendezvous cookie [20 octets] g^y Diffie-Hellman [128 octets] KH Handshake digest [20 octets] Here is how the prop224 ones look like: RENDEZVOUS_COOKIE [20 bytes] HANDSHAKE_INFO [64 bytes] 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? Thanks!!! :)
On 20 Sep 2017, at 00:44, George Kadianakis <desnacked@riseup.net> 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 ------------------------------------------------------------------------
teor <teor2345@gmail.com> writes:
On 20 Sep 2017, at 00:44, George Kadianakis <desnacked@riseup.net> 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
Thanks for the discussion and research, Ian and teor! I summarized the findings here: https://trac.torproject.org/projects/tor/ticket/23420#comment:5 Not sure what's the right approach here. Perhaps I'm fine with doing nothing at this point, and figuring this out in the future if v4 ever comes. Cheers!
participants (2)
-
George Kadianakis -
teor