From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f03ffdf470e3c559 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!npeer02.iad.highwinds-media.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!nwrddc02.gnilink.net.POSTED!7c706d3b!not-for-mail From: David Thompson Newsgroups: comp.lang.ada Subject: Re: Interesting performance quirk. Organization: Poor Message-ID: References: <4903c066$0$28676$4d3efbfe@news.sover.net> <49045079$0$28711$4d3efbfe@news.sover.net> <4906f908$0$5781$4d3efbfe@news.sover.net> <34e18564-7913-426a-bb26-324314791d32@d1g2000hsg.googlegroups.com> <490833fc$0$5742$4d3efbfe@news.sover.net> X-Newsreader: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Nov 2008 06:31:34 GMT NNTP-Posting-Host: 70.104.88.64 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc02.gnilink.net 1226903494 70.104.88.64 (Mon, 17 Nov 2008 01:31:34 EST) NNTP-Posting-Date: Mon, 17 Nov 2008 01:31:34 EST Xref: g2news1.google.com comp.lang.ada:2693 Date: 2008-11-17T06:31:34+00:00 List-Id: On Wed, 29 Oct 2008 05:59:24 -0400, "Peter C. Chapin" wrote: > Ludovic Brenta wrote: > > > I believe OpenSSL uses hand-written and carefully optimised assembly > > for its inner loops. > For some algorithms and some targets, including x86 Blowfish. Unless deselected at build (specifically configuration) time. (The actual assembler source is created by perl effectively macros, so it might be more exact to call it hand-designed.) > That's interesting. It would help to explain the speed difference... > although as I said I'm sure I can do better, at least a little better, > with the compiled Ada than I am currently. > > In any event I don't want to "resort" to assembly language or to > removing the Ada mandated checks (at least not in the final version). My > assumption is the the sort of person who would be interested in using a > crypto library in Ada would have that interest precisely because of the > safety afforded by the Ada language. This is why I'm content with the > library being a bit slower than the competitors that are throwing safety > to the wind by, for example, using assembly language. > > Considering that cryptography is, almost by definition, used in security > sensitive programs it seems like issues of safety and correctness should > take priority over raw efficiency. Fast is good, of course, but it's > even more important to be both right and secure. Hence Ada and not C > (and definitely not assembly language). > Correctness is certainly vital, but the extreme nonlinearity of any good crypto algorithm means that even a small functional error will almost certainly show up very quickly and obviously. However, in modern systems it has become sometimes important to control exactly the instructions executed, and CPU's execution of those instructions (typically using assembler-dependent special operations), because of 'side-channel' (mostly timing and power) attacks that have been developed that take advantage of things like scheduling and caching behavior of the crypto machine code. So carefully written assembler can actually be more secure! But I don't know if all the openssl is.) - formerly david.thompson1 || achar(64) || worldnet.att.net