The Vault Development - Encrypt files

Discussion in 'privacy technology' started by softtouch, Jun 21, 2009.

Thread Status:
Not open for further replies.
  1. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown
    My thinking there is simply regarding security LRW is said to be more secure than block. AES 256 is said to be more secure than 128. Is that in any way going to change how secure The Vault is, probably not. But is there any harm in a proper implemented version of either? No.


    Same explanation as above. I do know that TrueCrypt offers this feature, and we all now how well-respected TC is. I thought it would be good to offer that. But again, it probable will not change anything security wise, as these features are not needed.

    I have mentioned before that I would like to see the header be able to be stripped, and stored desperately from a vault. That is still true.

    We have changed vault creation so that they are now filled with random data, so there can be no distinction between "real" data and "empty" data.
     
  2. Justin Troutman

    Justin Troutman Cryptography Expert

    Joined:
    Dec 23, 2007
    Posts:
    226
    Location:
    North Carolina, USA / Minas Gerais, BR
    I could understand narrow-block modes, like LRW or XTS, for disk encryption, and probably even recommend a wide-block mode, like EME, for better "poor man's authentication," but I don't think file encryption is the right environment for it. By using a confidentiality mode, like CTR or CBC, followed by a MAC, like CMAC, you'll get great results -- in fact, the greatest, as far as notions of confidentiality and integrity go. Of course, you'll need to make sure you use the modes properly. For CBC to be IND-CPA, the IV must be random -- not fixed or a counter. Assuming that, as well as encrypting first, then authenticating, and you'll get IND-CCA2 /\ INT-CTXT. I can break this down, and give an algorithmic view of it later, if that helps.


    Right. And I'm mostly concerned with the complexity it will add to the implementation, which is where you're most likely to make a mistake.

    Furthermore, a double cipher's effective key length is essentially no more than that of a single cipher, since the upper bound on the advantage hits one (i.e., meet-in-the-middle attack), for the double cipher, at the same point it does for the single cipher (i.e., exhaustive search). To be fair, that doesn't say all there is to say about the security of a double cipher. Rather, we can say that its security, in the Shannon model, is increased. In other words, the success probability of an adversary is much lower in the case of a double cipher than with a single cipher (i.e., it would require more queries to gain the same advantage). All in all, though, the meet-in-the-middle attack severely limits the gain; while you gain something, it is negligible. (By negligible, I mean half a bit of security for an advantage 0.5.)

    Take DES, for example. First, we model the block cipher as a family of random permutations - one for each key. The adversary gets oracle access to the block cipher and its inverse. The adversary's job is to distinguish the cascade and its inverse from a random permutation and its inverse, roughly. If the adversary wants an advantage 0.5, he'll have to ask $2^{50}$ queries, $2^{55.5}$ queries, and $2^{78.5}$ queries, for single, double, and triple encryption, respectively. You might notice that the gap between single encryption and double encryption is relatively small, while the gap between double encryption and triple encryption is significantly larger. As such, to approach the security you would expect from a composition of multiple ciphers, the minimum is three; it provides the security that one might naively expect from double encryption. Four has been shown to be no worse than three, regarding maximal advantage, but, to the best of my knowledge, we still don't know if adding more ciphers, beyond three, really increases security.

    Triple encryption increases security (significantly) in a way that double encryption cannot (negligibly); it follows that triple encryption, with three independent keys, is the shortest potentially "good" cascade, in this sense. This has been proven under the ideal-cipher model, using code-based game-playing techniques. (Note, I use "Shannon model" and "ideal-cipher model" interchangeably.)

    Have you looked at the way other encryption software handle keyfiles?

    No worries at all. You're doing great. I am slowly, but surely, refining my Brazilian Portuguese. Living there for a while certainly boosted my understanding, and being engaged to Brazilian makes it even easier to keep practicing, but it's challenging, nonetheless!
     
  3. LockBox

    LockBox Registered Member

    Joined:
    Nov 20, 2004
    Posts:
    2,328
    Location:
    Here, There and Everywhere
    Since this is being hashed out on a public forum (sorry for the pun), N8chavez, what is your role in this? In the last thread that was closed you were merely an interested poster and now you seem to be very much involved in the development of the software. I wondered why you took so many of those posts so personally in that closed thread - and I guess now we know why. For reasons of credibility and transparency, could you explain the roles of softtouch and n8chavez? Who's who and who's doing what? Who is calling the shots?
     
  4. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown
    That was the case in the other thread; I was just a very interested user trying to stick up for someone whom I felt was not being treated fairly, as I've done many times throughout the years. I have since contacted Softtouch and, I dare say, we've struck up a friendship. That being said he is the actual developer; he writes the code. I help out in any way I can, be it through ideas, graphics, research, diction writing, testing, etc. I do not write code. I provide the over-zealous imagination.

    As far as who calls the shots, this is all softtouch. If I have an idea or a problem I will discuss it with him. He is very good at listening to me, especially since I've very picky. I think it fair to say that his software has morphed into something he had not imagined since I started with him. Of course all this, I believe, is for the better.
     
    Last edited: Jul 17, 2009
  5. LockBox

    LockBox Registered Member

    Joined:
    Nov 20, 2004
    Posts:
    2,328
    Location:
    Here, There and Everywhere
    I see. That clears that up! Thanks...
     
  6. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    some might argue combined auth+encrypt modes like GCM provide the best results for such situations. (at least, you might get better parallelism in implementation for high throughput / threaded cores...)

    best regards,
     
  7. pidbo

    pidbo Registered Member

    Joined:
    Dec 25, 2006
    Posts:
    198
    Where can I download the beta?...I went to the page and there is just a full version with tvdevreg.exe and trial version.
     
  8. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown
    That's correct. Both of those, the trial and the full version are the latest beta. See here. Perhaps I am not understanding you correctly?
     
  9. Justin Troutman

    Justin Troutman Cryptography Expert

    Joined:
    Dec 23, 2007
    Posts:
    226
    Location:
    North Carolina, USA / Minas Gerais, BR
    Integrity-aware modes of operation are certainly useful; in my "Alice Tutors Bob" paper, I wrote a little about EAX, which is based on the generic composition known as EAX2. EAX2 is essentially CTR-then-OMAC1, with OMAC1 being equivalent to CMAC. It's an IND-CCA2 /\ INT-CTXT mode, to boot. GCM is also a really good design based on generic composition; it's CTR and a Carter-Wegman style MAC that uses polynomial hashing. GCM is a fully parallelizable one-pass mode, whereas EAX is a non-parallelizable two-pass mode, which can make a significant performance difference. Both are provably secure in the sense of IND-CCA2 /\ INT-CTXT, though, so they share the most secure aspects. Oh, and for those bound by standards, GCM has you covered.
     
  10. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    indeed. i will defer all further responses to Justin as he is doing a better job in this thread than i.

    (i should have noticed the "Cryptography Expert" ranking next to your name before replying. :)
     
  11. Justin Troutman

    Justin Troutman Cryptography Expert

    Joined:
    Dec 23, 2007
    Posts:
    226
    Location:
    North Carolina, USA / Minas Gerais, BR
    This result that I mentioned is based on Bellare and Rogaway's work, with the open question of whether or not longer cascades increase security. Recently, as I just now remembered, Gazi and Maurer partially answered it, by showing that for block ciphers whose key space is smaller than its message space, longer cascades do increase security up to a certain limit. An example of this would be DES.

    Haha, no, no. Please continue to post to your heart's content. I enjoy the discussions.

    Besides, I prefer to think of myself as a perpetual student of cryptography.
     
  12. DesignSecure

    DesignSecure Registered Member

    Joined:
    Jul 25, 2009
    Posts:
    4
    If you don't mind me saying so - isn't The Vault just doing what FreeOTFE and FreeOTFE Explorer do, but with less functionality than FreeOTFE/FreeOTFE Explorer?

    It sounds like you're almost trying to reinvent the wheel here?
     
  13. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown
    I am very sorry I have not been as active as I would like. I have had some medical issues lately that have taken priority. That being said, I am back and ready to answer any and all questions to the best of my ability.

    DesignSecure - I do not mind that question at all. It is very good observation, in fact my emphasis for this project was a sort of improved TCExplorer (not TrurCrypt). If you'll noticed FreeOTFE still relies on their device driver, which cannot be attached to without administrative rights. They do have a "highly portable" mode, but these rights are still required. Trying running it using a limited account, or even in Sandboxie with "Drop My Rights" enabled for the box. FreeOTFE cannot even be run in this case, and cannot be used on public systems.

    FreeOTFE Explorer is a little bit different; it does not rely on device drivers. This eliminated the need for administrative rights, but it also does not allow the 'mounted' file to act as a virtual drive. The Vault functions similarly to this. FreeOTFE Explorer can create .vol files using various ciphers. But there are areas in which The Vault is better, features that FreeOTFE Explorer does not have:

    • It is designed to be completely portable and does not require the use of administrative rights. There is one exe that's needed (and an optional ini file that stores settings), that's it. Just drop that on your flash drive and you can use The Vault from any system.
    • It securely erases any temporary files that are used, complying with the DoD-M standard.
    • The Vault give you the option to use non-default applications with file types you specify; meaning that you can use OpenOffice portable on your flash drive even if that is not the default office application on the system.
    • Users can easily enlarge their vaults if they require more space than when it was originally created.
    • Certain files (pdf, wav, mp3, wma, flv, swf, txt, asc, ini, inf, nfo, rtf, diz, pas, c, h, cpp, reg) can be viewed while inside vaults, which is done with the use of an internal viewer and does not require the files to be extracted first.
    • The Vault has an optional auto-close feature, which automatically closes any open vaults and securely erases and temporary files used. This will only occur at time when there is not user interaction. This could be quite useful should the user forget about The Vault.

    I hope that answers your question. Any file based solution, FreeOTFE or TCExplorer, etc., that does not have the ability to mount to a virtual drive is going to be limited. Our goal here was to bridge that gap as much as possible and still not require drivers, thus administrative rights.

    It is worth mentioning that both FreeOTFE and TrueCrypt require the application to be previously installed first on public systems before users can make use of it. This is highly unlikely that this will be the case, and requires the use of administrative rights also.

    Please let me know if I can be of any further assistance.

    Nathan Chavez
     
    Last edited: Jul 25, 2009
  14. 1boss1

    1boss1 Registered Member

    Joined:
    Jun 26, 2009
    Posts:
    401
    Location:
    Australia
    Internet Explorer done what Netscape had already done, Google Chrome set out to do what dozens of others had done over a decade prior. Alternatives lead to more innovation, and better functionality which benefits the end user.

    Even if they were identical (which they aren't) even minor things like the UI layout can cause different users to prefer one over the other.

    IMHO choice is a great thing, especially with niche software that only has a handful of players.
     
  15. Less

    Less Registered Member

    Joined:
    Dec 24, 2008
    Posts:
    288
    while the guru giving their expert views, please bear in mind that there isnt any "perfect" software.......

    how should it be done....... it is the developers' call...
    not about what u think it should be done...
     
  16. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown
    Thanks 1boss1 and Less -

    But there was no intended negativity from that query. I understand the skepticism, after all The Vault is not a big name. But every application that is had to start somewhere. We take somewhat of a different view with this app and that needed to be explained. I hope I did an adequate job in doing so.
     
  17. softtouch

    softtouch Registered Member

    Joined:
    Jan 31, 2006
    Posts:
    415
  18. whoarestinkler

    whoarestinkler Registered Member

    Joined:
    Apr 24, 2009
    Posts:
    12
    Fully agreed! What about cluster tips and directory entries? Does it drops a file with the entered key or like Truecrypt keeps all keys in amemory?
     
  19. softtouch

    softtouch Registered Member

    Joined:
    Jan 31, 2006
    Posts:
    415
    Slack space will be overwritten. File and directory names will be overwritten multiple times, using the maximum allowed length for file names. Trying to recover such an erased file failed with the software we tested. Files which could be recovered contained unusable data only. But we are still working to improve this.

    No key is stored on disk, it will be kept only in memory for the time a vault container is open.

    Of course, we are limited in what we can do without the help of a driver, from user land only.
     
  20. whoarestinkler

    whoarestinkler Registered Member

    Joined:
    Apr 24, 2009
    Posts:
    12
    And what about "pagefile.sys" file deallocation on exit? Do you have an "emergency" button like Truecrypt for instant dismount? Are all "after use" erase operations will be invisible for user and executed in background? If so, your software is brilliant.
     
  21. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown
    Thank you for your questions. I will try to answer them as best I can.

    It is not possible for The Vault to do this. TrueCrypt makes use of a driver, which allows it (and any similar software) to "mount" a container as a readable and writable drive. The Vault does not use such a driver. Containers are not mounted as virtual drives. Using a driver would required the user to have admin right. If The Vault was to follow the path of other applications it would no longer be portable.

    Again, the driver is what permits mounting and dismounting. Using a diver would also allow The Vault to circumvent the swap. We are currently discussing our options here, but we both feel very strongly that there needs to be a portable solution that is a bit more powerful than BlowfishCS, axcrypt, or any decent archiving application.

    Both TruCrypt and FreeOTFE recommend that users disable the swap for these reasons.

    That is the goal. In our internal tests in seems to be successful. We are discussing our options here as well. One such method would make use of third party tools such Eraser and Sdelete. Sandboxie optionally takes a similar approach using these tools when erasing sandboxes.
     
  22. LockBox

    LockBox Registered Member

    Joined:
    Nov 20, 2004
    Posts:
    2,328
    Location:
    Here, There and Everywhere
    I'm curious why you would make an application that is a "work in progress" and one that's been put together rather quickly - as paid softwareo_O The free version allows files of only one megabyte.

    Being a strong believer that crytpo software should be written by cryptographic professionals, I am even more astounded that this application is now a paid application. Even after half of your implemented ideas came as a group effort (rather bizarre) from an online forum, you are charging? Maybe that's a good thing for security as a whole as it will end up in fewer hands.

    Sorry, I just can't support your work as it's being currently carried out.
     
  23. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown
    I just love the negativity that spews from Wilders. It's fantastic. Tell me this, how are users supposed to get started, how are they supposed to develop a reputation? It seems that no one is willing to even give our software a chance because it is new. I am sorry you feel the way you do. I would have preferred constructive criticisms, but it seems that no one here is wiling to help in any way.

    We have worked very hard on The Vault, trying to implement features that users could appreciate and use. But all we get is the middle finger because we are newbies.
     
    Last edited: Aug 5, 2009
  24. LockBox

    LockBox Registered Member

    Joined:
    Nov 20, 2004
    Posts:
    2,328
    Location:
    Here, There and Everywhere
    Nate, I think my post was directly related to the fact that you are charging for this software. TrueCrypt: Free. FreeOTFE: Free The Vault: Payware
    Really, does that make any sense for cobbled together software?

    Every little bit of criticism has been met with pleas for pity rather than accepting it as part of the package when you develop software outside your area of expertise. I don't think anybody has criticized The Vault simply because it's new.
     
  25. n8chavez

    n8chavez Registered Member

    Joined:
    Jul 19, 2003
    Posts:
    3,334
    Location:
    Location Unknown

    That is because nothing that has ever been mentioned was ever in the least bit helpful; no one told of us experiences, issues, or what to do to fix them. We are just given general conceptual advice. In other words no one has ever given any indication that they have even used it before they criticize. That's what angers me. Statements like your above anger me. Why that dig? Was it necessary?

    If you have read this thread you'd know that I am not the developer of this software. I am just an interested person, who happens to enjoy research, that is willing to give unknown developers the benefit of the doubt and a little help where I can, which is something that is sorely lacking here.
     
    Last edited: Aug 5, 2009
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.