comp.lang.ada
 help / color / mirror / Atom feed
From: David Thompson <dave.thompson2@verizon.net>
Subject: Re: Interesting performance quirk.
Date: Mon, 17 Nov 2008 06:31:34 GMT
Date: 2008-11-17T06:31:34+00:00	[thread overview]
Message-ID: <rkc1i4p7qsbmoelptav1udh41o1m5sjbl5@4ax.com> (raw)
In-Reply-To: 490833fc$0$5742$4d3efbfe@news.sover.net

On Wed, 29 Oct 2008 05:59:24 -0400, "Peter C. Chapin"
<pcc482719@gmail.com> 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



  parent reply	other threads:[~2008-11-17  6:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-26  0:57 Interesting performance quirk Peter C. Chapin
2008-10-26  2:15 ` Jeffrey Creem
2008-10-26 11:16   ` Peter C. Chapin
2008-10-26  4:57 ` tmoran
2008-10-26 11:11   ` Peter C. Chapin
2008-10-28  8:49     ` Martin
2008-10-28 11:35       ` Peter C. Chapin
2008-10-28 14:21         ` Robert A Duff
2008-10-29  1:42           ` Peter C. Chapin
2008-10-28 18:27         ` Jeffrey R. Carter
2008-10-29  1:39           ` Peter C. Chapin
2008-10-29  5:27             ` Jeffrey R. Carter
2008-10-28 23:22         ` Ludovic Brenta
2008-10-29  8:42           ` oenone
2008-10-29  9:59           ` Peter C. Chapin
2008-10-29 10:19             ` Martin
2008-11-17  6:31             ` David Thompson [this message]
2008-11-17 11:51               ` Peter C. Chapin
2008-10-29  9:54         ` Alex R. Mosteo
2008-10-30 11:16           ` Peter C. Chapin
2008-10-29 16:12         ` Colin Paul Gloster
2008-10-30 11:23           ` Peter C. Chapin
2008-10-31 13:41             ` Colin Paul Gloster
2008-11-01 15:41               ` Gene
2008-10-29 20:18 ` Florian Weimer
2008-10-30 11:15   ` Peter C. Chapin
2008-11-07  0:44 ` Randy Brukardt
2008-11-07  1:23   ` Peter C. Chapin
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox