[tor-bugs] #5460 [Tor Client]: Write proposal(s) to evaluate circuit crypto authentication

[Tor Bug Tracker & Wiki]

#5460: Write proposal(s) to evaluate circuit crypto authentication
------------------------+---------------------------------------------------
 Reporter:  mikeperry   |          Owner:       
     Type:  defect      |         Status:  new  
 Priority:  major       |      Milestone:       
Component:  Tor Client  |        Version:       
 Keywords:              |         Parent:  #5456
   Points:              |   Actualpoints:       
------------------------+---------------------------------------------------

Comment(by rransom):

 Replying to [ticket:5460 mikeperry]:
 > We need to write a proposal to determine the best way to provide
 authentication to our circuit crypto, so that cells that have been
 tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not
 the third.

 The goal is to ensure that any attempt to tag a circuit destroys all
 further data sent on it, so that the attacker cannot tag a circuit's data
 in any way other than by destroying it.  (These anti-tagging measures do
 nothing about timing-based ‘tagging’ techniques; they are motivated by the
 assumption that tagging a circuit's data is much easier or more effective
 than any timing attack.)


 > As I understand it, there are two competing possibilities:
 >
 > 1. Self-authenticating crypto (BEAR/LION/LIONESS, others?)

 BEAR/LION/LIONESS are not ‘self-authenticating crypto’.  They are large-
 block block ciphers which ensure that any change to a block's data on one
 side of an honest relay completely scrambles the block's data on the other
 side.  They would need to be accompanied by an end-to-end MAC.

 > 2. Per-hop MAC
 >
 > The main disadvantage of 1 is that it's likely slow and not very many
 people use it.

 LION can be made relatively fast (certainly faster than Tor's current
 crypto) by using an appropriate stream cipher and message-digest function
 in it.  (Per-hop MACs can be made faster, but LION isn't slow.)

 > The disadvantage of 2 is that it requires us to disclose path length
 count and position to nodes, as well as have MACs that either grow with
 increased path length, or become less secure with increased path length.

 These disadvantages are not required.  Nick proposed these ideas because
 they may allow better security-versus-MAC-size tradeoffs.


 > There are probably other issues. I believe the current plan is to
 produce both options in one or more proposals and compare and contrast
 them.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5460#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online