Crypto Help!

I don't know if anyone has ever created a type of table stating when to use for example SHA1 over MD5. I am looking for a reference on when one type of hashing should be used over another.

I've had questions on previous tests regarding these types of questions and I don't work with crypto daily.

Any help would be greatly appreciated!

Find more posts tagged with

Comments

JDMurray

Here's a few:

1. Use SHA1 when you need a hash space larger than what MD5 can provide (160-bits vs. 128-bits). SHA-1 will give you fewer possible collisions, but there will still be the possibility of collisions.
2. Use MD5 to hash forensics data because it's what a US count of law expects to see in a forensics report (but include SHA-1 hashes too for extra integrity checking of your finding and data)
3. Use one over the other because it is faster to perform hash calculation in your particular implementation.
4. You are working under customer requirements to only support SHA1 or later, or be backward-compatible with MD5.

Any more anybody?

dover

Not sure I understand where you're going. Are you looking for help in when to use certain forms of crypto? or when to use specific algorithms within a specific type of cryptosystem?

With crypto, usually the biggest determinant for which method to use normally depends on how valuable the data is and how long it needs to be kept secret.

In the MD5 vs. SHA1 scenario, MD5 has been shown to be more prone to collisions than SHA1. In 2008 attacks against digital certificates signed using MD5 were published where an attacker could generate additional certificates that contained "different content that have the same digital signature as an original certificate."

Here's a cool, but relatively older chart of the relative 'strength' of varius hashing algorithms through time

Crypto was one of the subjects I had to review quite a bit. Eventually I ended up making tons of notes on each type of cryptosystem:

Symmetric
Asymmetric
Hash

And then within each category I tried to define as many of the algorithms and techniques I could think of and information about key length, block size, transformations....everything I could think of.

For example...

Symmetric key crypto
General info: Secret-key (one-key) encryption
Efficient - one key is used to both encrypt and decrypt
Key management:
Need a way to securely distribute the key
Pre-shared secrets (delivered out of band)
Asymmetric encryption (RSA, El Gamal, ECC)
Diffie Hellman key exchange
Examples:
DES - data encryption standard Key size: 56bits Modes: ECB - CBC -CFB - OFB - CTR
Triple DES - triple DES Key sizes: 2-key des 112bit 3-key des 168bit
AES - Advanced Encryption Standard Block cipher w/ variable block AND key length
Transformations: XOR, substitutions, rotation, permutation
RC (family) block cipher variable sizes 32, 64, 128 key sizes range from 0 to 2048 bits

Finally, I tried to map out how to mix and match them to achieve the goals of crypto: Confidentiality, Data Integrity, Authentication and Non-repudiation.

Like combining hash functions and asymmetric crypto to create non-repudiation:
Take a message -> run through a hashing algorithm -> encrypt the hash output using the sender's private key -> send to destination
Destination receives message -> uses the sender's public key to decrypt the encrypted hash value -> sends received message through the same hash algorithm -> compares the two hash values

Hope it helps...it sent me on a little work-avoiding tangent for a while anyway.

webgeek

@JDMurray: Thanks for the info

@dover: I'm looking for the same type of info you have put in your reply. I have seen crypto questions asking what the best type of hash to use for x. Since crypto is not my strong point I was wondering if a table existed stating when should one type of hashing should be used. I've been searching all day but I will probably make one for future testers.

JDMurray

Cryptographic hashing does not care about what its input is. For example, you wouldn't use one hashing algorithm for textual data and another one for binary data. All bits are just bits to all crypto hashing algorithms. Which hashing algorithm is used in what application is determined by several factors, but the content of the input is not one of them.

And despite cryptographic hashing being called "one-way encryption," it is technically not encryption because its output is not reversible (i.e., it's input cannot be reconstructed from the output). Like encryption, however, hashing does fall under the general category of cryptographic algorithms.

JDMurray

dover wrote: »

Finally, I tried to map out how to mix and match them to achieve the goals of crypto: Confidentiality, Data Integrity, Authentication and Non-repudiation.

You are missing "availability," which crypto also enables. For example, we would not have much eCommerce available to us over the Internet without crypto.

webgeek

All GREAT info! This will def help me in the crypto domain since it is my weakest....testing on Sept 8th!

the_hutch

JDMurray wrote: »

Here's a few:

1. Use SHA1 when you need a hash space larger than what MD5 can provide (160-bits vs. 128-bits). SHA-1 will give you fewer possible collisions, but there will still be the possibility of collisions.

Great review of the distinctions. I think one thing should be emphasized though, in regard to your first point. It doesn't matter what hashing algorithm output size is used (and I am speaking in terms of future generations and standards too), there will ALWAYS be a possibility of collision. You will sometimes hear people or companies make claims about hash standard improvements, indicating that some standard or implementation has eliminated the possibility of collisions (in fact, my ISC2 instructor actually threw a statement like this out there). The fact is, this will never be true. Consider the theory behind it. You are talking about representing a nearly infinite number of possible combinations of data with a finite (fixed-size) message digest. You can't ever expect a unique output (confined to a finite field), when generated from an infinite (or at least pseudo infinite) range of possibilities.

Paperlantern

webgeek wrote: »

All GREAT info! This will def help me in the crypto domain since it is my weakest....testing on Sept 8th!

Good luck to you, I am testing on the 10th. Crypto isn't my WEAKEST domain, but its down near the bottom somewhere that's for sure. Hope to see a couple more test passed posts here in that time.

paul78

Good luck to those taking the test.

I don't want to confuse the issue so my comments is not not intended to imply that the ISC2 body of knowledge will concur with how the real world views the use of MD5.

Today, most organizations only use md5 for as a checksum for the purpose of integrity checking for file transmissions, etc.

MD5 is actually considered a compromised hash function as a collision attack exist. From a security perspective, MD5 should be avoided for hashing passwords, masking data, SSL, and other functions requiring strong hashing.

dover

JD

I see your point - I hadn't considered availability a key goal of crypto. In the 'textbook' world I don't think I've ever seen it referred to as a specific, primary goal of cryptography - but I could definitely be mistaken.

You are absolutely correct in the real world applicaion of cryptosystems - cryptography does help to ensure availability. It is used to protect critical information that could be used to 'take down' real-world systems and is used everyday to provide for a secure medium to manage devices and conduct 'secure' transactions. Without the underlying crypto protecting the information there would be precious little ecommerce - like you said.

Would you say that crypto's role in availability is indirect? A result of the application of cryptography enabling certain activities and abilities that would not be realistic/plausible otherwise?

Webgeek - good luck on the test!

JDMurray

dover wrote: »

Would you say that crypto's role in availability is indirect?

No, crypto plays a direct role in availability. There are definitely many causes where services could not be available unless they were supported by crypto. Yes, it's the confidentiality and integrity parts of crypto that actually sustains the availability of services, such as eCommerce. Therefore, it seems natural to demote the availability aspect of crypto to a secondary status. However, in InfoSec we have the CIA triad, in which availability is a peer with confidentiality and integrity. Therefore I would say crypto plays a direct role in availability too.

JDMurray

paul78 wrote: »

MD5 is actually considered a compromised hash function as a collision attack exist. From a security perspective, MD5 should be avoided for hashing passwords, masking data, SSL, and other functions requiring strong hashing.

When you present a forensic report in a court of law, and it doesn't contain the MD5 hash values that the court expects, will your defense be to launch into an academic discussion about how crypto researchers have conjured a few examples of MD5 hash collisions that are of no practical use in the real world?

You gotta give your customers what they want. If they want MD5, you gotta use it.

paul78

I'm not suggesting that MD5 has no place. We use for for file integrity checking. But I work in financial services, and my customers are banks, credit card companies, and broker-dealers. The use of MD5 for certain operations such as hashing passwords and masking data is considered an application weakness and could result in an audit finding. My company's software development standards actually explicitly does not permit use of MD5 for these purposes. Where I work, getting anything other than a satisfactory audit is a really bad thing.

I'm actually not familiar with forensic reporting so thanks for that interesting point. It does seem that for that purpose MD5 should be sufficient in the same way that we use MD5 for file integrity checking.

I suspect we both probably agree that there's no one size fits all.

BTW - the Flame malware apparently used the weakness in MD5 to forge a valid certificate for Microsoft Windows update service. That's the reason behind my comment about MD5 for SSL certificates. And why we don't permit MD5 for certificates where I work.

JDMurray

paul78 wrote: »

And why we don't permit MD5 for certificates where I work.

Absolutely. Unless there a compatibility with legacy systems issue, SHA-2 should be what's required for digital certs. Flame actually exploited how MD5 was used in digital certs.