[tor-dev] Padding prop224 REND1 cells to blend them with legacy cells

[teor]

> On 20 Sep 2017, at 00:44, George Kadianakis <desnacked at 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
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170920/cc7b6b97/attachment.sig>