Punkbuster / DRM / copy protection as Open Source?

This is a discussion on Punkbuster / DRM / copy protection as Open Source? within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Originally Posted by abachler Fast factoring that only works if one of the factors used in key generation is small. ...

  1. #16
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    Quote Originally Posted by abachler View Post
    Fast factoring
    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

  2. #17
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by MacGyver View Post
    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.
    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.

  3. #18
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  4. #19
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Perspective View Post
    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
    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.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  5. #20
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    Quote Originally Posted by Mario F. View Post

    The form of the attack is irrelevant in this context.
    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.

  6. #21
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  7. #22
    Internet Superhero
    Join Date
    Sep 2006
    Location
    Denmark
    Posts
    964
    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.

    I'm susceptible to a cold boot attack until I unmount the volume.
    Well you're not susceptible to cold boot attacks as long as the system is on, or have i misunderstood something crucial?
    How I need a drink, alcoholic in nature, after the heavy lectures involving quantum mechanics.

  8. #23
    Registered User
    Join Date
    Jul 2007
    Posts
    88
    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.

    Quote Originally Posted by MacGyver View Post
    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.
    Good posting. I as looking for these kind. Sounds interesting and logical for me.

  9. #24
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    Quote Originally Posted by Neo1 View Post
    Well you're not susceptible to cold boot attacks as long as the system is on, or have i misunderstood something crucial?
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  10. #25
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    Quote Originally Posted by sept View Post
    But these attacks are not fault of TrueCrypt itself. TrueCrypt IS secure as long proven otherwise.
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  11. #26
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,211
    Quote Originally Posted by sept View Post
    Good posting. I as looking for these kind. Sounds interesting and logical for me.
    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.

  12. #27
    Registered User
    Join Date
    Jul 2007
    Posts
    88
    Quote Originally Posted by Mario F. View Post
    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.
    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.

  13. #28
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    Quote Originally Posted by sept View Post
    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.

    As example I did chose an usb stick. I can [..]
    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.
    Last edited by Mario F.; 03-11-2008 at 06:54 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  14. #29
    Registered User
    Join Date
    Jul 2007
    Posts
    88
    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.

    Quote Originally Posted by Mario F. View Post
    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.
    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".

  15. #30
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,575
    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&#37; 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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. How to add copy protection to a software?
    By h3ro in forum Tech Board
    Replies: 43
    Last Post: 09-07-2008, 08:09 PM
  2. propogation of open source
    By abachler in forum A Brief History of Cprogramming.com
    Replies: 3
    Last Post: 12-28-2007, 10:03 AM
  3. Replies: 2
    Last Post: 01-15-2002, 06:00 PM
  4. OpenGL Open Source
    By gnu-ehacks in forum Game Programming
    Replies: 2
    Last Post: 11-29-2001, 12:50 AM
  5. Ghost in the CD Drive
    By Natase in forum A Brief History of Cprogramming.com
    Replies: 17
    Last Post: 10-12-2001, 06:38 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21