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
