[openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Jay Foster]

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
> presentation).
>
> Jeff
> _______________________________________________
> 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.

Jay