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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!novia!transit4.readnews.com!news-out.readnews.com!postnews3.readnews.com!not-for-mail Date: Mon, 17 Nov 2008 06:51:51 -0500 From: "Peter C. Chapin" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Interesting performance quirk. 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> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <49215ad7$0$5213$4d3efbfe@news.sover.net> Organization: SoVerNet (sover.net) NNTP-Posting-Host: 1db60783.news.sover.net X-Trace: DXC=OZUYB5L`Z[:WUUlR<856?k70daM71hm=7nb<:S]Slg? X-Complaints-To: abuse@sover.net X-Original-Bytes: 4391 Xref: g2news2.google.com comp.lang.ada:8422 Date: 2008-11-17T06:51:51-05:00 List-Id: David Thompson wrote: >> 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. I understand your point, but its not necessarily that simple. Take a look at http://www.schneier.com/blowfish-bug.txt which describes a "common" implementation bug where the code inadvertently overwrites a large number of key bits with 1 bits. Because encryption and decryption process the key in the same way, this bug does not reveal itself as a problem with round trip processing. Now in this case one would expect any reasonable degree of testing to show the problem... but that assumes the test cases were generated with an implementation that is free of this issue. If multiple carefully written implementations all agree that increases one's confidence in the result, but what does that really prove? They could all be wrong in exactly the same way. Here "being wrong" might well mean "weakened security relative to published theoretical results." For example, consider Blowfish again... the algorithm requires a large number of digits from the hexadecimal expansion of pi during its initialization. Where did I get those initial values? I copied them from Schneier's reference implementation. I'm sure that's probably what a lot of Blowfish implementors do. Yet what if they are wrong? My test cases based on Schneier's published test vectors (on the site above) wouldn't show the problem because we'd both be using the wrong initial values. Should I believe those are really the digits from the hexadecimal expansion of pi just because Schneier says so? No... more checking needs to be done. What I *should* do is write my own program to compute those values, use a tool like SPARK to prove my program correct, and then cross check its output with several other independently computed values for pi. In fact, it's on my to-do list to do exactly this (but I admit it's fairly low in priority right now). I'd be very surprised, of course, if Schneier's value of pi is wrong but, hey, you never know. > 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! That's interesting. I've heard of these kinds of attacks before but I admit that I don't know much about them. I'll have to look into it. Thanks for the heads-up. Peter