This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author debatem1
Recipients daniel.urban, debatem1, eric.araujo, exarkun, giampaolo.rodola, gregory.p.smith, heikki, loewis, mcrute, pitrou
Date 2010-06-15.14:49:42
SpamBayes Score 4.1914038e-07
Marked as misclassified No
Message-id <AANLkTimBTJVxg6x5fmEugMbs4O8bAdVfoLbarxNh_2VG@mail.gmail.com>
In-reply-to <1276608073.65.0.599603228222.issue8998@psf.upfronthosting.co.za>
Content
On Tue, Jun 15, 2010 at 9:21 AM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> I've taken a quick look at the source tree (there doesn't seem to be any separate docs) and here is my opinion:
> - the evp.py API is too low-level (it's a one-to-one mapping to the OpenSSL C API); we would want at least some kind of object-oriented abstraction around the basic concepts (such as in the hashlib and ssl modules) rather than passing opaque pointers around

evp.py is mostly for internal use (to map the openssl calls into
Python) and won't exist in the rewrite- most of the people who would
want to use that should really be using M2Crypto or similar.

> - the other APIs (cipher.py, envelope.py, signature.py) look conversely too high-level, since they focus on specific use cases and make some arbitrary choices for the user (for example, envelope.py imposes AES-192)

The goals of the library are simplicity and ease of use. I've
frequently found that out of fear of making incorrect choices, people
will simply decide not to use crypto at all, or that they make
incredibly stupid choices like using RSA without padding. I'd be
willing to add in the option to alter those options via keyword
arguments if it became a major point of contention, but in general I
think its better for those who "just want to encrypt something" to
have a lot of those decisions made for them. The specific decision
you're talking about was made because while AES-256 has a bigger
number at the end, its key schedule appears weaker in light of recent
attacks.

> By the way, the use of function signature annotations to mirror C APIs as Python APIs through ctypes is nice, perhaps you should upload it as a separate library on PyPI :)

I've posted them as recipes on ASPN ([0] and [1]). I used a similar
technique and the JNI to mechanically wrap the Android libraries
(Java) for access from Python, and it worked pretty well. Looking at
the data from pypi, ease-of-use things don't seem to see a lot of use,
but if you think I ought to then I could go ahead and do that.

Geremy Condra

[0] http://code.activestate.com/recipes/576731-c-function-decorator/
[1] http://code.activestate.com/recipes/576734-c-struct-decorator/
History
Date User Action Args
2010-06-15 14:49:48debatem1setrecipients: + debatem1, loewis, gregory.p.smith, exarkun, pitrou, giampaolo.rodola, heikki, eric.araujo, daniel.urban, mcrute
2010-06-15 14:49:46debatem1linkissue8998 messages
2010-06-15 14:49:42debatem1create