Main Area and Open Discussion > General Software Discussion

Truecrypt defeats FBI

<< < (3/5) > >>

lanux128:
The files were encrypted using Truecrypt and an unnamed algorithm, reportedly based on the 256-bit AES standard. In the UK, Dantas would be compelled to reveal his passphrase under threat of imprisonment, but no such law exists in Brazil.
--- End quote ---

a probable fallout from this case will be a change in the Brazilian method of extracting information.

40hz:
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
-Crush (June 28, 2010, 07:32 PM)
--- End quote ---

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 encryption?

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:

9frB&SNSYWlbN?TRZ+X6M&s)Sxt;2}wSL6OhAUG,`B&P|[.-O^*m%R`%JM7An`:
ge?NP2:t'%KM_Ih'!<$n+'5FnvVPGg\amea~I3,(-M~gC0;&fw:ejL3(,GJt`t<
4~B'>#4[IRb4G=)#b5o<NR)gQp=_/0QqZV~mOawt|%.HEEA=-@PLoS[CI;1?}C"
cUU+xoO0!>/wqq`VhY/H81?)`TgXLq''YCq{Zl?1BX|fAyo6X:(Kq;$-_q':<7%

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...

Crush:
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 encryption?
-> Crush Cryptonizer does it
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.
-> Crush Cryptonizer doesn´t uses the filename, but random salt is generated or can be loaded by a hardware random number generator. I started Crytonizer 2.0 that also can handle hardware informations for encoding/decoding and I´ll also include the destination filename.
The One Time Pad can be used to generate a very long filename - it uses the complete content of a selected file in full length. In Cryptonizer 2.0 it will be combined with the password.

Eóin:
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.
-40hz (June 29, 2010, 01:17 AM)
--- End quote ---

My question would be, how likely is it that someone would know how to generate your password? A good security system is one that can stand up to an attack even if every detail of it's implementation is known by the attacker.

Crush:
I have a new idea how to make passwords for encryption more secure: http://www.youtube.com/watch?v=YzVZbgpHJYg
Even if others know it they cannot login if they are not you!

Navigation

[0] Message Index

[#] Next page

[*] Previous page