So when leaving the password in memory it is possible to extract it and mount the volume again? Well this is not much different from writing the password on a piece of paper and leaving it in the open, that can hardly be considered a weakness in the program, rather a weakness with the user that is using it. All one needs to do is unmount the encrypted volume properly before shutdown.
Or would you also consider a lock unsafe because a thief could get in if he somehow got a hold of the key?
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
Are you fishing Neo? It's hardly the same thing. This has to do with how TrueCrypt operates.
This is not to say TrueCrypt is a piece of crap. It's to say that it is susceptible to attack. The form of the attack is irrelevant in this context.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Using the key to decrypt an encrypted volume can hardly be considered an attack? The user leaves the key in memory because he/she didn't close the encrypted volume properly.
As long as the volume gets dismounted properly, the password won't be left in memory for anyone to see. I fail to see how this is much different from leaving the key in a lock?
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
You are failing to see my point and I'm probably not doing a good job explaining it.
It's not the algorithm that is under attack. It's the application security features that support the algorithm that are. I agree with you if we were discussing the former. However, we are discussing TrueCrypt, the application.
I'm susceptible to a cold boot attack until I unmount the volume. I can conceive numerous situations in which this could happen. Cold boot attacks are highly effective. TrueCrypt doesn't support a safeguard mechanism.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
A safeguard mechanism? To make sure that the key gets deleted from memory if the system shuts down for other reasons than the user requesting it? Is this even possible, i mean, in the case of a power shortage for example, there is nothing that the TrueCrypt devs can do to avoid the key being exposed in memory.
Code:if(POWER_SHORTAGE) { delete password[]; return 1; }
In that sense you are right i guess, but then again, this applies to all other cryptography applications, so perhaps it is not a specific problem with TrueCrypt, but rather a weakness in PC cryptography in general. There is not much to do about it.
Well you're not susceptible to cold boot attacks as long as the system is on, or have i misunderstood something crucial?I'm susceptible to a cold boot attack until I unmount the volume.
How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.
Coldboot attack. Kinda offtopic. That`s some external attack. Sure TrueCrypt is only secure as long you dismount your volumes.
SSL from Client to Server is also only secure against man in the middle as long it`s used like the manual says and not local attack to Client or Server
All applications are only secure under a number of conditions. For TrueCrypt:
- secure if no local attack if the container is mounted (coldboot)
- if no hardware keylogger
- if no violence used
- no trojan running while volume mounted
- no weak password
....
But these attacks are not fault of TrueCrypt itself. TrueCrypt IS secure as long proven otherwise.
Good posting. I as looking for these kind. Sounds interesting and logical for me.
Well, a "cold boot" reads data from RAM. Consequently, It needs the computer to be on. Depending on the chips and their temperature at the time of shutdow, a computer can be susceptible for a few hours. But not turning off a computer (or having it in sleep mode as I do often even when back and from work) definitely constitutes the highest risk.
I guess one could consider this to not even be an application attack, but an hardware attack. I can concede there. However some software already creates mechanisms to at least mitigate the problem. PGP, for instance has something called virtual drives, but I'm unsure as to how exactly they work.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I really don't want to do of this a new religion, but you better check your statement. TrueCrypt is not secure to at least one known attack. That makes it insecure. It's irrelevant what you think of that attack. The bottom line is that it is insecure.
If the folks at Princeton thought like you, they wouldn't a) invest their time and effort to try and find holes in well known applications and algorithms and b) warn the makers and the industry in general to help them make their software/hardware/whatever more secure.
It's not off topic. You brought the subject of security. And this subject is much more than, as you keep saying, reading the manual. Live with it.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
In that case, allow me to elaborate.
Think about PB's mission. PB isn't about hiding information as much as it is about finding hidden information on a hostile system. When you consider that type of mission, you realize it's practically impossible to get perfect. Probably theoretically impossible to get perfect, too.
The real solution to anticheating is heuristics. The behavior of all players can be translated into mathematics, and analyzed.
For me it`s secure.
As example I did chose an usb stick. I can
1) encrypt it with truecrypt
2) copy some data on it
3) dismount it
4) now travel from A to B
5) mount it
6) read data
7) dismount it
If I now lose the usb stick while traveling from A to B then all my data is secure. No one can download a tool and click crack and no one can pay 1.000 $ to write a program which can unscramble the data.
As soon someone has interest to pay more then 1.000 $ them can simply show me a gun and I will tell them whatever they want to know. Also breaking into my house while the container is still mounted and stealing my ram would work.
That`s what I mean with secure. Sure there is nothing 100% secure and I did not want do argue with that. There are always tricks. Someone who breaks into my house and installs a small hardware keylogger also got me. But it`s not fault of TrueCrypt. Currently TrueCrypt does a perfect job, there is nothing much the developers could do much better to improve security.
Really? Well, yes they can and surely they will.
One example? They can and probably will implement solutions similar or better than those in place for PGP
Meanwhile I advise you to curb that enthusiasm of yours when the TrueCrypt development community itself agrees there's a lot more to be done (here and here). The cardinal sin of software like this is to think "there isn't much more to be done to improve security", as you put it.
Sure you can. And you can also leave your encrypted, mounted, stick on your office computer while you go and take a leak. Meanwhile, your jealous geek colleague can rip off your work.As example I did chose an usb stick. I can [..]
Last edited by Mario F.; 03-11-2008 at 05:54 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Yes, it`s ok. TrueCrypt isn`t perfect (no software is perfect) I have loads of suggestions but it`s working, it`s very good and I am happy about it`s future development.
This isn`t a fight of words where I create a theoretically environment and you find ways how an attacker could theoretically break into this theoretically environment.
In this case I didn`t say that my comp is also encrypted. But I didn`t want to write a book, just a posting.
The goal was to ensure the transport from A to B and for this little situation itīs just working very well.
I see talking about security in IT is just talking about little problems. Otherwise you end up with arguing about a backup tool "yeah, but if war breaks out and you get hit by an atom bomb you end up dead and all your data is lost, so better store your data online on at least 100 different servers".
Actually its a lot simpler than that. Just as I've been trying to tell you it is simply a matter of establishing if some application or encryption algorithm offers ways it can be attacked, compromised or exploited.
There is nothing wrong in saying yes. What would be really strange would be saying no. It is exactly because of this that we ended discussing "little problems". Because it really irks me to hear anyone saying "it's perfectly secure", "it has never been broken" or "there is nothing more that needs to be done".
90% of the security of your data lies in your mind. Encryption algorithms and the software that wraps them only do 10%. Meanwhile, not knowing the issues is bad, ignoring them or refusing to accept them is...
---
Going back to your initial question, I don't know really (even though there are commercial software running on public domain algorithms, mind you).
But I completely agree with the concept that the more an algorithm is exposed to the public scrutiny, the more secure it can become. However there still seems to exist a school of thought that believes today encryption should still behave like in WWII where security was achieved through secrecy. Why they still believe in this, I have no idea. As you well pointed out, all of them without exception were sooner or later found to be inadequate.
One possible cause could probably be an attempt to reach a non public domain algorithm offering a high level of security. A private company that finds this could make a load of money. So, the "Secrecy Ideology" may not be a true reason, but instead a strong desire to achieve a private domain algorithm that most certainly would skyrocket any company shares through nasdaq roof.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.