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

[Tor Bug Tracker & Wiki]

#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):

 Replying to [comment:15 mike123]:
 > Unable to reproduce the wild claim. If the encryption fails, it fails
 gracefully and an error is reported.
 >
 > outbuflen = 16
 > blocksize = 16
 > inbuflen = 16
 >
 > Under those conditions do_cbc_encrypt() does not return a failure.
 >
 > My manual states that the size of the buffer must be a multiple of the
 cipher's block size, including a multiple of 1.

 My copy of the libgcrypt info documentation says otherwise:
 {{{
     `GCRY_CIPHER_CBC_CTS'
           Enable cipher text stealing (CTS) for the CBC mode.  Cannot
           be used simultaneous as GCRY_CIPHER_CBC_MAC.  CTS mode makes
           it possible to transform data of almost arbitrary size (only
           limitation is that it must be greater than the algorithm's
           block size).
 }}}

 And at first glance, the following chunk of code seemed to match the
 documentation.  (I missed the first clause of the `&&`.)
 {{{
   if ((inbuflen % c->cipher->blocksize)
       && !(inbuflen > c->cipher->blocksize
            && (c->flags & GCRY_CIPHER_CBC_CTS)))
     return GPG_ERR_INV_LENGTH;
 }}}

 Now that I've read the function more carefully, `gcry_cipher_encrypt` does
 encrypt one-block messages, although it does so by ignoring the
 `GCRY_CIPHER_CBC_CTS` flag.  That libgcrypt bug does seem to save you from
 leaking short strings as plaintext, although it also makes at least one
 attack much easier.


 > Do you expect the method to create magical content if it can't? Of
 course it returns the original buffer if something failed. It returns the
 original buffer or the encoded buffer. It doesn't "garble" the original
 buffer if an error occurs.

 I expect any function which claims to encrypt data to either output a
 ciphertext or report an error.  No program should '''ever''' silently use
 plaintext as if it were ciphertext, even if an error occurs while trying
 to encrypt a message.

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