<div class="gmail_quote">On Mon, Sep 6, 2010 at 12:45 PM, Thomas DuBuisson <span dir="ltr"><<a href="mailto:thomas.dubuisson@gmail.com">thomas.dubuisson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">David said:<br>
> I'd be interested with breaking the dependency on OpenSSL, for various<br>
> reasons:<br>
</div>> [snip]<br>
<br>
Can't say I'm surprised by these. Its unfortunate the situation<br>
hasn't improved. I recall a half decent O'Reilly book on OpenSSL but<br>
if you weren't using it as a cookbook (and wanted a 1-off solution)<br>
then it wasn't so useful.<br></blockquote><div><br></div><div>Exactly. I managed to piece together the behavior I wanted by careful inclusion and omission from the O'Reilly book, but even it is more a book of lore and tricks than a real reference manual. Given the shape of the API, unfortunately I suspect that it's quite hard to get any better.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> So, a replacement would need to be a complete replacement for TLS. I did in<br>
> fact try to start with this, implementing my own simpler TLS-ish protocol,<br>
> using crypto primitives directly. It took a group of crypto experts about 5<br>
> minutes to punch 3 different holes in the protocol<br>
<br>
</div>You could have gone to Hackage and checked your protocols correctness<br>
using CPSA, not that the side-channel attacks would be discovered by<br>
such a tool.<br></blockquote><div><br></div><div>Interesting. I had seen CPSA announced at one point, but there appears to be no documentation whatsoever. Did I miss the doc links?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> That said, with the Haskell Crypto API stabilizing, I've been toying with<br>
> the project of a pure Haskell TLS implementation, which would solve the<br>
> annoying dependency issue while hanging on to a hardened protocol.<br>
<br>
</div>I'm releasing crypto-api-0.1 on Tuesday so if you have any last minute<br>
comments now is the time!</blockquote><div><br></div><div>I'll take a look, but I've been loosely following and don't recall any major objections.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> However,<br>
> this is also far from a simple endeavor, especially if the implementation is<br>
> to be hardened against side-channel attacks, which I'm not even sure is<br>
> possible in Haskell.<br>
<br>
</div>Well, to determine if that's possible we'd need a definition of<br>
side-channel attack which is counter to many definitions of<br>
side-channel ;-). Perhaps a list of common ones OpenSSL thinks it<br>
addresses would give us a good start.<br></blockquote><div><br></div><div>The two large families of side-channel attacks that I know of and that have been popular (== successful) recently are:</div><div><br></div><div> - Simple timing attacks: If code path A takes longer than code path B to execute, an attacker can use that information to reverse engineer the outcome of branching tests, and from there possibly recover secret key material. This is particularly nasty because the attack can be carried out remotely, by repeatedly executing the protocol in a way that exercises the vulnerable code path.</div>
<div><br></div><div> - Cache state attacks: If code path A has different data access patterns than code path B, it may be possible to deduce which was executed by examining CPU cache statistics. This attack is more theoretical than practically useful, because it requires local access to the CPU executing the crypto code, and that there be little else executing on the system to pollute the cache stats. But I do recall a couple of publications that showed OpenSSL being successfully attacked to some extent through CPU cache analysis.</div>
<div><br></div><div>IMHO the former is the big one that needs to be protected against, I won't really lose any sleep over the second one just yet.</div><div><br></div><div>The definition of a simple timing attack can be basically boiled down to: any branching in the code must be to two alternatives with equal cost (or thereabouts, sufficiently close to be indistinguishable from timing noise).</div>
<div><br></div><div>For instance, if comparing two hashes for equality, the code should not exit early if a difference is found, as that would leak to the attacker the number of bytes of his hash that were correct. This is incidentally one component in the successful attack against the Xbox 360's security system: they were comparing hashes with memcmp(), which exits early on a difference, enabling an attacker to determine the correct hash for a modded firmware by brute force.</div>
<div><br></div><div>This is fundamentally at odds with lazy evaluation, the ultimate early exit. All crypto code needs to be completely strict to resist timing attacks, or at least very carefully lazy. In a garbage collected language, the code also needs to take care to avoid allocating significantly more in one branch than in the other, lest the pauses induced by garbage collection give away hints as to the chosen code path (though arguably, the GC behavior in a complex program is sufficiently unguessable for an attacker to not be an issue).</div>
<div><br></div><div>Am I making sense?</div><div><br></div><div>Another of my tentative projects was to write a C library that implements popular crypto building blocks, with a large battery of tests for correctness and resistance to timing attacks. Getting resistance to timing attacks is somewhat simpler (though still treacherous) in C, and having such a library available for protocol builders would be quite valuable. Sadly, time is a heartless bitch and continually gives less of itself than I would need to do all these things.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">If you start on such a task (Haskell TLS) then perhaps you could drop<br>
a line to l@h.o or c@h.o?<br></blockquote><div><br></div><div>Most certainly. A full TLS stack is not something one attempts alone ;-).</div><div><br></div><div>- Dave</div></div>