Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Call me paranoid, but I really like to keep my stuff secret, but readily available on the cloud. So, asking this question.

  1. How safe and reliable is encryption software (e.g., truecrypt)? The reason I ask is that, what is I encrypt my data today with this software and after a couple of years, the software is gone ! What happens to my encrypted data?

  2. Is it equally safe to AES encrypt using 7-zip? Will it provide the same level or equivalent level of encryption as truecrypt or other encryption software? (I agree truecrypt will be better because of the container encryption it gives.) And what happens if 7-zip shuts down after 5 years?

I am sorry if I am sounding paranoid, but I am coming back to my original question... Is there any application/software independent encryption? Meaning, can I encrypt with one software and decrypt with another so that I will not be dependent on just one vendor? I want my encryption to depend ONLY on the password and NOT on the encryption program/software?

The next question, can I write my own program that does AES/stronger encryption when I give it a passphrase, so that I don't need to depend on third party software for encryption? If yes, which language supports the same?

Can someone give me a heads up as to where to look for in case of writing my own encryption program?

share|improve this question
1  
7zip and TrueCrypt are open source - I don't think you're going to have to worry about that code disappearing from the face of the earth. But if you want encryption without any additional things like what TrueCrypt and 7-zip may be doing - you can encrypt your data directly with, say, AES, and can use any other program that can decrypt an AES stream. –  birryree Nov 9 '11 at 18:21
2  
From my point of view the assumption that OSS is more secure by definition, because anyone can read the code, cannot hold. Proven by Debian, which had a weak random key generator in the OpenSSL package for 2 years and nobody did notice. debian.org/security/2008/dsa-1571 –  Simon Jun 29 '12 at 12:03
1  
It's anecdotal but this story about the FBI's inability to crack a Truecrypt drive after 12 months of trying definitely gives me some confidence in the software. theregister.co.uk/2010/06/28/brazil_banker_crypto_lock_out –  Andrew Jun 29 '12 at 16:10

5 Answers 5

up vote 17 down vote accepted

Don't write your own encryption program. You will do something wrong.

Media persistence like you talk about is a real problem. There are tons of old records stored on reel-to-reel tapes and not much equipment left to read it. You as the data owner will have to make sure you're moving to newer technologies as appropriate.

That said, 7zip is open-source. You can grab the source, build it yourself, and save that compiled binary. If 7zip shuts down in 5 years, you still have your copy of the binary -- the same one you used to do the encryption. Use it to do the decryption.

If you're going to be storing data for long periods, I'd also suggest including some kind of PAR2 recovery data alongside the encrypted container, to repair the container against literal bit rot.

share|improve this answer
1  
Better yet, keep the source code so you can compile it on your current operating system (for when Windows gets obsolete). –  Shahbaz Jul 18 at 9:20

AES is the way to go, it is the current standard encryption algorithm, which means it is the ones which gets more attention and real-life cracking attempts, a great value for assessing encryption algorithm's security.

You can go for AES256 to benefit of the longer key, 256 bit of asymmetric encryption keys are over-killing for today's (realistic) understanding of future proofing.

If you want more, you can resort in multiple encryption chaining, i.e. AES+Twofish+Serpent, that is sound for current consensus.

However, future proofing would be quite tricky: casting guess about possible math breakthroughs is plainly not possible, and even doing projections about computing power growth in one or few decades introduces huge levels of uncertainty.

This, as of theoretical backgorund, but on end user's perspective implementation is often the critical point, and that is the main point why no one without solid experience in cryptography (both math and real life implementations) should not consider about implementing their own cryptosystem.

A software providing encryption should sustain a large amount of test and auditing (better if public, security by obscurity, as a role of thumb, does not work), starting from the code (does it contains malicious code? i.e. how can we trust Truecrypt after recent concerns about latest releases?) and even the compiler (was it tampered to inject malicious code?), the software and the platform itself (does it leaks memory or temp files? does the OS keylog me? is there some malware running? etc), and finally the hardware - was it tampered? is it safe from TEMPEST-like attacks intercepting em signals from keyboard, screen, internal circuitry - that's why some high grade encryption solution runs on dedicated hardware.

share|improve this answer

Can I still decrypt it in 10 years?

The file format for true-crypt containers is documented, and relatively simple. Writing a decryptor shouldn't be hard. The complex part is the file system, such as NTFS storing the files withing the container. But since there are open source drivers for NTFS, I wouldn't worry too much about that either.

So I wouldn't worry about the data becoming unreadable. Losing the ciphertext is much more likely than being unable to decrypt it.

How secure is it?

Concerning security, the strength of AES itself is probably sufficient, and if you're truly paranoid about progress of cryptoanalysis, you can use cipher chains.

There are some other issues:

  • An attacker who sees multiple revisions of the container can see which blocks were changed. This is typically the case if you host a container in the cloud. In particular this reveals hidden volumes.
  • The Key derivation function that turns the password into a key is rather weak. It uses only 1000 or 2000 iterations, making it quite fast to bruteforce i.e. the cost per password guess is pretty low. scrypt with well chosen parameters would make bruteforce harder by a factor of a million or so. This means you should choose a really high entropy password.
  • No integrity checks. An attacker can change arbitrary blocks of your container, changing the associated plaintext without TrueCrypt noticing.

While TrueCrypt has its flaws, it's very unlikely that a beginner will produce something more secure.

share|improve this answer

application/software independent encryption ... where to look for in case of writing my own encryption program?

Yes, future proofing data is a good idea. By choosing a good file format -- preferably some "open" format that already has several applications that can read it -- it makes it more likely that at least one application will exist (or can be created) in the future, such that we can read that data in the future.

I agree with "insta" that there isn't anything significantly better than using AES encryption with any of the open archive formats such as 7z, and then store in multiple locations either: copies of that encrypted file -- or PAR2 recovery volumes generated from that encrypted archive file. And also storing the encryption passphrase in a few places so we can find it again in the future.

Applications that already support decrypting data stored in that standard AES-encrypted 7z file format include the 7-Zip archiver, sevenzsharp, Ark, PeaZip, File Roller, and a dozen other applications.

Writing your own encryption/decryption program entirely from scratch probably won't produce anything better -- and is highly likely to produce something much worse -- than using some pre-existing AES library or application.

However, the process of writing such a from-scratch program can be highly educational.

In principle, you could implement AES-256 "from scratch" directly from the AES: FIPS-197 standards document, in any programming language. If you don't already have a favorite programming language (or a language you've already selected as one you want more practice using), I hear that Python is popular among people teaching a first programming course ( Criteria for selecting language for first programming course ).

However, FIPS standards are a bit difficult to read. If you want to write yet another "from scratch" implementation of AES, I recommend (in no particular order):

Each of those things helps you learn things that make the standards document easier to understand.

share|improve this answer

Best tools for encryption are standards based with the implementation per reviewed. 7 Zip, using AES and being open source meets these needs.

Don't waste anymore energy worrying about the tool you choose if meets those two basic requirements. For decades the weak point has been the endpoints. No need to break AES, just steal the key, put a gun to the key holders head if you have to, offer someone who has access a bucket load of money, if it's worth it... it's easier, cheaper and faster than cracking AES.

What you need to concern yourself with is key management and protecting your key. How are you going to stop someone stealing it, and if they do, how are you going to know they have it? Note that changing the key is hard, as you need to decrypt and re-encrypt all your data. Your backups become useless (unless you keep the old key, which almost defeats changing it). I suggest some light:) bed time reading - Bruce Schneier - Secrets and Lies would be a good start.

share|improve this answer
    
I do not understand your point about changing the key. I as the attacker will presumably have copies of all your encrypted files. If I can steal one of your keys, you have to assume that I can steal the associated data. Decrypting and reencrypting will not protect you. –  emory Jul 8 '13 at 20:48
    
@emory: You do have a point. Changing keys and passwords is purely and solely because of the risk of a key getting compromised increasing over time. An old key will access a copy of old data, but not be able to access more recent data. It depends how time sensitive the data is. The reason I mentioned changing keys is it is considered best practice in most cases, but in this case, may not be a good idea. –  mattnz Jul 8 '13 at 22:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.