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

[CTO]

On Sep 25, 7:44 am, Antoine Pitrou <solip... at pitrou.net> wrote:
> Bill Janssen <janssen at ...> writes:
>
> > Again, I wasn't proposing to replace m2cryto or pycrypto or anything
> > else; I was suggesting that providing easy-to-use APIs to a couple of
> > commonly-requested crypto features, for use by non-cryptographers,
> > wouldn't be a bad idea.
>
> I think it would be good indeed. Since we already wrapping OpenSSL, let's give
> access to more of its features instead of having people find additional binary
> packages (of varying quality) for their platform.

I've started putting the code together. It's very rough, but it does
vaguely what it's supposed to do. It only supports AES192 right now,
but it shouldn't be any harder to expand on that than it was to
write the existing code, and I'd appreciate the contributions of
anyone interested in seeing this in the standard library- it needs
the help.

You can find my code over at http://gitorious.org/cryptography-py/cryptography-py.

> As for some of the points which have been raised here:
...snip...
> - Please don't call the package "evp", it's cryptic (;-)) and tied to a specific
> implementation. "crypto" would be fine and obvious.

I know of at least one implementation that uses Crypto as its
name, and forgot to send them an email earlier this week. I'll
do that today, and if they don't seem bent on changing the
capitalization, I don't see any problem there.

A side note: the code I've posted is a little schizophrenic
since we haven't figured a name or toplevel structure out. That
can change whenever a consensus  emerges.

> - I don't think there should be a default argument. People shouldn't try to do
> any crypto at all if they aren't able to choose an algorithm. Documenting
> (perhaps recommending) a couple of them (AES, RSA) would be more helpful than
> supporting a silent default.

Right now it just divides one cryptosystem into each module.
For example, to use AES192, you can simply say:

import aes
ciphertext = aes.encrypt("this is a message", "this is my password")
plaintext = aes.decrypt(ciphertext, "this is my password")
assert plaintext == "this is a message"

and it handles salt generation, IV generation, bitlength selection,
and key strengthening for you.

Eventually, if crypto becomes the name of the package, it will
probably turn into "from crypto import aes".

> - The API needn't (and shouldn't) be the same as for hashing objects. A digest()
> method doesn't make sense. Ideally some of the {en,de}crypting objects could be
> file-like objects, but it's not really necessary IMO (and it can always be done
> in pure Python on top of a lower-level C extension, assuming the extension does
> provide a streaming interface).

I can provide the streaming interface if it's desired. It would in
some cases
be more efficient, but for most I think it's needless complexity.
Again,
others may disagree, and I'm sure there's fertile ground for
discussion
there.

Geremy Condra