Decide if it's safe to pass the Dooble around the Tor Community

Hi can you use dooble web browser for the torbrowser instead of Firefox ? Http://dooble.sf.net

Trac:
Username: mike123

added component::torbrowserbutton owner::mike123 priority::medium reporter::mike123 resolution::invalid status::closed type::enhancement labels

Trac:
Username: mike123
Component: - Select a component to TorBrowserButton
Owner: N/A to mikeperry

Absolutely. As soon as the Dbooble web browser satisfies all of our Design Requirements, we'll drop Firefox immediately and switch over. https://www.torproject.org/projects/torbrowser/design/#DesignRequirements

Oh, and it also has to play HTML5 video.

Trac:
Status: new to needs_revision

Trac:
Status: needs_revision to assigned
Owner: mikeperry to mike123

Their crypto used to ‘secure’ user data saved to disk looks seriously bogus. I don't recommend touching Dooble.

Trac:
Milestone: Deliverable-Nov2011 to N/A

Hallo? Dooble has lots of security requirements and encrypts even all the user data with the highest available cipher on the machine. i scrolled through the requirements list. dooble shoxuld fit all. please evaluate more and tell me here waht exaxtly you miss. html 5 is supported alredy. dooble is secure uses webkit and has all the security coding in the sense of a user. in case you miss something please advice. it could be coded in fast for your needs. please let this ticket open until that what you need is coded in but please specify what you miss. thanks

Trac:
Username: mike123

Trac:
Cc: N/A to g.koppen@jondos.de

Hai. I think it's great Doobie already solves all of our problems. Please show me links to the Doobie design docs or test cases that describe their awesomeness, because if it more than two times more awasome than half as awesome as Firefox, I am totally down for hitting this Doobie. I mean it sounds like it is at least 1.5 times more awesome than half as awesome as Fiarfaux but how can u be sure if its not 1.3 times more awesome these things r hard to measure u no

Also I liek teh svg http://dooble.sourceforge.net/images/605_logo_round2.png is it faces or is it an table or is it a network of internets its so hard to tell please help help help

P.S. gk: I'm at 99% certainty this ticket is just noise, don't waste your time :)

Replying to mikeperry:

P.S. gk: I'm at 99% certainty this ticket is just noise, don't waste your time :) Doh! And I thought we've found the silver bullet. ;)

you find all the security patches on the Readme file here http://dooble.svn.sourceforge.net/viewvc/dooble/trunk/browser/Doc/RELEASE-NOTES?view=markup&pathrev=4178

Of course we can describe the security things, Firefox only has over addons. I can list a few, if you list some things, it has not due to your requirements list.

• Dooble starts each session new with a total blank browser. No bookmarks, no cookies, no history, no cache data etc.
• in case you set a password on dooble, it generated encrypted containers, to store cookies, history bookmarks etc. So dooble has a tresor.
• the highest available cipher on your system is automatically choosen
• the proxy is highly customizable. It supports already I2P and as well over the normal proxy you can use TOR.
• In the settings you find many many settings to e.g.
• block third party frames, e.g. all facebook buttons and frames
• suppress http refferrs
• Dooble has a cookie washer to erase all cookies every x minutes
• dooble has a cookie manager, to wash out all cookies but keep some exception cookies
• you can modify cookies and bake them ;-)
• you can define the history data period
• dooble can block pop ups
• dooble can block java script in each small definition
• Cross Auditing scripts and windows can be blocked
• Http forwsrding can be suppressed
• Dooble can show the IP address of the website.
• in case you want to step into dooble, we can add as well the own IP address of TOR, so you are sure to have not the own address posted to the site
• Dooble can periodically clean memory cache data as well !! From the RAM and Hard disk
• dooble search engines are all security search engines ! ddg, or ixquick,
• dooble suports yacy for p2p decentral search in case the user uses it
• Dooble has an addon for encrypted chat serverless
• this browser is fully open source and has open source wikinews as rss feed at the startpage
• is available on all POSIX Os, mac, Win, linux
• uses QT as well as Vidalia uses QT, so we could create a DLL plugin for vidalia in one TAB of dooble and distribute the plugin DLL like the chat interface addon with dooble, so users can start the open a tab inside dooble as a plugin for the vidalia steering panel as a tab. as it is Qt as well.

Trac:
Username: mike123

Replying to mike123:

Hallo? Dooble has lots of security requirements and encrypts even all the user data with the highest available cipher on the machine.

Except that it doesn't encrypt strings which are 16 bytes long or shorter.

Trac:
Resolution: N/A to invalid
Status: assigned to closed

Of course it encrypts strings of all sizes, even empty ones.

Trac:
Username: mike123

rransom: You're totally harshing on my buzz, man. There's so many things rolled into this Doobie my head is spinning.

Unfortunately, most of them seem useless to us. It looks like Doobie is taking a temporal approach to privacy rather than an origin-based approach. We're pretty sure this is not the right way to go, because of cross-origin linkability problems even over short browsing sessions.

However, the minimum set of features for this Doobie to be passed around the Tor community is to meet https://www.torproject.org/projects/torbrowser/design/#security. If it meets that and comes with some tests to show it (see https://www.torproject.org/projects/torbrowser/design/#proxy-obedience), we might reconsider our position of telling people to Just Say No.

But Doobie also has to meet https://www.torproject.org/projects/torbrowser/design/#privacy before it can replace our modified Firefox in Tor Browser. From the laundry list above, it sounds like it only meets it if you break half the web by blocking all third party iframes (and even then, it probably doesn't really satisfy the requirements until you break all of the web by also disabling third party images and scripts).

Replying to mike123:

Of course it encrypts strings of all sizes, even empty ones.

• dmisc::encodedString() starts by padding its input to a multiple of the cipher's block size (16 bytes for all modern block ciphers which would be used with an encryption ‘mode’).
• It then calls gcry_cipher_encrypt to encrypt that padded buffer ‘in place’.
• Since a 16-byte-or-shorter string is padded to 16 bytes, and 16 bytes is not strictly longer than the cipher's block size, and the GCRY_CIPHER_CBC_CTS flag was set during the call to gcry_cipher_open, gcry_cipher_encrypt returns an error.
• Since gcry_cipher_encrypt returns an error, dmisc::encodedString() returns its (plaintext) input string.

So, no it doesn't.

And I should probably point out that when gcry_cipher_encrypt fails, it scribbles over its output buffer to try to keep the caller from using plaintext as if it were the ciphertext. dmisc::encodedString() goes to some trouble to make sure that it returns the plaintext anyway.

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.

---

static gcry_err_code_t do_cbc_encrypt (gcry_cipher_hd_t c, unsigned char *outbuf, unsigned int outbuflen, const unsigned char *inbuf, unsigned int inbuflen) { unsigned int n; unsigned char *ivp; int i; size_t blocksize = c->cipher->blocksize; unsigned nblocks = inbuflen / blocksize;

if (outbuflen < ((c->flags & GCRY_CIPHER_CBC_MAC)? blocksize : inbuflen)) return GPG_ERR_BUFFER_TOO_SHORT;

if ((inbuflen % c->cipher->blocksize) && !(inbuflen > c->cipher->blocksize && (c->flags & GCRY_CIPHER_CBC_CTS))) return GPG_ERR_INV_LENGTH;

if ((c->flags & GCRY_CIPHER_CBC_CTS) && inbuflen > blocksize) { if ((inbuflen % blocksize) == 0) nblocks--; }

if (c->bulk.cbc_enc) { c->bulk.cbc_enc (&c->context.c, c->u_iv.iv, outbuf, inbuf, nblocks, (c->flags & GCRY_CIPHER_CBC_MAC)); inbuf += nblocks * blocksize; if (!(c->flags & GCRY_CIPHER_CBC_MAC)) outbuf += nblocks * blocksize; } else { for (n=0; n < nblocks; n++ ) { for (ivp=c->u_iv.iv,i=0; i < blocksize; i++ ) outbuf[i] = inbuf[i] ^ *ivp++; c->cipher->encrypt ( &c->context.c, outbuf, outbuf ); memcpy (c->u_iv.iv, outbuf, blocksize ); inbuf += blocksize; if (!(c->flags & GCRY_CIPHER_CBC_MAC)) outbuf += blocksize; } }

if ((c->flags & GCRY_CIPHER_CBC_CTS) && inbuflen > blocksize) { /* We have to be careful here, since outbuf might be equal to inbuf. */ int restbytes; unsigned char b;

  if ((inbuflen % blocksize) == 0)
    restbytes = blocksize;
  else
    restbytes = inbuflen % blocksize;

  outbuf -= blocksize;
  for (ivp = c->u_iv.iv, i = 0; i < restbytes; i++)
    {
      b = inbuf[i];
      outbuf[blocksize + i] = outbuf[i];
      outbuf[i] = b ^ *ivp++;
    }
  for (; i < blocksize; i++)
    outbuf[i] = 0 ^ *ivp++;

  c->cipher->encrypt (&c->context.c, outbuf, outbuf);
  memcpy (c->u_iv.iv, outbuf, blocksize);
}

return 0;

<

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.

Testcase:

Simple.

#include <gcrypt.h> #include <stdio.h> #include <stdlib.h>

int main(void) { int rc = EXIT_SUCCESS; gcry_error_t err = 0; gcry_cipher_hd_t cipherCtx;

if(!gcry_check_version(GCRYPT_VERSION)) { rc = EXIT_FAILURE; printf("gcry_check_version() failure.\n"); }

gcry_control(GCRYCTL_ENABLE_M_GUARD); gcry_control(GCRYCTL_SUSPEND_SECMEM_WARN);

if((err = gcry_control(GCRYCTL_INIT_SECMEM, 16384, 0)) != 0) { rc = EXIT_FAILURE; printf("gcry_control() failure (%s).\n", gcry_strerror(err)); }

gcry_control(GCRYCTL_RESUME_SECMEM_WARN); gcry_control(GCRYCTL_INITIALIZATION_FINISHED, 0);

int algo = gcry_cipher_map_name("aes256");

if((err = gcry_cipher_open(&cipherCtx, algo, GCRY_CIPHER_MODE_CBC, GCRY_CIPHER_SECURE | GCRY_CIPHER_CBC_CTS)) != 0) { rc = EXIT_FAILURE; printf("gcry_cipher_open() failure (%s).\n", gcry_strerror(err)); }

char *buffer = 0; char *cipherPassphrase = (char *) gcry_calloc_secure (256, sizeof(char));

if(cipherPassphrase) { size_t blockLength = gcry_cipher_get_algo_blklen(algo);

  buffer = (char *) gcry_calloc_secure(blockLength, sizeof(char));

  if(buffer)

{ size_t ivLength = 0;

if((ivLength = gcry_cipher_get_algo_blklen(algo)) != 0) { printf("aes256 has a block size of %d.\n", (int) blockLength);

 char *iv = (char *) gcry_calloc_secure(ivLength, sizeof(char));

 if(iv)

{ gcry_cipher_reset(cipherCtx); memcpy((void *) iv, (const void *) cipherPassphrase, ivLength); err = gcry_cipher_setiv(cipherCtx, (const void *) iv, ivLength);

if(err) { rc = EXIT_FAILURE; printf("gcry_cipher_setiv() failure (%s).\n", gcry_strerror(err)); }

memset(buffer, 0, blockLength); memcpy(buffer, "Hello!", 6); printf("Some buffer: %s.\n", buffer);

if((err = gcry_cipher_encrypt(cipherCtx, (void *) buffer, blockLength, (const void *) 0, (size_t) 0)) != 0) { rc = EXIT_FAILURE; printf("gcry_cipher_encrypt() failure (%s).\n", gcry_strerror(err)); }

printf("Some buffer after encoding: %s.\n", buffer); gcry_cipher_reset(cipherCtx); memcpy((void *) iv, (const void *) cipherPassphrase, ivLength); err = gcry_cipher_setiv(cipherCtx, (const void *) iv, ivLength);

if(err) { rc = EXIT_FAILURE; printf("gcry_cipher_setiv() failure (%s).\n", gcry_strerror(err)); }

if((err = gcry_cipher_decrypt(cipherCtx, (void *) buffer, blockLength, (const void *) 0, (size_t) 0)) != 0) { rc = EXIT_FAILURE; printf("gcry_cipher_decrypt() failure (%s).\n", gcry_strerror(err)); }

printf("Some buffer after decoding: %s.\n", buffer); gcry_free(iv); } } }

  gcry_free(buffer);
}

gcry_free(cipherPassphrase); gcry_cipher_close(cipherCtx); return rc; }

And the results.

aes256 has a block size of 16. Some buffer: Hello!. Some buffer after encoding: lk����SuK▒��TS�. Some buffer after decoding: Hello!.

Trac:
Username: mike123

Sweet. Maybe the Doobie isn't so harmful after all!

I'm still pretty sure its privacy properties make it unfit to replace Firefox Tor Browser at this stage, but if it obeys proxy settings and doesn't leak state from shared plugins/other browsers, and is careful about the disk, it might not be a terrible thing to use, if you only use it to visit one website at a time.

P.S. Impressive stress test of Trac's comment length.

Trac:
Status: closed to reopened
Summary: using Dooble Web Browser for the Torbrowser to Decide if it's safe to pass the Dooble around the Tor Community
Resolution: invalid to N/A

okay, we opened these support tickets to meet your requirements, this trac stress ticket can be closed, if the support tickets habe been closed, we open this trac ticket again, ok?

Support Requests item #35237 06 - item #352370.. 13, was opened at 2012-05-05 00:06 https://sourceforge.net/tracker/?group_id=238964&atid=1108294 https://sourceforge.net/tracker/?func=detail&atid=1108294&aid=3523706&group_id=238964

It would be good to work together, not only to merge both together for a product, but as well to get dooble into the state you and we want to have it to be able to use it according your reuqirement needs, of which we think many are already given and could be resolved soon with your help too (and in case you are not sponsored by FF). It is as well a question of market philospohy too, now as the chrome is on top of FF. We definately need a real open source browser as third alternative to both. Tor is the perfect match to address doobies approach for security to the security interested customers of tor. Please add some initiative too.

Trac:
Username: mike123

tahnks for Reopening.

Trac:
Username: mike123

Replying to mikeperry:

but if it obeys proxy settings It does not (I could not resist testing it a bit). Probably due to Webkits epic ftp proxy failure bug, dunno. Thus: Good luck mike123 in fixing all your issues.

FTR: We're sponsored by neither Mozilla nor Google. In fact, near as we can tell, neither give a shit about us on an org level (other than a handful of really awesome rogue engineers). Worse, a substantial segment of both orgs seems to think it would be more convenient for them if we didn't exist at all.

However, you never change horses mid-stream, the devil you know is better than the one you don't, etc etc etc. We've gotten informal requests from every browser vendor (including Google, Apple, Microsoft, Opera, and a few others from the long tail) to support their product, but when it comes down to it, the actual engineering support from them disappears and we're the ones left holding the bag.

Partly because of this (but also because it's just good practice anyway) we've created detailed design documents so that it's clear we're serious about approaching privacy from a rational position that normal people will also find intuitive, and so that it's also clear we didn't just pick Firefox because JWZ was our childhood hero (though he was pretty badass before he lost focus and became an entertainer).

Hence, my trolling above was my way of telling you we're not going to jump ship to a brand new browser and abandon all of our hard work without justification, and certainly not if the expectation of the switch is that we'll be the ones to clean up all of the things we find unacceptable with the new browser.

Good luck, and I hope to hear from you again soon!

Thanks, I will ask, if dooble can more step by step forward to the requirements. From the process now, I think your are a team, with which one can talk. That´s great. From the dooble team we can say that not all is easy, but if you see the excellent dooble code and excellent dooble comments and code codumentation, I think all the technicians from our and your side are excellent technical experts. Dunno how the dooble maintainer reacts for this inititative, but we will know with the beginning of the week, This is not a request to abdandon all your good work, it is a request to install a better alternative and an approach to have a real open source browser with a high security aspect for the users used. Dooble is a ver very small team, developer, who donates a lot of sparetime. there is no money or industry thinking behind it. Its all private, excellence coding for private users. So we understand what hard coding is and so your experience is requested, not to abandon you latest work. Your experience invested in a new secure browser combination with tor. For that, indeed the question is, if dooble is at the level to meet requirements, if not, we could move step by step into that direction. So thanks for keeping your mind up and open and to guide us. From holding the bag.. we develop a browser. That goes on, to move together, this might be here and there a little tweak, but it is not impossible. What we need is the tor steering process, that has then to be done by you, as we only can integrate that. So, after the evaluation says, if would be possible, My suggestion would be, to make a tab inside dooble to steer tor. That is the idea to switch from a tor button to a tor tab. The or tab is a Qt plugin, e.g. fro windows a Dll. Dooble already supports Addons, There is the Chat Messenger Addon http://interface.sf.net distributed by default with the windows installer. interface.dll is added in the plugins directory. This is a simple model how to add as well another tab. the tor tab. We could compile vifalia Qt gui for tor into that or create a new qt simple steering gui for tor. So here you come into the frame, we could do that in a dooble svn-branach, or create an own project tortab.sf.net, if you agree, please register before it is taken. I would assign the icon and design part of the tab. The code for the Qt host of the plugin is as well in this svn http://interface.svn.sourceforge.net/viewvc/interface/communicator/guichat/trunk/plugin-host/ so we need not to develop/test in dooble. While we start the tortab project, dooble already has the code to accept the plugin, and could start the development to improve and meet requirements. Please let me know, if that could be a model, where the branch should be and add me to the project. As my supervisor says always, use the most modern technology, I think I understand to stick to all the good work, but to go ahread with developement means to exchange experience. See VLC media player, they changed as well to Qt, very quick and have 5 Mio downloads per day or week. Change is something different than thoughing away. We together want to create (new). Thanks.

Trac:
Username: mike123

Replying to gk:

Replying to mikeperry:

but if it obeys proxy settings It does not (I could not resist testing it a bit). Probably due to Webkits epic ftp proxy failure bug, dunno. Thus: Good luck mike123 in fixing all your issues.

Can you describe how you have done your tests and what the results are and what you expected different? Which settings did you use, auto retrive proxy settings? for a company firewall test there is one bug in the proxy, that was referring to the ISA proxy of microsoft and specific company firewall. So we test tor over dooble now.

Trac:
Username: mike123

Replying to mike123:

Replying to gk:

Replying to mikeperry:

but if it obeys proxy settings It does not (I could not resist testing it a bit). Probably due to Webkits epic ftp proxy failure bug, dunno. Thus: Good luck mike123 in fixing all your issues.

Can you describe how you have done your tests and what the results are and what you expected different? Which settings did you use, auto retrive proxy settings? for a company firewall test there is one bug in the proxy, that was referring to the ISA proxy of microsoft and specific company firewall. So we test tor over dooble now.

I tried this test case: Starting vidalia, starting dooble, go to settings-proxy. Set browsing proxy and download proxy to MANUAL. Heck Http, uncheck FTP, Set Host to 127.0.0.1, Port to : 8118 and Type = Http. Then leave password and username blank. It loads under www.whatismyip.com a different one than in the other browser. So it works here?

Trac:
Username: mike123

Replying to mike123:

Can you describe how you have done your tests and what the results are and what you expected different? Which settings did you use, auto retrive proxy settings? I used JonDonym for testing, an anonymization network similar to Tor with similar goals in mind (https://anonymous-proxy-servers.net). But actually a simple proxy should do it here as well. I entered the proxy settings manually (HTTP 127.0.0.1:4001) in every proxy field I could find in the proxy panel as I wanted to test on http://ip-check.info. The latter tries circumventing the proxy settings actively using different techniques (e.g. FTP, hence I entered the proxy settings for FTP as well). While loading the test (ignore the output as the layout and presentation of the results do not work with Dooble yet) I looked at Wireshark and it gave me: 1) DNS leaks for ip-check.info and 2) the FTP traffic bypassed JonDonym. Thus, Dooble is not following the proxy settings. The reason is probably:

https://anonymous-proxy-servers.net/blog/index.php?/archives/233-Chrome-and-Safari-leak-IP-address.html

And yes, we filed a bug, ages ago:

https://bugs.webkit.org/show_bug.cgi?id=50622

But nobody seems to care about shrug. BTW: You may still see the problem (as it should be shown to Dooble users as well) visiting http://ip-check.info with e.g. the latest Chrome.

Replying to gk:

Replying to mike123:

Can you describe how you have done your tests The reason is probably:

https://anonymous-proxy-servers.net/blog/index.php?/archives/233-Chrome-and-Safari-leak-IP-address.html

And yes, we filed a bug, ages ago:

https://bugs.webkit.org/show_bug.cgi?id=50622

Ok, thanks, so FTP-Downloads over proxy are based on the webkit library and not on dooble code and affects chrome and safari as well. Then FTP downloads should be disabled for the tortab development. But seriously, I heard nothing where dooble does not fulfill the requirements. In a test surfing works very fine over tor. As there is a suggestion for a project plan how to develop the tortab and I would bring myself in for a little aspekt, dooble already can consider addons and is functional and the further development can consider further improvements as well for proxy security use, I think it is up to you to respond, how we want to create this. Vidalia as a tab plugin dll for dooble would be great, as it combines the torbutton, the torbrowser and vidalia. Can you ask in your team who all could imagine to join such a plugin development?

Trac:
Username: mike123

Replying to 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.

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.

cool, this man is an excellent expert. from reading it, very deep looking into doobles code and knowing of what is spoken. I though think that the question, if a passpharase is secure enough to encrypt cookies, is a little bit too detailed, as dooble is the only browser worldwide, which has a tresor and safe. If the users wants to wash out cookies or history data, there is an auto function to do that, or just use the non-auth session, which is like a portable usb stick version.

here is what the developer answers:

It is not practical for Dooble to question the validity of all of the libraries that it uses. My approach is to report errors and proceed in some predictable fashion. There are known issues with Qt, with Qt on X11, with Qt on OS X, etc. Dooble uses the libraries as best as it can. Questioning every dependency requires a level of paranoia that Dooble is not comfortable with.

"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."

The method is required to return a buffer of bytes. If it fails internally, it reports the error and returns the original buffer. Its failure is deemed acceptable. Dooble's intent is to provide a crisp browsing experience. It does so by tolerating some mishaps. An assortment of operations would need to be placed in atomic transactions if the method is modified to return an empty buffer or some other value. Since the method is used for recording information to databases, its failure is completely acceptable.

Impressive critique. "

And I think this is just the point on the i, what you found out, but dooble is of course usable to browse over tor and to easily destroy the cookies on the usb stick or the desktop installation. or, if one bookmark should be kept, this can be done in a tresor, no other browser has encrypted bookmarks, this is awesome, and I think tor customers and dooble intents meet in a perfect match of requirements.

Trac:
Username: mike123

OK, the middleman has left the building. Some answers in some order.

Multiple passphrases? Not in Dooble. If the current passphrase is replaced, existing data is either re-encoded or discarded. It's theoretically possible to produce equal hashes from varying content, but you already know that. It's possible that during data purging, temporary information is left unattended. Completely acceptable. Suggestion noted.

That's fine. Noted.

Indeed, Dooble does use repetitive vectors. The cookie manager is not designed around encryption.

Known. Hashes are used throughout for locating entries. Lots of places use hashes, lots. A better approach is to assign OIDs, but that desire has not been implemented.

Again, I know there are two possible outcomes.

Dooble has one developer, one. It is an evolving project.

These design flaws, as you call them, have elegant solutions.

Regarding the impressive critique, I was being just as sarcastic as some previous commentator. People will use Dooble with or without Tor and it, Dooble, does not require Tor's blessing. Dooble is a whole lot of love. Offer suggestions, but PLEASE leave Dooble out of this community.

Thanks.

Trac:
Username: textbrowser

Replying to textbrowser:

Multiple passphrases? Not in Dooble. If the current passphrase is replaced, existing data is either re-encoded or discarded.

Interesting. Then there is no reason to put a hash of the current passphrase in every record.

Indeed, Dooble does use repetitive vectors. The cookie manager is not designed around encryption.

The cookie-storage code is designed around a design flaw in Dooble's encryption -- it relies on the fact that each plaintext has only one ciphertext.

Regarding the impressive critique, I was being just as sarcastic as some previous commentator. People will use Dooble with or without Tor and it, Dooble, does not require Tor's blessing. Dooble is a whole lot of love. Offer suggestions, but PLEASE leave Dooble out of this community.

You seem to not even be willing to add error-handling code to the functions which call encodedString, and that would be far less difficult than the redesign of Dooble's data-storage code that would be needed to make Dooble's encryption useful. So I am in favor of keeping Dooble as far away from Tor as possible, too. Bye.

Trac:
Status: reopened to closed
Resolution: N/A to invalid

There is a very valid reason for storing passphrase hashes. If a user enters a temporary-session mode, some data is recorded in order to satisfy visual containers. Such containers are populated by reading and decoding values from databases. Dooble needs to know which values belong to that session and it does so by using passphrase hashes. Instead of a hash, a boolean could be used to indicate that the data is temporary. However, that is not the current case.

Error-proofing encodedString() is not a simple task. It is understood to tolerate failure. I've noted your suggestion.

Enjoy playing with Fire.

It's been a hoot. Bye.

Trac:
Username: textbrowser

Hi Mike, you specified these needs:

"Hey Textbrowser,

I think you misunderstood me wrt to the level of commitment from us.

Our commitment extends this far:

1. Once Dooble meets https://www.torproject.org/projects/torbrowser/design/#security, we'll stop telling people not to use it with Tor. Right now, it does not meet even these most basic requirements.

2. Once Dooble meets https://www.torproject.org/projects/torbrowser/design/#privacy to an equal or greater degree than our Firefox implementation (click the links in that section for details) with the same degree of functionality (especially the ability to use Google docs and plan youtube videos without plugins, and the ability to interpret and apply HTTPS-Everywhere rules), we'll consider begin devoting Tor development resources to making an official Dooble-based bundle.

Unfortunately, we have no Tor development resources to devote up until that point. "

Just one comment: youtuble plugins can be already disabled and furthermore to refer to the https everywhere addon, I would say this is an addon, is it shipped with the Torbowser? So be fair from the method to compare browsers and not all the enhancements for it. We will look at yout two links in greater details, but what exactly do you miss from them in dooble? We should open up tickets or have a list and plan, when the long way could be see some light in the tunnel. As now two developers closed this ticket, and not the community has anything said besides rrandom, who give side details sponsored by google to destroy innovation, this might be done by third party people.

https://sourceforge.net/projects/torbrowser/

this domain has been shifted over to your sf.net name. Do you want to use it? I think it is not a good initiative to use it for the firefox bundle, so I let your name as admin there in and ask some others e.g. the russion pre-owner of the domain if there are ideas for a vidalia qt plugin. This means to change the vidalia mainframe to a webfram and compile it as a tab-plugin like it has been done in this app: http://interface.sf.net

this approach does not even need dooble. Here is a simple qt frame host to host the plugin: http://interface.svn.sourceforge.net/viewvc/interface/communicator/guichat/trunk/plugin-host/

For the https everywhere functionality there will be a feature request in dooble. Ok, Dooble versions will evolve and we might look later, though it is not dooble, it is the mind of people taking part. Besides disabling youtube plugins and https everywhere nothing else has been listed, in case the privacy and security links are fullfilled. here the referring dooble support tickets (see link above) have been done.

Trac:
Username: mike123

Transition completed with randomized vectors. All database hashes eliminated. Passphrase hash is salted via hash(random-bytes + passphrase).

Trac:
Username: mike123

Thanks mike1234567890. You couldn't resist? Such a valiant effort for an undeserving audience. OK, I'll be nice.

Some other thoughts.

Replaced cookies.db. The database now houses encoded values of raw forms. One field.

For the curious, hashes that include salts offer protection against rainbow tables.

The random passphrases have always been 256 or so bytes. They have never been fewer than 16 bytes.

Researching the suggestion pertaining to the use of hashes of passphrases as cipher keys.

Now discarding the provided passphrase. Poof.

Yeah. The changes were completed in a few days without a commitment from this or any other group.

I like how some functions work. They're predictable. Logging may become fancier and more informative.

Some YouTube videos play without enabling Web plugins.

The important conclusion is that "Doobie" isn't a bogus project. We're still evolving, learning, twisting.

Trac:
Username: textbrowser

Replying to textbrowser:

Replaced cookies.db. The database now houses encoded values of raw forms. One field.

Good. That prevents a whole class of attacks.

Researching the suggestion pertaining to the use of hashes of passphrases as cipher keys.

See the documentation for gcry_kdf_derive for the recommended standard way to convert a passphrase into a key.

The important conclusion is that "Doobie" isn't a bogus project. We're still evolving, learning, twisting.

Thanks for fixing those issues. I thought you weren't interested in fixing them.

Also, you probably need to remove the IV from the beginning of a ciphertext buffer before decrypting it.

Trac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, ln5

Thanks.

The vector is removed.

gcry_error_t dmisc::setInitializationVector(QByteArray &bytes) { size_t ivLength = 0; gcry_error_t err = 0;

if((ivLength = gcry_cipher_get_algo_blklen(s_algorithm)) != 0) { char *iv = (char *) gcry_calloc_secure(ivLength, sizeof(char));

  if(iv)
{
  if(bytes.isEmpty())
    {
      gcry_create_nonce((void *) iv, ivLength);
      bytes.append(iv, ivLength);
    }
  else
    {
      ivLength = qMin(ivLength, static_cast<size_t> (bytes.size()));
      memcpy((void *) iv,
	     (const void *) bytes.constData(),
	     ivLength);
      bytes.remove(0, ivLength);
    }

  err = gcry_cipher_setiv(s_cipherCtx, (const void *) iv, ivLength);
  gcry_free(iv);
}
  else
err = GPG_ERR_ENOMEM;
}

else err = GPG_ERR_INV_LENGTH;

return err; }

Dooble shadows Qt/WebKit with respect to image blocking. JavaScript may be blocked per site. I don't know if the disabling of it propagates to every frame of a page. Please experiment and provide a detailed report to Dooble. Your insight is important. Peachy.

Trac:
Username: textbrowser

closed