On Sep 25, 7:44 am, Antoine Pitrou <solip...@pitrou.net> wrote:
Bill Janssen <janssen@...> 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