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

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Wed, Nov 2, 2011 at 2:19 PM, Watson Ladd <watsonbladd@xxxxxxxxx> wrote:
> On Wed, Nov 2, 2011 at 11:45 AM, Robert Ransom <rransom.8774@xxxxxxxxx> wrote:
>> On 2011-11-02, Watson Ladd <watsonbladd@xxxxxxxxx> 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.

See https://blog.torproject.org/blog/one-cell-enough ; see also the
part in the original Tor design paper where we discuss integrity
checking and tagging attacks.  See also the three paragraphs near the
beginning of section 6.4 in the document under discussion, which say:

"""
   It's not such an obvious improvement.  Including more MACs is more
   expensive in per-cell overhead.  The attacks that we would foil this
   way but not with Option 3 are not so much better than the the passive or
   timing-based-active end-to-end attacks that would still remain.

   Consider that if option 3 is in place, an end-to-end attacker who
   wants to do a tagging attack at one node can garble the rest of the
   circuit and see if the output is garbled at the exit node.  But such
   an attacker could just as easily close the circuit at one of those
   nodes and watch for a corresponding close event, or even better --
   simply pause traffic on that circuit for a while and watch for a
   corresponding gap at the exit.  The only advantage of the garbling
   attack would be that garbled cells are presumably rarer than circuit
   closes or traffic pauses, and thus easier to use to distinguish
   target circuits.  But that's still questionable: the other attacks
   win fine, and the pause attack doesn't risk detection as much.

   So why might we want to do this?  First, the overhead doesn't need to
   be as bad as you might first expect (see below).  Second, it would be
   nice to increase the security margin as much as possible: "attacks
   only get better".
"""

In summary:

 - If you control first and last hops in any currently known
deployable low-latency anonymity design, you win already through
active and passive timing attacks.  (As Paul notes in his mail.)
 - Xor tagging attacks are strictly easier to detect than timing
attacks, since the attacker risks breaking the circuits that they
don't in fact control.
 - Therefore it isn't completely obvious that any attacker actually
gets weaker if Tor does hop-by-hop integrity-checking.  (Before
anybody says "but..." here, please actually go read that blog post :)
)
 - Moreover, doing whole-cell crypto (as in option 3) lowers the
number of bits that you can get out of a tagging attack.  So the
incremental advantage of option 4 (hop-by-hop integrity checking) over
option 3 may be even less than its advantage over current Tor.

 - But maybe we should do hop-by-hop integrity checking anyway, since:
   - Less sophisticated attackers probably would have an easier time
implementing tagging attacks than they would implementing timing
correlation attacks.
   - "Attacks get better, not worse."  Right now, I can't think of a
way to make cell tagging better than active or passive timing attacks.
 But who knows, maybe we'll be glad later that we added it for some
reason if somebody finds a novel attack on some other part of our
protocol stack or something.
  - It's doesn't have to be all that expensive in space to help a lot,
and it doesn't seem to be any more expensive in time than the
whole-cell-crypto designs of option 3.  (It might in fact be cheaper
in time, depending.)

This is one of the parts of the document that I wish people would
discuss, btw.  The conclusions here are not obvious to me, and
although I prefer hop-by-hop checking based on the reasons above, I
don't think that they're absolutely compelling.

> Ends of circuit alone are not enough.

That's certainly worth discussing, but it's not what Robert was
disagreeing with.  What you said was "Tor encrypts the data ... with
no integrity checks."  I think that's what he was reacting to.

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