<br><br><div class="gmail_quote">On Sat, Sep 26, 2009 at 12:01 AM, geremy condra <span dir="ltr"><<a href="mailto:debatem1@gmail.com">debatem1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Fri, Sep 25, 2009 at 10:35 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>geremy condra wrote:<br>
><br>
><br>
> On Fri, Sep 25, 2009 at 9:49 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a><br>
</div><div><div></div><div>> <mailto:<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>>> wrote:<br>
><br>
>     CTO wrote:<br>
>     > EVP covers hashing, signatures, and encryption/decryption. If we're<br>
>     > going<br>
>     > to go for a longer name, maybe "cryptography" would be more<br>
>     > appropriate?<br>
><br>
>     Something to keep in mind while working on this is your threat model for<br>
>     the library. If you aren't going to do anything to guard against<br>
>     side-channel attacks (which are rather hard to avoid in a cross platform<br>
>     algorithm on a general purpose PC) or against attacks which grab<br>
>     unencrypted messages and keys from released-but-not-overwritten computer<br>
>     memory or (worse) the swap file, then this should be mentioned in the<br>
>     documentation.<br>
><br>
>     That way application developers that are looking for that extra level of<br>
>     security will know they need to look elsewhere.<br>
><br>
>     Regards,<br>
>     Nick.<br>
><br>
><br>
> I can make a note of it, although I'm unsure what concrete steps I could<br>
> take to prevent such attacks from succeeding. Any ideas?<br>
<br>
</div></div>OpenSSL may actually guard against of the first part already. I'm unsure<br>
about the second part though. And I don't know enough about the problems<br>
to know how to fix them either - I just know when I'm theoretically<br>
leaving these attack vectors open and make sure to defend them by other<br>
means (such as physically securing the affected networks).<br>
<br>
But it's this kind of stuff that people are talking about when they<br>
point out that practical crypto is harder than just using good algorithms.<br>
<br>
Cheers,<br>
Nick.<font color="#888888"></font><font color="#888888"></font> </blockquote></div></div><div><br>It seems to me that most timing attacks should already be out, so I'm not<br>*too* worried about that- but I have literally no idea how to stop the secrets<br>

from being dropped into swap in this context. I think what I'm going to do<br>is just make a note of it in the docs for the module and make sure that<br>there's enough contact info in there to ensure that anybody reviewing the<br>

code can let me know if we're doing something stupid. <br><br>And on that note: since most of my knowledge of crypto is theoretical <br>in nature, I'm going to be leaning a lot on those of you with more <br>practical experience as we go forward with this. <br>

Therefore, for everybody reading this list- please, <br>*review the code*! If you think there's a problem, assume<br>you're right and let me know- we really, really, really do not want <br>half-baked crypto in the standard lib. Assuming that's even<br>

where this is headed.<br><br>Geremy Condra<br></div></div>
</blockquote></div><br>Added the notice to the top of aes.c.<br><br>Geremy Condra<br>