>> 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.
Yes. >> 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) Yes. > 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) Yes. > Skipjack (80-bit keylength, fully deprecated if I read your post right) Yes. Although there’s a big difference between an algorithm designed for a certain key length/strength, and an algorithm that turned out to provide fewer bits of strength than expected by designers. There are applications that for various reasons cannot handle long keys. 80 bits is fine for them. > if not already done: PKCS1 v1.5 padding (known to be vulnerable, should be > superseded by OAEP) Yes. And/or RSA-PSS, but I personally like OAEP better (and don’t care all that much for security proofs :). > That every algorithm that may be worth deprecation for security reasons. Of > course we should retain them for historical reasons. > Yes and yes. :-) -- -- 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
