On Fri, Sep 25, 2009 at 10:35 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
geremy condra wrote:
>
>
> On Fri, Sep 25, 2009 at 9:49 PM, Nick Coghlan <ncoghlan@gmail.com
> <mailto:ncoghlan@gmail.com>> wrote:
>
>     CTO wrote:
>     > EVP covers hashing, signatures, and encryption/decryption. If we're
>     > going
>     > to go for a longer name, maybe "cryptography" would be more
>     > appropriate?
>
>     Something to keep in mind while working on this is your threat model for
>     the library. If you aren't going to do anything to guard against
>     side-channel attacks (which are rather hard to avoid in a cross platform
>     algorithm on a general purpose PC) or against attacks which grab
>     unencrypted messages and keys from released-but-not-overwritten computer
>     memory or (worse) the swap file, then this should be mentioned in the
>     documentation.
>
>     That way application developers that are looking for that extra level of
>     security will know they need to look elsewhere.
>
>     Regards,
>     Nick.
>
>
> I can make a note of it, although I'm unsure what concrete steps I could
> take to prevent such attacks from succeeding. Any ideas?

OpenSSL may actually guard against of the first part already. I'm unsure
about the second part though. And I don't know enough about the problems
to know how to fix them either - I just know when I'm theoretically
leaving these attack vectors open and make sure to defend them by other
means (such as physically securing the affected networks).

But it's this kind of stuff that people are talking about when they
point out that practical crypto is harder than just using good algorithms.

Cheers,
Nick. 

It seems to me that most timing attacks should already be out, so I'm not
*too* worried about that- but I have literally no idea how to stop the secrets
from being dropped into swap in this context. I think what I'm going to do
is just make a note of it in the docs for the module and make sure that
there's enough contact info in there to ensure that anybody reviewing the
code can let me know if we're doing something stupid.

And on that note: since most of my knowledge of crypto is theoretical
in nature, I'm going to be leaning a lot on those of you with more
practical experience as we go forward with this.
Therefore, for everybody reading this list- please,
*review the code*! If you think there's a problem, assume
you're right and let me know- we really, really, really do not want
half-baked crypto in the standard lib. Assuming that's even
where this is headed.

Geremy Condra