Re: [tor-dev] obfsproxy buffering

[Philipp Winter <identity.function@xxxxxxxxx>]

On Sun, Nov 17, 2013 at 07:33:12PM -0800, David Stainton wrote:
> It seems like the solution is to write a super simple "framing
> protocol"... which is to say that I can first send a frame length; and
> on the receiving end simply read until frame length worth of data is
> consumed... and then apply the crypto_stream cipher on that frame with
> the correct corresponding nonce.

That sounds like a reasonable solution.  ScrambleSuit also has its own protocol
header, if that helps:
https://gitweb.torproject.org/user/phw/scramblesuit.git/blob/HEAD:/message.py#l161

Also, I'm probably stating the obvious here, but you seem to be using a static
key for encryption and decryption.  That results in a many time pad, i.e., the
same key is used for many plain texts.  That's a problem because Tor's TLS
handshake is predictable and a censor could observe that multiple independent
SaltyStream connections share several bytes in their handshake.  You might want
to use a key derivation function, as also suggested by the NaCl doc:

> NaCl does not make any promises regarding the resistance of crypto_stream to
> "related-key attacks." It is the caller's responsibility to use proper
> key-derivation functions.

Cheers,
Philipp
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev