[python-crypto] Add AES to amkCrypto?

[M.-A. Lemburg]

Bryan Olson wrote:
> 
> Bryan Olson wrote:
> >
> > > Marc-Andre Lemburg wrote:
> > > > The API designed by Andrew Kuchling is the defacto standard
> > > > for interfacing to crypto algorithms in Python. His pycrypt
> > > > library has been around for many years and suits the task very well.
> > >
> > > > There's really no need to design yet another API...
> > >
> > > I disagree.  The amkCrypto interface is terrible, and especially
> > > for block cipher modes of operation.  It defines a source-code
> > > template to wrap around every block cipher at compile time to
> > > provide the modes for that one cipher.
> >
> > Huh ? The mode is a parameter of cipher constructors. What do you
> > mean with "source-code template" ?
> 
> I mean that in the API by Andrew Kuchling, the modes are
> hard-coded for each cipher.  The same code got repeated around
> each cipher to produce the various modes.  Andrew had a code
> template to put around a cipher to generate the modes.  I
> understand most of these are now imported from OpenSSL, but
> that makes them even less flexible.

Ok, now I understand: you want to play with new algorithms
at an even lower level. I don't think that this is common usage
though.

Andrew's and the OpenSSL implementation have separate APIs
for each mode because they can be optimized in different
ways. The only way to get the compiler to optimize the code
is by writing it down once for each mode. That way you get
the best possible performance. In addition to this step, the
algorithm state can usually be optimized w/r to the mode too.
 
> > mxCrypto (which is part of amkCrypto) does some switching on
> > the mode parameter since OpenSSL has different APIs for each mode,
> > but this is not exposed at Python level.
> 
> Not exposing it doesn't make it better.  How does one add a
> new mode or a new cipher under the current API?

By writing the cipher in Python or C and then adding it to the
package. I don't get your point here. The API defines how Python
will interact with the implementation, it does not define
what goes on underneath.

> > > NIST is holding workshops on modes of operation, and will
> > > probably define new ones along with the AES.  Modes and
> > > ciphers should be interchangeable, and we should be able to
> > > write each in either Python or an extension (and have it work
> > > with the others of course).
> >
> > I think this is what "PC Drew" (what's your real name, BTW ?)
> > had in mind with his higherlevel API.
> >
> > An codec style interface would also be nice to have. Streams
> > could then easily be encoded and decoded on-the-fly.
> 
> So this calls for a new API.

A new high level API, yes.
 
> > > > As for integrating AES into amkCrypto, I think the best way is
> > > > to wait until OpenSLL has support for it and then integrate
> > > > that support into amkCrypto.
> > >
> > > OpenSSL is centered on one cryptographic protocol.  I'd like
> > > to see the basic AES cipher, without any modes, in the
> > > standard Python distribution.  Recent changes in export law
> > > allow free software to include strong encryption.  We should
> > > also get SHA-256, SHA-384 and SHA-512 into the standard
> > > distribution.
> >
> > OpenSSL is many things: its a collection of very fast cipher,
> > hash and public key algorithms as well as an implementation of
> > various binary serialization standards for keys, certificates,
> > etc. plus some various other things.  The SSL implementation
> > sits on top of these.
> 
> It has the many things needed to implement TLS, and usually
> only has them to the extent needed to implement TLS.  It's
> very hard to use as a general crypto library for Python.

Why ? mxCrypto has proven that all includes ciphers and hashes
can be made available to Python.
 
> > The goal of mxCrypto was to expose the lower-level parts of
> > OpenSSL to be able to implement other cryptographic protocols.
> 
> What Python cannot do well is the low level primitives, such
> as block ciphers and hash functions.  Things like encoding and
> decoding certificates is easier in Python than in C.

Sure, but where does the API in amkCrypto restrict you to using
C as implementation language ?
 
-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/1/_/22498/_/981034490/
---------------------------------------------------------------------_->