Hi,while discussing with a colleague the idea came about the following encryption approach where I would like to hear your opinions about it.

Sensitive data could be encrypted by using some routine (e.g. xor; of course I knew that this offers none protection at all, but to pass the idea it's fine) which is used with a string chosen by the user. This string is nowhere stored, so it would not be possible to extract it somehow in the protected/ encrypted data with reverse engineering, DMA, etc.When it is needed to decrypt the data (e.g. by booting an enrypted hdd) the user must enter the string which was chosen for encrypting it to receive the right data. If entering a wrong string the data still gets encrypted but with the supplied string and therefore resulting in garbage data.Only attack point I came up with was with brute-forcing, but this should if chosen a strong encryption routine and string combo very time consuming, especially when you would have to reboot for every attempt.

Any thoughts on this? Is such a system already available or have I overlooked something (weakness)?This was just an idea we came up with, however, as RSA etc. seems to be quite secure there wouldn't be really a need for this, just curious on other opinions.

Well, you lose one of the big three of the CIA, availability, pretty quickly. If all it takes is one wrong key pressed and your encrypted data is then re-encrypted with that new string, I guess you're pretty much out of luck - especially in your example of booting an encrypted drive

Definitely bad for users (who can't type in their own password correctly) and fairly easy for someone with malicious intent to render data useless.

Hi,What you are describing is a lot like using a strong passphrase to protect an encryption key. Rather than use the passphrase as the key, the passphrase is used to unlock the key for use.

The xor crypto system in this case is basically a one-time pad. While one-time pads are theoretically impossible to crack when encoding short messages using them to protect computer data is a bad idea. The pass phrase would be fairly short (less than 1000 characters?) and would therefore repeat often. Known plaintext attacks (e.g. using file system structures) against an xor key could quickly reveal parts of the key.

Unless you are a propellerhead I wouldn't consider implementing your own crypto systems. The publicly available, peer reviewed systems already out there will suit your needs and there's plenty of full-disk encryption solutions out there.

I believe that with Truecrypt, you can salt the key with a file that stored on a USB thumb drive. This way, you would have to have the thumb drive with you when you decrypt the data. This would be two-form factor authentication, since you would also need a passphrase.

Truecrypt will also let you create an encrypted partition within an encrypted partition. This approach basically makes the inside encrypted partition appear as "noise." I would consider this an obfuscation technique.

I am not a crypto expert, but I would think that when strong encryption is used with the above, your data should be fairly protected.

Just to clarify - this isn't planned to implement in any working system, it was just an idea which I may use in one of my personal projects I am working on for testing purposes.

Although I am using TrueCrypt myself I haven't come across about the mentioned thumb drive thing, I will test this when I have some more time, thanks for the info. Sounds like a nice additional layer of protection to add.

Awesome, when you create an encrypted container/partition in TrueCrypt, you should have an option to add certain files as salts. You should be able to point it to a file or two on a thumb drive. I haven't tested this myself, but I can't imagine why it would work. I have often thought about testing it

When you get to the screen where you enter a password, there's a check box just below that says 'use keyfile' or similar. You can check that and then there's a button to click with additional options to specify a file to use.

I think I had used an .mp3 file and not only did it work as the keyfile, but I was still able to play and hear that .mp3 with no issue.

awesec wrote:Hi,while discussing with a colleague the idea came about the following encryption approach where I would like to hear your opinions about it.

I'd stay with the methods of encryption that have been vetted. There have been millions of man-hours spent on cracking these things so stick with the ones that are known secure.

awesec wrote:Sensitive data could be encrypted by using some routine (e.g. xor; of course I knew that this offers none protection at all, but to pass the idea it's fine) which is used with a string chosen by the user. This string is nowhere stored, so it would not be possible to extract it somehow in the protected/ encrypted data with reverse engineering, DMA, etc.When it is needed to decrypt the data (e.g. by booting an enrypted hdd) the user must enter the string which was chosen for encrypting it to receive the right data. If entering a wrong string the data still gets encrypted but with the supplied string and therefore resulting in garbage data.Only attack point I came up with was with brute-forcing, but this should if chosen a strong encryption routine and string combo very time consuming, especially when you would have to reboot for every attempt.

In cryptography there are public items and private items. In your case one of the "publics" is the software to do the encryption. I know it isn't necessarily easy, all someone has to do is jump past the portion of code requiring a reboot and they can try over and over again.