[Python-ideas] adding digital signature and encryption "hashes" to hashlib?
debatem1 at gmail.com
Sat Sep 26 06:01:49 CEST 2009
On Fri, Sep 25, 2009 at 10:35 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> geremy condra wrote:
> > On Fri, Sep 25, 2009 at 9:49 PM, Nick Coghlan <ncoghlan at gmail.com
> > <mailto:ncoghlan at 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
> > 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
> > algorithm on a general purpose PC) or against attacks which grab
> > unencrypted messages and keys from released-but-not-overwritten
> > 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
> > 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.
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas