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