Re: [tor-bugs] #5761 [TorBrowserButton]: Decide if it's safe to pass the Dooble around the Tor Community

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#5761: Decide if it's safe to pass the Dooble around the Tor Community
---------------------------------+------------------------------------------
    Reporter:  mike123           |       Owner:  mike123 
        Type:  enhancement       |      Status:  reopened
    Priority:  normal            |   Milestone:          
   Component:  TorBrowserButton  |     Version:          
  Resolution:                    |    Keywords:          
      Parent:                    |      Points:          
Actualpoints:                    |  
---------------------------------+------------------------------------------

Comment(by rransom):

 So, on to the design flaws that make most of Dooble's encryption useless:

 Dooble uses the passphrase directly as its block-cipher key, without
 hashing it first.  One of the nasty effects of this flaw is that if a user
 uses the same first 32 bytes in multiple passphrases, the resulting key
 will be the same.  (Yes, users will actually do this.)

 Dooble writes an unsalted hash of the passphrase to disk, as part of every
 SQLite database record which contains strings encrypted using (the first
 32 bytes of) the passphrase.  This makes brute-force attacks against all
 Dooble users' passphrases at once ''much'' easier.  It also makes it
 fairly easy to determine how many different passphrases a user has used
 with a set of Dooble databases.

 Dooble uses the same IV for all encryption operations with a key.  Thus,
 every plaintext string corresponds to exactly one ciphertext.  (The Dooble
 developers are clearly aware of this vulnerability, because the cookie
 manager in dcookies.cc is designed around it.)

 The favicon-storage code in dmisc.cc writes an unkeyed hash of the
 plaintext URL and host, along with their ciphertexts using the current
 key.  Since there are relatively few hostnames on the Internet, and even
 fewer commonly-browsed hostnames, this gives an attacker at least a few
 ciphertexts with known plaintexts.

 The cookie manager encrypts each cookie's âHTTP-onlyâ and âsecureâ flags
 as separate ciphertexts, too, and these are almost as good as known
 plaintexts (even if the attacker can't figure out from the pattern of
 cookie name, path, and value lengths for a given domain what the exact
 plaintext is) for the attack below (each flag should decrypt to either â0â
 or â1â).

 An attacker who has access to the database while the user is not using a
 passphrase, and who can find at least one known plaintext for that
 passphrase, can cut-and-paste ciphertext blocks as follows:
  * Choose a one-block ciphertext C with known plaintext P.
  * Construct a new ciphertext X := (random block) .. C .. (random block)
 .. (random block) .
  * Place X in a database record where its corresponding plaintext Y will
 be sent across the network to a location the attacker can observe with
 minimal user interaction.  (I would suggest a cookie value.)
 When the attacker receives Y, the attacker can recover the IV as (second
 block of Y) XOR P XOR (first block of X) .  But Dooble's IV is not only
 constant, it's set to the first 16 bytes of the secret key!  So this
 chosen-ciphertext attack recovers (at least) half of the user's key
 material.  If the user used a random password, it's probably less than 16
 bytes long, so the attacker wins immediately.  If the user used a
 âpassphraseâ from a natural language, a brute-force search will easily
 recover the rest of the key.

 String-validation code (in Dooble or somewhere in WebKit) might interfere
 with receiving the plaintext corresponding to a chosen ciphertext, but a
 few checks which might accidentally prevent disasters like âoops I sent
 the secret key over the networkâ are not a valid substitute for (a) using
 your encryption function properly and (b) using a real message
 authentication code along with your encryption.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5761#comment:27>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs