[tor-dev] A concrete proposal for crypto (at least part of it)

Paul Syverson syverson at itd.nrl.navy.mil
Wed Nov 2 18:40:15 UTC 2011

On Wed, Nov 02, 2011 at 01:19:52PM -0500, Watson Ladd wrote:
> On Wed, Nov 2, 2011 at 11:45 AM, Robert Ransom <rransom.8774 at gmail.com> wrote:
> > On 2011-11-02, Watson Ladd <watsonbladd at gmail.com> wrote:
> >> Dear All,
> >[...omitted..]
> >
> >> Right now Tor encrypts the streams of data from a client to a OR with
> >> AES-CTR and no integrity checks.
> >
> > Bullshit. We have a 32-bit-per-cell integrity check at the ends
> > of a circuit.
> So let's say that I am a malicious 1st hop and a malicious 3rd hop,
> and I want to find out. If I have known plaintext I can modify it,
> say the packet type headers.  Then the third router will see
> nonsense and know that it this circuit is compromised. The second
> router can detect this with my proposal, it cannot right now. Ends
> of circuit alone are not enough.

There may be other virtues to integrity checks besides at the end
nodes, but this example is not compelling. All our experiments and
analyses have indicated that it is trivial for end nodes to know when
they share a circuit. You mention an active adversary, but it is
trivial for such an adversary to put a timing signature on traffic
detectable at the other end---trivial but unnecessary. My own work
showed a passive adversary is sufficient, and Bauer et al. showed that
you don't even need to pass application data cells: circuit setup is
enough.  Despite extensive research, nobody has yet come up with a
padding/dropping scheme to resist a passive, let alone active, adversary
adequate and practical enough to consider implementing and deploying.


More information about the tor-dev mailing list