Am 08.07.2015 um 19:09 schrieb Jeffrey Walton: > Its been a while since a class entered the Weak namespace. It *might* > be time to consider some candidates for Weak. I think SHA-1 is a > worthy candidate. > > SHA-1 provides 80-bits of theoretical security. Marc Stevens has that > down to about 60-bits, which is well within the reach of many > attackers, especially since compute time is so cheap on EC2 and Nova. > (More correctly, its at 2^61; see HashClash at > https://marc-stevens.nl/p/hashclash/). > > From history, we know adversaries will attack 60-bits or so. There's > little reason to go around the crypto because the adversaries can go > through it in this case. To be clear, if its economical, they will > still go around it. For example, if its easier to look up a static, > hardcoded private key in Little Black Box > (https://code.google.com/p/littleblackbox/), then the adversary will > do so. > > We saw attacks on the crypto in the TI Signing Key break > (https://en.wikipedia.org/wiki/Texas_Instruments_signing_key_controversy); > and we saw it in the Flame malware with its prefix collision attack on > MD5 (https://en.wikipedia.org/wiki/Flame_%28malware%29). > > From a standards and compliance point of view, 80-bits of security has > been withdrawn from US Federal by NIST. 112-bits of security was in > effect in 2011, and the transition period for deprecation of 80-bits > was over in 2013. ECRYPT, NESSIE and ISO have similar requirements. > > And even the browsers are moving against it. > (https://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html, > https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/ > and > http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx). > > So, the first QUESTION: should we move SHA-1 into Weak? Yes. It is broken and its usage should definitely strongly discouraged, even more considering most people start with Applied Cryptography or the HAC. > > If NO, then the second QUESTION is: when should we revisit? Or maybe > what is the criteria to make the list? > > The final QUESTION is, what other algorithms would be potential > candidates for the list?
* RIPEMD-128 (64-bit collision resistance)
* RIPEMD-160 (80-bit collision resistance, fully deprecated if I read
your post right)
* maybe: Tiger (96-bit collision resistance, not sure if this is
already "too low")
* maybe: TEA (known to be very weak against related-key attacks)
* Skipjack (80-bit keylength, fully deprecated if I read your post right)
* if not already done: PKCS1 v1.5 padding (known to be vulnerable,
should be superseded by OAEP)
That every algorithm that may be worth deprecation for security reasons.
Of course we should retain them for historical reasons.
BR
JPM
>
> Jeff
> --
> --
> You received this message because you are subscribed to the "Crypto++
> Users" Google Group.
> To unsubscribe, send an email to
> [email protected].
> More information about Crypto++ and this group is available at
> http://www.cryptopp.com.
> ---
> You received this message because you are subscribed to the Google
> Groups "Crypto++ Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected]
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [email protected].
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
