[148711] in cryptography@c2.net mail archive
Re: [Cryptography] how reliably do audits spot backdoors?
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Wed Dec 25 15:00:03 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <52B93AE9.9070906@echeque.com>
Date: Wed, 25 Dec 2013 12:09:43 -0500
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "James A. Donald" <jamesd@echeque.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8525702318803458667==
Content-Type: multipart/alternative; boundary=089e0112c02c60e54604ee5eed25
--089e0112c02c60e54604ee5eed25
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Dec 24, 2013 at 2:42 AM, James A. Donald <jamesd@echeque.com> wrote:
> On 2013-12-24 04:33, Benjamin Kreuter wrote:
>
>> I have been wondering for some time if this might be more a symptom of
>> the languages we are using than a fundamental difficulty in the
>> auditing process itself. Quite a few UCC entries rely on undefined or
>> counterintuitive behavior in C.
>>
>
> I find C quite intuitive, possibly as a result of having done a bit of
> code review.
>
> What you would call counterintuitive, I read as idiomatic, and what is
> undefined, I read as unidiomatic.
>
> So, the underhanded C examples would have failed code review, not because
> their terribly sneaky measures would have been detected in code review, but
> for being unidiomatic, obfuscated, uglified, or complexified.
>
> The code review would have come to an end, and the developer ordered to do
> a rewrite, before the trick had been detected.
But that type of code review is only possible for closed source where
someone is being paid or in an exceptionally highly motivated open source
project.
I can't slap the authors of OpenSSL and tell them to document their stuff,
let alone force a rewrite
--
Website: http://hallambaker.com/
--089e0112c02c60e54604ee5eed25
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Dec 24, 2013 at 2:42 AM, James A. Donald <span dir=3D"ltr">=
<<a href=3D"mailto:jamesd@echeque.com" target=3D"_blank">jamesd@echeque.=
com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 2013-12-24 04:33, Benjamin Kreuter wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I have been wondering for some time if this might be more a symptom of<br>
the languages we are using than a fundamental difficulty in the<br>
auditing process itself. =A0Quite a few UCC entries rely on undefined or<br=
>
counterintuitive behavior in C.<br>
</blockquote>
<br>
I find C quite intuitive, possibly as a result of having done a bit of code=
review.<br>
<br>
What you would call counterintuitive, I read as idiomatic, and what is unde=
fined, I read as unidiomatic.<br>
<br>
So, the underhanded C examples would have failed code review, not because t=
heir terribly sneaky measures would have been detected in code review, but =
for being unidiomatic, obfuscated, uglified, or complexified.<br>
<br>
The code review would have come to an end, and the developer ordered to do =
a rewrite, before the trick had been detected.</blockquote><div><br></div><=
div>But that type of code review is only possible for closed source where s=
omeone is being paid or in an exceptionally highly motivated open source pr=
oject.</div>
<div><br></div><div>I can't slap the authors of OpenSSL and tell them t=
o document their stuff, let alone force a rewrite</div><div><br></div><div>=
=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div>
--089e0112c02c60e54604ee5eed25--
--===============8525702318803458667==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8525702318803458667==--
