[openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback
jayf0ster at roadrunner.com
Tue Nov 17 19:24:17 UTC 2015
On 11/17/2015 9:56 AM, Jeffrey Walton wrote:
>>> We can significantly reduce that liability by removing any assembler
>>> optimisations. Also just because something is available doesn't mean it
>>> has to be "default". We can have good defaults whilst keeping old crypto.
>> Zooko Wilcox O'Hearn recently gave a talk at a software assurance
>> conference on the downsides of assembly language routines in software.
>> I'm trying to locate it now. All in all, this is probably a move in
>> the right direction, especially for non-contemporary algorithms, to
>> help sunset them and maintain them with minimal effort.
> My bad... I just talked to Zooko about the presentation. He was not
> able to attend the conference, so there is no presentation to link to.
> However, here is the write-up in the Tahoe-LAFS Bug Reporter:
> https://tahoe-lafs.org/trac/pycryptopp/ticket/85#comment:20. It makes
> the case for No-ASM. (And was the corpus of knowledge for the
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
I can understand the desire to remove the assembly code options, but I
think there are legitimate reasons to leave them in. From the write-up
referenced (above), "because the added speed really makes no difference
to our uses, as far as I know" was a reason given for removing
assembly. I think this is based on some assumptions that are not
universally true, such as OpenSSL is running on multi-GHz multi-core
64-bit processors. This is not always the case. I recently updated a
product I support (50MHz single core) to OpenSSL 1.0.2d, and found that
the assembly optimizations gave me a 40% increase in performance over
the C version (AES decryption). 40% was very significant in my case.
Seems like the low power IoT devices might be similarly CPU challenged
in the future.
More information about the openssl-users