Printable View
For example TrueCrypt and GnuPG are Open Source and not broken yet.
The other exampels are Punkbuster / Digital Rights Management or any copy protection. All those examples are based uppon Closed Source and closed protocols. Also Security by Obscurity / Security by Obsfucation. Next commonness, most of them got tricked already.
Isn`t it possible to make those kinds of programs also professional, Open Source and uncrackable at least for a long while?
What makes you think TrueCrypt and GnuPG haven't been broken already?
Maybe someone has and isn`t telling us, but this is always theoretically possible and not constructive to think so. At least there is no public tool which *anyone* can easy download and click "crack".
Example: you encrypt and usb stick with truecrypt, reading the manual before and using a strong password. If the usb stick gets stolen the only attack is bruteforce and it takes to long.
Other ways are only workarrounds (using violence or hardware keylogger) but not fault of truecrypt. That`s what I mean with has not broken yet.
All of the algorithms used in TrueCrypt belong to the public domain (I know at least Rijndael does). Meanwhile, libraries like Crypto, for instance, implement a number of AES algorithms.
I'm not sure what your question is. You identified a couple of free and open source software that handles AES. Yet, your questions seems to be why there aren't any.
AES is insecure as I have stated before, it just isnt feasable for the average small country to crack it.
>I'm not sure what your question is
I think the question stems from the observation that current open standards remain in-tact, while some closed ones are broken. So why use closed encryption techniques?
The academic world definately agrees with this line of thinking, the more scrutiny a cryptographic alogrithm is put through the better its chances of being secure.
It's cryptographically secure. That means that it can't be broken by an adversary with bounded computational power. The bound is usually the inability to solve some computationally difficult problem, like reversing a cryptographic hash.Quote:
Originally Posted by abachler
Like you have stated before? When? Where?Quote:
Originally Posted by abachler
My question was if Punkbuster / DRM / copy protection could be implemented as Open Source + if them could be uncrackable. Break 2 and 3 in my first posting.Quote:
Originally Posted by Mario F.
What makes you think they have? Innocent until proven otherwise right?Quote:
Originally Posted by Mario F.
Punkbuster isn't an encryption program. You're missing the entire purpose of it.
Programs like TrueCrypt and GnuPG are working in the interests of the user. In the case of PB, if the player is cheating, PB is working against the interest of the user. In this case, in the theoretical, PB always loses. Practically, this isn't necessarily the case.
So because PB is "on site" (ie. on the computer) as far as an attacker is concered, it's easy to attack. Same with TrueCrypt, for example: http://en.wikipedia.org/wiki/TrueCry...ted_Weaknesses. Someone wanting to get through TrueCrypt could do it if they have access to the machine, but that's true for pretty much almost anything.
But again, you're comparing two totally different things. An open source version of PB would suck worse than the closed one does now. Anticheating needs to be done via different methods than what is currently being employed.
Well McGyver beat me to it.Quote:
Originally Posted by Neo1
Gotcha.Quote:
Originally Posted by Perspective
There's an unfortunate tendency on some commercial circles to believe that secrecy produces security, when it is in fact the other way around.
Please point me to this mythical non-brute-force method of cracking AES.Quote:
Originally Posted by abachler
Fast factoring
No, no no!
Fast factoring has not even been discovered yet.
AES is cryptographically secure. The problem with AES (and that of many other excellent algorithms) is the way it is implemented. That is, the wrapper application that leaves backdoors or leaks information.
that only works if one of the factors used in key generation is small. If they are chosen to be large and of similar size (as they are in current practice) than fast factoring doesn't help you. Also, this was known circa 1985 :pQuote:
Originally Posted by abachler
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.Quote:
Originally Posted by MacGyver
Or would you also consider a lock unsafe because a thief could get in if he somehow got a hold of the key?
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.
I said FAST factoring, not factoring. If you looked at something 20 years old then you didnt find fast factoring, since no method of FF for large numbers was known until 2003. There is also a way to find the discrete logorithm in less than polynomial time.Quote:
Originally Posted by Perspective
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.Quote:
Originally Posted by Mario F.
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?
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.
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?Quote:
I'm susceptible to a cold boot attack until I unmount the volume.
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.Quote:
Originally Posted by MacGyver
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.Quote:
Originally Posted by Neo1
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.
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.Quote:
Originally Posted by sept
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.
In that case, allow me to elaborate. ;)Quote:
Originally Posted by sept
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.Quote:
Originally Posted by Mario F.
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.
Quote:
Originally Posted by sept
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.Quote:
As example I did chose an usb stick. I can [..]
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.Quote:
Originally Posted by Mario F.
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.
Copy protection/DRM is an interesting situation. Let's compare it to encrypted communication.
In encrypted communication, there's users Alice and Bob who want to communicate, and attacker Charlie who wants to listen and/or manipulate. To keep their communication secret, Alice and Bob choose a symmetric cipher to encrypt the data stream. To do this, they need a shared key. They need to find some way to exchange the keys without Charlie being able to listen in. If Charlie gets the key, the encryption is completely useless.
Alice and Bob have various means of exchanging keys. They could meet in person, for example. Or they can use an asymmetric cipher to encrypt the shared key and just publish their public keys. Once the exchange is done, however, they have the key in a secret location and Charlie cannot possibly hope to get it, short of breaking into their houses. The algorithm can be completely open. That doesn't matter, because it is cryptographically secure. As long as the key is safe, the communication is safe.
In DRM, Alice is the content producer, Bob is the media playing chain (from decoder to screen), and Charlie is the pirate who wants to steal the movie. The communication is the media data. This is a highly absurd situation. To decrypt the media, Bob (the media player) needs to have the key. But Bob is a local program on Charlie's local computer. Under normal circumstances, Charlie has full access to everything on his computer. (So-called "trusted" computing means that this is not the case.) This includes the media player, which somewhere, somehow stores the decryption key. DRM's algorithms are open. AACS uses AES, which is well-known. The weakness is the key. Media players go to absurd lengths to hide the key from the user. Obviously, were the players open-source, there'd be no hope of hiding the key. As it is, it's still impossible, but Vista's funky protection features and the length to which developers go to obfuscate the key mean that it's considerably harder to find it.