On Mon, Nov 16, 2015 at 04:51:10PM +0100, Emilia Käsper wrote: > As for specific deprecation strategies: > - Don't forget that all applications will have to recompile against 1.1.
The EVP_get_cipherbyname() and EVP_get_digestbyname() interfaces remain, so nothing changes at compile-time. Most code does not use EVP_<algorithm-name>() directly. This means that: * Most errors are not caught at compile time. * Porting is not the difficult part, the much more difficult problem is dealing with runtime access to any algorithms needed to handle data at rest. > - Disabling algorithms doesn't work well for us as it's just pushing the > decision on the distros. It also wouldn't win us any resources as we'd > still be responsible for keeping the code bug-free. The only win would be > in default compiled code size. Removing assembly support would substantially lower support cost. For many of the algorithms we can likely find a reference implementation in an RFC or similar standards document, if our own code is substantially more refined (and requires greater support effort). > - We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python, > PHP etc) who correctly account for the fact that an implementation may be > missing (which they have to, anyway) will continue to work. These don't help with EVP "by name" indirection. > - Removing assembly support is a GREAT suggestion to simplify the > complexity, and I think we should do this for anything we end up leaving > in, and perhaps even for some things not yet on the hit list (RC4?). Yes, and probably. > - I appreciate OpenSSL's role as a "Swiss army knife" research tool but > research needs shouldn't prevail over those of real applications. We are > generally not on the frontline of deprecating things - RC4 isn't yet on the > list. SSLv3 isn't yet on the list, etc. But we can't become the Internet > Archive of All Old Crypto either, and there's some cleanup to do that's > long overdue. Researchers can indeed use older toolkits, my concern is real users, with non-SSL applications (data at rest). > - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty > widespread MySQL breakage. That made MySQL backport a change increasing the > DH key length from 512 to 2048 bits. For end user security, it's a win. I > would prefer that we start cashing in these improvements before the next > Logjam happens. (This is my view; as you can see views differ even within > the team.) This is SSL/TLS where we have algorithm agility. I support the Logjam changes. It is likely time for us to take the next (not final) step from 768 to 1024 as the min prime size. > - On binary elliptic curves: with recent cryptographic advances, I believe > these are now firmly planted in the "internet archive" category, even if > not practically broken yet. The other reason for removing these is that our > implementations are crappy. They're not constant-time, and they've been > shown to contain bugs. Improving upon these implementations is not a good > use of dev time imo, given their decreasing credibility. I agree they need to go from SSL/TLS. What about S/MIME and CMS? > Here's the list of algorithms gone from BoringSSL: > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves Boring SSL has a very narrow user base. By all means drop as much as you can get away with. > And here's the list gone from LibreSSL, from what I can tell: > > MD2, MDC2, RC5, SEED Likewise, not a wide user base. We can make incremental steps, drop assembly support and SSL/TLS codepoints in this release, and assess things from there. My hope is that the support cost of a stable reference implementation in C (yes, likely not constant time) is not that onerous. -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev