[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #3122 [Tor Client]: Write and use constant-time comparison functions

#3122: Write and use constant-time comparison functions
-------------------------+--------------------------------------------------
 Reporter:  rransom      |          Owner:  ioerror
     Type:  enhancement  |         Status:  new    
 Priority:  major        |      Milestone:         
Component:  Tor Client   |        Version:         
 Keywords:               |         Parent:         
   Points:               |   Actualpoints:         
-------------------------+--------------------------------------------------

Comment(by rransom):

 Replying to [comment:2 cypherpunks]:
 > There are a lot of places in the code where memcmp() is called on memory
 buffers that look like they might contain various hashes or digests:

 Applying memcmp to a hash or digest is not normally a problem.  memcmp is
 only dangerous when applied to a MAC, password, or other secret value
 which the attacker can attempt to guess one byte at a time.

 There are a few cases where we pretend that a hash value of non-secret
 information is hard for an attacker to guess, most notably in our bridge
 design where anyone who knows the hash of a published bridge's identity
 public key can use that hash to retrieve the bridge's descriptor from the
 bridge authority, but the correct fix for that type of security hole is to
 stop using a value that is so easily obtained as a password of any kind.

 > Some cases look particularly concerning. For example, in the following
 code 'handshake_reply' appears to be supplied by the remote party and it
 is compared with something called "key material".
 >
 > src/or/onion.c:331:
 {{{
   if (memcmp(key_material, handshake_reply+DH_KEY_LEN, DIGEST_LEN)) {
     /* H(K) does *not* match. Something fishy. */
      log_warn(LD_PROTOCOL,"Digest DOES NOT MATCH on onion handshake. "
            "Bug or attack.");
     goto err;
   }
 }}}
 >
 > In the worst-case, the attacker could simply supply different values of
 handshake_reply, observe how long each takes to compare, and figure out
 the value of key_material statistically byte-by-byte.

 Or the attacker could read HK out of the (plaintext) CREATED cell sent by
 the relay, exactly where the client is reading it from.

 HK is a hash of the Diffie-Hellman shared secret between a client and a
 relay, and it is used in exactly two ways in Tor's protocol: for key
 confirmation (the use you are complaining about), and as a replay-
 prevention nonce in the hidden-service protocol.  We know it is public
 information.

 And as nickm just explained, the attacker cannot extract the correct value
 of HK for a handshake from the client using a timing attack on that memcmp
 because the attacker can only test one guess.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3122#comment:6>
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