[Python-ideas] adding digital signature and encryption "hashes" to hashlib?

geremy condra debatem1 at gmail.com
Sat Sep 26 07:06:52 CEST 2009


On Sat, Sep 26, 2009 at 12:01 AM, geremy condra <debatem1 at gmail.com> wrote:

>
>
> 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
>> 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
>

Added the notice to the top of aes.c.

Geremy Condra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090926/89841da4/attachment.html>


More information about the Python-ideas mailing list