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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev