Ciphersuites, more mixed messages than my Xgf

[Acanthus]

I've been looking into manually managing ciphersuites and I had a few questions that i'm hoping someone up-to-date on cipher security can answer. The articles i have read have conflicting and dated information all over the place.

#1: It is my understanding that as of OpenSSL 1.0.1e (or TLS 1.2) that block ciphers (specifically AES and Camellia) are no longer vulnerable to cache timing side-channel attacks. Is this correct?

#2: Knowing #1, it is now safe to say that block ciphers in CBC mode are once again safe, even though that there are a few known weak attack vectors that simplify them slightly.

#3: SHA1 has known collisions, SHA2-256 is the new minimum known secure standard, correct?

#4: For all normal intents and purposes RC4 is completely broken. Don't use it. Is this a correct blanket statement?

#5: Ephemeral keys are are the only way to achieve perfect forward secrecy using OpenSSL or TLS 1.2, correct?

And finally a question: Is there a mathematical or probability reason to consider GCM safer than CBC after the current round of OpenSSL updates?

Thanks in advance guys, this is a lot of BS to shuffle through via google and wikis.

 

[smakme7757]

I have RC4 running as the highest priority on my webserver. Most banks have also switched over to RC4 primarily due to the BEAST attack.

So I would say number 4 is untrue.

SHA1 has been attacked successfully under certain circumstances, so 256 is best for new systems and implementations.

 

[Acanthus]

I have RC4 running as the highest priority on my webserver. Most banks have also switched over to RC4 primarily due to the BEAST attack.

So I would say number 4 is untrue.

SHA1 has been attacked successfully under certain circumstances, so 256 is best for new systems and implementations.

BEAST doesn't work in TLS 1.2.

Number 4?

https://en.wikipedia.org/wiki/RC4#Security

https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

http://www.isg.rhul.ac.uk/tls/

The most current documentation i can find says that RC4 is dead again, and that CBC ciphers are again safe.

 

[smakme7757]

Ok, thanks for the info!

As far as I know, and this isn't exactly my field of expertise, but RC4 has always had a "warm up" problem where the first 256 bytes of an RC4 output can contain byte patterns that are exactly the same.



Anyhow I found this link which seems to give a pretty human explanation of the problem.



http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html

 

[unokitty]

I've been looking into manually managing ciphersuites and I had a few questions that i'm hoping someone up-to-date on cipher security can answer. The articles i have read have conflicting and dated information all over the place.

#1: It is my understanding that as of OpenSSL 1.0.1e (or TLS 1.2) that block ciphers (specifically AES and Camellia) are no longer vulnerable to cache timing side-channel attacks. Is this correct?

#2: Knowing #1, it is now safe to say that block ciphers in CBC mode are once again safe, even though that there are a few known weak attack vectors that simplify them slightly.

#3: SHA1 has known collisions, SHA2-256 is the new minimum known secure standard, correct?

#4: For all normal intents and purposes RC4 is completely broken. Don't use it. Is this a correct blanket statement?

#5: Ephemeral keys are are the only way to achieve perfect forward secrecy using OpenSSL or TLS 1.2, correct?

And finally a question: Is there a mathematical or probability reason to consider GCM safer than CBC after the current round of OpenSSL updates?

Thanks in advance guys, this is a lot of BS to shuffle through via google and wikis.

Cryptology has many subtle aspects.

For example, if you look at NIST"s Policy on Hash Functions, you would find:

SHA-1: Federal agencies should stop using SHA-1 for generating digital signatures, generating time stamps and for other applications that require collision resistance. Federal agencies may use SHA-1 for the following applications: verifying old digital signatures and time stamps, generating and verifying hash-based message authentication codes (HMACs), key derivation functions (KDFs), and random bit/number generation. Further guidance on the use of SHA-1 is provided in SP 800-131A.

Since NIST ended the SHA-3 Cryptographic Hash Algorithm Competition on October 2, 2012, when it announced KECCAK as the winner of the competition, and the new SHA-3 hash algorithm, you may also want to look into the process they employed to develop the new standard.

Best of luck,
Uno

 

[Acanthus]

Cryptology has many subtle aspects.

For example, if you look at NIST"s Policy on Hash Functions, you would find:



Since NIST ended the SHA-3 Cryptographic Hash Algorithm Competition on October 2, 2012, when it announced KECCAK as the winner of the competition, and the new SHA-3 hash algorithm, you may also want to look into the process they employed to develop the new standard.

Best of luck,
Uno

Thanks for the info!

I was aware of the existence of SHA-3 but now it is so bleeding edge that it isn't supported by browsers yet.