Results 1 to 9 of 9

Thread: Defending Cryptography

  1. #1

    Defending Cryptography

    In a recent discussion, a point was brought up that cryptography shouldn't be relied on as a form of security, because of the ease of attacks that can be made against it (IE brute force, cryptanalysis)

    For instance, if I have a database of plaintext passwords that are attacked, they are all immediately useable. If they are hashed, then further attacks need to be made against them to reveal useful information.

    MD5 is no longer usable:
    http://www.infosec.sdu.edu.cn/paper/md5-attack.pdf

    So here's my question, was MD5 ever a good solution? These attacks are possible now, and they were possible when MD5 was devised. So knowing that cryptographic functions seem to have a time to live characteristic, how can we defend its use?

    Consistent password changes would make a cracked hash useless when the pass is changed... but how can we measure how long a type of cryptography will be useful? (ex. how often should we force password changes?) Do we just depend on NIST to know that?

  2. #2
    Good topic for discussion!

    <My two cents>

    Pretty tough for a mortal to know how long the cryptographic protocol they are going to use is safe and for how long, IMHO you need to rely on the experts to provide guidance - unless you are a mathmetician who loves that stuff - I wish I was.

    Certification of algorithms either by CC or by a standards body is critical if you ask me, if you trust the certification body, whether that be NIST or for Australia DSD or CC certification, personally I have neither the time nor the resources (nor propably the brain power) to assess fully a cryptographic algorithm/protocol for how 'breakable' it is, I have to rely on the certification of the organisations/standards bodies I have mentioned above.

    Cryptography should not be the only control you rely on, you need to use defense-in-depth where practical but again this needs to be decided based on your risk assessment of the data you want to protect. If you are relying on cryptography then you are admitting that the someone can intercept or gain access to the data (albeit encrypted version), when the real controls you want to be implementing are stopping people from ever seeing the encrypted data.

    If you are protecting critical, sensitive info that everyone wants then you would want to use the strongest possible crypto you can (on top of other controls to stop people obtaining the encryted data in the first place!!!!!!!!!)
    But if you are protecting something that people do not have a reason to want to steal or that they can cause little damage with if they do then using [Insert favourite algoritm here] may meet your requirements.

    </My two cents>

  3. #3
    Senior Member
    Join Date
    Dec 2003
    Location
    Pacific Northwest
    Posts
    1,675
    Hey Soda,

    One of the biggest problems we are now facing is the clustering of resources to crack. What once would take +mega years, now could take a far shorter elapse time. As always, the strength of the algorithm is extremely important, however protecting and frequently changing the Key is far more important. Even with that being said, with time all crypto can be cracked by brute force. The quantum discussion we had months ago seems to ringing in my ears. So how does this apply to crypto?

    http://www.cs.dartmouth.edu/~jford/crypto.html

    cheers
    Connection refused, try again later.

  4. #4
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,885
    Because of the research and automated tool that can generate MD5 collisions, I've slid over to SHA-1 hashes. I'm curious what folks are going to do who use products like Tripwire to hash entire HDs. MD5 was their default forever. I guess they too will move along to algos like SHA-1

    Funny you bring this up. We also went through this same conversation. All of the sources we spoke to say that you can't predict how long a hashing algo will be useful, thus, you need to build in other tiers to your defenses (such as 90 day pw changes per NIST 800 series docs).
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  5. #5
    There has to be some guideline for determining what data is worth encrypting and what isn't...

    For instance-

    Passwords which may be accessible via web application should be encrypted.
    A document outlining a trade secret should not be encrypted. (I don't really mean this... keep reading)

    Why? Because a trade secret will be forever valuable, and you can't switch through trade secrets every 90 days. History has proven that it will be compromised, given enough time, resources, or knowledge of the algorithm. Is it safe to say that if encryption is needed on a document holding a trade secret, then that document is somewhere it shouldn't belong?

  6. #6
    Computer Forensics
    Join Date
    Jul 2001
    Posts
    672
    Originally posted here by Soda_Popinsky
    There has to be some guideline for determining what data is worth encrypting and what isn't...

    For instance-

    Passwords which may be accessible via web application should be encrypted.
    A document outlining a trade secret should not be encrypted. (I don't really mean this... keep reading)

    Why? Because a trade secret will be forever valuable, and you can't switch through trade secrets every 90 days. History has proven that it will be compromised, given enough time, resources, or knowledge of the algorithm. Is it safe to say that if encryption is needed on a document holding a trade secret, then that document is somewhere it shouldn't belong?
    This is where data classification comes in to play. If data is federally protected, you better be damn sure to encrypt it, and if it's sensitive to the company then you would be better off encrypting it. stolen data that has been encrypted isn't considered compromised. However, if the private key is stolen as well...well then you have a problem. I use md5 and sha-1 currently for file and disk verification..I just need 200GB of ram to handle the disks I need to hash so it doesn't take an hour or so.
    When it comes to documents I think people really need to start looking at DRM.

    Everything outlives its usefulness..look at RC4.
    Antionline in a nutshell
    \"You\'re putting the fate of the world in the hands of a bunch of idiots I wouldn\'t trust with a potato gun\"

    Trust your Technolust

  7. #7
    stolen data that has been encrypted isn't considered compromised.
    That depends on the algorithm. If I used a +1 ceaser cipher...

    So what is considered a safe algorithm? I'm guessing NIST maintains a list of them?

    edited after following post:

    Thanks hog
    http://csrc.nist.gov/CryptoToolkit/

  8. #8
    Computer Forensics
    Join Date
    Jul 2001
    Posts
    672
    Originally posted here by Soda_Popinsky
    That depends on the algorithm. If I used a +1 ceaser cipher...

    So what is considered a safe algorithm? I'm guessing NIST maintains a list of them?
    True but according to atleast state regs that's the case. I hope no one in their right mind would consider caesar..oh wait Microsoft still uses ROT-13(14) to "encrypt" the registry.

    AES is the current standard, but yes NIST does maintain a listing of FIPS approved algorithms.
    Antionline in a nutshell
    \"You\'re putting the fate of the world in the hands of a bunch of idiots I wouldn\'t trust with a potato gun\"

    Trust your Technolust

  9. #9
    Senior Member
    Join Date
    Sep 2005
    Posts
    221
    http://www.securityfocus.com/news/11292

    This is a good little read on SHA-1 and it looks like the names in your PDF appear here too.
    Definitions: Hacker vs. Cracker
    Gentoo Linux user, which probably says a lot about me..
    AGA member 14460 || KGS : Trevoke and games archived

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •