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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
