40hz: I´ll do it. Tell me your wishes for such a program.
mwb1100: I made a file-encryptor with implemented OTP that has a hardware radioactivity as a source for pure randomness: Crush Cryptonizer
Not trying to make work for you, but if you're looking for a NANY project here goes...
Tell me if this makes any sense:
The biggest problem with most people is their passwords. They're too short, too simple, and lack sufficient randomness.
What if there were an encryption package that took a relatively easy to remember password and used that as a seed to produce a very complex, very long password that got used to do the actual
That way, you could know your file was encrypted using AES or Blowfish or whatever; and you could know that the password you used to do the encryption was something like i<399ntyRNs
. ("I love 99 naughty nurses!") - but what you wouldn't know is the real
password used for the encryption because the app used your i<399ntyRNs
to generate something like this to do the actual encryption:
It might also be cool to use the user password in conjunction with something like the filename for the seed so that each generated
password would be different for each file, even though the same user
password got repeatedly used.
So now, the 'real' password for FILE01.TXT would be totally different than that for FILE02.TXT - despite user password: i<399ntyRNs
being the same on both.
This offers three advantages:
1. The file is encrypted using a highly long and complex password that has a good degree of randomness. And even though it's not genuinely random, it's still more random than most people could come up with. (Our minds are so full of subconscious associations that it's next to impossible for us to be random.) Now those 256 or 512+ character passwords become viable even though the user doesn't know what they are or ever have to remember them.
2. In order to decrypt the file, you'd also need to use the same app that generated the complex password. So having the file and knowing what the encryption algorithm and user password was wouldn't help you decode it unless you knew the internally used password - or knew how to generate it.
3. Each generated password is different for each differently named file even if the same user selected password gets used repeatedly because the file name is also part of the seed. So now there's less of an issue reusing an easily remembered user password so long as each filename is different.
Note: rather than screw around with a hex editor and binaries, you could get a similar result by manually renaming the file after encryption
. Since the name is part of the seed, doing something as simple as adding a digit
to the end of the file name (i.e. FILE123 becomes FILE1230) would break decryption even if you had the app and the user selected password.
Sorry... it's late, I'm exhausted - and I'm probably rambling and repeating myself by now...