The Vault Development - Encrypt files

I decided to continue developing The Vault because I see that it has potential.

Learned from the old thread, negative and positive comments, I have re-designed the program, remove the algorithm and replaced them with open source algorithms.

Before bashing me or the program again, I would like to have a clean discussion about the program, which will help me to improve it further.
You might ask "why the hell does this guy post it here again?", the answer is, here at wilders are many security specialists, and any comment from them will only help me to make the program better.

The current beta version does not delete or modify original files added to the vault.
We all know that beta versions (and even final releases) will have bugs, sometimes not seen by the developer. It would be nice to have the reported, so they can be fixed.

The Vault will fit the need of the average user, not the security specialist. It is portable, and does not need installation.

Feature summary of the current beta at the moment of this posting:
- Allow to add files and folder (internal functions and drag n' drop from Explorer)
- Allow to rename/delete files and folder
- Display files and folder in a treeview (with drag n' drop support)
- Allow to run files out of a vault
- Allow to extract files and folder
- Encrypt file and folder names
- Allow to create new vault's anywhere on the HDD
- Can transfer an existing vault to new locations
- Secure erase files and folder which are deleted
- Create and delete folder in a vault to organize the files
- Provide a performance test
- Can display the content of a file en- and decrypted in a hex editor
- Assigning applications to extensions
- Defining the pattern for the secure erase function

I completely removed the previous implementation of the encryption algorithms and use now the open source cipher and hashes developed by David Barton and maintained since 1999. Source can be downloaded on the website of David Barton at http://www.cityinthesky.co.uk/cryptography.html

I implemented the following cipher and hashes:
Cipher: Blowfish, AES, Serpent and TwoFish
Hashes: MD5, Sha256, Sha384 and Sha512

When the user create a new vault, he can select the cipher and hash for this vault. Each new vault can have different encryption.

The Vault does not use a single file system anymore. Files and folder are in physical folder on the harddrive.

Files executed out of a vault will be extracted to the temp folder and started from there. The Vault will try to determine the program which will open the file extracted, run it, wait for its termination and secure erase the temporary file. In case the file was modified, the file in the vault will be updated with the new file.

The download of the beta is at http://www.delphifreeware.com/thevault

Actual screen shots and descriptions can be found there too.

 

The program, in it's current state is full of bugs. I have a suggestion, if you are really serious about this application, first learn to beta test it and debug it yourself. Otherwise, there will be countless bugged versions, and by the time you will release a final bug-free version, nobody will trust your application anymore. And trust is a very important factor when it comes to security related apps.

Here are some examples. For instance, if I add a file to the Vault folder, your application crashes (because you are wrongly assuming that nobody will modify that folder). Even worse, if I delete your locations file, you don't find your vaults anymore! When you secure erase a file in the Temp folder, you first rename it to SECURE_ERASED, but you don't bother checking if the file exists, or if there is another folder with that name; this results in failing to delete the original file at all. You zip your config files with a password (presumably to make a backup), but you don't use the password user provided - is that a program generated password? If so, wrong again, as I already told you in another thread.

 

Thanks for the hints.
I expected that in the beta, I am not surprised. And your feedback helps to solve such issues.

The zipfile is just a backup, so it does not need to use anything else than a program generated password. It contains the thevault.ini, which is encrypted.

The SECURE_ERASED thing is true, thats a critical bug, and will be fixed quickly.

About deleting files, of course, you can even screw up Windows by just deleting files. But I get your point.

Can you explain me what you mean with this "(because you are wrongly assuming that nobody will modify that folder)". Do you mean user modifying the folder in the background or what do you mean?

 

Hi there, don't worry about it. Great to see you again. Please continue your good work.

 

Softtouch, to clarify, what precisely is the problem that The Vault is seeking is solve? Based on the list of its features (see here), the application seems to be duplicating functionality provided by WinZip (and perhaps other utilities).

Please don’t interpret my comment negatively. I am simply suggesting that you should have a well articulated vision for The Vault and a clear sense of how it is different (better) than alternatives.

P.S.: Welcome back to the forum!

 

Hi Pleonasm,

if I think about it, yes, you are right. But does not any "file manager" allow adding, deleting, extracting files etc.?

And yes, people could indeed just use WinZip or similar.

One difference to winzip would be that it erase the files and that the erased files (even when recovered with recovery software) will have no valid content.
A second difference is that is is much faster extracting or executing files then winzip.
Other than that, yes, I don't see much difference to other compression utilities in the current beta.

V0.9.4.10
- Secure erased improved
- Ini files are locked during the time The Vault is running
- Restoring of initialization files from backup improved
- Started with coding of monitoring folder and file changes from outside the vault

 

From what I've read you should just choose the most secure and have no other options, that would be AES and MD5 I think.

 

Speed wise, I would remove the serpent. All other cipher and hash combination can encrypt with about 68mb/s on my pc, except serpent, which tops at 14mb/s.

Comparing MD5 and SHA, SHA should be better as the hash.
SHA is slower than MD5, but the larger digest size makes it stronger against brute force attacks.

 

Softtouch, another difference between The Vault and WinZip is that the former appears to have the ability to encrypt file and folder names. With the latter, you need to embed an archive within an encrypted archive to hide the file/folder names (which is a trivial process, but an extra step nonetheless). Because this issue arises from compliance to the industry standard ZIP file format specification, all such compatible compression utilities will have the same limitation.

Another related utility that you may wish to examine for ideas to enhance The Value is PGP NetShare. This tool allows a user to encrypt a folder such that all files/subfolders created therein are automatically secured. Access to the folder by the user or by an application is completely transparent (after the user’s passphrase has been entered once during the session).

 

Pardon my late addition, but this is just a heads up that I'll be elaborating on my thoughts about this later today, so please do keep checking back. It's something that I believe will serve you well.

Cheers,

Justin

 

Justin - I wanted to let you know that there have been a lot of big changes to The Vault recently. Most of them have not yet been released and are in internal builds only, as of now. The cryptography algorithms used are now those that are open source, such as FreeOTFE. The Vault has changed from encrypting individual files to using encrypted areas of the disk, like TrueCrypt and FreeOTFE. I am not sure if this will effect your comments but be aware that there is a new internal build with many changes and/or improvements. It is coming along quite nicely.

Please PM me if you would like a copy of this build.

Softtouch and I will be happy to help in any way we can.

Thank you all for your help.

 

Pardon my delay in posting my comments.

First, as much as I applaud any cryptographic effort, when it comes to implementing it, if it's going to be serious, production software, then I recommend that only those with cryptographic experience develop it. Cryptography has, arguably, the best track record out of any of the proverbial security onion's layers; when it does fall apart, it's almost never because of the cryptography itself, but, instead, the implementation. Although I wouldn't advise deploying your software where security is actually of any concern, I'll still provide some pointers, should you decide to continue.

Second, I notice that you've whittled your cryptographic primitive choices down to a few; that's great, because the more cryptography you cram in, the more complexity you introduce to the implementation. As the ol' adage goes, "complexity is security's worst enemy." Essentially, to achieve the strongest notions of confidentiality and integrity (IND-CCA2 /\ INT-CTXT), you need an IND-CPA encryption scheme and a SUF-CMA authentication scheme, applied in the Encrypt-then-Authenticate composition. You can take care of this with the AES alone; for example, encrypt first with AES-CTR, then apply CMAC-AES to the ciphertext.

Third, as hinted to above, you need authentication. While encryption preserves confidentiality, authentication preserves integrity. If the importance of this isn't clear, try to think of scenarios where being able to manipulate information is worse than being able to divulge it. It follows that a lack of integrity preservation can lead to a loss of confidentiality preservation. I've written about this in the past, in an article that was adapted for IEEE Security & Privacy; you can read it here. It includes great references that further support the strategy that if you're going to encrypt, you need to authenticate too.

(The article, which briefly introduces the concept of "green cryptography," has been extended to elaborate more on his new recycling-based design paradigm and will appear in an upcoming two-part series co-authored by myself and Vincent Rijmen, co-designer of the AES.)

Also, given the parallel to WinZip, it might be useful to point you towards cryptanalysis of WinZip and WinRAR. It echoes the difficulty of cryptographic implementation and how the most subtle of subtleties can undermine the security of what appears to be the proper composition of encryption and authentication. It's not just the data that needs to be secured, but the metadata, as well; otherwise, information can, and probably will, leak.

Gary S.-W. Yeo and Raphael C.-W. Phan present attacks on WinRAR, in their 2006 paper, entitled, "On the security of the WinRAR encryption feature." In the abstract, they state, "Our results, compared to recent attacks on WinZip by Kohno, show that WinRAR appears to offer slightly better security features." Tadayoshi Kohno presents attacks on WinZip in his 2004 paper, entitled, "Attacking and repairing the WinZip encryption scheme." Here's a link to the full paper by Tadayoshi Kohno, entitled, "Analysis of the WinZip encryption method."

That's all I've got time for at the moment, but I'll do my best to ponder over it some more and contribute more later. Until then, do give this some thought, and reconsider the goal of this project. If you're going into it without experience, then it's probably best left as an exercise in learning.

 

My understanding is that only malleable cryptographic algorithms permit an attacker to intelligently alter the contents of an encrypted file. For this class of algorithms, it’s important to digitally sign an encrypted file to ensure content integrity.

Question: In practice, which common cryptographic solutions are malleable? Which are non-malleable?

Thank you.

 

Contrary to what many might think, block cipher confidentiality modes of operation are malleable, and that's because they're designed to do one thing: preserve confidentiality. It's often much easier than it might seem to make controlled manipulations to ciphertext; even seemingly unintelligible decryptions shouldn't be discounted as harmless. You could say that authentication is more important than encryption, when you consider the effects of being able to manipulate information versus being able to divulge it. It's important to understand the distinct goals of encryption and authentication; that is, encryption is to confidentiality what authentication is to integrity.

To answer your question, in the context of symmetric cryptography, encryption schemes provide confidentiality, while authenticated encryption schemes provide confidentiality and integrity. There's a catch though; the order of encryption and authentication has an effect on the composite's malleability or nonmalleability. I recommend reading Bellare and Namprempre's work on this, titled, "Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm," as it covers all of the bases. This work serves as the basis for my advocation of Encrypt-then-Authenticate, or Encrypt-then-MAC, as they call it.

 

Thanks for the reply, Justin.

Yet, I still wonder about whether intelligently manipulating ciphertext is a “theoretical” problem with essentially no real-world risk. For example, if an adversary gains access to a 1 MB encrypted file, the foe can “splice” into the file new encrypted content thereby altering its integrity. However, the placement of that new content within the file cannot be done intelligently—since, the adversary isn’t able to decrypt the file. Thus, an adversary can "corrupt" the contents of an ecrypted file, but that is certainly not the same as intelligently manipulating ciphertext.

Comments and clarifications?

 

Nice program softtouch, been giving it a spin and i like it. Glad to see you continued it after the last thread.

Did you seriously make Galaxy Fight? I'm positive i still have that on disk boxed up in the shed some 22 years later

 

It was much improved compared to the last version. Glad you like it.

Yes, I wrote that little game, a long long time ago... as I was still young...
It was the first game I wrote, in assembler.
You can see in the biography on my website what games I wrote, maybe you know some other too.

 

As I previously mentioned, The Vault has been under some intense changes lately. I believe it is now ready to be beta tested by a wider audience. Please be aware that it is beta, as version 1.0 is not yet ready to be released.

Feature List:

• The Vault now uses the open source ciphers AES 256, Blowfish 448, and Twofish 256.
  
• MD5 128, SHA 256, or SHA 512 hashes are used when creating vaults
  
• It now securely erases any temporary files that are used, complying with the DoD-M standard.
  
• The Vault is designed to be portable. It does not make use of drivers. This allows user to not have to worry about not having administrative privileges when using a flash drive.
  
• It can also be used on a workstation, and allows for large vault sized and registering of the .vdr extension.
  
• Entire folders can easily be imported into a vault.
  
• 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.
  
• Files can be edited, having the changes save to your vault. This is done be first extracting the file to a secure temporary location. These temporary files are securely erased when they are no longer in use.
  
• The Vault allows users to specify which application they would like to be the default for encrypted files, which is particularly useful with portable office applications
  
• Folder hierarchies are not permitted, allowing for greater organization.
  
• Entire folders can now be extracted (securely), which allows for greater compatibility with portable programs.
  
  
• The Vault now 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.
  
• It now allows for the use of a keyfile, which allows the user to access their password, should they forget.
  
• The Vault can now transfer files, vaults, the executable, and user preferences, over to other locations.

A lot of work has gone into this project. Yet we understand there is still a lot left to be done. We would greatly appreciate any constructive feedback we receive.

Thank you.

Nathan Chavez

 

why only 256? do you have a gigantic quantum computer in your garage that is a risk to 128 via quantum search? (did you see the paper breaking aes-256 down to 2^119 (but not AES-128 ), etc)

WHY

great.

this is only true if paged memory, swap, page cache is not operating and/or you go the driver route with elevated privs to lock pages. next!

run the software on/in totally compromised environments and never know! thanks!
(seriously, this is not a benefit in any sense other than not ****ing up the host kernel or requiring a reboot)

you call this a feature? BAD!
(if i have to explain why this is bad, then i don't need to bother explaining it to you...)

again, another claim without merit.

please remove the "features" which destroy privacy in the name of convenience.

best regards,

 

Confidentiality modes of operation, such as CBC, are insecure against chosen-ciphertext attacks; it follows that CBC can be manipulated in an intelligent way. CBC recovers from errors within one block and Bellovin's cut-and-paste attacks on IPSec exploit this property. Quoting from a '97 paper by Wagner and Schneier, analyzing SSL 3.0:

Obviously, the extent to which intelligent manipulation can occur is largely dictated by the application, the smart thing to do is authenticate (i.e., use a MAC). CBC was never intended to provide integrity; if you ask anything more from it than confidentiality, you're asking for trouble. This is the best general advice I can give developers, because they almost always expect too much; tragically, many aren't aware of the importance of integrity or even what a MAC is. Conceptually, you might say, "If my goal is confidentiality, then I need encryption." Realistically, even if you're only goal is confidentiality, you're going to need authentication, too. (Note: I use authentication and integrity interchangeably, within the context of symmetric cryptography.)

AES with a 128-bit key would suffice, and conservatively, at that. It simplifies the implementation, which is where you're most likely to commit a blunder and have any security hopes fall apart; that's the way it usually goes, when it goes.

What happens if I manipulate the vault, then recompute a new hash value on the manipulated vault? Hash functions are unkeyed, so there's nothing to stop me from recomputing it on any alterations I make. A keyed MAC solves that problem.

 

Yes i know a couple of the others, but i especially remember Galaxy Fight because when i first upgraded to the Amiga i didn't have many games for months and it was one of the first i got.

Wow, i can't believe i've bumped in to the author of that game over 20 years later. I'm pretty sure i had your C64 Tips & Tricks disk also, just not the book.

SID & VIC, PEEK & POKE.. Your page sure brings back some great memories. Great to see you are still releasing programs.

 

How is this coming along?

 

I believe this is coming along quite well. We are working on a few things, stripping and backing up the header, possible LRW mode, and a possible keyfile generator, header encryption, and possible double encryption. We have decided to eliminate the password recovery feature, taking the stance of other like BestCrypt where if you forget the password you're SOL.

I would very much appreciate any and all feedback on this, specifically the implementation of the ciphers used. I am by no means a cryptography expert, that is softtouch's area. That being said, I would consider it a great learning opportunity if you would go into detail in regard to any weaknesses there are.

I believe it is going well. Others might not think so, but I'd appreciate any feedback that will help us fix any issue.

 

What's the rationale behind implementing LRW mode?

Again, what's the rationale behind double encryption?

 

I have to agree on this matter. I am not a friend of LRW, and I consider not to change then encryption or integration of it any further at this state of development.

A double encryption does also not make sense to me, it will not improve the security at all in my opinion, just will slow down the encryption process.

What we are doing at the moment is to find back doors. One of the backdoors *could* be the keyfile, so we might remove the feature to create a keyfile.

Sorry that I cannot explain it better, I am not a native English speaker...