From michael at stroeder.com  Sat Jan 27 14:09:55 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 27 Jan 2001 14:09:55 +0100
Subject: Interested in a Crypto-SIG?
Message-ID: <3A72C8A3.C4B4D69A@stroeder.com>

HI!

(I know that SIG proposals should go to the META-SIG list but I
guess not many developers are subscribed to this list. Therefore I
start the discussion here.)

I would like to propose a Crypto-SIG. The goal is to define Pythonic
class APIs for various cryptographic and related standards to enable
developers to use a unified API for implementing crypto-enabled
applications in Python independent of the underlying implementations
(basically inspired by Sun's Java crypto-related APIs).

APIs for (in my personally preferred order):
- cryptographic algorithms (similar to Sun's JCE for Java)
- encoding/decoding ASN.1 objects
- X.509 certificates (including path validation)
- SSL
- S/MIME
- SPKI
- OpenPGP
- XML-DSIG

Let me know what you think.

Ciao, Michael.


From Daniel.Kinnaer at Advalvas.be  Sat Jan 27 14:57:57 2001
From: Daniel.Kinnaer at Advalvas.be (Daniel)
Date: Sat, 27 Jan 2001 13:57:57 GMT
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com>
Message-ID: <3a72d11f.17643900@news.skynet.be>

On Sat, 27 Jan 2001 14:09:55 +0100, Michael =?iso-8859-1?Q?Str=F6der?=
<michael at stroeder.com> wrote:

>I would like to propose a Crypto-SIG. 
>Let me know what you think.
>
>Ciao, Michael.


It would be nice to have the new AES in a Python module, just like
BlowFish, TwoFish, TDES, etc.   All of these algorithms (written in C)
can be readily found on the net.  Not a very easy subject, though...

best regards,

Daniel 


From michael at stroeder.com  Sat Jan 27 15:07:09 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 27 Jan 2001 15:07:09 +0100
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com> <3a72d11f.17643900@news.skynet.be>
Message-ID: <3A72D60D.9351601A@stroeder.com>

Daniel wrote:
> 
> On Sat, 27 Jan 2001 14:09:55 +0100, Michael =?iso-8859-1?Q?Str=F6der?=
> <michael at stroeder.com> wrote:
> 
> >I would like to propose a Crypto-SIG.
> >Let me know what you think.
> 
> It would be nice to have the new AES in a Python module, just like
> BlowFish, TwoFish, TDES, etc.   All of these algorithms (written in C)
> can be readily found on the net. 

Yes, there are already a lot of implementations of cryptographic
algorithms floating around. My main concern is that they all have
different APIs. Not easy for application programmers to choose the
right lib.

> Not a very easy subject, though...

Yes. That's why I would like to bring together all the isolated
efforts and focus on creating a unified API.

Ciao, Michael.


From amk at mira.erols.com  Sat Jan 27 19:17:46 2001
From: amk at mira.erols.com (A.M. Kuchling)
Date: 27 Jan 2001 18:17:46 GMT
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com>
Message-ID: <slrn97650f.i1.amk@mira.erols.com>

On Sat, 27 Jan 2001 14:09:55 +0100, 
	Michael Str?der <michael at stroeder.com> wrote:
>I would like to propose a Crypto-SIG. The goal is to define Pythonic
>class APIs for various cryptographic and related standards to enable
>developers to use a unified API for implementing crypto-enabled
>applications in Python independent of the underlying implementations
>(basically inspired by Sun's Java crypto-related APIs).

Are you the same person who proposed this yesterday on the Meta-SIG?
Anyway, I'll give you the same answer: a unified API would be an
excellent idea, but a SIG seems unnecessary.  There's already a
python-crypto list at egroups which could be used to coordinate work
on such a unified API (it's the second link for a Google search on
"python crypto"), and the main issue is probably developer time.

--amk


From bryan at eevolved.com  Sat Jan 27 19:32:24 2001
From: bryan at eevolved.com (Bryan Mongeau)
Date: Sat, 27 Jan 2001 18:32:24 GMT
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com> <3a72d11f.17643900@news.skynet.be>
Message-ID: <YuEc6.3712$fe1.72426@news20.bellglobal.com>

Daniel wrote:

> On Sat, 27 Jan 2001 14:09:55 +0100, Michael =?iso-8859-1?Q?Str=F6der?=
> <michael at stroeder.com> wrote:
> 
> >I would like to propose a Crypto-SIG.
> >Let me know what you think.
> >
> >Ciao, Michael.
> 
> 
> It would be nice to have the new AES in a Python module, just like
> BlowFish, TwoFish, TDES, etc.   All of these algorithms (written in C)
> can be readily found on the net.  Not a very easy subject, though...
> 
> best regards,
> 
> Daniel

Your wish is my command. :)
Check out a higher thread, I am releasing my AES python module. There are 
other goodies as well. 

enjoy.
-- 
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
www.eevolved.com
<==================================>

"Heroism on command, senseless violence, and all the loathsome nonsense 
that goes by the name of patriotism -- how passionately I hate them!"-- 
Einstein


From michael at stroeder.com  Sat Jan 27 20:14:03 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 27 Jan 2001 20:14:03 +0100
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com> <slrn97650f.i1.amk@mira.erols.com>
Message-ID: <3A731DFB.3CF394C3@stroeder.com>

"A.M. Kuchling" wrote:
> 
> On Sat, 27 Jan 2001 14:09:55 +0100,
>         Michael Str?der <michael at stroeder.com> wrote:
> >I would like to propose a Crypto-SIG. The goal is to define Pythonic
> >class APIs for various cryptographic and related standards to enable
> >developers to use a unified API for implementing crypto-enabled
> >applications in Python independent of the underlying implementations
> >(basically inspired by Sun's Java crypto-related APIs).
> 
> Are you the same person who proposed this yesterday on the Meta-SIG?

No. But good to know that I'm not the only one. ;-)

> Anyway, I'll give you the same answer: a unified API would be an
> excellent idea, but a SIG seems unnecessary.  There's already a
> python-crypto list at egroups which could be used to coordinate work
> on such a unified API

The mailing list on egroups could be a start. But I would prefer
something which looks more "official" and is tied closer to Python
activities itself. I'm willing to act as a SIG-coordinator.

> and the main issue is probably developer time.

Yes. But everybody can save time if it's not necessary any more to
reinvent wheel for every crypto package.

Ciao, Michael.


From michael at stroeder.com  Sat Jan 27 20:19:02 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 27 Jan 2001 20:19:02 +0100
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com> <slrn97650f.i1.amk@mira.erols.com>
Message-ID: <3A731F26.15461A27@stroeder.com>

"A.M. Kuchling" wrote:
> 
> There's already a
> python-crypto list at egroups which could be used to coordinate work
> on such a unified API

-------- Original Message --------
Subject: Welcome to python-crypto
Date: 27 Jan 2001 18:58:49 -0000
From: python-crypto Moderator <python-crypto-owner at yahoogroups.com>
[..]
<P>The list is hosted inside the US, as are its archives, so
to avoid falling afoul of the US export restrictions, it's
recommended that postings not contain complete programs or modules. 
A few lines of code, for illustrating a point or a bug, are probably
OK.  Patches to existing crypto code falls in a grey area; it's best
to mail them to the software's maintainer. 
-------- Original Message --------

This does not attract me very much.

Ciao, Michael.


From moshez at zadka.site.co.il  Sat Jan 27 20:30:55 2001
From: moshez at zadka.site.co.il (Moshe Zadka)
Date: Sat, 27 Jan 2001 21:30:55 +0200 (IST)
Subject: Interested in a Crypto-SIG?
In-Reply-To: <3A731F26.15461A27@stroeder.com>
References: <3A731F26.15461A27@stroeder.com>, <3A72C8A3.C4B4D69A@stroeder.com> <slrn97650f.i1.amk@mira.erols.com>
Message-ID: <mailman.980623894.3390.python-list@python.org>

On Sat, 27 Jan 2001, <michael at stroeder.com> wrote:

> -------- Original Message --------
> Subject: Welcome to python-crypto
> Date: 27 Jan 2001 18:58:49 -0000
> From: python-crypto Moderator <python-crypto-owner at yahoogroups.com>
> [..]
> <P>The list is hosted inside the US, as are its archives, so
> to avoid falling afoul of the US export restrictions, it's
> recommended that postings not contain complete programs or modules. 
> A few lines of code, for illustrating a point or a bug, are probably
> OK.  Patches to existing crypto code falls in a grey area; it's best
> to mail them to the software's maintainer. 
> -------- Original Message --------
> 
> This does not attract me very much.

The python.org servers are also inside the US, and are subject to 
the same restrictions.
-- 
Moshe Zadka <sig at zadka.site.co.il>
This is a signature anti-virus. 
Please stop the spread of signature viruses!
Fingerprint: 4BD1 7705 EEC0 260A 7F21  4817 C7FC A636 46D0 1BD6


From bryan at eevolved.com  Sat Jan 27 23:18:05 2001
From: bryan at eevolved.com (Bryan Mongeau)
Date: Sat, 27 Jan 2001 22:18:05 GMT
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com> <slrn97650f.i1.amk@mira.erols.com> <3A731DFB.3CF394C3@stroeder.com>
Message-ID: <xOHc6.132391$JT5.4910791@news20.bellglobal.com>

Michael Str?der wrote:

> The mailing list on egroups could be a start. But I would prefer
> something which looks more "official" and is tied closer to Python
> activities itself. I'm willing to act as a SIG-coordinator.
> 
> > and the main issue is probably developer time.
> 
> Yes. But everybody can save time if it's not necessary any more to
> reinvent wheel for every crypto package.
> 
> Ciao, Michael.

This is a commendable initiative, Michael, that I support fully. If I 
weren't tied up in a giant project I would gladly donate some of my time as 
well.

Please keep me posted of any developments on this front so I might be able 
to adhere to / retrofit any crypto SIG standards. I'm also available for 
input should you appreciate that.

And yes, I hate wheels too. I've invented too many of them. :)

-- 
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
www.eevolved.com
<==================================>

"Heroism on command, senseless violence, and all the loathsome nonsense 
that goes by the name of patriotism -- how passionately I hate them!"-- 
Einstein


From amk at mira.erols.com  Sun Jan 28 19:36:11 2001
From: amk at mira.erols.com (A.M. Kuchling)
Date: 28 Jan 2001 18:36:11 GMT
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com> <slrn97650f.i1.amk@mira.erols.com> <3A731F26.15461A27@stroeder.com> <slrn978o29.gn.amk@mira.erols.com> <3A7461AC.AC5768@stroeder.com>
Message-ID: <slrn978qf4.kk.amk@mira.erols.com>

On Sun, 28 Jan 2001 19:15:08 +0100, 
	Michael Stroeder <michael at stroeder.com> wrote:
>Yes, I know how much work a reasonable crypto API for Python is.
>
>But there are people currently working on this stuff (e.g. M2Crypto,
>some commercial projects). This is my try to coordinate the work
>which is already done to save our time!

Yes, but my point is that the mere creation of a SIG won't do that.
Writing a draft of a proposed crypto API, or the requirements for such
an interface, is more likely to start something moving.  

--amk


From drewpc at colorado.edu  Tue Jan 30 19:09:42 2001
From: drewpc at colorado.edu (PC Drew)
Date: Tue, 30 Jan 2001 11:09:42 -0700
Subject: [python-crypto] Add AES to amkCrypto?
Message-ID: <59317538836.20010130110942@colorado.edu>

I just read on Python-URL! that someone has released the new AES in
python. (http://deja.com/=dnc/getdoc.xp?AN=720935577)  I also
expressed interest in creating an encryption sig and was told of
amkCrytpo and m2crypto.  After looking at amkCrypto (not extensively,
but I read through the manual) I was wondering if there would be any
interest in contacting the developer of the AES port and trying to
integrate his work in to amkCrypto (and m2crypto, if there's
interest).  Also, what sort of interest is there in trying to get this
released with the Python distribution (instead of a seperate module)?
 What sort of laws are there against this?

Thanks!

--
PC Drew

  Be nice or I'll replace you with a very
  small shell script.



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





From ngps at post1.com  Tue Jan 30 17:16:03 2001
From: ngps at post1.com (Ng Pheng Siong)
Date: Wed, 31 Jan 2001 00:16:03 +0800
Subject: [python-crypto] [Announce] M2Crypto 0.06 snapshot #1
Message-ID: <20010131001603.E1235@madcap.dyndns.org>

Hi,

M2Crypto 0.06 snapshot #1 is now available. This release fixes
a bug in its SSL which causes Medusa https to crash when IE or Opera
comes a-calling.

Win32 binaries for both Python 1.5.2 and Python 2.0 are bundled.

Please go here:

    http://www.post1.com/home/ngps/m2


Cheers.
-- 
Ng Pheng Siong <ngps at post1.com> * http://www.post1.com/home/ngps


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





From michael at stroeder.com  Tue Jan 30 21:03:06 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 30 Jan 2001 21:03:06 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <59317538836.20010130110942@colorado.edu>
Message-ID: <3A771DFA.71056D40@stroeder.com>

PC Drew wrote:
> 
> I just read on Python-URL! that someone has released the new AES in
> python. (http://deja.com/=dnc/getdoc.xp?AN=720935577)  I also
> expressed interest in creating an encryption sig and was told of
> amkCrytpo and m2crypto.

IMHO the main problem for application and crypto lib developers is
the lack of a standard API. Crypto lib developers are designing new
APIs every time and application developers have to deal with the
different APIs.
=> there should be a standard class library which abstracts from
various algorithms and their implementation etc.

This would save time...

Ciao, Michael.

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





From drewpc at colorado.edu  Wed Jan 31 01:14:27 2001
From: drewpc at colorado.edu (PC Drew)
Date: Tue, 30 Jan 2001 17:14:27 -0700
Subject: [python-crypto] Add AES to amkCrypto?
In-Reply-To: <3A771DFA.71056D40@stroeder.com>
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com>
Message-ID: <54339427196.20010130171427@colorado.edu>

I totally agree.  That's why I suggested an crypto-sig...mostly to
develop a standard API.  In addition to that, I think that it is
important to also develop an abstraction layer to go with the API so
that, not only do things look the same, but if you wanted to go from
one algorithm to another, it would be very easy.

If anyone is interested in defining this with me, please email me and
I'll get a list together and we can start hashing this out.  I'm also
interested in doing the same thing with compression libraries, and I'd
like some feedback on that as well.

-- 
PC Drew


Tuesday, January 30, 2001, 1:03:06 PM, you wrote:

MS> PC Drew wrote:
>>
>> I just read on Python-URL! that someone has released the new AES in
>> python. (http://deja.com/=dnc/getdoc.xp?AN=720935577)? I also
>> expressed interest in creating an encryption sig and was told of
>> amkCrytpo and m2crypto.

MS> IMHO the main problem for application and crypto lib developers is
MS> the lack of a standard API. Crypto lib developers are designing new
MS> APIs every time and application developers have to deal with the
MS> different APIs.
=>> there should be a standard class library which abstracts from
MS> various algorithms and their implementation etc.

MS> This would save time...

MS> Ciao, Michael.

MS> Yahoo! Groups Sponsor
MS> www.???



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





From mal at lemburg.com  Wed Jan 31 12:24:36 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 31 Jan 2001 12:24:36 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com>
Message-ID: <3A77F5F4.A22B0811@lemburg.com>

Michael Str?der wrote:
> 
> PC Drew wrote:
> >
> > I just read on Python-URL! that someone has released the new AES in
> > python. (http://deja.com/=dnc/getdoc.xp?AN=720935577)  I also
> > expressed interest in creating an encryption sig and was told of
> > amkCrytpo and m2crypto.
> 
> IMHO the main problem for application and crypto lib developers is
> the lack of a standard API. Crypto lib developers are designing new
> APIs every time and application developers have to deal with the
> different APIs.
> => there should be a standard class library which abstracts from
> various algorithms and their implementation etc.
> 
> This would save time...

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

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.

-- 
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/_/980940297/
---------------------------------------------------------------------_->





From drewpc at colorado.edu  Wed Jan 31 15:51:07 2001
From: drewpc at colorado.edu (PC Drew)
Date: Wed, 31 Jan 2001 07:51:07 -0700
Subject: [python-crypto] Add AES to amkCrypto?
In-Reply-To: <3A77F5F4.A22B0811@lemburg.com>
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com> <3A77F5F4.A22B0811@lemburg.com>
Message-ID: <107392034776.20010131075107@colorado.edu>


Wednesday, January 31, 2001, 4:24:36 AM, you wrote:

MAL> Michael Str?der wrote:
>>
>> PC Drew wrote:
>> >
>> > I just read on Python-URL! that someone has released the new AES in
>> > python. (http://deja.com/=dnc/getdoc.xp?AN=720935577)? I also
>> > expressed interest in creating an encryption sig and was told of
>> > amkCrytpo and m2crypto.
>>
>> IMHO the main problem for application and crypto lib developers is
>> the lack of a standard API. Crypto lib developers are designing new
>> APIs every time and application developers have to deal with the
>> different APIs.
>> => there should be a standard class library which abstracts from
>> various algorithms and their implementation etc.
>>
>> This would save time...

MAL> The API designed by Andrew Kuchling is the defacto standard
MAL> for interfacing to crypto algorithms in Python. His pycrypt
MAL> library has been around for many years and suits the task very well.

I didn't know that his API was the defacto standard, but I like the
way he has it organized.  I'm not saying that we should start from the
drawing board, I'm only saying that we should document a formal API
for writing crypto algorithms and publish it (on python.org?).  Then
trying to get that in the Python distribution.  You're saying it's the
defacto standard, all I'm proposing is that we actually make a
standard and use Andrew's code as the framework.

MAL> There's really no need to design yet another API...

MAL> As for integrating AES into amkCrypto, I think the best way is
MAL> to wait until OpenSLL has support for it and then integrate
MAL> that support into amkCrypto.

Just out of curiosity, why do you think that?  I don't know anything
about the development of OpenSSL so I don't know how they do things.
Why wouldn't it be prudent to "just do it"?



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





From mal at lemburg.com  Wed Jan 31 16:32:27 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 31 Jan 2001 16:32:27 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com> <3A77F5F4.A22B0811@lemburg.com> <107392034776.20010131075107@colorado.edu>
Message-ID: <3A78300B.BBA93AA6@lemburg.com>

PC Drew wrote:
> 
> Wednesday, January 31, 2001, 4:24:36 AM, you wrote:
> 
> MAL> Michael Str?der wrote:
> >>
> >> PC Drew wrote:
> >> >
> >> > I just read on Python-URL! that someone has released the new AES in
> >> > python. (http://deja.com/=dnc/getdoc.xp?AN=720935577)  I also
> >> > expressed interest in creating an encryption sig and was told of
> >> > amkCrytpo and m2crypto.
> >>
> >> IMHO the main problem for application and crypto lib developers is
> >> the lack of a standard API. Crypto lib developers are designing new
> >> APIs every time and application developers have to deal with the
> >> different APIs.
> >> => there should be a standard class library which abstracts from
> >> various algorithms and their implementation etc.
> >>
> >> This would save time...
> 
> MAL> The API designed by Andrew Kuchling is the defacto standard
> MAL> for interfacing to crypto algorithms in Python. His pycrypt
> MAL> library has been around for many years and suits the task very well.
> 
> I didn't know that his API was the defacto standard, but I like the
> way he has it organized.  I'm not saying that we should start from the
> drawing board, I'm only saying that we should document a formal API
> for writing crypto algorithms and publish it (on python.org?).  Then
> trying to get that in the Python distribution.  You're saying it's the
> defacto standard, all I'm proposing is that we actually make a
> standard and use Andrew's code as the framework.

You mean wrap Andrew's docs as HTML file ? That should be
possible (his docs are written in LaTeX).
 
We could then have a python.org page for it much like the
database API page and probably also move this mailing list
there as crypto-sig.

> MAL> There's really no need to design yet another API...
> 
> MAL> As for integrating AES into amkCrypto, I think the best way is
> MAL> to wait until OpenSLL has support for it and then integrate
> MAL> that support into amkCrypto.
> 
> Just out of curiosity, why do you think that?  I don't know anything
> about the development of OpenSSL so I don't know how they do things.
> Why wouldn't it be prudent to "just do it"?

Because the maintainers of OpenSSL are really smart guys and
know a lot about writing code which runs as fast as possible.

Maintaining such code (usually a combination of C and assembler)
to run on multiple platforms isn't a simple task at all, but they are
doing a great job at it.

If you don't want to wait, though, go ahead and wrap the
AES C code into a Python module using the same APIs as the
other ciphers in amkCrypto. People will then be able to upgrade
to the OpenSSL based ciphers later on.

-- 
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/_/980956915/
---------------------------------------------------------------------_->





From rsalz at caveosystems.com  Wed Jan 31 17:15:56 2001
From: rsalz at caveosystems.com (Rich Salz)
Date: Wed, 31 Jan 2001 11:15:56 -0500
Subject: [python-crypto] Add AES to amkCrypto?
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com> <3A77F5F4.A22B0811@lemburg.com> <107392034776.20010131075107@colorado.edu> <3A78300B.BBA93AA6@lemburg.com>
Message-ID: <3A783A3C.C42E4660@caveosystems.com>

I strongly agree that this group should focus on the class definitions. 
Leave the C code to openssl, which is already a world-class open source
crypto toolkit.  See www.openssl.org  I think pure-python crypto
implementations are interesting, but not very useful.  Wei Da's crypto++
is also excellent.

BTW, openssl has had rijndael (AES) crypto functions for a few months.
	/r$

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





From drewpc at colorado.edu  Wed Jan 31 19:14:48 2001
From: drewpc at colorado.edu (PC Drew)
Date: Wed, 31 Jan 2001 11:14:48 -0700
Subject: [python-crypto] Add AES to amkCrypto?
In-Reply-To: <3A783A3C.C42E4660@caveosystems.com>
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com> <3A77F5F4.A22B0811@lemburg.com> <107392034776.20010131075107@colorado.edu> <3A78300B.BBA93AA6@lemburg.com> <3A783A3C.C42E4660@caveosystems.com>
Message-ID: <26404257861.20010131111448@colorado.edu>


Wednesday, January 31, 2001, 9:15:56 AM, you wrote:

RS> I strongly agree that this group should focus on the class definitions.
RS> Leave the C code to openssl, which is already a world-class open source
RS> crypto toolkit.

I agree.  There's no point in reinventing the wheel, especially if
these guys really know what they're doing.

RS> ? See www.openssl.org? I think pure-python crypto
RS> implementations are interesting, but not very useful.

I agree.

RS> ? Wei Da's crypto++
RS> is also excellent.

where can I look at this?

RS> BTW, openssl has had rijndael (AES) crypto functions for a few months.
RS> ????? /r$

is it the new AES standard or the original algorithm (I think I
remember seeing that there were some changes made since the acceptance
of Rijandael as the AES)?  I could be wrong.



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





From rsalz at caveosystems.com  Wed Jan 31 20:04:26 2001
From: rsalz at caveosystems.com (Rich Salz)
Date: Wed, 31 Jan 2001 14:04:26 -0500
Subject: [python-crypto] Add AES to amkCrypto?
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com> <3A77F5F4.A22B0811@lemburg.com> <107392034776.20010131075107@colorado.edu> <3A78300B.BBA93AA6@lemburg.com> <3A783A3C.C42E4660@caveosystems.com> <26404257861.20010131111448@colorado.edu>
Message-ID: <3A7861BA.38345A57@caveosystems.com>

Crypto++ is at http://www.eskimo.com/~weidai/cryptlib.html

As for AES/Rijndael changes, I really don't think so.  There were some
changes about the suggested number of rounds and keysizes, but that was
between NIST Rounds 1 and 2, and not post-acceptance.  (Kinda defeats
the purpose if you choose an algorithm, then change it from what
everyone studied.)
	/r$

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





From drewpc at colorado.edu  Wed Jan 31 18:44:49 2001
From: drewpc at colorado.edu (PC Drew)
Date: Wed, 31 Jan 2001 10:44:49 -0700
Subject: [python-crypto] Add AES to amkCrypto?
In-Reply-To: <3A78300B.BBA93AA6@lemburg.com>
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com> <3A77F5F4.A22B0811@lemburg.com> <107392034776.20010131075107@colorado.edu> <3A78300B.BBA93AA6@lemburg.com>
Message-ID: <20402458880.20010131104449@colorado.edu>


Wednesday, January 31, 2001, 8:32:27 AM, you wrote:

>>
>> I didn't know that his API was the defacto standard, but I like the
>> way he has it organized.? I'm not saying that we should start from the
>> drawing board, I'm only saying that we should document a formal API
>> for writing crypto algorithms and publish it (on python.org?).? Then
>> trying to get that in the Python distribution.? You're saying it's the
>> defacto standard, all I'm proposing is that we actually make a
>> standard and use Andrew's code as the framework.

MAL> You mean wrap Andrew's docs as HTML file ? That should be
MAL> possible (his docs are written in LaTeX).

A little bit more than that, but yeah.  I need to look at his
documentation again, but I want to formally document the API and then
post it.  In addition to that, I want to have a standard, cross
platform install (if possible), similar to that of the XML SIG
install.  I want to create a crypto abstraction layer to be something
like this:

ciphertext = encrypt("DES", plaintext)

(obviously not exactly like that, but you get my drift) so that people
can easily change this to be:

ciphertext = encrypt("AES", plaintext)

when the need arises.  All of these ideas are just that.  That's why I
want to create a SIG for this...to discuss all of these ideas.

MAL> We could then have a python.org page for it much like the
MAL> database API page and probably also move this mailing list
MAL> there as crypto-sig.

>> MAL> There's really no need to design yet another API...
>>
>> MAL> As for integrating AES into amkCrypto, I think the best way is
>> MAL> to wait until OpenSLL has support for it and then integrate
>> MAL> that support into amkCrypto.
>>
>> Just out of curiosity, why do you think that?? I don't know anything
>> about the development of OpenSSL so I don't know how they do things.
>> Why wouldn't it be prudent to "just do it"?

MAL> Because the maintainers of OpenSSL are really smart guys and
MAL> know a lot about writing code which runs as fast as possible.

MAL> Maintaining such code (usually a combination of C and assembler)
MAL> to run on multiple platforms isn't a simple task at all, but they are
MAL> doing a great job at it.

So how does that library work, and how does it correspond to
amkCrypto?  Doe the OpenSSL guys write it in C and then someone wraps
it for Python?  If so, then what's the difference between that and
amkCrypto?

MAL> If you don't want to wait, though, go ahead and wrap the
MAL> AES C code into a Python module using the same APIs as the
MAL> other ciphers in amkCrypto. People will then be able to upgrade
MAL> to the OpenSSL based ciphers later on.

I'm thinking about that...see above questions though.



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





From mal at lemburg.com  Wed Jan 31 19:37:30 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 31 Jan 2001 19:37:30 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <59317538836.20010130110942@colorado.edu> <3A771DFA.71056D40@stroeder.com> <3A77F5F4.A22B0811@lemburg.com> <107392034776.20010131075107@colorado.edu> <3A78300B.BBA93AA6@lemburg.com> <20402458880.20010131104449@colorado.edu>
Message-ID: <3A785B6A.F9752DDD@lemburg.com>

PC Drew wrote:
> 
> Wednesday, January 31, 2001, 8:32:27 AM, you wrote:
> 
> >>
> >> I didn't know that his API was the defacto standard, but I like the
> >> way he has it organized.  I'm not saying that we should start from the
> >> drawing board, I'm only saying that we should document a formal API
> >> for writing crypto algorithms and publish it (on python.org?).  Then
> >> trying to get that in the Python distribution.  You're saying it's the
> >> defacto standard, all I'm proposing is that we actually make a
> >> standard and use Andrew's code as the framework.
> 
> MAL> You mean wrap Andrew's docs as HTML file ? That should be
> MAL> possible (his docs are written in LaTeX).
> 
> A little bit more than that, but yeah.  I need to look at his
> documentation again, but I want to formally document the API and then
> post it.  In addition to that, I want to have a standard, cross
> platform install (if possible), similar to that of the XML SIG
> install.  I want to create a crypto abstraction layer to be something
> like this:
> 
> ciphertext = encrypt("DES", plaintext)
> 
> (obviously not exactly like that, but you get my drift) so that people
> can easily change this to be:
> 
> ciphertext = encrypt("AES", plaintext)
> 
> when the need arises.  All of these ideas are just that.  That's why I
> want to create a SIG for this...to discuss all of these ideas.

Seems like a good idea.

To create a SIG, you'll need to write a short summary of what the
SIG should have a goal and why we need it. Then post this summary
to the meta-sig to have it discussed.

If all goes well, then a new list will be created. Ah, yes, you'll
also need a SIG maintainer who sets up the web-page etc.

See the meta-sig archvies for examples on how this is done.

> MAL> We could then have a python.org page for it much like the
> MAL> database API page and probably also move this mailing list
> MAL> there as crypto-sig.
> 
> >> MAL> There's really no need to design yet another API...
> >>
> >> MAL> As for integrating AES into amkCrypto, I think the best way is
> >> MAL> to wait until OpenSLL has support for it and then integrate
> >> MAL> that support into amkCrypto.
> >>
> >> Just out of curiosity, why do you think that?  I don't know anything
> >> about the development of OpenSSL so I don't know how they do things.
> >> Why wouldn't it be prudent to "just do it"?
> 
> MAL> Because the maintainers of OpenSSL are really smart guys and
> MAL> know a lot about writing code which runs as fast as possible.
> 
> MAL> Maintaining such code (usually a combination of C and assembler)
> MAL> to run on multiple platforms isn't a simple task at all, but they are
> MAL> doing a great job at it.
> 
> So how does that library work, and how does it correspond to
> amkCrypto?  Doe the OpenSSL guys write it in C and then someone wraps
> it for Python?  If so, then what's the difference between that and
> amkCrypto?

amkCrypto is the combination of Andrew's pycrypt lib (which also
includes a quite bit of C code) and mxCrypto (which is a wrapper
of the ciphers and hashes in OpenSSL) which I wrote some time
ago.

The algorithms which Andrew implemented in C are mostly also
available in OpenSSL, but usually run much faster due. Eric
Young wrote the original code base for OpenSSL which was formerly
known as SSLeay.

> MAL> If you don't want to wait, though, go ahead and wrap the
> MAL> AES C code into a Python module using the same APIs as the
> MAL> other ciphers in amkCrypto. People will then be able to upgrade
> MAL> to the OpenSSL based ciphers later on.
> 
> I'm thinking about that...see above questions though.

-- 
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/_/980968836/
---------------------------------------------------------------------_->





From itamarst at yahoo.com  Wed Jan 31 14:50:12 2001
From: itamarst at yahoo.com (Itamar S.-T.)
Date: Wed, 31 Jan 2001 05:50:12 -0800 (PST)
Subject: [python-crypto] Add AES to amkCrypto?
In-Reply-To: <3A771DFA.71056D40@stroeder.com>
Message-ID: <20010131135012.18206.qmail@web313.mail.yahoo.com>

> IMHO the main problem for application and crypto lib
> developers is
> the lack of a standard API. Crypto lib developers
> are designing new
> APIs every time and application developers have to
> deal with the
> different APIs.
> => there should be a standard class library which
> abstracts from
> various algorithms and their implementation etc.

Yeah, this would be very useful. At some point I got a
Rijndael Python module working based on the twofish
python code (which BTW last I checked is broken), but
I ended up doing a lot of cut and pasting. Having some
code to base this on would have been saved time. Now
that there's the new AES code this isn't relevant
anyway, but still.



=====
Itamar Shtull-Trauring, itamar(at)shtull-trauring.org

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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





From mal at lemburg.com  Wed Jan 31 15:15:51 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 31 Jan 2001 15:15:51 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <20010131135012.18206.qmail@web313.mail.yahoo.com>
Message-ID: <3A781E17.E5E50BC@lemburg.com>

"Itamar S.-T." wrote:
> 
> > IMHO the main problem for application and crypto lib
> > developers is
> > the lack of a standard API. Crypto lib developers
> > are designing new
> > APIs every time and application developers have to
> > deal with the
> > different APIs.
> > => there should be a standard class library which
> > abstracts from
> > various algorithms and their implementation etc.
> 
> Yeah, this would be very useful. At some point I got a
> Rijndael Python module working based on the twofish
> python code (which BTW last I checked is broken), but
> I ended up doing a lot of cut and pasting. Having some
> code to base this on would have been saved time. Now
> that there's the new AES code this isn't relevant
> anyway, but still.

Again, we already have such a standard API for the
various types of crypto algorithms: the one defined
by Andrew Kuchling which is the basis for amkCrypto. It has
proven useful and general enough to cover most implementation
details which arise when adding a new algorithm to the base.

The API is well documented and amkCrypto can be taken as
reference implementation.

-- 
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/_/980951430/
---------------------------------------------------------------------_->





From bolson at certicom.com  Wed Jan 31 21:45:21 2001
From: bolson at certicom.com (Bryan Olson)
Date: Wed, 31 Jan 2001 12:45:21 -0800
Subject: [python-crypto] Add AES to amkCrypto?
Message-ID: <852569E5.0071AFE6.00@smtpmail.certicom.com>


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.

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


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


--Bryan



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





From mal at lemburg.com  Wed Jan 31 22:58:33 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Wed, 31 Jan 2001 22:58:33 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <852569E5.0071AFE6.00@smtpmail.certicom.com>
Message-ID: <3A788A89.6FEB3447@lemburg.com>

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

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

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

The goal of mxCrypto was to expose the lower-level parts of
OpenSSL to be able to implement other cryptograhpic protocols.

m2Crypto is aiming at exposing the higher level to Python.

Note that even though we could add a strong cipher to the
Python distribution, this would probably not do any good: some
countries do not allow to *import* and use strong cryptographic
code. Python would no longer be downloadable for people living
in these countries.

-- 
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/_/980979298/
---------------------------------------------------------------------_->





From drewpc at colorado.edu  Wed Jan 31 16:29:11 2001
From: drewpc at colorado.edu (PC Drew)
Date: Wed, 31 Jan 2001 15:29:11 +0000
Subject: [python-crypto] Add AES to amkCrypto?
References: <852569E5.0071AFE6.00@smtpmail.certicom.com> <3A788A89.6FEB3447@lemburg.com>
Message-ID: <3A782F47.58CD16AE@colorado.edu>

"M.-A. Lemburg" 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" ?
> 
> 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.
> 
> > 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.

My name is Philip Cartier Drew, but I go by "PC" (my initials).  Drew
is my last name.

Here's what I want.  I want to be able to take a file or a block of text
and be able to encrypt it in any encryption algorithm, using any key
size.
The user would provide both the plaintext and the key to the function. 
I'm
not proposing key rings like PGP and stuff like that, just basically
providing
a Python interface to these encryption libraries.  I want to provide a
consistant
interface to every algorithm though.

> 
> An codec style interface would also be nice to have. Streams
> could then easily be encoded and decoded on-the-fly.

can you explain that?

> 
> > > 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.
> 
> The goal of mxCrypto was to expose the lower-level parts of
> OpenSSL to be able to implement other cryptograhpic protocols.
> 
> m2Crypto is aiming at exposing the higher level to Python.
> 
> Note that even though we could add a strong cipher to the
> Python distribution, this would probably not do any good: some
> countries do not allow to *import* and use strong cryptographic
> code. Python would no longer be downloadable for people living
> in these countries.

That's an interesting thought...I didn't know that countries would
limit the importing of strong cryptography.  Okay, so how about
providing an easy way to download and install the cryptography package?
For instance, I really hate having to download 15 packages just to get
a feature working.  It'd be nice to have one download so that it's easy
for the user to install.

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





From drewpc at colorado.edu  Wed Jan 31 23:17:39 2001
From: drewpc at colorado.edu (PC Drew)
Date: Wed, 31 Jan 2001 15:17:39 -0700 (MST)
Subject: [python-crypto] Add AES to amkCrypto?
In-Reply-To: <852569E5.0071AFE6.00@smtpmail.certicom.com>
References: <852569E5.0071AFE6.00@smtpmail.certicom.com>
Message-ID: <980979459.3a788f0359667@webmail.colorado.edu>

Quoting Bryan Olson <bolson at certicom.com>:

> Marc-Andre Lemburg wrote:<BR>
> &gt; The API designed by Andrew Kuchling is the defacto standard<BR>
> &gt; for interfacing to crypto algorithms in Python. His pycrypt<BR>
> &gt; library has been around for many years and suits the task very
> well.<BR>
> <BR>
> &gt; There's really no need to design yet another API...<BR>
> <BR>
> I disagree.&nbsp; The amkCrypto interface is terrible, and
> especially<BR>
> for block cipher modes of operation.&nbsp; It defines a source-code<BR>
> template to wrap around every block cipher at compile time to<BR>
> provide the modes for that one cipher.<BR>

So does that mean you'd be interested in helping write the API?  I'd really
be interested in having you help, it's nice to have someone with a totally
different opinion.  Let me know if you're interested. (or anyone else for
that matter)

> <BR>
> NIST is holding workshops on modes of operation, and will<BR>
> probably define new ones along with the AES.&nbsp; Modes and<BR>
> ciphers should be interchangeable, and we should be able to<BR>
> write each in either Python or an extension (and have it work<BR>
> with the others of course).<BR>
> <BR>

Do you have any more information on these workshops?  A URL?

> <BR>
> &gt; As for integrating AES into amkCrypto, I think the best way is<BR>
> &gt; to wait until OpenSLL has support for it and then integrate<BR>
> &gt; that support into amkCrypto.<BR>
> <BR>
> OpenSSL is centered on one cryptographic protocol.&nbsp; I'd like<BR>
> to see the basic AES cipher, without any modes, in the<BR>
> standard Python distribution.&nbsp; Recent changes in export law<BR>
> allow free software to include strong encryption.&nbsp; We should<BR>
> also get SHA-256, SHA-384 and SHA-512 into the standard<BR>
> distribution.<BR>

I agree.  Guido said that there were a lot of issues involved (since it's
strong encryption, obviously)...maybe we could hash some of this out and present
it to Guido to put in to the distribution.

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