On 14/11/2015 18:32, Viktor Dukhovni wrote: > On Sat, Nov 14, 2015 at 07:32:33AM +0000, Peter Waltenberg wrote: > >> I also can't see any point expunging old algorithms from the sources, >> making them not build by default should be enough. > It is difficult enough to maintain code that is typically built, > dead code is even harder to keep correct. And what are distributions > of the library to do? Break a lot of customer code by shipping > with the algorithms disabled? Or re-enable compilation? > >> The only thing I would suggest is dropping assembler support for >> anything that's been retired, just to cut the maintenance effort / risk >> of breakage. If it's legacy only, performance shouldn't be an issue. > That probably makes more sense. Drop associated SSL/TLS ciphersuite > codepoints and drop assembly support (if any). Leave the C > implementation in libcrypto to support legacy "data at rest" > applications. > > The proposed list was: > > CAST > IDEA > MDC2 > MD2 [ already disabled by default ] > RC5 [ already disabled by default ] > RIPEMD > SEED > WHIRLPOOL > ALL BINARY ELLIPTIC CURVES > > If I were to guess, it would be that the base crypto implementations > of IDEA, SEED and binary elliptic curves need to stay. We could > perhaps get away with removing CAST and RIPEMD. No idea about the > rest. >
It is perhaps time to split crypto library in two libraries libcryptolegacy and libcryptostrong... My two cents. Philippe L. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
