This project has moved and is read-only. For the latest updates, please go here.

Password Network Proposal

Topics: Feature Requests
Jan 13, 2015 at 8:17 AM
Edited Jan 15, 2015 at 1:54 AM
Password Network Proposal

I believe the title explains a fair amount. Please read the rest for greater detail.

Truecrypt creates a distributed cache anonymous network for only storing TC random generated passwords (the team could even work with anonymity giants like Tor, I2p, Freenet, etc). Each user will contribute a relatively negligible amount of their hard drive to store networked passwords. Even if the encrypted PW's were copied a thousand times for redundancy, each TC client would only need to contribute less than 100mb of their HDD. Being that this contribution is small, TC can be designed to change the size of each users network cache dynamically as demand changes.

Upon creation of a container, TC creates a long complex PW that one cannot realistically be expected to remember with of course a slight alteration to the end (and or beginning) of the random PW by the user. During the creation of the container the UI will ask the user to add a unique string of characters of their choosing to the beginning and or end of the complex password. The user then creates a simple PW to access the long complex random password from the distributed network. Like the freenet network protocol. TC's distributed network will automatically destroy a random PW in say 3 or 7 days (could be user defined) if not accessed in the specified time period. Users have the option of storing the random PW elsewhere if needed after extended down time. The user can then resubmit the RPW (random password) to the network when they return to a networked machine. This I believe will grant the user a high degree of plausible deniability in that one cannot prove that the TC user chose to leave the random PW to the network or chose to retain it in some way. The distributed network would be tiny with little network overhead as it would contain encrypted RPW's (random passwords) and their redundant counterparts.

If you DO NOT read the rest, you will logically find flaws that are covered in the following writings.

OPTIONS & PROMPTS DURING VOLUME CREATION WIZARD (Development questions throughout):

Maybe truecrypt should request user participation even if the user has not created any volumes on the current machine.

Prompt them with the following:
  • As a member of the truecrypt community we humbly (or strongly) request (or recommend) that you participate this machine in the ANONYMOUS and DISTRIBUTED password network (click here to learn more). Truecrypt will use a tiny amount of space to store the passwords (All passwords on the network are encrypted and NEVER readable to other users) of other users of the network and in return they will do the same for you. The amount of space used by truecrypt for this network will likely never grow beyond 100mb (the equivalent of about 30 average mp3 songs), so don't worry, even some of the smallest internal hard drives can hold thousands of them with a lot of room to spare. Contributing to the network even if you don't have a password stored on the network, will help with anonymity, decrease individual cache size, and decrease network load. United we stand, divided we fall.
Below is an option and choice details during PW creation:
  • Randomly generate a password and distribute it to the TrueCrypt network. (Recommended)
  • NOTE: To take it a step further, we incorporate the concept of password expiration time. Your randomly generated password will be held in the the network for the amount of time you choose. The truecrypt software will remind you regularly to postpone it's destruction. By default this will happen daily to avoid allowing an attacker that gains physical access to your machine to know the user defined expiration time or that you even have a password on the network. A pop up dialog box will appear bearing something like "If you have a networked PW, would you like to postpone it's destruction? If so, enter your memorable PW here_________".
  • Attention! This option should be chosen even if you choose to save the password elsewhere. The fact that this is the default action taken by truecrypt grants users of this software plausible deniability. The more users that select this option, the more the password network will grow thus increasing the validity of the PD argument. (YOUR PASSWORD CANNOT BE DECRYPTED BY ANYONE BUT YOU!)
  • Your password will be randomly generated by the truecrypt software. You will then be required to create a memorable password to decrypt this randomly generated password from truecrypt's anonymous distributed network cache. The memorable password chosen can be used to access the randomly generated password from anywhere you have access to a trucrypt client. You will also have the recommended option of adding a unique string of characters to your randomly generated password for added protection against arguably impractical brute forcing attempts by an attacker. This way, even if an attacker tries each discovered random password it will never work because you hold the last piece or pieces of the puzzle. With the addition of keyfiles, the chance of decrypting a target container is remote at best.
  • These techniques grants you plausible deniability in that it is unrealistic that you could be expected to remember a huge randomly generated password. Even if you provide the attacker a FALSE memorable password on demand, if it does not work to retrieve the randomly generated password from the network, one could argue that it has already expired. Even if you choose to have the password retained indefinitely on the network, it cannot be proven that you have chosen to. You will also have the option of retaining the randomly generated password using other means. Again, your decision to cannot be proven. Strong encryption and plausible deniability are the defining features of truecrypt. We will continue to innovate on these fronts. Please don't forget that your donations help to accelerate the maturity of this software. Stay safe.
=============================================================

All of this is basically SIMILAR to giving a friend a zip file containing your complex password and telling him/her to destroy it if your not heard from every (user specified) 3 or so days. In this case though, no trusted party would be needed. For those who would rather not open their encrypted containers on a networked machine, the possibility of retrieving the password from the network then transferring it to the non-networked machine using something like a low capacity USB drive that can afterwards be wiped rapidly remains a possibility.

Could the above defeat RIPA and unrestrained (but unwilling to waste time needlessly) malicious entities? Please, productive and mature responses are preferred. I have never claimed to be an expert in this field. No ravaging necessary.
Jan 15, 2015 at 9:28 AM
Edited Jan 15, 2015 at 11:05 AM
1) The "simple password" is in effect the real password, the target of every attacker
2) The network implementation creates abundant opportunity for the appearance of complex and subtle exploits
3) VeraCrypt's nature is such that air-gapped machines are the typical or a very common usage scenario
4) Complex software needed to implement this produces rather high development & maintenance costs
5) As described, such a system could be implemented as a third party application (password manager).

For the above reasons I cannot view this scheme as a productive use of scarce VeraCrypt resources at this time.
Jan 15, 2015 at 3:42 PM
I think commenter8 has explained this nicely.

Increasing the attack surface is a dangerous path to travel. From what I have read about VeraCrypt it seems to be focused on genuine security. A truly welcome relief from many other encryption programs currently available.
Jan 17, 2015 at 4:00 AM
Edited Jan 17, 2015 at 4:05 AM
1) Inaccurate, as the simple password merely recovers a 60% (variable) piece of the total password. The remainder is user defined during creation of the container. Example: Total password = USER STRING 1 (plus) RANDOM GENERATED STRING (plus) USER STRING 2 (plus) KEYFILES. The point of all of this to argue that a key piece of the total password isn't realistically memorable by the average person. An attacker who brute forces the network to find a bunch of random passwords wouldn't have a clue if he/she stumbled onto yours unless he/she already knows your simple password. Local or remote access to your machine potentially means game over. In the case that your system is networked (which a significant number encryption users happen to be), system compromise would mean the same for either implementations weather using my prop or not. My prop, while developmentally intensive could add another layer of plausible deniability.

2) Agreed, any new system brings along with it unknown issues. Though the protection something like this could afford the average users might warrant the potential issues. The Tor project has been through countless issues and has from them created a fairly robust system that everyone is free to draw from.

3) When you say typical, how was this ascertained? I will admit to lightly combing through the encryption community, though from most of my exposure it seems most users are inconvenienced by air gapping. Air gapping means having a separate machine specifically for specialized tasks like decryption. This entry requirement is for most from my understanding a deterrent and would likely not have resulted in the mass adoption truecrypt has had.

4) I threw the idea out there simply to stimulate creativity and expel it while it was fresh. It is by no means even near perfect but I hoped you enthusiasts would help to refine it or better yet branch the idea into something that could work. Verawipe is too a tool that would improve PD. Mounir for this reason has chosen to invest his time into it's production. He could for the same reason do the same for something like this. Very light development of something like this could stimulate activity from the rest of the community (even Tor, I2p, and Freenet devs themselves). Some need to see things take shape before they jump in.

5) It would be nice and preferable to see this idea become something standalone. In this way a crap load of testing could occur before linking it to something as sensitive as container encryption.

Sorry if my responses haven't been thorough enough to cover every aspect of each idea. I get few minutes a day to do casual browsing, so I have to be brief and must in most cases omit important information in the hopes that others will make the necessary connections on their own. If their is a hole, I'm hoping it'll be filled rather than flagged.

Thank you for every moment you spent even thinking about this all. To me, the time and energy you grant me or my idea is precious. At no point will I ever forget that.

Cheers!