[tor-bugs] #7085 [Tor bundles/installation]: Integrate Cryptocat Browser Extension into Tor Browser Bundle

[Tor Bug Tracker & Wiki]

#7085: Integrate Cryptocat Browser Extension into Tor Browser Bundle
--------------------------------------+-------------------------------------
 Reporter:  kaepora                   |          Owner:  erinn                        
     Type:  enhancement               |         Status:  new                          
 Priority:  normal                    |      Milestone:  TorBrowserBundle 2.2.x-stable
Component:  Tor bundles/installation  |        Version:  Tor: unspecified             
 Keywords:                            |         Parent:                               
   Points:                            |   Actualpoints:                               
--------------------------------------+-------------------------------------

Comment(by nickm):

 Replying to [comment:6 kaepora]:
 > It appears that none of our primitives are even slightly constant time.
 But in response to this I must ask: How likely is it that timing attacks
 will be a danger in this context?

 Like I explained last night, I think this might be motivated reasoning.

 If you *had* a high-quality side-channel-free implementation of your
 various crypto primitives, you wouldn't be making this argument.  You'd
 just be saying "We have a high-quality implementation of our primitives;
 we don't need to worry about it!"  I think that if you knew how to get a
 high-quality side-channel-free implementation of your various crypto
 operations, you would just switch to it, right?

 > I am inclined to believe it to be unlikely: The ciphertext will be sent
 and received from different browser versions, run on different operating
 systems using different hardware. The risk of precisely consistent timing
 is extremely minimal. Furthermore, the nature of the software design makes
 it difficult for this sort of attack to be relevant. ''Note: If I'm saying
 something wrong here, please correct me; I am not an expert on timing
 attacks! ''

 This is what absolutely everybody says, before they get hit with timing
 side-channels.

 I can't analyze your protocol, because I don't know what the protocol is,
 because of the holes in the documentation. But if there is any case where
 one computer does something in response to another computer doing
 something -- for example, a handshake getting answered with a handshake --
 then you need to be concerned about this.  Even if one browser is not
 vulnerable, another might be.  Even if all the desktop browsers you test
 aren't vulnerable, you would need to analyze low-resource situations, like
 smartphones and whatnot.  Even if you try to exploit and you can't, that
 wouldn't prove that no exploit is possible.

 So: Please care!

 > Per our discussion on IRC, I am going to work up some more documentation
 regarding our protocol and software design, but I am just wondering
 whether timing attacks are worth being a blocking issue here at all. What
 are your thoughts?

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