From bolson at certicom.com  Thu Feb  1 00:24:55 2001
From: bolson at certicom.com (Bryan Olson)
Date: Wed, 31 Jan 2001 15:24:55 -0800
Subject: [python-crypto] Add AES to amkCrypto?
Message-ID: <852569E5.0080952B.00@smtpmail.certicom.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" ?

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.


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


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

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

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


--Bryan



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





From bolson at certicom.com  Thu Feb  1 02:06:36 2001
From: bolson at certicom.com (Bryan Olson)
Date: Wed, 31 Jan 2001 17:06:36 -0800
Subject: [python-crypto] Add AES to amkCrypto?
Message-ID: <852569E6.0005F246.00@smtpmail.certicom.com>

> Quoting Bryan Olson <bolson at certicom.com>:
> > The amkCrypto interface is terrible [...]
>
> 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)

Sure.  I myself didn't know there was much interest.

My own vision is a library that is lucid at every level.  Most
libraries I've worked with are focused on one kind of task,
and lower layers are a mess if they're exposed at all.

I'd like to have a pure-Python version.  For block ciphers and
other primitives where Python is a factor of hundreds slower
than C, the library should look for an extension module, but
fall back to pure Python if none is found.


> > NIST is holding workshops on modes of operation [...]
> Do you have any more information on these workshops?  A URL?

http://csrc.nist.gov/encryption/modes/


--Bryan



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





From michael at stroeder.com  Thu Feb  1 10:37:16 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 01 Feb 2001 10:37:16 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <852569E6.0005F246.00@smtpmail.certicom.com>
Message-ID: <3A792E4C.11EAF9E@stroeder.com>

HI!

I'm glad to see this discussion here.

My vision is to have a class API which is flexible at every level
even at run-time and where different crypto modules can be used
concurrently (something like Sun's JCE, dig around on
http://java.sun.com/products/jce/).

There should be a cryptographic API for abstracting:
- all kind of cryptographic algorithms
- parameters for algorithms
- key stores
amkCrypto, the low-level parts of M2Crypto and other pure Python or
C wrapper modules could be tied below this.

There might be interest in abstracting cryptographic protocols as
well:
- X509
- PGP
- SPKI (e.g. Pisces)
- SSL
- S/MIME
- XML-DSIG
M2Crypto or my own X.509 class lib (only decoding certs and CRLs up
to now) could be tied below such a API.

and related standards like
- ASN.1
If M2Crypto exposes new ASN.1 routines in upcoming OpenSSL 0.9.7 it
could implement such a API. I'm also trying to come with a new pure
Python ASN.1 library.

This is a heavy task. But if people here coordinate their efforts we
could make it usable quite soon - I think.

Ciao, Michael.

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





From ngps at post1.com  Thu Feb  1 17:27:41 2001
From: ngps at post1.com (Ng Pheng Siong)
Date: Fri, 2 Feb 2001 00:27:41 +0800
Subject: [python-crypto] [Announce] M2Crypto 0.06 snapshot #2 - ZServerSSL
Message-ID: <20010202002741.A352@madcap.dyndns.org>

Hi,

A new snapshot of M2Crypto is now available. The major change:

 ZServerSSL Rides Again
------------------------

Whew! It's been a year! ZServerSSL was last released on 1 Feb 2000 for
Zope 2.1.3.

It has now been dusted off and re-released for Zope 2.3.0.

Tested with Zope-2.3.0-win32-x86 with M2Crypto for Python1.

Tested with Zope-2.3.0-src on FreeBSD with M2Crypto for 
both Python1 and Python2.

Interoperated with Netscape, IE and Opera on Win32, and also Netscape
on FreeBSD.

Beware browsers with broken HTTP/1.1 - they drive ZServerSSL to 100%
CPU utilisation: An example is Netscape Communicator 4.72 on my
FreeBSD boxen.

(Or maybe it's ZServer's HTTP/1.1 that's broken. ;-)

X.509 certificate-based client authentication for HTTPS and the
encrypting monitor, both features of the ZServerSSL released a year
ago, to come RSN!


As usual, get M2Crypto here:

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


Feedback is appreciated. 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/_/981046156/
---------------------------------------------------------------------_->





From drewpc at colorado.edu  Thu Feb  1 23:02:20 2001
From: drewpc at colorado.edu (PC Drew)
Date: Thu, 01 Feb 2001 15:02:20 -0700 (MST)
Subject: [python-crypto] To clarify...
Message-ID: <981064940.3a79dcec3d55d@webmail.colorado.edu>

Okay, so we've been replying to each other's emails so much that it's time to
start another thread. So here's what I've gathered so far...let me know if I'm
wrong.

1.  There IS an interested in a cryptography SIG.  Since I'm hearing "but not
right now" from the Python guys, we should hold back on this for now.  If we get
some stuff going, then maybe we can move this list and some other stuff to a
SIG.

2.  People ARE interested in coming up with a formal API.  Similar to the
Database API (and they have a SIG!!!).  I'm thinking that the API should be
flexible enough to be able to handle different variations of any given algorithm
(i.e. key lengths).

3.  Because our API will be so flexible and encapsulated, the implementation of
each algorithm could be in C or in Python, as far as the user is concerned, it
doesn't matter.  As Bryan said, that means that reference implementations can be
completed and added more quickly than the C implementations, but once the thing
is implemented, the end developer doesn't care whether or not it's in C or in
Python (I'm talking about in terms of using the alogrithm in his code...of
course he cares about the speed and stuff).

4.  The base level of the API would be a direct interface to the algorithm
itself.  That means that if the developer doesn't want any fancy schmancy other
stuff (i.e. keyring stuff for PGP), he can go directly to the algorithm.  But,
stacked on top of the base level algorithms, will be implementations for SSL,
S/MIME, PGP, certificates, etc (like Michael wanted).

Thoughts?

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





From mal at lemburg.com  Fri Feb  2 10:50:00 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Fri, 02 Feb 2001 10:50:00 +0100
Subject: [python-crypto] To clarify...
References: <981064940.3a79dcec3d55d@webmail.colorado.edu>
Message-ID: <3A7A82C8.485F20F8@lemburg.com>

PC Drew wrote:
> 
> Okay, so we've been replying to each other's emails so much that it's time to
> start another thread. So here's what I've gathered so far...let me know if I'm
> wrong.
> 
> 1.  There IS an interested in a cryptography SIG.  Since I'm hearing "but not
> right now" from the Python guys, we should hold back on this for now.  If we get
> some stuff going, then maybe we can move this list and some other stuff to a
> SIG.
> 
> 2.  People ARE interested in coming up with a formal API.  Similar to the
> Database API (and they have a SIG!!!).  I'm thinking that the API should be
> flexible enough to be able to handle different variations of any given algorithm
> (i.e. key lengths).
> 
> 3.  Because our API will be so flexible and encapsulated, the implementation of
> each algorithm could be in C or in Python, as far as the user is concerned, it
> doesn't matter.  As Bryan said, that means that reference implementations can be
> completed and added more quickly than the C implementations, but once the thing
> is implemented, the end developer doesn't care whether or not it's in C or in
> Python (I'm talking about in terms of using the alogrithm in his code...of
> course he cares about the speed and stuff).
> 
> 4.  The base level of the API would be a direct interface to the algorithm
> itself.  That means that if the developer doesn't want any fancy schmancy other
> stuff (i.e. keyring stuff for PGP), he can go directly to the algorithm.  But,
> stacked on top of the base level algorithms, will be implementations for SSL,
> S/MIME, PGP, certificates, etc (like Michael wanted).
> 
> Thoughts?

The application frame for a crypto API is somewhat different than
for database backends, but in general I agree, a standard for
the Python interface of cipher, hash and key algorithms would be
a nice addition. Again, I find Andrew's interfaces pretty much up
to the task, so these should be used as reference.

Note that you are talking about three levels of API specification:

1. low-level: shifting bits around
2. medium-level: process data
3. high-level: process protocols and complex secure storage mechanisms

amkCrypto is level 2. m2Crypto aims at level 3. We currently
do not expose level 1.

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





From mal at lemburg.com  Thu Feb  1 14:34:00 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Feb 2001 14:34:00 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <852569E5.0080952B.00@smtpmail.certicom.com>
Message-ID: <3A7965C8.231FA5CA@lemburg.com>

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





From mal at lemburg.com  Thu Feb  1 14:55:42 2001
From: mal at lemburg.com (M.-A. Lemburg)
Date: Thu, 01 Feb 2001 14:55:42 +0100
Subject: [python-crypto] Add AES to amkCrypto?
References: <852569E5.0071AFE6.00@smtpmail.certicom.com> <3A788A89.6FEB3447@lemburg.com> <3A782F47.58CD16AE@colorado.edu>
Message-ID: <3A796ADE.E4A45257@lemburg.com>

PC Drew wrote:
> 
> "M.-A. Lemburg" wrote:
> > ...
> > 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.

Ah, ok. Hi Philip :-)
 
> 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.

Sounds like a reasonable proposal... something like the codec
registry design, only for ciphers and hashes.

There's a catch to this though: not all ciphers support variable
key-lengths, most even don't support variable block lengths. Then
there are sometimes extra parameters which are specific to one
cipher only (e.g. some initial state parameter or the number of
rounds to apply).

Why not write this up as a module on top of amkCrypto ?

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

Codecs encode and decode data using either direct interfaces
or via the standard file interface. Ciphers could easily be
used to encode streams going in and out of Python this way.

For details, read codecs.py and Misc/unicode.txt. The codec
design originated in the Unicode implementation, but can be
put to use in a lot of other different contexts as well.
 
> > 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.

Ok, but that's really a different subject (CPAN for Python) and
covered by different SIGs (e.g. the catalog-sig, I think).

Since amkCrypto already uses distutils, we are already in a fine
position. OpenSSL is quite portable and available on most platforms
as well (as RPM or as DLL for Windows). We could even try to tweak
distutils into compiling OpenSSL as well, if that's a problem.

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





From bolson at certicom.com  Thu Feb  1 20:47:03 2001
From: bolson at certicom.com (Bryan Olson)
Date: Thu, 1 Feb 2001 11:47:03 -0800
Subject: [python-crypto] Add AES to amkCrypto?
Message-ID: <852569E6.006C5E0D.00@smtpmail.certicom.com>

Marc-Andre Lemburg wrote:
> Bryan Olson wrote:
> > 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.

Yet here we are with a new cipher we want to put in the
library, and your answer is to wait until OpenSSL implements
it.  Python is a terrific language for reference
implementations. Actually one of the AES finalists, Serpent,
was first implemented in Python.

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

And that makes sense for OpenSSL where the goal is to
implement one predefined protocol.  The modes are fixed so no
great flexibility is required.

What I want is a Python crypto library that takes advantage of
Python's strengths.  We're getting a new cipher and new modes,
and we have the ideal language for a reference implementation.
It makes no sense for us to wait for the C version.


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

The API should allow us to put new implementations
"underneath".  I have my new block cipher and the new OID's
for it. I'll implemented it, say in Python, and I want to pass
it to the library to use with the higher level protocols.

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

Here's a real-world example.  I wrote a pure-Python RSA class
that generates keys, signs as per PKCS#1, encodes and decodes
keys, reports the OID's for algorithm and key and such.  I use
this class in creating certificates, and I have analogous
classes for DSA and ECDSA.

My production root keys reside on Luna CA^3 tokens, which use
an extended PKCS#11 interface.  So I wrote an extension to
bring the PKCS#11 interface into Python.

I wrote a class that inherits from the RSA class and uses RSA
keys on the hardware token.  I re-implemented key generation
and signing to call through PKCS#11. I can pass this class to
my certificate generator the same way as the all-soft version.

Python's strength is this kind of flexibility.  If the RSA
implementation is in C and buried inside OpenSSL, I have no
idea how to make it use my PKCS#11 Python extension.  (As I
understand things, the amkCrypto RSA class is currently in
Python, but the stated plan is to replace it with OpenSSL).


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

My point is that I want to use Python.  Only a few things need
to be in C.


--Bryan



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





From michael at stroeder.com  Thu Feb  1 15:47:53 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 01 Feb 2001 15:47:53 +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> <3A785B6A.F9752DDD@lemburg.com>
Message-ID: <3A797719.B81B788C@stroeder.com>

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

I forward my proposal from news:comp.lang.python. I'm also preparing
a proposal with a list of requirements and maybe some examples.

Ciao, Michael.

-------- Original Message --------
Subject: Interested in a Crypto-SIG?
Date: Sat, 27 Jan 2001 14:09:55 +0100
From: Michael Str?der <michael at stroeder.com>
Organization: stroeder.com
Newsgroups: comp.lang.python

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.

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





From michael at stroeder.com  Fri Feb  2 17:48:27 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 02 Feb 2001 17:48:27 +0100
Subject: [python-crypto] To clarify...
References: <981064940.3a79dcec3d55d@webmail.colorado.edu>
Message-ID: <3A7AE4DB.EDB8C25B@stroeder.com>

PC Drew wrote:
> 
> So here's what I've gathered so far...
> [..]
> Thoughts?

Perfect summarize!

Ciao, Michael.

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





From michael at stroeder.com  Fri Feb  2 17:50:46 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 02 Feb 2001 17:50:46 +0100
Subject: [python-crypto] To clarify...
References: <981064940.3a79dcec3d55d@webmail.colorado.edu> <3A7A82C8.485F20F8@lemburg.com>
Message-ID: <3A7AE566.9FBEF35A@stroeder.com>

"M.-A. Lemburg" wrote:
> 
> Note that you are talking about three levels of API specification:
> 
> 1. low-level: shifting bits around
> 2. medium-level: process data
> 3. high-level: process protocols and complex secure storage mechanisms
> 
> amkCrypto is level 2. m2Crypto aims at level 3. We currently
> do not expose level 1.

If 2. includes processing hashes and ciphers with arbitrary
algorithm parameters IMHO yes, we don't have to expose something
below 2.

Ciao, Michael.

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





From rsalz at caveosystems.com  Sat Feb  3 04:19:19 2001
From: rsalz at caveosystems.com (Rich Salz)
Date: Fri, 02 Feb 2001 22:19:19 -0500
Subject: pycrypt++
References: <3A7977CF.BA8B20EF@stroeder.com>
Message-ID: <3A7B78B6.4B1F3899@caveosystems.com>

Attached are the header files we feed into swig. They're simplified
wrappers around the heavier C++ objects.  In almost all cases, the class
Sxxx is the scriptable version of Cxxx.  It exposes only those methods
we've needed, and it contains an auto_ptr<> to the C++ object.  Hope you
find this useful.  If you want to use it "for real" we need to work out
soem details but I do not htink there will be a problem.
	/r$
ps:  we are changing our name to zolera systems, since there is a caveo
technology -- see www.caveo.com  the new servers will be up in a week or
two.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: z-inc.tgz
Type: application/x-compressed
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20010202/a8b60e99/attachment.bin>

From drewpc at colorado.edu  Thu Feb  1 22:44:59 2001
From: drewpc at colorado.edu (PC Drew)
Date: Thu, 01 Feb 2001 21:44:59 GMT
Subject: Interested in a Crypto-SIG?
References: <3A72C8A3.C4B4D69A@stroeder.com>
Message-ID: <95clco$ecq$1@nnrp1.deja.com>

In article <3A72C8A3.C4B4D69A at stroeder.com>,
  Michael =?iso-8859-1?Q?Str=F6der?= <michael at stroeder.com> wrote:
> 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).
>

I'm the one who proposed the idea to the meat-sig list the other day.
Since then, I've joined the python-crypto list and have been having
interesting discussions regarding this idea.

There seems to be a genuine interest in this idea and I think that we
should start drafting up an API.  I'm starting to look into amkCrypto
and m2crypto heavily so that I can see what things I haven't thought
about.  I hope to have some sort of draft in the next week. I'll
coordinate this with you.

Also, I think once we get started on this, it'll be easier to try and
get a SIG.  I too think that it'd be better to get a SIG!!


Sent via Deja.com
http://www.deja.com/


From juergen.erhard at gmx.net  Wed Feb  7 01:11:07 2001
From: juergen.erhard at gmx.net (Jürgen A. Erhard)
Date: Wed, 07 Feb 2001 01:11:07 +0100
Subject: Interested in a Crypto-SIG?
In-Reply-To: <slrn978o29.gn.amk@mira.erols.com>
References: <3A72C8A3.C4B4D69A@stroeder.com> <slrn97650f.i1.amk@mira.erols.com> <3A731F26.15461A27@stroeder.com> <slrn978o29.gn.amk@mira.erols.com>
Message-ID: <mailman.981511010.7121.python-list@python.org>

>>>>> "A" == A M Kuchling <amk at mira.erols.com> writes:

    A> On Sat, 27 Jan 2001 20:19:02 +0100, 
    A> 	Michael Str?der <michael at stroeder.com> wrote:
    >> <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. 
    >> 
    >> This does not attract me very much.

    A> Given the relaxing of US export laws last year, this text is
    A> really no longer necessary, and I should edit the list
    A> description accordingly.  (Shows how much time I spend on
    A> crypto these days...)

It's not export *laws* it's just the *regulations* of the *current*
Administration.

And, as we all know, the Administration just changed...

I'm not expecting too much good from *that* guy.  And I'd *certainly*
wait with moving in crypto-related matters until those regulations had
turned into real, Senate/HR-fortified, law.

Sorry if I spoiled you day,

Bye, J

-- 
J?rgen A. Erhard    juergen.erhard at gmx.net   phone: (GERMANY) 0721 27326
     MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html
          George Herrimann's Krazy Kat (http://www.krazy.com)
  "Windows NT" is an acronym for "Windows? No thanks." -- Russ McManus


From janus.liebregts at surfnet.nl  Wed Feb  7 15:07:50 2001
From: janus.liebregts at surfnet.nl (Janus Liebregts)
Date: Wed, 07 Feb 2001 15:07:50 +0100
Subject: Mailing list
References: <3A810C3E.C0347883@stroeder.com> <3A81221F.B8D2A066@surfnet.nl>
Message-ID: <3A8156B6.897E2455@surfnet.nl>

A non-text attachment was scrubbed...
Name: smime.p7m
Type: application/x-pkcs7-mime
Size: 5612 bytes
Desc: S/MIME Encrypted Message
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20010207/3dbbba22/attachment.bin>

From michael at stroeder.com  Wed Feb  7 16:12:09 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 07 Feb 2001 16:12:09 +0100
Subject: [python-crypto] python-crypto list hosted at SURFnet.nl
References: <3A815E95.5399B6C3@stroeder.com> <3A816393.2536BB@caveosystems.com>
Message-ID: <3A8165C9.ADA8FC76@stroeder.com>

Rich Salz wrote:
> 
> Moving the mailing list doesn't change anything, since the US
> Regulations never discussed free and open technical discussion.

I expected to raise this discussion...

>  Unless
> you believe that someone from outside the US posting crypto code to the
> mailing list could get yahoogroups in trouble?

Yes, I'm e.g. concerned that posting code to Yahoo might make Yahoo
closing the archive in the future. I do not claim to be sure that
there are/will be problems at all and which ones exactly. But I'm
pretty sure to reduce the amount of possible problems by hosting in
NL.

Please, we should not discuss this in detail. It was already
discussed to death on e.g. the openssl-dev list. Everyone interested
in more details and different opinions should go digging in
openssl-dev archives.

> It's your list, of course, and you're free to do what you want.

The egroups list was not mine. AFAIK it was created by A.M.Kuchling.
I'm just trying to avoid trouble and discussion which keeps us away
from working.

Ciao, Michael.

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







From michael at stroeder.com  Wed Feb  7 15:41:25 2001
From: michael at stroeder.com (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 07 Feb 2001 15:41:25 +0100
Subject: [python-crypto] python-crypto list hosted at SURFnet.nl
Message-ID: <3A815E95.5399B6C3@stroeder.com>

HI!

I'm glad to announce that SURFnet in the Netherlands agreed on
providing the service to host the mailing list for crypto-related
Python development:

  PYTHON-CRYPTO at NIC.SURFNET.NL

The reason for this new mailing list is that the situation regarding
export regulations for cryptographic code from the U.S. is still not
clear enough. IMHO we can avoid a problems with crypto code posted
to the mailing list by hosting in a country known to be very liberal
in this field.

Please join the list at:

  http://listserv.surfnet.nl/archives/python-crypto.html

Hope to see you there.

Citizens of the U.S. or any other country with export regulations
for cryptographic software have to take care about themselves for
not getting into trouble by posting code to this list.

Ciao, Michael.

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







From rsalz at caveosystems.com  Wed Feb  7 16:02:43 2001
From: rsalz at caveosystems.com (Rich Salz)
Date: Wed, 07 Feb 2001 10:02:43 -0500
Subject: [python-crypto] python-crypto list hosted at SURFnet.nl
References: <3A815E95.5399B6C3@stroeder.com>
Message-ID: <3A816393.2536BB@caveosystems.com>

Moving the mailing list doesn't change anything, since the US
Regulations never discussed free and open technical discussion.  Unless
you believe that someone from outside the US posting crypto code to the
mailing list could get yahoogroups in trouble?

It's your list, of course, and you're free to do what you want.
	/r$

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







From michael at STROEDER.COM  Wed Feb  7 15:40:49 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 7 Feb 2001 15:40:49 +0100
Subject: [PYTHON-CRYPTO] python-crypto list hosted at SURFnet.nl
Message-ID: <3A815E71.F7A72DDC@stroeder.com>

HI!

I'm glad to announce that SURFnet in the Netherlands agreed on
providing the service to host the mailing list for crypto-related
Python development:

  PYTHON-CRYPTO at NIC.SURFNET.NL

The reason for this new mailing list is that the situation regarding
export regulations for cryptographic code from the U.S. is still not
totally clear to be called painless. IMHO we can avoid problems with
crypto code posted to the mailing list by hosting it in a country
known to be very liberal in this field.

Please join the list at:

  http://listserv.surfnet.nl/archives/python-crypto.html

Hope to see you there.

Citizens of the U.S. or any other country with export regulations
for cryptographic software have to take care about themselves for
not getting into trouble by posting code to this list.

Ciao, Michael.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2028 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-crypto/attachments/20010207/4635d887/attachment.bin>

From akuchlin at cnri.reston.va.us  Wed Feb  7 16:17:31 2001
From: akuchlin at cnri.reston.va.us (Andrew Kuchling)
Date: Wed, 7 Feb 2001 10:17:31 -0500
Subject: [python-crypto] python-crypto list hosted at SURFnet.nl
In-Reply-To: <3A8165C9.ADA8FC76@stroeder.com>; from michael@stroeder.com on Wed, Feb 07, 2001 at 04:12:09PM +0100
References: <3A815E95.5399B6C3@stroeder.com> <3A816393.2536BB@caveosystems.com> <3A8165C9.ADA8FC76@stroeder.com>
Message-ID: <20010207101731.C1446@thrak.cnri.reston.va.us>

On Wed, Feb 07, 2001 at 04:12:09PM +0100, Michael Str?der wrote:
>The egroups list was not mine. AFAIK it was created by A.M.Kuchling.
>I'm just trying to avoid trouble and discussion which keeps us away
>from working.

Correct.  I think I'd encourage people to move to the new list just in
case the US regulations tighten again.  The recent article about
terrorists using encryption makes me wonder if they're intentional
leaks to justify an upcoming change in policy by the Bush
administration.

I won't delete the egroups list in order to preserve the archive, and
to have it available as a backup in case the new list proves
unreliable, but would suggest using the new list for discussion.  I
still haven't gotten around to reading the lengthy API thread from
last week, and will post any replies of mine to the new list.

--amk



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







From richard at BIZARSOFTWARE.COM.AU  Wed Feb  7 23:32:12 2001
From: richard at BIZARSOFTWARE.COM.AU (Richard Jones)
Date: Thu, 8 Feb 2001 09:32:12 +1100
Subject: [PYTHON-CRYPTO] Current state of the art?
Message-ID: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>

Hi all,

Could people please summarise the current state of the art?

I'm specifically interested in OpenPGP from Python, but am curious where
other systems stand.


    Richard

--
Richard Jones
richard at bizarsoftware.com.au
Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)




From bryan at EEVOLVED.COM  Thu Feb  8 02:42:19 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Wed, 7 Feb 2001 20:42:19 -0500
Subject: [PYTHON-CRYPTO] Bryan calling Bryan (ECDSA).
Message-ID: <0102072042190C.00694@mephit>

Sorry about my previous posting... I seem to have been ignorant to the
existence of the egroup [crypto-python] before now. Silly me. And I thought
comp.lang.python had it all... :)

I couldn't help but notice Bryan Olson's astute observations about amkCrypto
and M2Crypto being too tightly bound to SSL. I concur that ciphers ought to
be abstracted from the SSL protocol, and made available independently. Some
even suggested waiting for AES to be included in OpenSSL to make it available
to python programmers.

This is precisely what I was attempting to avoid by creating pyAES. OpenSSL
has its applications and it executes them admirably. However, including such
a large package merely to access a few crypto functions seems to me like an
unnecessary bloat. Especially if it is to be bundled in a python distribution.

Bryan, I was overjoyed to see that you have written an ECDSA class in pure
python. ECDSA has been causing me extreme headaches in my Eliptic Curve class
and is responsible for making an otherwise tight .so into a hideous monster.
I would love to get my hands on it.  I have also implemented a loose
interpretation of TLS with AES and ECC that will be under 100K when I get to
drop the DSA C functions. It is lacking certificates and signing though,
which to my amazement, seem to be your forte. Perhaps we could collaborate to
produce something really amazing? If not, then I would appreciate being able
to take a look at your ECDSA and PKCS#1 classes. Any linkage would be great,
can't seem to find you in google anywhere. Feel free to also contact me
privately.

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

"...one of the strongest motives that lead men to art and science is escape
from everyday life with its painful crudity and hopeless dreariness, from the
fetters of one's own ever-shifting desires. A finely tempered nature longs to
escape from the personal life into the world of objective perception and
thought."-- Einstein




From akuchlin at CNRI.RESTON.VA.US  Wed Feb  7 23:52:34 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Wed, 7 Feb 2001 17:52:34 -0500
Subject: [PYTHON-CRYPTO] Current state of the art?
In-Reply-To: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>; from
              richard@BIZARSOFTWARE.COM.AU on Thu, Feb 08,
              2001 at 09:32:12AM +1100
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
Message-ID: <20010207175234.A2219@thrak.cnri.reston.va.us>

On Thu, Feb 08, 2001 at 09:32:12AM +1100, Richard Jones wrote:
>I'm specifically interested in OpenPGP from Python, but am curious where
>other systems stand.

I wrote a module for controlling a GPG subprocess, because GPG has a
nice interface for being executed that way, but it only handles
verifying signatures because that's all I needed.  Someone took the
code and started a SourceForge project
(http://sourceforge.net/projects/python-gpg/) with the goal of working
on it further, but hasn't actually done anything with it.

Some really old code for generating PGP packets in pure Python exists,
but it's doubtless far out of date with the current OpenPGP spec.

--amk




From akuchlin at CNRI.RESTON.VA.US  Wed Feb  7 22:48:45 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Wed, 7 Feb 2001 16:48:45 -0500
Subject: [PYTHON-CRYPTO] [python-crypto] Add AES to amkCrypto?
In-Reply-To: <3A796ADE.E4A45257@lemburg.com>; from mal@lemburg.com on Thu,
              Feb 01, 2001 at 02:55:42PM +0100
References: <852569E5.0071AFE6.00@smtpmail.certicom.com>
            <3A788A89.6FEB3447@lemburg.com> <3A782F47.58CD16AE@colorado.edu>
            <3A796ADE.E4A45257@lemburg.com>
Message-ID: <20010207164845.B2148@thrak.cnri.reston.va.us>

(Going through the thread on the egroups list...)

On Thu, Feb 01, 2001 at 02:55:42PM +0100, M.-A. Lemburg wrote:
>For details, read codecs.py and Misc/unicode.txt. The codec
>design originated in the Unicode implementation, but can be
>put to use in a lot of other different contexts as well.

Are you suggesting that we re-use the codec infrastructure in 2.0 to
create encrypting codecs, or just borrow the interface?  If the
former, I don't see how a codec would be passed a parameter such as
the key, # of rounds, &c. though if that's already possible, it would
be very nice; you would get encrypting stream readers and writers with
very little effort.

>as well (as RPM or as DLL for Windows). We could even try to tweak
>distutils into compiling OpenSSL as well, if that's a problem.

This seems impractical; OpenSSL has a configure script of its own, and
it seems pretty complicated.

--amk




From akuchlin at CNRI.RESTON.VA.US  Wed Feb  7 22:53:56 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Wed, 7 Feb 2001 16:53:56 -0500
Subject: [PYTHON-CRYPTO] [python-crypto] Add AES to amkCrypto?
In-Reply-To: <20402458880.20010131104449@colorado.edu>; from
              drewpc@colorado.edu on Wed, Jan 31, 2001 at 10:44:49AM -0700
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: <20010207165356.C2148@thrak.cnri.reston.va.us>

On Wed, Jan 31, 2001 at 10:44:49AM -0700, PC Drew wrote:
>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?

The OpenSSL people maintain C implementations, and someone else wraps
it for Python.  amkCrypto originally had its own copies of
implementations scavenged from various other libraries, but no attempt
was made to add assembly code or to carefully compare different
implementations to see which was fastest.  It seems easiest to re-use
the work done by the OpenSSL group, rather than expending effort
attempting to duplicate their work.

--amk




From akuchlin at mems-exchange.org  Wed Feb  7 22:33:32 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 7 Feb 2001 16:33:32 -0500
Subject: [PYTHON-CRYPTO] Add AES to amkCrypto?
In-Reply-To: <3A7965C8.231FA5CA@lemburg.com>
References: <852569E5.0080952B.00@smtpmail.certicom.com>
            <3A7965C8.231FA5CA@lemburg.com>
Message-ID: <E14QcDU-0003Lt-00@ute.cnri.reston.va.us>

(Going through the thread on the egroups list...)

On Thu, Feb 01, 2001 at 02:34:00PM +0100, M.-A. Lemburg wrote:
>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

I think Bryan is mostly referring to the preprocessing of C source
files that amkCrypto has always done.  Because the feedback modes are
fiddly to get right (off-by-one errors and that sort of thing), I
wanted to save myself effort.  Therefore, to implement a cipher you
just implement functions to encrypt and decrypt a single block; a
script then tangles your single function together with a module
template that handles the feedback modes for you.  Hashes work
similarly.

This idea was already showing some strain with algorithms such as CAST
that have variable parameters.  In CAST, the number of rounds has to
be specified as a byte of the key, because there's no way to modify
the constructor.  Remember, the first version was written around 1995,
when I was young and stupid!  We're best off just discarding
amkCrypto's implementation completely.

I'd suggest starting by defining a new API for hash operations and
block ciphers, because they're easiest to get right, I think.  In fact
maybe the hash API is perfectly fine as it stands.  The block cipher
API may not be quite right, but it's probably not *too* far wrong.

The public key APIs (RSA, ElGamal) in amkCrypto *are* far wrong, being
basically just toys.  For example, in the first version you checked
signatures by calling a method named validate(); clearly I was on
crack when choosing that name, because this operation is called
'verify' in the literature, and has always been called 'verify'!
IMHO, just forget about amkCrypto public-key them and define new ones,
not bothering about backward compatibility at all.  But note that
public-key will probably drag in complicated other issues such as
certificates; before embarking on that messy task, let's try to do
hashes and block ciphers, which will at least take care of Bryan's AES
code.

--amk




From akuchlin at mems-exchange.org  Wed Feb  7 22:42:42 2001
From: akuchlin at mems-exchange.org (Andrew Kuchling)
Date: Wed, 07 Feb 2001 16:42:42 -0500
Subject: [python-crypto] Re: Add AES to amkCrypto?
In-Reply-To: <3A7965C8.231FA5CA@lemburg.com>
References: <852569E5.0080952B.00@smtpmail.certicom.com> <3A7965C8.231FA5CA@lemburg.com>                  
Message-ID: <E14QcMM-0003RL-00@ute.cnri.reston.va.us>

[Resending to the egroups list because the listserv seems to be
swallowing my messages...]

(Going through the thread on the egroups list...)

 
On Thu, Feb 01, 2001 at 02:34:00PM +0100, M.-A. Lemburg wrote:
>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
 
I think Bryan is mostly referring to the preprocessing of C source
files that amkCrypto has always done.  Because the feedback modes are
fiddly to get right (off-by-one errors and that sort of thing), I
wanted to save myself effort.  Therefore, to implement a cipher you
just implement functions to encrypt and decrypt a single block; a
script then tangles your single function together with a module
template that handles the feedback modes for you.  Hashes work
similarly.
 
This idea was already showing some strain with algorithms such as CAST
that have variable parameters.  In CAST, the number of rounds has to
be specified as a byte of the key, because there's no way to modify
the constructor.  Remember, the first version was written around 1995,
when I was young and stupid!  We're best off just discarding
amkCrypto's implementation completely.
 
I'd suggest starting by defining a new API for hash operations and
block ciphers, because they're easiest to get right, I think.  In fact
maybe the hash API is perfectly fine as it stands.  The block cipher
API may not be quite right, but it's probably not *too* far wrong.

The public key APIs (RSA, ElGamal) in amkCrypto *are* far wrong, being
basically just toys.  For example, in the first version you checked
signatures by calling a method named validate(); clearly I was on
crack when choosing that name, because this operation is called
'verify' in the literature, and has always been called 'verify'!
IMHO, just forget about amkCrypto public-key them and define new ones,
not bothering about backward compatibility at all.  But note that
public-key will probably drag in complicated other issues such as
certificates; before embarking on that messy task, let's try to do
hashes and block ciphers, which will at least take care of Bryan's AES
code.
 
--amk

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







From bryan at EEVOLVED.COM  Wed Feb  7 21:04:12 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Wed, 7 Feb 2001 15:04:12 -0500
Subject: [PYTHON-CRYPTO] Okay, I'll break the ice... :)
Message-ID: <01020715041209.00694@mephit>

Wow, a fresh list. I love it. :)

This post will probably be read only by Michael and I but oh well...

Having a crypto-SIG would do wonders for python's acceptance. In the same way
that the dbAPI-SIG suddenly made persistent python objects readily available
to even the lay programmer, powerful crypto routines should be wieldable by
everyone like this:

>>> from crypto import aes

>>> encryptor = aes( "key string")  # Can be hashed or not? Easier for laymen?

>>> encryptedText = encryptor.encrypt( "uncrackable plaintext")

>>> print encryptedText

? :??r???O>? ?9?? :??r???O>? ?9?

>>> encryptor.decrypt(encryptedText)
'uncrackable plaintext'

>>> encryptor.setKey("A different key string")

>>> encryptor.decrypt(encryptedText)
<garbage>

Same goes for public key operations, but with the added methods of "sign" and
"verify".

I think the most important thing is to hide implementation details as much as
possible.  If we can make the crypto sig as easy to use as shelve, then we
have it made. :)

I also don't think we should waste our time with the older algorithms, except
in the case of maintaining compatibility with industry standards like SSL.
AES and ECC are here now and we shouldn't implement anything less.  Alright
and maybe RSA for those folks that still are sceptical of ECC. :)

BTW my contribution to this community is at

http://www.sourceforge.net/projects/pyaes

SHA256, ECC in GF^233, AES and a cool PRNG.

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

"...one of the strongest motives that lead men to art and science is escape
from everyday life with its painful crudity and hopeless dreariness, from the
fetters of one's own ever-shifting desires. A finely tempered nature longs to
escape from the personal life into the world of objective perception and
thought."-- Einstein




From michael at STROEDER.COM  Thu Feb  8 09:15:47 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 8 Feb 2001 09:15:47 +0100
Subject: [PYTHON-CRYPTO] Okay, I'll break the ice... :)
References: <01020715041209.00694@mephit>
Message-ID: <3A8255B3.39FF537E@stroeder.com>

Bryan Mongeau wrote:
>
> Wow, a fresh list. I love it. :)
>
> This post will probably be read only by Michael and I but oh well...

Fortunately you're wrong. There have been around 20 subscriptions up
to now.

> >>> from crypto import aes

I have something in mind like (lay man's version and very short)

import crypto

# Search for a implementation providing AES, use the first available
aes = crypto.locate_alg('aes')
# Set the currently used key object
aes.setKey(key)
# Encrypt the clear text
ciphertext = aes.encrypt(cleartext)

etc.

Note that key is also meant as key object, an instance of an
appropriate key storage class. I started to write a draft proposal
but I'm stuck since I have to get some urgent work done.

I'd like to encourage everyone interested in a generic class API to
take a look at
http://java.sun.com/products/jdk/1.3/docs/guide/security/ which
makes me really jealous...

Ciao, Michael.




From michael at STROEDER.COM  Thu Feb  8 09:24:43 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 8 Feb 2001 09:24:43 +0100
Subject: [PYTHON-CRYPTO] Bryan calling Bryan (ECDSA).
References: <0102072042190C.00694@mephit>
Message-ID: <3A8257CB.AC9A9729@stroeder.com>

Bryan Mongeau wrote:
>
> I couldn't help but notice Bryan Olson's astute observations about amkCrypto
> and M2Crypto being too tightly bound to SSL. I concur that ciphers ought to
> be abstracted from the SSL protocol, and made available independently. Some
> even suggested waiting for AES to be included in OpenSSL to make it available
> to python programmers.

OpenSSL is not only a implementation of SSL. It also provides C
implementations of widely used cipher algorithms. E.g. amkCrypto
makes these algorithm implementations available to Python programs.

> This is precisely what I was attempting to avoid by creating pyAES. OpenSSL
> has its applications and it executes them admirably. However, including such
> a large package merely to access a few crypto functions seems to me like an
> unnecessary bloat. Especially if it is to be bundled in a python distribution.

You're right that adding OpenSSL libs to every cryptographic
application might be a code bloat for small programs. (On the other
hand most Python 2.0 installations are today built and installed
with OpenSSL anyway.)

To get a solution acceptable in a wider range of applications I
would like to suggest the definition of a class API which completely
abstracts from the underlying implementations and where an
application can locate a cryptographic algorithm or protocol at
run-time (factory class design pattern?).

Ciao, Michael.




From bryan at EEVOLVED.COM  Thu Feb  8 10:58:01 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Thu, 8 Feb 2001 04:58:01 -0500
Subject: [PYTHON-CRYPTO] SIG thoughts.
In-Reply-To: <3A8255B3.39FF537E@stroeder.com>
References: <01020715041209.00694@mephit> <3A8255B3.39FF537E@stroeder.com>
Message-ID: <01020804580102.00689@mephit>

<Quotes from Micheal Stroder>

> Fortunately you're wrong. There have been around 20 subscriptions up
> to now.

Glad to hear it! I look forward to being able to absorb their input.

> # Search for a implementation providing AES, use the first available
> aes = crypto.locate_alg('aes')

Hmmm... Are you proposing the crypto module contain all possible ciphers,
both symmetric and asymmetric? If so, then do you envision pure python
implementations of all these ciphers?

That would be great of course, but have you looked at any of the existing
(mostly C) implementations of these algorithms? My experience is limited to
AES and ECC and I have looked at some of the more obfuscated sections like
key scheduling. I thanked the lord I didn't have to code it.  These
algorithms were written by experts, and any porting of that code to python
would have to rely on the expertise of the porter. Not to mention these
algorithms are very throughput sensitive, and an existing optimized and
tested C implementation would be hard to improve on and easy to deteriorate.

My point is that if all the ciphers were mashed together with platform
dependent SOs or DLLs, building and maintaining the crypto module suddenly
becomes a herculean task and you seem like a very busy guy...:) I think
seperating the crypto modules into their respective components would:

1- Permit easier maintenance and delegation of work.
2- Tighten code written for only one cipher. (think freeze)
3- Isolate any potential security risk resulting from faulty implementations.

I concur with you on useability issues. It would be easy to have one module.
But isn't that the goal of a SIG? To trust that all modules that comply with
a given SIG will have a standard API? Is it really tedious to import AES or
DES or CAST when you know these classes will have *identical* methods?

> Note that key is also meant as key object, an instance of an
> appropriate key storage class. I started to write a draft proposal
> but I'm stuck since I have to get some urgent work done.

Very interesting. Wouldn't a key "object" just be a string though? Don't even
need pickle or shelve for persistence, just write it to file. Password
encrypt if desired. Voila.  Should we make an object for that?

> I'd like to encourage everyone interested in a generic class API to
> take a look at
> http://java.sun.com/products/jdk/1.3/docs/guide/security/ which
> makes me really jealous...

Maybe it's my partisan nature, but I fail to see the cause of your jealousy.
The java.security API merely uses an obvious naming convention which we could
easily (and should) emulate.  When a method is called "KeyPairGenerator"
there is very little confusion as to what it does. Are you jealous because
Sun has it documented and we're here talking on this list? :)

> OpenSSL is not only a implementation of SSL. It also provides C
> implementations of widely used cipher algorithms. E.g. amkCrypto
> makes these algorithm implementations available to Python programs.

But does amkCrypto abstract those functions from the rest of OpenSSL? Can I
import only DES? What about freezing amk apps?

> You're right that adding OpenSSL libs to every cryptographic
> application might be a code bloat for small programs. (On the other
> hand most Python 2.0 installations are today built and installed
> with OpenSSL anyway.)

Let's do some quick tallying:

I'm learning the hard way that distributing a real-world, general usage
application written in python already requires a ~2MB bloat called the
python VM. Suddenly Guido's master plan becomes clear as I become another
python distributor. :) Adding another 1.7 MB (last I checked) for crypto
functions that largely go unused? Not acceptable in my application and I'm
sure others agree would agree. Add a small GUI toolkit for anything useful, 2
MBs minimum. These figures all take into account compression.

After all ~70% [1] of internet users are still stuck on < 56K. With the third
world markets opening up, expect this figure to jump.  A 5.7 meg download
takes ~25 minutes at 4K/sec (optimistic), longer than most people's attention
spans, and this "program" does NOTHING. Sure the program script might only be
10K, but without that 5.7 megs of support, it's just another text file.

I remember the days of 2400 baud. I choose to chop wherever I can because
bandwidth is a precious commodity. OpenSSL was first on the block.

> To get a solution acceptable in a wider range of applications I
> would like to suggest the definition of a class API which completely
> abstracts from the underlying implementations and where an
> application can locate a cryptographic algorithm or protocol at
> run-time (factory class design pattern?).

Couldn't an

>>> import crypto.<whatever the cipher name I want>

achieve the same result in one less line of code? Not to mention searching
for algorithms is avoided completely?

Hope my input is of some constructive help.

[1] : http://www.abcnews.go.com/sections/tech/DailyNews/wwwsurvey980714.html
A little dated but hey... Can't spend all my time on google... :) I adjusted
the figure down 10% a bit to reflect this.

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

"...one of the strongest motives that lead men to art and science is escape
from everyday life with its painful crudity and hopeless dreariness, from the
fetters of one's own ever-shifting desires. A finely tempered nature longs to
escape from the personal life into the world of objective perception and
thought."-- Einstein




From michael at STROEDER.COM  Thu Feb  8 11:32:37 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 8 Feb 2001 11:32:37 +0100
Subject: [PYTHON-CRYPTO] SIG thoughts.
References: <01020715041209.00694@mephit> <3A8255B3.39FF537E@stroeder.com>
            <01020804580102.00689@mephit>
Message-ID: <3A8275C5.FA0939C4@stroeder.com>

Bryan Mongeau wrote:
>
> <Quotes from Micheal Stroder>
>
> > # Search for a implementation providing AES, use the first available
> > aes = crypto.locate_alg('aes')
>
> Hmmm... Are you proposing the crypto module contain all possible ciphers,
> both symmetric and asymmetric? If so, then do you envision pure python
> implementations of all these ciphers?

No, algorithm implementations are meant to register their
capabilities at run-time. crypto.locate_alg('aes') would then try to
locate the first possible implementation for e.g. AES.

There could be several implementations for the same algorithm, e.g.
RSA provided in pure Python, C wrapper module or a driver for a
hardware crypto device. The different implementation vendors should
have registered names (requires a definition of a easy-to-use name
space) that the application is able to choose a specific
implementation by algorithm/protocol and vendor name.

> > Note that key is also meant as key object, an instance of an
> > appropriate key storage class. I started to write a draft proposal
> > but I'm stuck since I have to get some urgent work done.
>
> Very interesting. Wouldn't a key "object" just be a string though?

No. Think of keys with more parameters.

> Should we make an object for that?

Yes, for type-checking in debug mode. It should not be possible for
an application to use a RSA key for a AES cipher. I want to check
that with assert isinstance() statements.

> > I'd like to encourage everyone interested in a generic class API to
> > take a look at
> > http://java.sun.com/products/jdk/1.3/docs/guide/security/ which
> > makes me really jealous...
>
> Maybe it's my partisan nature, but I fail to see the cause of your jealousy.
> The java.security API merely uses an obvious naming convention which we could
> easily (and should) emulate.  When a method is called "KeyPairGenerator"
> there is very little confusion as to what it does. Are you jealous because
> Sun has it documented and we're here talking on this list? :)

Please try to understand JCE's dynamic nature first. Off course I'm
also jealous that I will never be able to provide such a good
documentation. ;-)

> Let's do some quick tallying:
> [..valid comments about code bloating by using big libs snipped..]

That's why I propose a dynamic registration of implementations. You
can distribute only the modules needed then. And you can choose the
implementations which fits your needs best.

Ciao, Michael.




From ngps at POST1.COM  Thu Feb  8 17:00:46 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Fri, 9 Feb 2001 00:00:46 +0800
Subject: [PYTHON-CRYPTO] Bryan calling Bryan (ECDSA).
In-Reply-To: <0102072042190C.00694@mephit>; from bryan@EEVOLVED.COM on Wed,
              Feb 07, 2001 at 08:42:19PM -0500
References: <0102072042190C.00694@mephit>
Message-ID: <20010209000046.E1369@madcap.dyndns.org>

On Wed, Feb 07, 2001 at 08:42:19PM -0500, Bryan Mongeau wrote:
> This is precisely what I was attempting to avoid by creating pyAES. OpenSSL
> has its applications and it executes them admirably. However, including such
> a large package merely to access a few crypto functions seems to me like an
> unnecessary bloat. Especially if it is to be bundled in a python distribution.

OpenSSL may or may not be bloatware, but IMHO its benefits are significant:

1. Portable to many platforms.
2. Assembly code on popular platforms.
3. Beginning to support hardware accelerators.
4. Bundled with recent open source Unices.
5. Large numbers of language bindings: Python, Perl, Tcl, Erlang, etc.

It certainly does not provide merely "a few crypto functions."


> Bryan, I was overjoyed to see that you have written an ECDSA class in pure
> python. ECDSA has been causing me extreme headaches in my Eliptic Curve class
> and is responsible for making an otherwise tight .so into a hideous monster.
> I would love to get my hands on it.  I have also implemented a loose
> interpretation of TLS with AES and ECC that will be under 100K when I get to
> drop the DSA C functions.

It is nice to have fun, of course, but is your loose interpretation of
TLS secure? Which other implementation(s) does it interoperate with?

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




From ngps at POST1.COM  Thu Feb  8 17:05:24 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Fri, 9 Feb 2001 00:05:24 +0800
Subject: [PYTHON-CRYPTO] SIG thoughts.
In-Reply-To: <3A8275C5.FA0939C4@stroeder.com>; from michael@STROEDER.COM on
              Thu, Feb 08, 2001 at 11:32:37AM +0100
References: <01020715041209.00694@mephit> <3A8255B3.39FF537E@stroeder.com>
            <01020804580102.00689@mephit> <3A8275C5.FA0939C4@stroeder.com>
Message-ID: <20010209000524.F1369@madcap.dyndns.org>

On Thu, Feb 08, 2001 at 11:32:37AM +0100, Michael Str?der wrote:
> No, algorithm implementations are meant to register their
> capabilities at run-time. crypto.locate_alg('aes') would then try to
> locate the first possible implementation for e.g. AES.

Michael,

Why reinvent the Java Crypto Architecture? What's so great about it?


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




From ngps at POST1.COM  Thu Feb  8 16:35:36 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Thu, 8 Feb 2001 23:35:36 +0800
Subject: [PYTHON-CRYPTO] Okay, I'll break the ice... :)
In-Reply-To: <01020715041209.00694@mephit>; from bryan@EEVOLVED.COM on Wed,
              Feb 07, 2001 at 03:04:12PM -0500
References: <01020715041209.00694@mephit>
Message-ID: <20010208233536.C1369@madcap.dyndns.org>

On Wed, Feb 07, 2001 at 03:04:12PM -0500, Bryan Mongeau wrote:
> Having a crypto-SIG would do wonders for python's acceptance. In the same way
> that the dbAPI-SIG suddenly made persistent python objects readily available
> to even the lay programmer, powerful crypto routines should be wieldable by
> everyone like this:

<pedantic>
The DB API doesn't really do persistent Python objects; it connects
Python to RDBMS's. Zope's ZODB does persistent Python objects.
</pedantic>


> >>> from crypto import aes
> >>> encryptor = aes( "key string")  # Can be hashed or not? Easier for laymen?

You'll need to be able to specify IV and mode.


> I also don't think we should waste our time with the older algorithms, except
> in the case of maintaining compatibility with industry standards like SSL.

For compatibility with SSL, you need the following:

EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-DSS-RC4-SHA:IDEA-CBC-SHA:RC4-SHA:RC4-MD5:IDEA-CBC-MD5:RC2-CBC-MD5:RC4-MD5:RC4-64-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:EXP1024-RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5


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




From akuchlin at CNRI.RESTON.VA.US  Thu Feb  8 17:33:36 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Thu, 8 Feb 2001 11:33:36 -0500
Subject: [PYTHON-CRYPTO] Current state of the art?
In-Reply-To: <20010208235326.D1369@madcap.dyndns.org>; from ngps@POST1.COM on
              Thu, Feb 08, 2001 at 11:53:26PM +0800
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <20010208235326.D1369@madcap.dyndns.org>
Message-ID: <20010208113336.D2336@thrak.cnri.reston.va.us>

On Thu, Feb 08, 2001 at 11:53:26PM +0800, Ng Pheng Siong wrote:
>M2Crypto, a Python binding for OpenSSL, has:

Which reminds me... the socketmodule in Python 2.0 has some very
simple support for SSL.  See Modules/Setup for how to compile it; 2.1
alphas should detect OpenSSL and turn on SSL support automatically.
However, I've been looking at the code recently and am not too
favorably impressed with it; I'll argue for dropping it from 2.1.  SSL
is a big API and the code in socketmodule.c only provides very basic
things.

--amk




From ngps at POST1.COM  Thu Feb  8 16:53:26 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Thu, 8 Feb 2001 23:53:26 +0800
Subject: [PYTHON-CRYPTO] Current state of the art?
In-Reply-To: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>; from
              richard@BIZARSOFTWARE.COM.AU on Thu, Feb 08,
              2001 at 09:32:12AM +1100
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
Message-ID: <20010208235326.D1369@madcap.dyndns.org>

On Thu, Feb 08, 2001 at 09:32:12AM +1100, Richard Jones wrote:
> Could people please summarise the current state of the art?
>
> I'm specifically interested in OpenPGP from Python, but am curious where
> other systems stand.

M2Crypto, a Python binding for OpenSSL, has:

- S/MIMEv2 and ZSmime, a Zope product that generates S/MIME-signed/encrypted
mail. Interoperates with Netscape Communicator and should also work with
Outlook.

- Some PGPv2 packet parsing code. But once I have S/MIME I stopped work
on this.

- SSL server frameworks: forking, threading and async-I/O. Have been used
to extend SimpleHTTPServer, Medusa's https server, Zope's ZServer and the
eff-bot's xmlrpc server. Also enhanced httplib in both Python 1 and 2.

I've also built an encrypting monitor for Zope, but I'm not satisfied
with it and I intend to build another using the Secure Remote Protocol
(SRP).

- RSA, DSA, DH.

- MD5, SHA1, RIPEMD160 and HMACs using those.

- Symmetric ciphers using an interface modeled after the OpenSSL EVP
interface. AES should be in the next release of OpenSSL and M2Crypto
will then support that.

- Bits and pieces of other stuff.


Here are M2Crypto's current stories: (I'm an XPer-wannabe! ;-)

- SSL socket timeouts.
- Prevent NULL returns becoming Py_None.
- Raise exception if necessary when returning NULL.
- Distutils setup file.
- Unit tests for BIO.CipherFilter.
- Handle exceptions in Python callbacks gracefully.
- PassKeep, a password safe.
- Wagner/Laurie lucre.
- Shared RSA key gen.
- ZSmime (and GuardedFile) for current Zope.
- Secure multiparty computation.
- Secure Remote Protocol.
- Fix caveats noted in the README.
+ Handle non-SSL connection to an SSL server gracefully.
    See demo/https/https_server.py's recv().
+ ZServerSSL for current Zope.


Oh, now that Zope has "Python scripts", maybe "signed Python scripts"
(a la signed applets) might be a fun thing to do.


M2Crypto is severely lacking in documentation. I hope to address this
RSN.

This is not a commercial, since M2Crypto is freely available under
a BSD license. ;-)

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




From akuchlin at CNRI.RESTON.VA.US  Thu Feb  8 17:41:14 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Thu, 8 Feb 2001 11:41:14 -0500
Subject: [PYTHON-CRYPTO] Bryan calling Bryan (ECDSA).
In-Reply-To: <3A8257CB.AC9A9729@stroeder.com>; from michael@STROEDER.COM on
              Thu, Feb 08, 2001 at 09:24:43AM +0100
References: <0102072042190C.00694@mephit> <3A8257CB.AC9A9729@stroeder.com>
Message-ID: <20010208114114.E2336@thrak.cnri.reston.va.us>

On Thu, Feb 08, 2001 at 09:24:43AM +0100, Michael Str?der wrote:
>You're right that adding OpenSSL libs to every cryptographic
>application might be a code bloat for small programs. (On the other
>hand most Python 2.0 installations are today built and installed
>with OpenSSL anyway.)

Also, note that current Linux distributions are coming with OpenSSL
installed, and presumably BSD distributions will follow suit.  Red Hat
7.0 even comes with M2Crypto as openssl-python.

>To get a solution acceptable in a wider range of applications I
>would like to suggest the definition of a class API which completely
>abstracts from the underlying implementations and where an
>application can locate a cryptographic algorithm or protocol at
>run-time (factory class design pattern?).

Strong agreement.

--amk




From michael at STROEDER.COM  Thu Feb  8 18:02:23 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 8 Feb 2001 18:02:23 +0100
Subject: [PYTHON-CRYPTO] Current state of the art?
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <20010208235326.D1369@madcap.dyndns.org>
            <20010208113336.D2336@thrak.cnri.reston.va.us>
Message-ID: <3A82D11F.3BF85AEB@stroeder.com>

Andrew Kuchling wrote:
>
> On Thu, Feb 08, 2001 at 11:53:26PM +0800, Ng Pheng Siong wrote:
> >M2Crypto, a Python binding for OpenSSL, has:
>
> Which reminds me... the socketmodule in Python 2.0 has some very
> simple support for SSL.

...but a different API than M2Crypto...

> However, I've been looking at the code recently and am not too
> favorably impressed with it; I'll argue for dropping it from 2.1.  SSL
> is a big API and the code in socketmodule.c only provides very basic
> things.

We're definitely getting closer to it... :-)

Ciao, Michael.




From michael at STROEDER.COM  Thu Feb  8 17:57:38 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 8 Feb 2001 17:57:38 +0100
Subject: [PYTHON-CRYPTO] SIG thoughts.
References: <01020715041209.00694@mephit> <3A8255B3.39FF537E@stroeder.com>
            <01020804580102.00689@mephit> <3A8275C5.FA0939C4@stroeder.com>
            <20010209000524.F1369@madcap.dyndns.org>
Message-ID: <3A82D002.12B54ED6@stroeder.com>

Ng Pheng Siong wrote:
> 
> On Thu, Feb 08, 2001 at 11:32:37AM +0100, Michael Str?der wrote:
> > No, algorithm implementations are meant to register their
> > capabilities at run-time. crypto.locate_alg('aes') would then try to
> > locate the first possible implementation for e.g. AES.
> 
> Why reinvent the Java Crypto Architecture? What's so great about it?

It's great that
- you have a unique API
- you can combine several implementations and choose the one which
fits your needs best at run-time
- you have a clean object model for all entities like algorithms,
keys with various encodings, key stores, cryptographic protocols....

Especially *you* should appreciate such a thing for M2Crypto because
it would save the time you're spending for designing and writing
Python wrapper classes for hiding the ugly SWIG-ed BIO interfaces
for C illiterates like me. ;-)

Ciao, Michael.




From akuchlin at CNRI.RESTON.VA.US  Thu Feb  8 22:41:10 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Thu, 8 Feb 2001 16:41:10 -0500
Subject: [PYTHON-CRYPTO] Hashing modules
Message-ID: <20010208164110.C2482@thrak.cnri.reston.va.us>

Let's take a look at the interface for hashing.  Here are the docs
from amkCrypto:

==========================

   All hashing modules share the same interface. After importing a given
   hashing module, call the new() function to create a new hashing
   object. (In older versions of the Python interpreter, the
   md5() function was used to perform this task. If you're modifying an
   old script, you should change any calls to md5() to use new()
   instead.) You can now feed arbitrary strings into the object, and can
   ask for the hash value at any time. The new() function can also be
   passed an optional string parameter, which will be hashed immediately.

   Hash function modules define one variable:

   digestsize
          An integer value; the size of the digest produced by the
          hashing objects. You could also obtain this value by creating a
          sample object, and taking the length of the digest string it
          returns, but using digestsize is faster.

   The methods for hashing objects are always the following:

   copy ()
          Return a separate copy of this hashing object. An update to
          this copy won't affect the original object.

   digest ()
          Return the hash value of this hashing object, as a string
          containing 8-bit data. The object is not altered in any way by
          this function; you can continue updating the object after
          calling this function.

   hexdigest ()
          Return the hash value of this hashing object, as a string
          containing the digest data as hexadecimal digits. The resulting
          string will be twice as long as that returned by digest(). The
          object is not altered in any way by this function; you can
          continue updating the object after calling this function.

   update (arg)
          Update this hashing object with the string arg.

   Here's an example, using RSA Data Security's MD5 algorithm:

>>> from Crypto.Hash import MD5
>>> m = MD5.new()
>>> m.update('abc')
>>> m.digest()
'\220\001P\230<\322O\260\326\226?@}(\341\177r'

   Or, more compactly:

>>> MD5.new('abc').digest()
'\220\001P\230<\322O\260\326\226?@}(\341\177r'

===========================================================================

Does this seem a reasonable interface for a hash algorithm?  Anything
missing?  Anything that can be dropped?  (.hexdigest() probably isn't
needed... or is it?)

Any ideas/features from other languages that we can steal?  Java's API
is documented at
http://java.sun.com/j2se/1.3/docs/api/java/security/MessageDigest.html;
can anyone find the docs for the Perl modules?

--amk




From bryan at EEVOLVED.COM  Thu Feb  8 21:47:09 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Thu, 8 Feb 2001 15:47:09 -0500
Subject: [PYTHON-CRYPTO] SIG thoughts.
In-Reply-To: <3A8275C5.FA0939C4@stroeder.com>
References: <01020715041209.00694@mephit> <01020804580102.00689@mephit>
            <3A8275C5.FA0939C4@stroeder.com>
Message-ID: <01020815470906.00689@mephit>

> No, algorithm implementations are meant to register their
> capabilities at run-time. crypto.locate_alg('aes') would then try to
> locate the first possible implementation for e.g. AES.
>
> There could be several implementations for the same algorithm, e.g.
> RSA provided in pure Python, C wrapper module or a driver for a
> hardware crypto device. The different implementation vendors should
> have registered names (requires a definition of a easy-to-use name
> space) that the application is able to choose a specific
> implementation by algorithm/protocol and vendor name.

Very cool. I like this. Two small issues I can think of:

aes = crypto.find_alg("aes")

precludes the ability to pass any arguments to the AES class constructor
without some trickery. Maybe:

aes = crypto.find_alg("aes",*args)

would be better? Secondly, what if multiple implementations of a given cipher
exist on a computer? Example, joe average installs a crypto device but is
unaware that he is using the C implementation because it was found first.
Could a search parameter be added?

> No. Think of keys with more parameters.

Help me out here... I can't think of any... :)

> Yes, for type-checking in debug mode. It should not be possible for
> an application to use a RSA key for a AES cipher. I want to check
> that with assert isinstance() statements.

This is an excellent idea that I concurr with completely! Is the goal to
protect lay programmers from their own mistakes?

> Please try to understand JCE's dynamic nature first. Off course I'm
> also jealous that I will never be able to provide such a good
> documentation. ;-)

Never say never... HappyDoc is a wonderful tool! :)

> That's why I propose a dynamic registration of implementations. You
> can distribute only the modules needed then. And you can choose the
> implementations which fits your needs best.

Maybe I don't know enough on the issue, but I don't see how the dynamic
registration would be possible to effectuate efficiently. Care to enlighten
me?

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

"He who joyfully marches to music rank and file, has already earned my
contempt. He has been given a large brain by mistake, since for him the
spinal cord would surely suffice. This disgrace to civilization should be
done away with at once. Heroism at command, how violently I hate all this,
how despicable and ignoble war is; I would rather be torn to shreds than be a
part of so base an action. It is my conviction that killing under the cloak
of war is nothing but an act of murder."-- Einstein




From akuchlin at CNRI.RESTON.VA.US  Thu Feb  8 22:50:23 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Thu, 8 Feb 2001 16:50:23 -0500
Subject: [PYTHON-CRYPTO] SIG thoughts.
In-Reply-To: <01020815470906.00689@mephit>; from bryan@EEVOLVED.COM on Thu,
              Feb 08, 2001 at 03:47:09PM -0500
References: <01020715041209.00694@mephit> <01020804580102.00689@mephit>
            <3A8275C5.FA0939C4@stroeder.com> <01020815470906.00689@mephit>
Message-ID: <20010208165023.D2482@thrak.cnri.reston.va.us>

On Thu, Feb 08, 2001 at 03:47:09PM -0500, Bryan Mongeau wrote:
>Very cool. I like this. Two small issues I can think of:
>aes = crypto.find_alg("aes")
>precludes the ability to pass any arguments to the AES class constructor
>without some trickery. Maybe:

Would find_alg() return an instance or a module, though?  Perhaps you'd write:
cipher_mod = crypto.find_alg('aes')
encryptor = cipher_mod.new(key, ...)

JCE has an interesting idea, using objects instead of simple strings
for keys; that allows having methods to do things like check the
parity of a DES key.  That might well be too cumbersome, though.

>Help me out here... I can't think of any... :)

RC5, which has a variable number of rounds and even a variable word size.

--amk




From bryan at EEVOLVED.COM  Thu Feb  8 23:07:31 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Thu, 8 Feb 2001 17:07:31 -0500
Subject: [PYTHON-CRYPTO] SIG thoughts. [ replies to AMK ]
In-Reply-To: <20010208165023.D2482@thrak.cnri.reston.va.us>
References: <01020715041209.00694@mephit> <01020815470906.00689@mephit>
            <20010208165023.D2482@thrak.cnri.reston.va.us>
Message-ID: <01020817073107.00689@mephit>

> Would find_alg() return an instance or a module, though?  Perhaps you'd
> write: cipher_mod = crypto.find_alg('aes')
> encryptor = cipher_mod.new(key, ...)

I fail to see how this is any more efficient or convenient than:

[ exaggerated naming convention ]

from crypto import aes
from crypto import aesOptimizedCImplementation
from crypto import aesHardwareImplementation

No confusion here as to which implementation is being used.

> RC5, which has a variable number of rounds and even a variable word size.

Learn something new everyday... :)
--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
www.eevolved.com
<==================================>

"He who joyfully marches to music rank and file, has already earned my
contempt. He has been given a large brain by mistake, since for him the
spinal cord would surely suffice. This disgrace to civilization should be
done away with at once. Heroism at command, how violently I hate all this,
how despicable and ignoble war is; I would rather be torn to shreds than be a
part of so base an action. It is my conviction that killing under the cloak
of war is nothing but an act of murder."-- Einstein




From rsalz at CAVEOSYSTEMS.COM  Fri Feb  9 01:46:32 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Thu, 8 Feb 2001 19:46:32 -0500
Subject: [PYTHON-CRYPTO] SIG thoughts. [ replies to AMK ]
References: <01020715041209.00694@mephit> <01020815470906.00689@mephit>
            <20010208165023.D2482@thrak.cnri.reston.va.us>
            <01020817073107.00689@mephit>
Message-ID: <3A833DE8.6E7AC0EB@caveosystems.com>

> > write: cipher_mod = crypto.find_alg('aes')

> I fail to see how this is any more efficient or convenient than:
>
> [ exaggerated naming convention ]
>
> from crypto import aes
> from crypto import aesOptimizedCImplementation
> from crypto import aesHardwareImplementation

The first method allows system defaults to set up "best" criteria for an
algorithm.

The second method requires every crypto application to be intimately
aware of host configuration issues.

The pyXML folks got the "find implementation" stuff exactly right.
        /r$




From andy at DUSTMAN.NET  Thu Feb  8 21:31:44 2001
From: andy at DUSTMAN.NET (Andy Dustman)
Date: Thu, 8 Feb 2001 15:31:44 -0500
Subject: [PYTHON-CRYPTO] Current state of the art?
In-Reply-To: <3A82D11F.3BF85AEB@stroeder.com>
Message-ID: <Pine.LNX.4.21.0102081517320.786-100000@kenny.comstar.net>

At one point (this was years ago), I worked on a SWIG-generated interface
to the SSLeay crypto routines (pre-OpenSSL). Most of the ciphers worked,
and there was access to BIGNUM objects, and I think maybe most of the RSA
stuff worked, and SHA1. This was in the "bad old days" of ITAR...

It would nice for this to be broken out as a package:

crypto
  +---bignum
  +---ciphers
         +----privatekey
                 +---aes
                 +---blowfish
                 +---des
         +----publickey
                 +---rsa
                 +---dsa
                 +---dh
         +----oneway
                 +---md5
                 +---sha1
                 +---ripemd160
  +---keymanagement
  +---network
  ...

crypto.ciphers.privatekey.* would have various object classes which
implement the various cipher modes (ECB, CBC, etc.); these could actually
be factory functions. I think it was AMK's stuff that had cryptors which
would take a plaintext string input and return ciphertext (or vice
versa). I liked that model, but we can also have ones that read/write file
objects.

--
Andy Dustman         PGP: 0xC72F3F1D
    @       .net     http://dustman.net/andy
"Normally with carbonara you use eggs, but I used lobster brains instead."
    -- Masahiko Kobe (Iron Chef Italian): 30-year-old Giant Lobster Battle




From bryan at EEVOLVED.COM  Thu Feb  8 21:34:57 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Thu, 8 Feb 2001 15:34:57 -0500
Subject: [PYTHON-CRYPTO] More thoughts [ replies to Ng ]
In-Reply-To: <20010209000046.E1369@madcap.dyndns.org>
References: <0102072042190C.00694@mephit>
            <20010209000046.E1369@madcap.dyndns.org>
Message-ID: <01020815345705.00689@mephit>

> OpenSSL may or may not be bloatware, but IMHO its benefits are significant:
>
> 1. Portable to many platforms.
> 2. Assembly code on popular platforms.
> 3. Beginning to support hardware accelerators.
> 4. Bundled with recent open source Unices.
> 5. Large numbers of language bindings: Python, Perl, Tcl, Erlang, etc.
>
> It certainly does not provide merely "a few crypto functions."

Your point, although salient, seems to miss what I was driving at. Evidently
OpenSSL provides myriad crypto routines, protocols and primitives. What I
postulated was that joe average python programmer will only ever use a few of
those functions. Proposals such as waiting for OpenSSL to include AES before
making it available to the python programmer make me shudder. Imagine the
reaction of the programmer packaging that app that only uses AES but suddenly
must include a 2 meg library. Granted, OpenSSL is already quasi-omnipresent
on *nixes, but real consumer applications have to deal with Windows and Mac.

I hope you don't misinterpret my opinions. I use OpenSSL daily for tasks
ranging from Apache mod_ssl to SSH to SCP and it performs admirably.  I
simply do not support any initiative that would see all of python's
cryptographic eggs placed in one basket.  Python is modular by design and we
should keep it that way.

> It is nice to have fun, of course, but is your loose interpretation of
> TLS secure? Which other implementation(s) does it interoperate with?

Very valid questions. I will do my best to address them here. Please keep in
mind some of this I have implemented, other parts are on my todo list. :)

>From RFC 2246 page 14:

>> The security parameters for a TLS Connection read and write state are
>> set by providing the following values: (SecurityParameters)

Connection End: Client or Server
BulkCipherAlgorithm: AES
CipherType: CBC
key_size: 192  # I chose 192 because my public key is 233 bit EC
key_material_length: 233  # the 233 bit secret exchanged
is_exportable: NO
mac_algorithm: SHA256
hash_size: 256
compression_algorithm: None

<note of interest>
The TLS RFC explicitly states that compression occurs BEFORE encryption,
which, in my opinion, is an extreme oversight in the face of recent zip
signature attacks on encrypted data. Maybe I'm wrong, but I prefer to do the
compression at the network layer. This is why my TLS SecurityParameters do
not have compression.
</note of interest>

Client and Server MAC, keys and IVs are all generated from the master secret.
The master secret, client and server randoms are created using a thread
scheduling entropy PRNG of my colleague's creation. See Sci.Crypt archives
for details or ask me about it. I'd love some input on its security. It's a
4K python script.

The handshake protocol is currently lacking certificates, but is otherwise
functional. I could remedy this if Bryan Olson would contact me.

The Change Cipher Spec protocol is not implemented nor do I intend to do so
due to the fact that I do not support any other block ciphers besides AES.

The Alert protocol is implemented as follows: If any fatal alerts occur, the
connection is immediately terminated. Other errors are ignored. This will
most likely change in future versions.

I have not tested my implementation of TLS with any other existing
implementions.

[ from another reply of Ng's ]

> >>> from crypto import aes
> >>> encryptor = aes( "key string")  # Can be hashed or not?

>You'll need to be able to specify IV and mode.

Good point. I assumed that we were talking about ease of use for laymen. You
can intuit that the aes constructor would look like this:

__init__(self, key=None, mode="ECB", IV=None)

Thanks for the comments! I hope this discussion continues on it's present
path. It will surely result in something cool!

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

"He who joyfully marches to music rank and file, has already earned my
contempt. He has been given a large brain by mistake, since for him the
spinal cord would surely suffice. This disgrace to civilization should be
done away with at once. Heroism at command, how violently I hate all this,
how despicable and ignoble war is; I would rather be torn to shreds than be a
part of so base an action. It is my conviction that killing under the cloak
of war is nothing but an act of murder."-- Einstein




From michael at STROEDER.COM  Sat Feb 10 17:31:57 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 10 Feb 2001 17:31:57 +0100
Subject: [PYTHON-CRYPTO] SIG thoughts. [ replies to AMK ]
References: <01020715041209.00694@mephit> <01020815470906.00689@mephit>
            <20010208165023.D2482@thrak.cnri.reston.va.us>
            <01020817073107.00689@mephit> <3A833DE8.6E7AC0EB@caveosystems.com>
Message-ID: <3A856CFD.6C56EEAC@stroeder.com>

Rich Salz wrote:
>
> The pyXML folks got the "find implementation" stuff exactly right.

Are you referring to the xml.dom stuff (DOMImplementation.py etc.)?

Ciao, Michael.




From michael at STROEDER.COM  Sat Feb 10 18:37:03 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 10 Feb 2001 18:37:03 +0100
Subject: [PYTHON-CRYPTO] SIG thoughts.
References: <01020715041209.00694@mephit> <01020804580102.00689@mephit>
            <3A8275C5.FA0939C4@stroeder.com> <01020815470906.00689@mephit>
            <20010208165023.D2482@thrak.cnri.reston.va.us>
Message-ID: <3A857C3F.22CC55A7@stroeder.com>

Andrew Kuchling wrote:
>
> Would find_alg() return an instance or a module, though?

The question is class or instance.
I would prefer to return an instance.

> JCE has an interesting idea, using objects instead of simple strings
> for keys; that allows having methods to do things like check the
> parity of a DES key.  That might well be too cumbersome, though.

I would like to define classes for every object handled in this API.
IMHO it's not too cumbersome. E.g. an implementation of a cipher
algorithm will have to deal with a key object only during
initialization of the cipher instance and is free to solely handle
the key string internally (for speed).

But with classes for each object we can use assert statements for
type checking.

Ciao, Michael.




From michael at STROEDER.COM  Sat Feb 10 18:46:32 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 10 Feb 2001 18:46:32 +0100
Subject: [PYTHON-CRYPTO] SIG thoughts.
References: <01020715041209.00694@mephit> <01020804580102.00689@mephit>
            <3A8275C5.FA0939C4@stroeder.com> <01020815470906.00689@mephit>
Message-ID: <3A857E78.7A4BF93D@stroeder.com>

Bryan Mongeau wrote:
>
> aes = crypto.find_alg("aes",*args)
> would be better?

Yes. If find_alg is a factory it should pass additional parameters
to the class' __init__() method during object creation.

> Secondly, what if multiple implementations of a given cipher
> exist on a computer? Example, joe average installs a crypto device but
> is unaware that he is using the C implementation because it was found
> first.

Should be matter of local policy either defined in a global config
file by a system administrator knowing what to do or defined...

> Could a search parameter be added?

...at run-time by a search parameter specifying the unambiguous name
of the implementation (definition of used name space required).

> > Yes, for type-checking in debug mode. It should not be possible for
> > an application to use a RSA key for a AES cipher. I want to check
> > that with assert isinstance() statements.
>
> This is an excellent idea that I concurr with completely! Is the goal to
> protect lay programmers from their own mistakes?

Mainly it's meant to protect myself. ;-)

> > That's why I propose a dynamic registration of implementations. You
> > can distribute only the modules needed then. And you can choose the
> > implementations which fits your needs best.
>
> Maybe I don't know enough on the issue, but I don't see how the dynamic
> registration would be possible to effectuate efficiently.

Mainly only creating an instance of e.g. an cipher algorithm object
is dynamic. Your application should off course re-use this cipher
object to be more efficient.

Ciao, Michael.




From michael at STROEDER.COM  Sat Feb 10 19:15:16 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 10 Feb 2001 19:15:16 +0100
Subject: [PYTHON-CRYPTO] Hashing modules
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
Message-ID: <3A858534.7A01739D@stroeder.com>

Andrew Kuchling wrote:
>
> Let's take a look at the interface for hashing.  Here are the docs
> from amkCrypto:
> [..]

This seems reasonable to me.

> >>> from Crypto.Hash import MD5
> >>> m = MD5.new()
> >>> m.update('abc')
> >>> m.digest()
> '\220\001P\230<\322O\260\326\226?@}(\341\177r'

Slightly different:

>>> import Crypto
>>> md5 = Crypto.getInstance('MD5')
>>> md5.update('abc')
>>> md5.digest()
> '\220\001P\230<\322O\260\326\226?@}(\341\177r'

> Does this seem a reasonable interface for a hash algorithm?

Yes.

> Anything missing?  Anything that can be dropped?
> (.hexdigest() probably isn't needed... or is it?)

Yes, drop .hexdigest() but add method .reset() that a dynamically
created object can be re-used.

Also we should try to implement a Codec-like StreamWriter() /
StreamReader() class for that like mentioned by M.-A. Lemburg on the
(deprecated) eGroups list.

Ciao, Michael.




From rsalz at CAVEOSYSTEMS.COM  Sat Feb 10 20:55:17 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Sat, 10 Feb 2001 14:55:17 -0500
Subject: [PYTHON-CRYPTO] SIG thoughts. [ replies to AMK ]
References: <01020715041209.00694@mephit> <01020815470906.00689@mephit>
            <20010208165023.D2482@thrak.cnri.reston.va.us>
            <01020817073107.00689@mephit> <3A833DE8.6E7AC0EB@caveosystems.com>
            <3A856CFD.6C56EEAC@stroeder.com>
Message-ID: <3A859CA5.C41FD753@caveosystems.com>

> > The pyXML folks got the "find implementation" stuff exactly right.
>
> Are you referring to the xml.dom stuff (DOMImplementation.py etc.)?

Yes.




From ngps at POST1.COM  Sun Feb 11 09:54:06 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Sun, 11 Feb 2001 16:54:06 +0800
Subject: [PYTHON-CRYPTO] Hashing modules
In-Reply-To: <3A858534.7A01739D@stroeder.com>; from michael@STROEDER.COM on
              Sat, Feb 10, 2001 at 07:15:16PM +0100
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
            <3A858534.7A01739D@stroeder.com>
Message-ID: <20010211165406.A327@madcap.dyndns.org>

On Sat, Feb 10, 2001 at 07:15:16PM +0100, Michael Str?der wrote:
> Andrew Kuchling wrote:
> > >>> from Crypto.Hash import MD5
> > >>> m = MD5.new()
> > >>> m.update('abc')
> > >>> m.digest()
> > '\220\001P\230<\322O\260\326\226?@}(\341\177r'
>
> Slightly different:
> >>> import Crypto
> >>> md5 = Crypto.getInstance('MD5')
> >>> md5.update('abc')
> >>> md5.digest()
> > '\220\001P\230<\322O\260\326\226?@}(\341\177r'

M2Crypto's:

>>> from M2Crypto.EVP import MessageDigest
>>> md5 = MessageDigest('md5')
>>> md5.update('abc')
>>> md5.digest()
'\220\001P\230<\322O\260\326\226?}(\341\177r'


> Also we should try to implement a Codec-like StreamWriter() /
> StreamReader() class for that like mentioned by M.-A. Lemburg on the
> (deprecated) eGroups list.

OpenSSL's stackable BIO interface is quite amenable to this.

Current M2Crypto has a BIO.CipherFilter, which provides a stream
reader/writer-like interface. The tests have not been written,
so the code probably won't work as is.

I am going to write a GUI password safe using BIO.CipherFilter.
(Scratching a personal itch here - I have too many similar but
different online passwords.)


Cheers.

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




From michael at STROEDER.COM  Sun Feb 11 11:37:18 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Feb 2001 11:37:18 +0100
Subject: [PYTHON-CRYPTO] Hashing modules
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
            <3A858534.7A01739D@stroeder.com>
            <20010211165406.A327@madcap.dyndns.org>
Message-ID: <3A866B5E.FE9A7281@stroeder.com>

Ng Pheng Siong wrote:
> 
> On Sat, Feb 10, 2001 at 07:15:16PM +0100, Michael Str?der wrote:
> > Andrew Kuchling wrote:
> > > >>> from Crypto.Hash import MD5
> > > >>> m = MD5.new()
> > > >>> m.update('abc')
> > > >>> m.digest()
> > > '\220\001P\230<\322O\260\326\226?@}(\341\177r'
> >
> > Slightly different:
> > >>> import Crypto
> > >>> md5 = Crypto.getInstance('MD5')
> > >>> md5.update('abc')
> > >>> md5.digest()
> > > '\220\001P\230<\322O\260\326\226?@}(\341\177r'
> 
> M2Crypto's:
> 
> >>> from M2Crypto.EVP import MessageDigest
> >>> md5 = MessageDigest('md5')
> >>> md5.update('abc')
> >>> md5.digest()
> '\220\001P\230<\322O\260\326\226?}(\341\177r'

So at least for a message digest function we almost agree on how it
should be done. :-)

Ciao, Michael.




From akuchlin at CNRI.RESTON.VA.US  Sun Feb 11 17:26:29 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Sun, 11 Feb 2001 11:26:29 -0500
Subject: [PYTHON-CRYPTO] SIG thoughts.
In-Reply-To: <3A857E78.7A4BF93D@stroeder.com>; from michael@STROEDER.COM on
              Sat, Feb 10, 2001 at 06:46:32PM +0100
References: <01020715041209.00694@mephit> <01020804580102.00689@mephit>
            <3A8275C5.FA0939C4@stroeder.com> <01020815470906.00689@mephit>
            <3A857E78.7A4BF93D@stroeder.com>
Message-ID: <20010211112629.A24464@newcnri.cnri.reston.va.us>

On Sat, Feb 10, 2001 at 06:46:32PM +0100, Michael Str?der wrote:
>> aes = crypto.find_alg("aes",*args)
>> would be better?
>Yes. If find_alg is a factory it should pass additional parameters
>to the class' __init__() method during object creation.

I like the idea of a registry for crypto functions similar to the one for
Unicode codecs.  Codecs have a flat namespace; do we want find_alg('MD5') or
find_alg('MD5', type='hash') or find_hash_alg('MD5')?  In other words, do we
have to know ahead of time that MD5 is a hash algorithm, or can we get an
instance first without knowing what the algorithm actually does?

>Should be matter of local policy either defined in a global config
>file by a system administrator knowing what to do or defined...

Does someone want to write a proposed interface for the registration and
search functions, and the config file?

--amk




From ngps at POST1.COM  Sun Feb 11 16:51:28 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Sun, 11 Feb 2001 23:51:28 +0800
Subject: [PYTHON-CRYPTO] Current state of the art?
In-Reply-To: <20010208113336.D2336@thrak.cnri.reston.va.us>; from
              akuchlin@CNRI.RESTON.VA.US on Thu, Feb 08,
              2001 at 11:33:36AM -0500
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <20010208235326.D1369@madcap.dyndns.org>
            <20010208113336.D2336@thrak.cnri.reston.va.us>
Message-ID: <20010211235128.A282@madcap.dyndns.org>

On Thu, Feb 08, 2001 at 11:33:36AM -0500, Andrew Kuchling wrote:
> Which reminds me... the socketmodule in Python 2.0 has some very
> simple support for SSL.  See Modules/Setup for how to compile it; 2.1
> alphas should detect OpenSSL and turn on SSL support automatically.
> However, I've been looking at the code recently and am not too
> favorably impressed with it; I'll argue for dropping it from 2.1.  SSL
> is a big API and the code in socketmodule.c only provides very basic
> things.

Aye. I was just looking into producing patches to make its SSL
read()/write() more robust. Making it threading is fine, but async
socket-I/O presents a small problem.

Also, APIs will be needed for SSL contexts and sessions, and X.509
certificate handling within SSL connections, etc.

It is indeed not sensible to plonk the whole thing into the Python
core.

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




From ngps at POST1.COM  Sun Feb 11 17:13:26 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Mon, 12 Feb 2001 00:13:26 +0800
Subject: [PYTHON-CRYPTO] Current state of the art?
In-Reply-To: <Pine.LNX.4.21.0102081517320.786-100000@kenny.comstar.net>; from
              andy@DUSTMAN.NET on Thu, Feb 08, 2001 at 03:31:44PM -0500
References: <3A82D11F.3BF85AEB@stroeder.com>
            <Pine.LNX.4.21.0102081517320.786-100000@kenny.comstar.net>
Message-ID: <20010212001326.C282@madcap.dyndns.org>

On Thu, Feb 08, 2001 at 03:31:44PM -0500, Andy Dustman wrote:
> crypto.ciphers.privatekey.* would have various object classes which
> implement the various cipher modes (ECB, CBC, etc.); these could actually
> be factory functions.

M2Crypto took the easy way out and named the OpenSSL ciphers eponymously:
'bf_ecb', 'des_ede3_cbc', 'rc5_cfb', etc. ;-)


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




From ngps at POST1.COM  Sun Feb 11 17:08:07 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Mon, 12 Feb 2001 00:08:07 +0800
Subject: [PYTHON-CRYPTO] Hashing modules
In-Reply-To: <3A866B5E.FE9A7281@stroeder.com>; from michael@STROEDER.COM on
              Sun, Feb 11, 2001 at 11:37:18AM +0100
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
            <3A858534.7A01739D@stroeder.com>
            <20010211165406.A327@madcap.dyndns.org>
            <3A866B5E.FE9A7281@stroeder.com>
Message-ID: <20010212000807.B282@madcap.dyndns.org>

On Sun, Feb 11, 2001 at 11:37:18AM +0100, Michael Str?der wrote:
> So at least for a message digest function we almost agree on how it
> should be done. :-)

;-)

M2Crypto.EVP.HMAC presents the same interface, only difference being
that its __init__() accepts an additional parameter 'key':

>>> from M2Crypto.EVP import HMAC
>>> h1 = HMAC(key='key', 'sha1')
>>> h1.update('abc')
>>> h1.digest()
"O\320\262\025'n\361/+>L\216\312\302\201\024\230\266V\374"


M2Crypto.EVP.hmac() is a convenience function:

>>> from M2Crypto.EVP import hmac
>>> hmac('key', 'abc', 'sha1')
"O\320\262\025'n\361/+>L\216\312\302\201\024\230\266V\374"


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




From akuchlin at CNRI.RESTON.VA.US  Sun Feb 11 17:42:06 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Sun, 11 Feb 2001 11:42:06 -0500
Subject: [PYTHON-CRYPTO] Current state of the art?
In-Reply-To: <20010211235128.A282@madcap.dyndns.org>; from ngps@post1.com on
              Sun, Feb 11, 2001 at 11:51:28PM +0800
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <20010208235326.D1369@madcap.dyndns.org>
            <20010208113336.D2336@thrak.cnri.reston.va.us>
            <20010211235128.A282@madcap.dyndns.org>
Message-ID: <20010211114206.C24464@newcnri.cnri.reston.va.us>

On Sun, Feb 11, 2001 at 11:51:28PM +0800, Ng Pheng Siong wrote:
>It is indeed not sensible to plonk the whole thing into the Python
>core.

But is it worth removing the existing SSL support?  I think it is, because
it's extra code and isn't very good, but I don't think GvR agrees.  (On the
other hand, perhaps crappy SSL support is better than none at all.)

--amk




From michael at STROEDER.COM  Sun Feb 11 17:43:32 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Feb 2001 17:43:32 +0100
Subject: [PYTHON-CRYPTO] Current state of the art?
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <20010208235326.D1369@madcap.dyndns.org>
            <20010208113336.D2336@thrak.cnri.reston.va.us>
            <20010211235128.A282@madcap.dyndns.org>
            <20010211114206.C24464@newcnri.cnri.reston.va.us>
Message-ID: <3A86C134.D0A34DDA@stroeder.com>

Andrew Kuchling wrote:
>
> On Sun, Feb 11, 2001 at 11:51:28PM +0800, Ng Pheng Siong wrote:
> >It is indeed not sensible to plonk the whole thing into the Python
> >core.
>
> But is it worth removing the existing SSL support?  I think it is, because
> it's extra code and isn't very good, but I don't think GvR agrees.  (On the
> other hand, perhaps crappy SSL support is better than none at all.)

IMHO we should defer this until we come up with something better.

Ciao, Michael.




From michael at STROEDER.COM  Sun Feb 11 17:39:26 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Feb 2001 17:39:26 +0100
Subject: [PYTHON-CRYPTO] SIG thoughts.
References: <01020715041209.00694@mephit> <01020804580102.00689@mephit>
            <3A8275C5.FA0939C4@stroeder.com> <01020815470906.00689@mephit>
            <3A857E78.7A4BF93D@stroeder.com>
            <20010211112629.A24464@newcnri.cnri.reston.va.us>
Message-ID: <3A86C03E.63D48ADF@stroeder.com>

Andrew Kuchling wrote:
>
> I like the idea of a registry for crypto functions similar to
> the one for Unicode codecs.  Codecs have a flat namespace; do
> we want find_alg('MD5') or find_alg('MD5', type='hash') or
> find_hash_alg('MD5')?  In other words, do we
> have to know ahead of time that MD5 is a hash algorithm, or can
> we get an instance first without knowing what the algorithm
> actually does?

I vote for a flat name space represented by a string and a single
factory class/function returning a hash/cipher/protocol object.

JCE does it like this and OpenSSL uses a flat name space for the
algorithms either. We should re-use either the name space of JCE or
of OpenSSL.

> >Should be matter of local policy either defined in a global config
> >file by a system administrator knowing what to do or defined...
>
> Does someone want to write a proposed interface for the registration and
> search functions, and the config file?

I planned to write one. But first I will write down the
requirements.

Ciao, Michael.




From dan at eevolved.com  Sun Feb 11 17:46:57 2001
From: dan at eevolved.com (Dan Parisien)
Date: Sun, 11 Feb 2001 11:46:57 -0500
Subject: [PYTHON-CRYPTO] complete disagreement
In-Reply-To: <20010211235128.A282@madcap.dyndns.org>
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <20010208113336.D2336@thrak.cnri.reston.va.us>
            <20010211235128.A282@madcap.dyndns.org>
Message-ID: <01021111465701.03023@localhost.localdomain>

> It is indeed not sensible to plonk the whole thing into the Python
> core.
I agree. SSL is a module for providing SSL support. It don't think you should
try and make it any base at all for a crypto module (unless it's to strip
code out and repackage it)

I don't know about you guys, but what I've read so far seems to be about
complicating things. Think as a programmer using your module. Instead of
following XML or Unicode module tricks (with runtime registration of crypto
functions) you should look at the Python DB way of doing things. Instead of
building a super-module that handles everything, I think this SIG should
focus on writing standards to interfaces (look at the random module) and
making sure people adhere to them.

this code:
aes = crypto.find_alg("aes", *args)

please don't make me have to code that... Think of the following problem:
is it called aes or rijndael? You are not making it easier or more efficient.
Please reflect on this because I am the one who is going to use your code :)

peace,
Dan




From dan at eevolved.com  Sun Feb 11 17:56:13 2001
From: dan at eevolved.com (Dan Parisien)
Date: Sun, 11 Feb 2001 11:56:13 -0500
Subject: [PYTHON-CRYPTO] Hashing modules
In-Reply-To: <20010212000807.B282@madcap.dyndns.org>
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
            <3A866B5E.FE9A7281@stroeder.com>
            <20010212000807.B282@madcap.dyndns.org>
Message-ID: <01021111561302.03023@localhost.localdomain>

On Domingo 11 Fevereiro 2001 11:08, you wrote:

> M2Crypto.EVP.HMAC presents the same interface, only difference being
>
> that its __init__() accepts an additional parameter 'key':
and it should be

i would rather
from sha import sha
s = sha("some random text").digest()

than
from sha import sha
s = sha.new("some random text").digest()

it just seems cleaner...

peace,
Dan




From michael at STROEDER.COM  Sun Feb 11 19:44:54 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Feb 2001 19:44:54 +0100
Subject: [PYTHON-CRYPTO] complete disagreement
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <20010208113336.D2336@thrak.cnri.reston.va.us>
            <20010211235128.A282@madcap.dyndns.org>
            <01021111465701.03023@localhost.localdomain>
Message-ID: <3A86DDA6.7B62A129@stroeder.com>

Dan Parisien wrote:
>
> Instead of
> following XML or Unicode module tricks (with runtime registration of crypto
> functions) you should look at the Python DB way of doing things.

Can you give us a better example?

> Instead of building a super-module that handles everything,

I'm not in favourite of a super-module. I'm arguing against a super
module.

> this code:
> aes = crypto.find_alg("aes", *args)
>
> please don't make me have to code that... Think of the following problem:
> is it called aes or rijndael?

You always have to use a name, no matter if you want to use a module
or pass a parameter to a factory function/class to return an
instance.

> You are not making it easier or more efficient.

I think this will make it more flexible.

> Please reflect on this because I am the one who is going to use your code :)

Please reflect that my main motivation is not to design a new fancy
API. I'm trying to get a flexible API which solves my real-world
problems.

Example:

In http://www.web2ldap.de I'm using cryptographic algorithms for the
following functionality (all optional):
- Modules crypt, md5, sha for creating client-hashed password on
LDAP server
  (all modules optional, on Win32 crypt is not available at all)
- M2Crypto for having a SSL-enabled web server
- My own libs for parsing and displaying X.509 certs and CRLs

All required modules may or may not be present on a certain platform
=> all functionality is optional. I'm trying to leave up as much as
possible to the administrator which software he wants to install on
his platform for the functionality he/she wants. Therefore I have to
detect all modules. Mainly today done by:

try:
  import md5
except ImportError:
  md5present

Well, in a Python installation without md5 module but with M2Crypto
being present I could use the MD5 implementation provided by
M2Crypto. On Win32 one might install module fcrypt (pure Python
substitute for crypt)...

Now what's wrong with thinking about 1. a unified API and 2. a
unified locator mechanism for hashed, ciphers, protocols ?

Ciao, Michael.




From michael at STROEDER.COM  Sun Feb 11 20:23:38 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Feb 2001 20:23:38 +0100
Subject: [PYTHON-CRYPTO] Hashing modules
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
            <3A858534.7A01739D@stroeder.com>
            <20010211165406.A327@madcap.dyndns.org>
Message-ID: <3A86E6BA.74AFFA79@stroeder.com>

Ng Pheng Siong wrote:
>
> > Also we should try to implement a Codec-like StreamWriter() /
> > StreamReader() class for that like mentioned by M.-A. Lemburg on the
> > (deprecated) eGroups list.
>
> OpenSSL's stackable BIO interface is quite amenable to this.

I'm not in favour of seeing this SWIGed BIO stuff in a high-level
Python API. IMHO the Codec-like approach is more Pythonic. But an
implementation is free to use BIOs below that API. ;-)

Ciao, Michael.




From dan at eevolved.com  Sun Feb 11 20:26:05 2001
From: dan at eevolved.com (Dan Parisien)
Date: Sun, 11 Feb 2001 14:26:05 -0500
Subject: [PYTHON-CRYPTO] complete disagreement
In-Reply-To: <3A86DDA6.7B62A129@stroeder.com>
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <01021111465701.03023@localhost.localdomain>
            <3A86DDA6.7B62A129@stroeder.com>
Message-ID: <01021114260503.03023@localhost.localdomain>

On Domingo 11 Fevereiro 2001 13:44, you wrote:
> Dan Parisien wrote:
> > Instead of
> > following XML or Unicode module tricks (with runtime registration of
> > crypto functions) you should look at the Python DB way of doing things.
>
> Can you give us a better example?

Steal ideas from:

Random Number Generator Interface:
http://python.org/doc/current/lib/rng-objects.html

whichdb
http://python.org/doc/current/lib/module-whichdb.html

shelve
http://python.org/doc/current/lib/module-shelve.html

example shelve code:

import shelve
import bsddb

db = shelve.open("filename")
db["some key"] = "some value"

---
Each crypto module should adhere to a standard interface depending on what it
is (e.g. symmetric cypher, asymmetric cypher, msg digest, key excange, etc.)
If the cypher or other has options that are different than what is in the std
interface, then all is well. Just add new methods and they will ignore by any
wrapper module.

I'm only worried about syntax, ease of code and maximizing reuse of code (the
last one being the most important).

> Example:
>
> In http://www.web2ldap.de I'm using cryptographic algorithms for the
> following functionality (all optional):
> - Modules crypt, md5, sha for creating client-hashed password on
> LDAP server
>   (all modules optional, on Win32 crypt is not available at all)
> - M2Crypto for having a SSL-enabled web server
> - My own libs for parsing and displaying X.509 certs and CRLs

funky. I've actually used your software before when I did some research on
LDAP. It's a good idea.

> All required modules may or may not be present on a certain platform
> => all functionality is optional. I'm trying to leave up as much as
> possible to the administrator which software he wants to install on
> his platform for the functionality he/she wants. Therefore I have to
> detect all modules. Mainly today done by:
>
> try:
>   import md5
> except ImportError:
>   md5present

I see nothing wrong with this type of code. This is no different than a
.find_alg("md5") except you never had to
a) code the find_alg
b) import the finder module into the namespace

but I digress... a searching module, as long as it remains only that, is a
cool idea that would help you a lot.

> Well, in a Python installation without md5 module but with M2Crypto
> being present I could use the MD5 implementation provided by
> M2Crypto. On Win32 one might install module fcrypt (pure Python
> substitute for crypt)...

I wish people would just write portable code. Bryan Mongeau is busy porting
his AES to windows right now. It's very difficult :( I don't know why they
don't teach portable code practices somewhere...

> Now what's wrong with thinking about 1. a unified API and 2. a
> unified locator mechanism for hashed, ciphers, protocols ?

Absolutely nothing. As long as the API doesn't reach too broadly and stays
minimal, all is well. A line not coded is the best line of code you
can write.

peace,
Dan




From michael at STROEDER.COM  Sun Feb 11 21:02:09 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Feb 2001 21:02:09 +0100
Subject: [PYTHON-CRYPTO] complete disagreement
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au>
            <01021111465701.03023@localhost.localdomain>
            <3A86DDA6.7B62A129@stroeder.com>
            <01021114260503.03023@localhost.localdomain>
Message-ID: <3A86EFC1.9ADDB554@stroeder.com>

Dan Parisien wrote:
>
> Each crypto module should adhere to a standard interface depending on what it
> is (e.g. symmetric cypher, asymmetric cypher, msg digest, key excange, etc.)

Yes.

> > try:
> >   import md5
> > except ImportError:
> >   md5present
>
> I see nothing wrong with this type of code.

You have know all possible implementations of a certain
algorithm/protocol by module name in advance.

Ciao, Michael.




From dan at eevolved.com  Sun Feb 11 21:00:15 2001
From: dan at eevolved.com (Dan Parisien)
Date: Sun, 11 Feb 2001 15:00:15 -0500
Subject: [PYTHON-CRYPTO] complete disagreement
In-Reply-To: <3A86EFC1.9ADDB554@stroeder.com>
References: <3A81CCEC.9F3EF9A5@bizarsoftware.com.au> <01021114260503.03023@localhost.localdomain> <3A86EFC1.9ADDB554@stroeder.com>
Message-ID: <01021115001505.03023@localhost.localdomain>

On Domingo 11 Fevereiro 2001 15:02, you wrote:
> You have know all possible implementations of a certain
> algorithm/protocol by module name in advance.

No, only the ones you support.

But as I said, I digress. A central registry of sorts for python crypto 
modules would be helpful in your case. As long as it isn't necessary for a 
programmer needing only to test a specific algorithm.

Peace,
Dan




From dan at eevolved.com  Sun Feb 11 21:01:32 2001
From: dan at eevolved.com (Dan Parisien)
Date: Sun, 11 Feb 2001 15:01:32 -0500
Subject: [PYTHON-CRYPTO] complete disagreement (*forgot something*)
Message-ID: <01021115013206.03023@localhost.localdomain>

On Domingo 11 Fevereiro 2001 14:26, you wrote:
> example shelve code:
>
> import shelve
> import bsddb
>
> db = shelve.open("filename")
> db["some key"] = "some value"

Oops. I never explained this one...
Modules that themselves depend on other crypto modules (think key exchange,
authentication schemes, secure network transmission) should not have to
include cypher algorithms in their code. They should just import default
ones and make it easy to change them like shelve works with databases.

shelve will take any database (defaults to (g)dbm) but you can replace its
underlying db with any db adhering to the python db standards by importing
 it. simple 'n clean. Plus each crypto algorithm is only written once. It can
 be used alone or by another module that exploits the fact it adheres to the
 standard python interface.

peace,
Dan




From dan at eevolved.com  Sun Feb 11 23:44:26 2001
From: dan at eevolved.com (Dan Parisien)
Date: Sun, 11 Feb 2001 17:44:26 -0500
Subject: [PYTHON-CRYPTO] complete disagreement (*forgot something*)
In-Reply-To: <3A87124E.C7836FCE@stroeder.com>
References: <01021115013206.03023@localhost.localdomain>
            <3A87124E.C7836FCE@stroeder.com>
Message-ID: <01021117442600.01065@localhost.localdomain>

On Domingo 11 Fevereiro 2001 17:29, you wrote:
> Dan Parisien wrote:
> > Plus each crypto algorithm is only written once.
>
> Unfortunately not. Review the discussion OpenSSL vs. pure Python
> implementations. Both sides have valid arguments.

I have. I don't agree with a do-all crypto lib. It breaks modularity. I am
not a big fan of OpenSSL. I don't like the design and I don't like the
nomenclature. OpenSSL is a great product however, it should just not be used
as a base for python crypto. OpenSSL is for SSL interoperability in Python
scripts, it should not be a source for crypto routines (although as a last
resort I would see why you would want that).

If instead it was easy to add a crypto functionality to python, the code
would come. swig isn't hard and there are c optimized routines for most
public domain crypto functions anyways.

However I must reemphasize basing python crypto on standard interfaces like
the random interface and the database interface.

Dan




From akuchlin at CNRI.RESTON.VA.US  Mon Feb 12 02:57:39 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Sun, 11 Feb 2001 20:57:39 -0500
Subject: [PYTHON-CRYPTO] Hashing modules
In-Reply-To: <01021111561302.03023@localhost.localdomain>; from
              dan@eevolved.com on Sun, Feb 11, 2001 at 11:56:13AM -0500
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
            <3A866B5E.FE9A7281@stroeder.com>
            <20010212000807.B282@madcap.dyndns.org>
            <01021111561302.03023@localhost.localdomain>
Message-ID: <20010211205739.A25787@newcnri.cnri.reston.va.us>

On Sun, Feb 11, 2001 at 11:56:13AM -0500, Dan Parisien wrote:
>from sha import sha
>s = sha.new("some random text").digest()

Typo here: the first line would be just "import sha"; new() is a function in
the module 'sha', not a class method.

--amk




From dan at eevolved.com  Mon Feb 12 07:55:38 2001
From: dan at eevolved.com (Dan Parisien)
Date: Mon, 12 Feb 2001 01:55:38 -0500
Subject: [PYTHON-CRYPTO] Hashing modules
In-Reply-To: <20010211205739.A25787@newcnri.cnri.reston.va.us>
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
            <01021111561302.03023@localhost.localdomain>
            <20010211205739.A25787@newcnri.cnri.reston.va.us>
Message-ID: <01021201553800.01366@localhost.localdomain>

On Domingo 11 Fevereiro 2001 20:57, you wrote:
> On Sun, Feb 11, 2001 at 11:56:13AM -0500, Dan Parisien wrote:
> >from sha import sha
> >s = sha.new("some random text").digest()
>
> Typo here: the first line would be just "import sha"; new() is a function
> in the module 'sha', not a class method.
>
> --amk

I was trying to show that I think a 'new' method is superfluous. I don't know
why you didn't make it a class instantiation.
Maybe it has something to do with message digest algorithms that I don't
know. Is there some central shared information to all msg digests?

Dan




From michael at STROEDER.COM  Sun Feb 11 23:29:34 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 11 Feb 2001 23:29:34 +0100
Subject: [PYTHON-CRYPTO] complete disagreement (*forgot something*)
References: <01021115013206.03023@localhost.localdomain>
Message-ID: <3A87124E.C7836FCE@stroeder.com>

Dan Parisien wrote:
>
> Plus each crypto algorithm is only written once.

Unfortunately not. Review the discussion OpenSSL vs. pure Python
implementations. Both sides have valid arguments.

Ciao, Michael.




From akuchlin at CNRI.RESTON.VA.US  Mon Feb 12 17:30:59 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Mon, 12 Feb 2001 11:30:59 -0500
Subject: [PYTHON-CRYPTO] Hashing modules
In-Reply-To: <01021201553800.01366@localhost.localdomain>; from
              dan@eevolved.com on Mon, Feb 12, 2001 at 01:55:38AM -0500
References: <20010208164110.C2482@thrak.cnri.reston.va.us>
            <01021111561302.03023@localhost.localdomain>
            <20010211205739.A25787@newcnri.cnri.reston.va.us>
            <01021201553800.01366@localhost.localdomain>
Message-ID: <20010212113059.D3637@thrak.cnri.reston.va.us>

On Mon, Feb 12, 2001 at 01:55:38AM -0500, Dan Parisien wrote:
>I was trying to show that I think a 'new' method is superfluous. I don't know
>why you didn't make it a class instantiation.

It's hard to say now; to repeat, all this code was written when I was
younger and stupider.  Probably it's because the hash methods were a
pure C extension, and writing true classes in C would be tedious;
extensions almost always implement types.

--amk




From florian.buron at enst-bretagne.fr  Fri Feb  9 19:27:33 2001
From: florian.buron at enst-bretagne.fr (florian.buron at enst-bretagne.fr)
Date: Fri, 9 Feb 2001 19:27:33 +0100
Subject: pyCA help
References: <00f001c081ad$cb94dd30$7b00a8c0@shadax> <3A67EDE5.F37495AE@stroeder.com> <01a801c0830f$49b5e760$7b00a8c0@shadax> <3A69DE58.18D3F88E@stroeder.com> <02a001c0831b$867b3130$7b00a8c0@shadax> <3A69F3D5.CA049DE6@stroeder.com> <02c501c08322$49bb6b00$7b00a8c0@shadax> <3A6A0C63.81282D9B@stroeder.com>
Message-ID: <017c01c092c5$f8880410$7b00a8c0@shadax>

Hi!
Just wanted to give a little feedback on PyCA. i think it's a very good
piece of software.
I only add a slight problem genrating working Email certificate for MSIE and
Netscape, because it wouldn't export the certificate in the mail i sent.
I found why :

[ x509v3_ext_EmailCerts ]
keyUsage = nonRepudiation, digitalSignature ,   keyEncipherment  #don't
forget keyEncipherment

Hope it'll help.

Ah! and i wanted to know why Certificates requests have two parts...
What is the use for .ldif?  for Ldap repository i guess?

See you
Florian



----- Original Message -----
From: "Michael Str?der" <michael at stroeder.com>
To: <florian.buron at enst-bretagne.fr>
Sent: Saturday, January 20, 2001 11:08 PM
Subject: Re: pyCA help


> florian.buron at enst-bretagne.fr wrote:
> >
> > The files were well copied.
> >
> > but what does the -name refers to in "openssl ca -name [name of CA
> > section] -in [pathname of CSR.pem]"
> > it's the CA section in the openssl.cnf ?
> > like CA_EmailCerts ????
>
> Exactly. Yes.
>
> > i'll try that :
> >
> >  openssl ca -config /usr/local/pyca/conf/openssl.cnf -name
> > A_EmailCerts  -in
> > cert-req-PKCS10.EmailCerts.xWMnhL9RigdpMPU7S_zeIg\=\=.pem
>
> So in the mean time you should have created already your first cert.
> BTW: What do you plan to do with pyCA?
> There's not much user feedback. :-(
>
> > hope my linux box won't explode :)
>
> Depends on the RSA key you created and your CPUID. No just
> kidding... ;-)
>
> Ciao, Michael.





From michael at STROEDER.COM  Mon Feb 12 19:02:49 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Mon, 12 Feb 2001 19:02:49 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2721210202.981973753@[10.0.0.100]>
Message-ID: <3A882549.F705566B@stroeder.com>

PC Drew wrote:
>
> 3. For all those who are interested in actually having formal documents
> describing the "new" (whatever comes out of these discussions) crypto
> standard, can we first discuss high level goals and then go from there?

How about these...

* It has to be possible to register implementation modules by system
configuration to enable an application to use an algorithm or
protocol without knowing in advance which implementation modules are
present. The system's administrator specifies the order of the
registered implementation modules during install time.

* The application has to be able to choose a specific implementation
module at run-time by explicitly specifying an implementation's
name.

* An application which only needs a specific algorithm or protocol
should not have to import a big multi-purpose library.

* The above implies the need for unique identifiers for algorithms,
protocols and vendors throughout the whole class API.

* It has to be possible to define all parameters for algorithms or
protocols through the API. Reasonable defaults should be used
whereever possible.

* At least in debug mode an exception should be raised if the
application passes wrong types of parameters to class methods of the
API.

* Same API for same type of component (e.g. a key store should be
always looking the same to the application)

Ciao, Michael.




From drewpc at COLORADO.EDU  Mon Feb 12 18:29:13 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Mon, 12 Feb 2001 10:29:13 -0700
Subject: [PYTHON-CRYPTO] Comments
Message-ID: <2721210202.981973753@[10.0.0.100]>

Sorry, I've been out of the loop for a while and just got caught up on a
500 messages from this new list :)

>From the looks of the last set of emails, I'm starting to see things that I
don't like.  Here are my thoughts:

1.  Start from the bottom and work our way up.  Meaning start with the
design of how we want to implement hashes (for instance).  Well, they all
need to have this, that, and the other functionality.  Okay, not that we've
designed and encapsulated each category of encryption, let's move up a
level.  How do we want to access these functions for consumer use?  Well,
they can access the module directly (i.e. import hashes.MD5) or maybe it'd
be cool to write a "find" utility to find the best MD5 implementation.  The
point is that we want to give the user as _much_ flexibility as
possible...first, design a good base interface, _then_ design a really cool
"find" module.  That should _not_ be the main focus at this stage.  Then,
once we've done this stage, then maybe an abstraction layer would be good.
Once that's done, let's try to get some of this into the python distro,
then, let's try and change some other modules to use ours (i.e. change the
random module so that it uses our cryptographically strong RNG).  That's
the route I see.

2.  There was talk about how to handle different implementations of an
alogrithm (i.e. MD5 in pure python, c, c++, assembly, etc).  I think this
is  _fundamental_ for this library.  Again, we want to give the end user as
_many_ options as possible.  If portability is their main focus, not speed,
let them choose the pure python version.  If they want speed and won't put
the software on anything but an i386 box, let them choose the assembly one
if they want to.  The key is finding a way for each implementation to
co-exist with each other...what if we defined a "implemenation" variable
for each module...one that stores "assembly" or "python" or "java", etc?
Or, since we'll be controlling the implementations that get included with
our package, why not just do a package structure: "hashes.MD5.python.imp1",
then if another MD5 in python module comes around, and we want to include
both, then call it "hashes.MD5.python.imp2".

3. For all those who are interested in actually having formal documents
describing the "new" (whatever comes out of these discussions) crypto
standard, can we first discuss high level goals and then go from there?  I
think that would be more constructive at first than everyone giving their
$0.02 about whether or not they want a find function.

4.  All in all, I'm really happy with the discussions that have taken place
in the last month or so...it looks like we are pretty much in agreement
about these things and I think that we can do some really great stuff if we
get some sort of organization.

--
PC Drew

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




From drewpc at COLORADO.EDU  Tue Feb 13 05:43:55 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Mon, 12 Feb 2001 21:43:55 -0700
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
Message-ID: <982039435.3a88bb8b658a3@webmail.colorado.edu>

I took Dan's pseudo code and turned it into python code.  Let me know what I did
wrong and what should be changed.  Sometime tomorrow I'll also write up the
goals and post it on the same site.

Here's where you can download the tar file:

http://rtt.colorado.edu/~drewpc/

--
PC Drew




From bryan at EEVOLVED.COM  Tue Feb 13 06:38:31 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Tue, 13 Feb 2001 00:38:31 -0500
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
In-Reply-To: <982039435.3a88bb8b658a3@webmail.colorado.edu>
References: <982039435.3a88bb8b658a3@webmail.colorado.edu>
Message-ID: <01021300383101.00697@mephit>

On Monday 12 February 2001 23:43, you wrote:
> I took Dan's pseudo code and turned it into python code.  Let me know what
> I did wrong and what should be changed.  Sometime tomorrow I'll also write
> up the goals and post it on the same site.
>

Excellent initiative! Looks tight + nice doc strings! :)

Only two small issues got caught in my brain sieve, pertaining to
AsymmetricBase:

1 - __init__,encrypt and decrypt all accept an "_algorithm" parameter. This
is somewhat confusing to me. If child classes inherit from AsymmetricBase,
aren't they necessarily implementing an algorithm? Would child classes always
set "_algorithm" to their algorithm? If so, isn't that redundant?

2- sign and verify. It would seems that these methods could actually use an
"_algorithm"  parameter due to the fact that signing and verification can be
conducted many ways using a given keypair. Examples: DSA, Nyberg-Ruppel and
Massy-Omura. Oh, and the verify docstring needs to be changed (copy/paste
from sign method? :)

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

"Imagination is more important than knowledge."-- Einstein




From dan at eevolved.com  Tue Feb 13 03:54:38 2001
From: dan at eevolved.com (Dan Parisien)
Date: Mon, 12 Feb 2001 21:54:38 -0500
Subject: [PYTHON-CRYPTO] Comments
In-Reply-To: <2721210202.981973753@[10.0.0.100]>
References: <2721210202.981973753@[10.0.0.100]>
Message-ID: <01021221543804.01837@localhost.localdomain>

On Segunda 12 Fevereiro 2001 12:29, you wrote:

>(i.e. change the
> random module so that it uses our cryptographically strong RNG).  That's
> the route I see.

Yeah, shouldn't Yarrow be distributed with standard python? Or a
secure random number generator that adheres to the standard Python random
number
generator interface but uses a source of safe entropic data as a default seed.
(aka: yarrow or whatever is available on the OS like the /dev/*rand series)

> 2.  There was talk about how to handle different implementations of an
> alogrithm (i.e. MD5 in pure python, c, c++, assembly, etc).  I think this
> is  _fundamental_ for this library.

I agree.

>"hashes.MD5.python.imp2".

Close, but I think that is flawed. In the real world, there will not be
many implementations of one algorithm for the same programming language.
Good code is hard to find :) However, I agree with the idea.

Also to solve Michael's problem we could adhere to a intuitive standard of
directories & subdirectories that could be recursed into instead of having
a central crypto registry:

+ crypto/
    . __init__.py
    + hash/
        . __init__.py
        . MD5.py
        . SHA.py
        . SHA256.py
        . SHA256c.pyd / SHA256c.so

    + symmetric/
        . __init__.py
        . aes.py
        . rijndaelc.pyd / rijndaelc.so
        . twofish.py
        . twofishc.pyd / twofishc.so
        . DES.py

    + asymmetric/
        . __init__.py
        . RSA.py
        . eccc.pyd / eccc.so
        . ecc.py

    + random/
        . __init__.py
        . yarrow.py
        . yarrowc.pyd / yarrowc.so

The .pyd/.so's would be swigged c code, the .py's pure python implementations
(or
wrappers around the swig code).

Here's my proposal for an API; trying to keep the nomenclature as intuitive
as possible.

simplified APIs:

class Hash:
    """
    Hash module base class
    """
    def __init__(data=None)
        """
        Constructor

        . data : initial data
        """

    def update(data)
        """
        Update the digest with additional data
        """

    def digest()
        """
        Return the message digest
        """

class Symmetric:
    """
    Base class for symmetric cipher

    Important Attributes:

    . key : Key to use for encryption/decryption
    """
    def __init__(key=None)
        """
        Constructor

        . key : (optional) key to use for encryption/decryption

        Raises EncryptionKeyError if the key is not of a valid size, etc
        """

    def keygen(size=None)
        """
        Generate a symmetric encryption key using a default (and replaceable)
            secure prng.

        . size : (optional) bit size of the key. If None, use a reasonable
            default. (I think bit size is more intuitive considering it is
            the de-facto way of refering to key sizes)

        Raises KeySizeError if the size is invalid
        """

    def encrypt(data, key=None)
        """
        Encrypt data.

        . data : Data to encrypt

        . key : (optional) use this key to encrypt data. If key is omitted,
            use value stored in attribute `key`.

        Raises EncryptionKeyError if the key is not valid or not set
        """

    def decrypt(data, key=None)
        """
        Return decrypted data.

        . data : Data to decrypt

        . key : (optional) same as the optional key in .encrypt

        Raises EncryptionKeyError if the key is not valid or not set
        """

class Asymmetric:
    """
    Base class for asymmetric ciphers

    Important Attributes:

    . privateKey : Private key

    . publicKey : Public key

    . encryptKey : Remote user's public key
    """
    def __init__(privatekey=None, publickey=None, encryptkey=None)
        """
        Constructor

        . privatekey : Default value for attribute privateKey

        . publickey :  Default value for attribute publicKey

        . encryptkey : Default value for attribute encryptKey

        Raises EncryptionKeyError if any of the keys are not valid.
        """

    def keypair(self, size=None):
        """
        Return generated [publicKey, privateKey]. Uses a default (and,
            as always, replaceable) secure prng.

        . size : bit size of the key. If not set, use a reasonable
            default

        Raises KeySizeError if the key size is not one of the supported
            key sizes
        """

    def encrypt(data, key=None):
        """
        Return encrypted data.

        . data : data to encrypt

        . key : key to use for encryption. If None, use attribute
            encryptKey.

        Raises EncryptionKeyError if the key is not valid or it is
            not set
        """

    def decrypt(data, key=None):
        """
        Return decrypted data.

        . data : data to decrypt

        . key : key to use for decryption. If None, use attribute
            privateKey.

        Raises EncryptionKeyError if the decyption key is not valid
            or it is not set
        """

    def sign(data, privkey=None)
        """
        Return signature.

        . key : key used to sign the data. If not set, attribute privateKey
            is used.

        Raises EncryptionKeyError if the private key is not valid or it is
            not set.
        """

    def verify(data, signature, pubkey=None)
        """
        If the signature is valid return 1, else return 0

        . data : Data that was signed

        . signature : signature to verify

        . pubkey : Remote user's public key. If None, verify with attribute
            encryptKey

        Raises EncryptionKeyError if the public key is not valid or it is not
            set anywhere.
        """

What do you guys think?

Dan




From drewpc at COLORADO.EDU  Tue Feb 13 04:33:36 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Mon, 12 Feb 2001 20:33:36 -0700
Subject: [PYTHON-CRYPTO] Comments
In-Reply-To: <01021221543804.01837@localhost.localdomain>
Message-ID: <2757473172.982010016@[10.0.0.100]>

--On Monday, February 12, 2001 9:54 PM -0500 Dan Parisien
<dan at eevolved.com> wrote:

> On Segunda 12 Fevereiro 2001 12:29, you wrote:
>
>> (i.e. change the
>> random module so that it uses our cryptographically strong RNG).  That's
>> the route I see.
>
> Yeah, shouldn't Yarrow be distributed with standard python? Or a
> secure random number generator that adheres to the standard Python random
> number
> generator interface but uses a source of safe entropic data as a default
> seed. (aka: yarrow or whatever is available on the OS like the /dev/*rand
> series)
>

I think so.  Anyone object?  I think we should lobby for that when we get
things up and running.

>> 2.  There was talk about how to handle different implementations of an
>> alogrithm (i.e. MD5 in pure python, c, c++, assembly, etc).  I think this
>> is  _fundamental_ for this library.
>
> I agree.
>
>> "hashes.MD5.python.imp2".
>
> Close, but I think that is flawed. In the real world, there will not be
> many implementations of one algorithm for the same programming language.
> Good code is hard to find :) However, I agree with the idea.
>

I know that's flawed, I was basically just showing a directory structure
way of doing things.

> Also to solve Michael's problem we could adhere to a intuitive standard of
> directories & subdirectories that could be recursed into instead of having
> a central crypto registry:
>
> + crypto/
>     . __init__.py
>     + hash/
>         . __init__.py
>         . MD5.py
>         . SHA.py
>         . SHA256.py
>         . SHA256c.pyd / SHA256c.so
>
>     + symmetric/
>         . __init__.py
>         . aes.py
>         . rijndaelc.pyd / rijndaelc.so
>         . twofish.py
>         . twofishc.pyd / twofishc.so
>         . DES.py
>
>     + asymmetric/
>         . __init__.py
>         . RSA.py
>         . eccc.pyd / eccc.so
>         . ecc.py
>
>     + random/
>         . __init__.py
>         . yarrow.py
>         . yarrowc.pyd / yarrowc.so
>
> The .pyd/.so's would be swigged c code, the .py's pure python
> implementations (or
> wrappers around the swig code).
>

I agree, looks great to me.

> Here's my proposal for an API; trying to keep the nomenclature as
> intuitive as possible.
>
> simplified APIs:
>
> class Hash:
>     """
>     Hash module base class
>     """
>     def __init__(data=None)
>         """
>         Constructor
>
>         . data : initial data
>         """
>
>     def update(data)
>         """
>         Update the digest with additional data
>         """
>
>     def digest()
>         """
>         Return the message digest
>         """
>

Looks good to me.  It'd be nice to have a variable that stores the size of
the digest and the number of rounds.  If this doesn't apply to the specific
algorithm, then the round is set to 1 and the digest size is set to the
digest size that it uses.  As described in the docs for amkCrypto, HAVAL
suports variable sized digests and mulitple rounds.

> class Symmetric:
>     """
>     Base class for symmetric cipher
>
>     Important Attributes:
>
>     . key : Key to use for encryption/decryption
>     """
>     def __init__(key=None)
>         """
>         Constructor
>
>         . key : (optional) key to use for encryption/decryption
>
>         Raises EncryptionKeyError if the key is not of a valid size, etc
>         """
>
>     def keygen(size=None)
>         """
>         Generate a symmetric encryption key using a default (and
>         replaceable) secure prng.
>
>         . size : (optional) bit size of the key. If None, use a reasonable
>             default. (I think bit size is more intuitive considering it is
>             the de-facto way of refering to key sizes)
>
>         Raises KeySizeError if the size is invalid
>         """
>
>     def encrypt(data, key=None)
>         """
>         Encrypt data.
>
>         . data : Data to encrypt
>
>         . key : (optional) use this key to encrypt data. If key is
>         omitted, use value stored in attribute `key`.
>
>         Raises EncryptionKeyError if the key is not valid or not set
>         """
>
>     def decrypt(data, key=None)
>         """
>         Return decrypted data.
>
>         . data : Data to decrypt
>
>         . key : (optional) same as the optional key in .encrypt
>
>         Raises EncryptionKeyError if the key is not valid or not set
>         """
>

Again, it'd be nice to be able to change the block size and the number of
rounds.

> class Asymmetric:
>     """
>     Base class for asymmetric ciphers
>
>     Important Attributes:
>
>     . privateKey : Private key
>
>     . publicKey : Public key
>
>     . encryptKey : Remote user's public key
>     """
>     def __init__(privatekey=None, publickey=None, encryptkey=None)
>         """
>         Constructor
>
>         . privatekey : Default value for attribute privateKey
>
>         . publickey :  Default value for attribute publicKey
>
>         . encryptkey : Default value for attribute encryptKey
>
>         Raises EncryptionKeyError if any of the keys are not valid.
>         """
>
>     def keypair(self, size=None):
>         """
>         Return generated [publicKey, privateKey]. Uses a default (and,
>             as always, replaceable) secure prng.
>
>         . size : bit size of the key. If not set, use a reasonable
>             default
>
>         Raises KeySizeError if the key size is not one of the supported
>             key sizes
>         """
>
>     def encrypt(data, key=None):
>         """
>         Return encrypted data.
>
>         . data : data to encrypt
>
>         . key : key to use for encryption. If None, use attribute
>             encryptKey.
>
>         Raises EncryptionKeyError if the key is not valid or it is
>             not set
>         """
>
>     def decrypt(data, key=None):
>         """
>         Return decrypted data.
>
>         . data : data to decrypt
>
>         . key : key to use for decryption. If None, use attribute
>             privateKey.
>
>         Raises EncryptionKeyError if the decyption key is not valid
>             or it is not set
>         """
>
>     def sign(data, privkey=None)
>         """
>         Return signature.
>
>         . key : key used to sign the data. If not set, attribute
>         privateKey is used.
>
>         Raises EncryptionKeyError if the private key is not valid or it is
>             not set.
>         """
>
>     def verify(data, signature, pubkey=None)
>         """
>         If the signature is valid return 1, else return 0
>
>         . data : Data that was signed
>
>         . signature : signature to verify
>
>         . pubkey : Remote user's public key. If None, verify with
>         attribute encryptKey
>
>         Raises EncryptionKeyError if the public key is not valid or it is
>         not set anywhere.
>         """
>

This part looks good too...I'm not sure, but can the user decide which
symmetric algorithm to use with an asymmetric algorithm?  I think so...if
so, there needs to be a variable that defines this.  Should it be an
instance of one of the symmetric modules or should it just be the name of
the module?

> What do you guys think?
>
> Dan

I think it's a great start!  I'll take this initial pseudo code and come up
with some actual Python code that matches this and post it on the web.  All
who care can download it and make comments.

--
PC Drew

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




From richard at BIZARSOFTWARE.COM.AU  Tue Feb 13 04:42:52 2001
From: richard at BIZARSOFTWARE.COM.AU (Richard Jones)
Date: Tue, 13 Feb 2001 14:42:52 +1100
Subject: [PYTHON-CRYPTO] Comments
References: <2757473172.982010016@[10.0.0.100]>
Message-ID: <3A88AD3C.1C9F6DCA@bizarsoftware.com.au>

PC Drew wrote:
> --On Monday, February 12, 2001 9:54 PM -0500 Dan Parisien
> <dan at eevolved.com> wrote:
> > Yeah, shouldn't Yarrow be distributed with standard python? Or a
> > secure random number generator that adheres to the standard Python random
> > number
> > generator interface but uses a source of safe entropic data as a default
> > seed. (aka: yarrow or whatever is available on the OS like the /dev/*rand
> > series)
>
> I think so.  Anyone object?  I think we should lobby for that when we get
> things up and running.

You could punt the idea to python-dev... I thought I saw something
somewhere talking about an improved random module going into python 2.1,
but I can't find a reference at the moment.


> > class Symmetric:
> >     """
> >     Base class for symmetric cipher
> >
> >     Important Attributes:
> >
> >     . key : Key to use for encryption/decryption
> >     """
> >     def __init__(key=None)
> >         """
> >         Constructor
> >
> >         . key : (optional) key to use for encryption/decryption
> >
> >         Raises EncryptionKeyError if the key is not of a valid size, etc
> >         """
> >
> >     def keygen(size=None)
> >         """
> >         Generate a symmetric encryption key using a default (and
> >         replaceable) secure prng.
> >
> >         . size : (optional) bit size of the key. If None, use a reasonable
> >             default. (I think bit size is more intuitive considering it is
> >             the de-facto way of refering to key sizes)
> >
> >         Raises KeySizeError if the size is invalid

   As purely a minor style issue, I'd rather see the actual default key
size in the method signature, rather than None...


> This part looks good too...I'm not sure, but can the user decide which
> symmetric algorithm to use with an asymmetric algorithm?  I think so...if
> so, there needs to be a variable that defines this.  Should it be an
> instance of one of the symmetric modules or should it just be the name of
> the module?

   I'd go with an instance - that way the implementation is completely open
to us stuffing any old instance object into the algorithm. Just define the
interface.


> I think it's a great start!  I'll take this initial pseudo code and come up
> with some actual Python code that matches this and post it on the web.  All
> who care can download it and make comments.

   Yay! :)



      Richard

--
Richard Jones
richard at bizarsoftware.com.au
Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)




From dan at eevolved.com  Tue Feb 13 06:19:28 2001
From: dan at eevolved.com (Dan Parisien)
Date: Tue, 13 Feb 2001 00:19:28 -0500
Subject: [PYTHON-CRYPTO] Comments
In-Reply-To: <2757473172.982010016@[10.0.0.100]>
References: <2757473172.982010016@[10.0.0.100]>
Message-ID: <01021300192801.09307@localhost.localdomain>

On Segunda 12 Fevereiro 2001 22:33, you wrote:

> This part looks good too...I'm not sure, but can the user decide which
> symmetric algorithm to use with an asymmetric algorithm?

Why are you trying to mix symmetric and asymmetric algorithms? If you want to
emulate PGP or a TLS that exchanges a symmetric key with an asymmetric
algorithm, then maybe we should define an API for that sort of crypto-system
as well... I don't think it would be hard.
That object could use instances of API-standards-adhering crypto classes.
Then that management object could be completely independant of underlying
crypto code.

Dan




From dan at eevolved.com  Tue Feb 13 02:37:15 2001
From: dan at eevolved.com (Dan Parisien)
Date: Mon, 12 Feb 2001 20:37:15 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A882549.F705566B@stroeder.com>
References: <2721210202.981973753@[10.0.0.100]> <3A882549.F705566B@stroeder.com>
Message-ID: <01021220371503.01837@localhost.localdomain>

On Segunda 12 Fevereiro 2001 13:02, you wrote:

> * It has to be possible to register implementation modules by system
> configuration to enable an application to use an algorithm or
> protocol without knowing in advance which implementation modules are
> present. The system's administrator specifies the order of the
> registered implementation modules during install time.

If we do it for python crypto, why not do it for all python modules? I also
don't see how this is feasible considering the only implementation idea I
have involves making the python crypto coder register his module with some
central registry (extreme yuck)...

> * The application has to be able to choose a specific implementation
> module at run-time by explicitly specifying an implementation's
> name.

As I said before, people may chose a name different that you are expecting
e.g. 'AES' or 'Rijndael'?

> * An application which only needs a specific algorithm or protocol
> should not have to import a big multi-purpose library.

This is important.

> * The above implies the need for unique identifiers for algorithms,
> protocols and vendors throughout the whole class API.

A nice comprehensible directory structure would suffice

> * It has to be possible to define all parameters for algorithms or
> protocols through the API. Reasonable defaults should be used
> whereever possible.

I like the whramdom style of chosing values based on time if seed x, y and z
are not explicitely chosen. I also like shelve's use of defaults when it
comes to using dbm (although I don't like dbm, I like the fact that if you
don't care you don't have to care ;)

> * At least in debug mode an exception should be raised if the
> application passes wrong types of parameters to class methods of the
> API.
I think it should always be raised.  As long as the standard methods adhere
to standard parameter calls, everything should be fine. Classes requiring
extra functionality should extend to the API by adding methods and chosing
reasonable defaults if those special methods are not called (e.g. rounds and
keysize)

> * Same API for same type of component (e.g. a key store should be
> always looking the same to the application)
Agreed.

Dan




From drewpc at COLORADO.EDU  Tue Feb 13 04:10:10 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Mon, 12 Feb 2001 20:10:10 -0700
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A882549.F705566B@stroeder.com>
Message-ID: <2756067462.982008610@[10.0.0.100]>

--On Monday, February 12, 2001 7:02 PM +0100 Michael Str?der <michael at STROEDER.COM> wrote:

> * It has to be possible to register implementation modules by system
> configuration to enable an application to use an algorithm or
> protocol without knowing in advance which implementation modules are
> present. The system's administrator specifies the order of the
> registered implementation modules during install time.
>

I'm not sure how I feel about this.  I think this could be really useful, but also really complex.  The question then becomes, is it worth the complexity?  Either way, I don't think we should focus on that right now. I think we should start building an API and then add on this feature.

> * The application has to be able to choose a specific implementation
> module at run-time by explicitly specifying an implementation's
> name.
>

correct.

> * An application which only needs a specific algorithm or protocol
> should not have to import a big multi-purpose library.
>

great idea.

> * The above implies the need for unique identifiers for algorithms,
> protocols and vendors throughout the whole class API.
>

correct.

> * It has to be possible to define all parameters for algorithms or
> protocols through the API. Reasonable defaults should be used
> whereever possible.
>

this is a must.  the user should be able to do anything or nothing.

> * At least in debug mode an exception should be raised if the
> application passes wrong types of parameters to class methods of the
> API.
>

I think this should be done all of the time, not just in debug mode.  I'm curious, why do you say "at least in debug mode"?  Is there an example that 
you have in mind where you wouldn't want to know this information?

> * Same API for same type of component (e.g. a key store should be
> always looking the same to the application)

correct.

Here are some more goals that I would like to see come out of this:

* Build a cryptographically strong PRNG that can be freely distributed with 
the Python package, that also works with our crypto package.

* Handle key exchanges and have a key "ring" that is available to all of the algorithms.  The key "ring" would be a seperate module that checks to make sure file permissions are "secure" and reads and writes keys.

* (this elaborates on one of the goals from above) Let the user access all points of the library.  If they want to deal directly with the algorithm, let them.  If they want to encrypt an email using PGP, let them (i.e. handle the key management and the encryption, etc).

* Have as many algorithms as possible, maybe starting off with pure python implementations and moving to C/C++ in due time.  The reason that I think we should go from Python -> C/C++ as opposed to the other way is because by 
using Python to first implement the algorithm, we can a) get it up and running more quickly and on more platforms and b) because it provides a good reference implementation, rather than a really fast implementation that would come later.  Remember, do it right first...then make it really fast.

* Provide an easy installation.  Ever tried installing GNOME or X from scratch?  You have to get about 500,000 packages and install them all.  No fun.  I want to provide as much as possible (if not everything that's needed) in one file.  When someone downloads this, they should "configure; make; make install" and it a) works every time and b) installs everything that's needed.  If that means including other peoples packages with ours...so be it.  I haven't installed the UNIX version of the PyXML package, but the windows install is great.  That's exacly what I think is necessary.

* Keep updated documentation on the web (hopefully python.org) along with links to more detailed information about each of the algorithms.

* Release every 6 months.  This should be bug fixes, new algorithms, new features, it doesn't matter.  Release good and release often.

* Audit other people's code.  Let's take a lesson from the OpenBSD guys and 
do things right.

What are everyone's thoughts on these new goals?

--
PC Drew

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




From jeremy at alum.mit.edu  Tue Feb 13 03:53:34 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Mon, 12 Feb 2001 21:53:34 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A88AABB.7BFFA35A@caveosystems.com>
References: <2756067462.982008610@[10.0.0.100]>
            <3A88AABB.7BFFA35A@caveosystems.com>
Message-ID: <14984.41390.990917.404562@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "R$" == Rich Salz <rsalz at CAVEOSYSTEMS.COM> writes:

  >> > * At least in debug mode an exception should be raised if the
  >> > application passes wrong types of parameters to class methods
  >> > of the API.
  >> I think this should be done all of the time, not just in debug
  >> mode.  I'm curious, why do you say "at least in debug mode"?  Is
  >> there an example that you have in mind where you wouldn't want to
  >> know this information?

  R$> Sure.  Once my code is written I do not want to pay the overhead
  R$> of run-time typechecking.

I agree.  The Python standard library does very minimal
type-checking.  Instead, the philosophy is that if a user supplies an
argument of the wrong type, an exception will be raised when the value
is actually used.  In many cases, the traceback is as clear as one
generated by an explicit type check.

Jeremy




From rsalz at CAVEOSYSTEMS.COM  Tue Feb 13 04:32:11 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Mon, 12 Feb 2001 22:32:11 -0500
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
Message-ID: <3A88AABB.7BFFA35A@caveosystems.com>

> I'm not sure how I feel about this.  I think this could be really useful, but also really complex.

I'm repeating myself. :)  It is not all that complex, and PyXML has done
it.  I agree with Michael that this must be a "Day One" requirement.

> > * The above implies the need for unique identifiers for algorithms,
> > protocols and vendors throughout the whole class API.

Well, we already have OID's for algorithms, and mechanisms.

> > * At least in debug mode an exception should be raised if the
> > application passes wrong types of parameters to class methods of the
> > API.
> I think this should be done all of the time, not just in debug mode.  I'm curious, why do you say "at least in debug mode"?  Is there an example that
> you have in mind where you wouldn't want to know this information?

Sure.  Once my code is written I do not want to pay the overhead of
run-time typechecking.

> * Handle key exchanges and have a key "ring" that is available to all of the algorithms.

Keyring is an interesting idea.  I'm not sure how important it is for
the first release. On the other hand, doing it right will overlap other
areas, particularly if you want to implement it on top of PKCS#11,
CryptoAPI, etc.

>  The key "ring" would be a seperate module that checks to make sure file permissions are "secure" and reads and writes keys.

I'm not sure about this.  How are the keys protected?  On a windows
platform, for example?

        /r$




From drewpc at COLORADO.EDU  Tue Feb 13 04:37:29 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Mon, 12 Feb 2001 20:37:29 -0700
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A88AABB.7BFFA35A@caveosystems.com>
Message-ID: <2757706492.982010249@[10.0.0.100]>

--On Monday, February 12, 2001 10:32 PM -0500 Rich Salz
<rsalz at CAVEOSYSTEMS.COM> wrote:

>> I'm not sure how I feel about this.  I think this could be really
>> useful, but also really complex.
>
> I'm repeating myself. :)  It is not all that complex, and PyXML has done
> it.  I agree with Michael that this must be a "Day One" requirement.
>

alright, I'm fine with that!

>> > * The above implies the need for unique identifiers for algorithms,
>> > protocols and vendors throughout the whole class API.
>
> Well, we already have OID's for algorithms, and mechanisms.
>
>> > * At least in debug mode an exception should be raised if the
>> > application passes wrong types of parameters to class methods of the
>> > API.
>> I think this should be done all of the time, not just in debug mode.
>> I'm curious, why do you say "at least in debug mode"?  Is there an
>> example that you have in mind where you wouldn't want to know this
>> information?
>
> Sure.  Once my code is written I do not want to pay the overhead of
> run-time typechecking.
>

good point.  Are you talking like a "if DEBUG:" type thing?  If so, would
it be okay to set DEBUG = true by default so that people have to
consciously turn it off, knowing full well that it will not check for
certain things?

>> * Handle key exchanges and have a key "ring" that is available to all of
>> the algorithms.
>
> Keyring is an interesting idea.  I'm not sure how important it is for
> the first release. On the other hand, doing it right will overlap other
> areas, particularly if you want to implement it on top of PKCS#11,
> CryptoAPI, etc.

I agree that it's not important for the first release.  I think it would be
nice later on though.

>
>>  The key "ring" would be a seperate module that checks to make sure file
>>  permissions are "secure" and reads and writes keys.
>
> I'm not sure about this.  How are the keys protected?  On a windows
> platform, for example?
>

How are they protected right now on windows?  I dunno!

--
PC Drew

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




From richard at BIZARSOFTWARE.COM.AU  Tue Feb 13 04:45:23 2001
From: richard at BIZARSOFTWARE.COM.AU (Richard Jones)
Date: Tue, 13 Feb 2001 14:45:23 +1100
Subject: [PYTHON-CRYPTO] Requirements
References: <2757706492.982010249@[10.0.0.100]>
Message-ID: <3A88ADD3.8DC7EC0F@bizarsoftware.com.au>

PC Drew wrote:
> --On Monday, February 12, 2001 10:32 PM -0500 Rich Salz
> <rsalz at CAVEOSYSTEMS.COM> wrote:
> >
> > Sure.  Once my code is written I do not want to pay the overhead of
> > run-time typechecking.
> >
>
> good point.  Are you talking like a "if DEBUG:" type thing?  If so, would
> it be okay to set DEBUG = true by default so that people have to
> consciously turn it off, knowing full well that it will not check for
> certain things?

   Python has __debug__, assert and the optimisation mode for just this
purpose...


      Richard

--
Richard Jones
richard at bizarsoftware.com.au
Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)




From akuchlin at CNRI.RESTON.VA.US  Tue Feb 13 04:43:08 2001
From: akuchlin at CNRI.RESTON.VA.US (Andrew Kuchling)
Date: Mon, 12 Feb 2001 22:43:08 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <01021220371503.01837@localhost.localdomain>; from
              dan@eevolved.com on Mon, Feb 12, 2001 at 08:37:15PM -0500
References: <2721210202.981973753@[10.0.0.100]>
            <3A882549.F705566B@stroeder.com>
            <01021220371503.01837@localhost.localdomain>
Message-ID: <20010212224308.A21640@newcnri.cnri.reston.va.us>

On Mon, Feb 12, 2001 at 08:37:15PM -0500, Dan Parisien wrote:
>If we do it for python crypto, why not do it for all python modules? I also
>don't see how this is feasible considering the only implementation idea I
>have involves making the python crypto coder register his module with some
>central registry (extreme yuck)...

Not necessarily; consider Unicode codecs again.  The codecs module has a
register() function for adding a search function.  When you request a codec,
all the registered search functions are called until one returns a match. In
Python 2.1, .pth files can contain code, so a .pth file installed by the
package could automatically register a new search function.

--amk




From stevena at NEOSYNAPSE.NET  Mon Feb 12 19:53:02 2001
From: stevena at NEOSYNAPSE.NET (Steven D. Arnold)
Date: Mon, 12 Feb 2001 13:53:02 -0500
Subject: [PYTHON-CRYPTO] ANN: Pure-Python Encryption Tools
Message-ID: <5.0.2.1.2.20010212133300.03a64ae0@phear.dementian.com>

Neosynapse Consulting Group announces the release of pure-Python encryption
tools.  These modules may be used as building blocks for programs that need
cryptographic services.  The modules are released as open-source software
under the Neosynapse Artistic License.

So far, we have an implementation of IDEA and a module for handling modular
arithmetic.  Coming soon, look for modules to handle problems relating to
prime numbers, a Blowfish module and an RSA public-key cryptography module.

Interested people are welcomed to participate in the development of these
open-source modules.  The software may be downloaded at:

         http://www.neosynapse.net/free_encrypt.htm


--
Steven D. Arnold                   President, Neosynapse Consulting Group
stevena at neosynapse.net                          http://www.neosynapse.net




From michael at STROEDER.COM  Tue Feb 13 08:16:41 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Feb 2001 08:16:41 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2757706492.982010249@[10.0.0.100]>
Message-ID: <3A88DF59.365186EA@stroeder.com>

PC Drew wrote:
>
> good point.  Are you talking like a "if DEBUG:" type thing?  If so, would
> it be okay to set DEBUG = true by default so that people have to
> consciously turn it off, knowing full well that it will not check for
> certain things?

Have a look at:
http://www.python.org/doc/current/ref/assert.html#l2h-339

Ciao, Michael.




From michael at STROEDER.COM  Tue Feb 13 07:54:53 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Feb 2001 07:54:53 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <3A88AABB.7BFFA35A@caveosystems.com>
            <14984.41390.990917.404562@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <3A88DA3D.19AF95E1@stroeder.com>

Jeremy Hylton wrote:
>
> >>>>> "R$" == Rich Salz <rsalz at CAVEOSYSTEMS.COM> writes:
>
>   >> > * At least in debug mode an exception should be raised if the
>   >> > application passes wrong types of parameters to class methods
>   >> > of the API.
>   >> I think this should be done all of the time, not just in debug
>   >> mode.
>
>   R$> Once my code is written I do not want to pay the overhead
>   R$> of run-time typechecking.
>
> I agree.  The Python standard library does very minimal
> type-checking.  Instead, the philosophy is that if a user supplies an
> argument of the wrong type, an exception will be raised when the value
> is actually used.  In many cases, the traceback is as clear as one
> generated by an explicit type check.

Just two notes:

1. An API where the application is independent of a specific
implementation (dynamic registration) makes it possible to have a
debug module and a more efficient module for production use.

2. Python tracebacks are most times sufficient but not always.
Jeremy, think of some deeply nested ASN.1 structures mapped to
deeply nested Python classes which almost have the same attributes.
Getting some experience in this field was time-consuming... ;-)

Ciao, Michael.




From michael at STROEDER.COM  Tue Feb 13 08:15:40 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Feb 2001 08:15:40 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <3A88AABB.7BFFA35A@caveosystems.com>
Message-ID: <3A88DF1C.594EEC24@stroeder.com>

Rich Salz wrote:
>
> > > * The above implies the need for unique identifiers for algorithms,
> > > protocols and vendors throughout the whole class API.
>
> Well, we already have OID's for algorithms, and mechanisms.

Well, I thought about OIDs. I just wondered if some people here are
too scared about numeroids.

Maybe we can mandate that implementations have to handle all
identifiers as string representations of numeric OIDs internally but
have to be able to resolve user-friendly aliases in the API.

> > * Handle key exchanges and have a key "ring" that is available to all of the
> > algorithms.
>
> Keyring is an interesting idea.  I'm not sure how important it is for
> the first release. On the other hand, doing it right will overlap other
> areas, particularly if you want to implement it on top of PKCS#11,
> CryptoAPI, etc.

Well, I'm concerned to get a module which enables application
developers to write secure code. Key stores (key rings) are a very
critical thing when developing crypto-applications. If we have a
class API for key stores we would have a nice abstraction layer for
platform dependent stuff or different security levels. During
run-time the system administrator or application chooses the
preferred type of key store needed for achieving a specific security
level.

I agree it's definitely not trivial.

> >  The key "ring" would be a seperate module that checks to make sure file
> > permissions are "secure" and reads and writes keys.
>
> I'm not sure about this.  How are the keys protected?  On a windows
> platform, for example?

This would be up to the key store implementation, off course. ;-)

Ciao, Michael (very abstract today ;-).




From michael at STROEDER.COM  Tue Feb 13 08:05:20 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Tue, 13 Feb 2001 08:05:20 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
Message-ID: <3A88DCB0.7A0EE57D@stroeder.com>

PC Drew wrote:
> 
> --On Monday, February 12, 2001 7:02 PM +0100 Michael Str?der 
> <michael at STROEDER.COM> wrote:
> 
> > * It has to be possible to register implementation modules by system
> > configuration to enable an application to use an algorithm or
> > protocol without knowing in advance which implementation modules are
> > present.
> 
> I'm not sure how I feel about this.  I think this could be really useful, but 
> also really complex.

I don't think it's too complex.

> The question then becomes, is it worth the complexity?

For me it's the main motivation for discussing such an API.

> * Build a cryptographically strong PRNG that can be freely distributed with
> the Python package, that also works with our crypto package.

I forgot to mention that the components for which the requirements
were written are:
- algorithms
- random number generators
- protocols
and...

> * Handle key exchanges and have a key "ring"

- key stores

> If they want to deal directly with the algorithm, let them.  If they
> want to encrypt an email using PGP, let them

Exactly. We're getting closer to it.

> * Have as many algorithms as possible, maybe starting off with
> pure python implementations and moving to C/C++ in due time.  The
> reason that I think we should go from Python -> C/C++ as opposed to
> the other way is because by
> using Python to first implement the algorithm, we can a) get it up
> and running more quickly and on more platforms and b) because it provides
> a good reference implementation, rather than a really fast implementation
> that would come later.  Remember, do it right first...then make it really fast.

Well, that's your point of view. I agree that producing correct code
is the main goal. But I agree with the people who are in favour with
OpenSSL: It's already a very good implementation (although written
in C ;-) and the code was reviewed and fully understood by many
people. If I would have to choose something for secure production
use I would stick to this.

> * Provide an easy installation.

Yes.

> I want to provide as much as possible (if not everything that's
> needed) in one file.  When someone downloads this, they should
> "configure; make; make install"

Python's DistUtils.

Ciao, Michael.




From drewpc at COLORADO.EDU  Tue Feb 13 16:27:13 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Tue, 13 Feb 2001 08:27:13 -0700
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
In-Reply-To: <01021300383101.00697@mephit>
References: <982039435.3a88bb8b658a3@webmail.colorado.edu>
            <01021300383101.00697@mephit>
Message-ID: <982078033.3a895251a0607@webmail.colorado.edu>

Quoting Bryan Mongeau <bryan at EEVOLVED.COM>:

> On Monday 12 February 2001 23:43, you wrote:
> > I took Dan's pseudo code and turned it into python code.  Let me know
> what
> > I did wrong and what should be changed.  Sometime tomorrow I'll also
> write
> > up the goals and post it on the same site.
> >
>
> Excellent initiative! Looks tight + nice doc strings! :)
>
> Only two small issues got caught in my brain sieve, pertaining to
> AsymmetricBase:
>
> 1 - __init__,encrypt and decrypt all accept an "_algorithm" parameter.
> This
> is somewhat confusing to me. If child classes inherit from
> AsymmetricBase,
> aren't they necessarily implementing an algorithm? Would child classes
> always
> set "_algorithm" to their algorithm? If so, isn't that redundant?
>

Yeah, for some reason I got it stuck in my head that this is where we'd need
that, but we won't need it until we get a little higher up.  For instance, when
you ssh somewhere the RSA stuff just encrypts your symmetric session key.  Your
actual session is encrypted using IDEA or Blowfish or something.  I'm
dumb...I've changed it and uploaded the changes.

> 2- sign and verify. It would seems that these methods could actually use
> an
> "_algorithm"  parameter due to the fact that signing and verification
> can be
> conducted many ways using a given keypair. Examples: DSA, Nyberg-Ruppel
> and
> Massy-Omura. Oh, and the verify docstring needs to be changed
> (copy/paste
> from sign method? :)
>

fixed that too :)


> Regards,
> --
> <==================================>
> Bryan Mongeau
> Lead Developer, Director
> eEvolved Real-Time Technologies Inc.
> http://www.eevolved.com
> <==================================>
>
> "Imagination is more important than knowledge."-- Einstein
>



--
PC Drew




From LISTSERV at NIC.SURFNET.NL  Wed Feb 14 00:37:14 2001
From: LISTSERV at NIC.SURFNET.NL (L-Soft list server at SURFnet (The Netherlands) (1.8d))
Date: Wed, 14 Feb 2001 00:37:14 +0100
Subject: PYTHON-CRYPTO: gscherb@MRIRESEARCH.ORG joined the list
Message-ID: <200102132337.AAA25513@post.webmailer.de>

Wed, 14 Feb 2001 00:37:14

Glenn  Scherb  <gscherb at MRIRESEARCH.ORG>  has   just  subscribed  to  the
PYTHON-CRYPTO list (generic crypto class API for Python).




From dan at eevolved.com  Wed Feb 14 01:18:27 2001
From: dan at eevolved.com (Dan Parisien)
Date: Tue, 13 Feb 2001 19:18:27 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A88DCB0.7A0EE57D@stroeder.com>
References: <2756067462.982008610@[10.0.0.100]> <3A88DCB0.7A0EE57D@stroeder.com>
Message-ID: <01021319182700.02849@localhost.localdomain>

On Ter?a 13 Fevereiro 2001 02:05, you wrote:

> For me it's the main motivation for discussing such an API.

Of course it is. This is what you need for your product. I would like to see
more proof of concept and less abtract suggestions...

If the directory tree is free of clutter or 'helper' python scripts/binary
python modules, then a search algorithm can be as trivial as a directory
search. Helper scripts or libs could be placed in a vanilla python path,
while only standard compliant modules would be placed in the python crypto/
dir tree.

> > * Handle key exchanges and have a key "ring"
> - key stores

I'm a big fan of a key ring. It could be written with shelve. I am not
certain about the specifics and would not want to reinvent the wheel on this
one. Any links anyone? (why am I asking? I'll search google.com. Has anyone
else noticed google is like humanity's motherbrain?)

> Well, that's your point of view. I agree that producing correct code
> is the main goal. But I agree with the people who are in favour with
> OpenSSL: It's already a very good implementation (although written
> in C ;-) and the code was reviewed and fully understood by many
> people. If I would have to choose something for secure production
> use I would stick to this.

It would be trivial to code API standard adhering implementations of specific
algorithms that in turn use OpenSSL's API. Anyone up to it?

Dan




From rsalz at CAVEOSYSTEMS.COM  Wed Feb 14 01:46:40 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Tue, 13 Feb 2001 19:46:40 -0500
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <3A88DCB0.7A0EE57D@stroeder.com>
            <01021319182700.02849@localhost.localdomain>
Message-ID: <3A89D570.5C0DC6CB@caveosystems.com>

> If the directory tree is free of clutter or 'helper' python scripts/binary
> python modules, then a search algorithm can be as trivial as a directory
> search.

I don't think so.  I would hope that the python-crypto library includes
implementations that worked with openssl and perhaps a pure-python
implementation.  A simple search will not tell the 3rd-party
crypto-using application which to use.

> I'm a big fan of a key ring. It could be written with shelve.

Does shelve support encrypting the data?  "Putting it in a mode 700
directory" isn't good enough -- a virus or trojan horse could send my
plaintext keyring to an adversary.  Not good.  Win32, arguably the
dominant platform in the world, has the concept of a keystore in its
CryptoAPI.  It would be very nice -- if not a requirement -- that
pycrypto be able to share keys with other windows apps on windows
platforms.

        /r$




From dan at eevolved.com  Wed Feb 14 02:06:45 2001
From: dan at eevolved.com (Dan Parisien)
Date: Tue, 13 Feb 2001 20:06:45 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A89D570.5C0DC6CB@caveosystems.com>
References: <2756067462.982008610@[10.0.0.100]>
            <01021319182700.02849@localhost.localdomain>
            <3A89D570.5C0DC6CB@caveosystems.com>
Message-ID: <01021320064501.02849@localhost.localdomain>

On Ter?a 13 Fevereiro 2001 19:46, you wrote:
> > If the directory tree is free of clutter or 'helper' python
> > scripts/binary python modules, then a search algorithm can be as trivial
> > as a directory search.
>
> I don't think so.  I would hope that the python-crypto library includes
> implementations that worked with openssl and perhaps a pure-python
> implementation.  A simple search will not tell the 3rd-party
> crypto-using application which to use.

I'm a little confused. 3rd party crypto-using apps? I don't understand this
paragraph. What in particular are you refering to? I'm talking about not
needing a find_alg(...)

Anyways, the 1st crypto API draft only supports a small subset of computer
security, namely encryption and hashing. Other crypto-system standards could
be added as soon as this SIG is out of its infancy.

> Does shelve support encrypting the data?

The encryption/decryption would be coded in database access routines.
Encryption before writes and decryption after reads.

> "Putting it in a mode 700
> directory" isn't good enough -- a virus or trojan horse could send my
> plaintext keyring to an adversary.

It's not? Encryption does not protect you from a trojan horse. If you encrypt
your keyring (and it is not with a password) your encryption key must be
stored somewhere. Where? The answer to that question doesn't matter because
the trojan horse would be able to get to any data your keyring program can
get to.

The way to protect against this is to store the key in your mind (password)
and type it in everytime you want to access your keyring. Rediculous, no?

> Not good.  Win32, arguably the
> dominant platform in the world,

Indeed... Arguably.
And for how long? ;)

> has the concept of a keystore in its
> CryptoAPI.  It would be very nice -- if not a requirement -- that
> pycrypto be able to share keys with other windows apps on windows
> platforms.

If sharing keys in your keyring with non-python apps is important, shelve is
a bad solution for a keyring. The keyring solution should be simple and
portable. Maybe an XML doc?

Peace,
Dan




From rsalz at CAVEOSYSTEMS.COM  Wed Feb 14 03:08:51 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Tue, 13 Feb 2001 21:08:51 -0500
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <01021319182700.02849@localhost.localdomain>
            <3A89D570.5C0DC6CB@caveosystems.com>
            <01021320064501.02849@localhost.localdomain>
Message-ID: <3A89E8B3.72ABD525@caveosystems.com>

> I'm a little confused. 3rd party crypto-using apps? I don't understand this
> paragraph. What in particular are you refering to? I'm talking about not
> needing a find_alg(...)

The point of this group is to make it easy to develop python apps that
use crypto, right? We want those apps to run everywhere, without
changes, regardless of whether the underlying host has hardware crypto,
openssl, pure-python methods, or (most likely) some combination thereof.

You might be able to hide find_alg inside an __init__.py, but I think
pycrypto will need some localhost-config info to figure out which
implementation modules to load.

> The way to protect against this is to store the key in your mind (password)
> and type it in everytime you want to access your keyring. Rediculous, no?

i gather you've never used pgp.

An unencrypted file behind a mode 700 directory is generally not
sufficient for anything other than casual hobbyist use.  I don't want my
private keys readable off a backup tape.

> If sharing keys in your keyring with non-python apps is important, shelve is
> a bad solution for a keyring. The keyring solution should be simple and
> portable. Maybe an XML doc?

shelve might be perfectly fine as one keyring implementation.

        /r$




From dan at eevolved.com  Wed Feb 14 03:16:16 2001
From: dan at eevolved.com (Dan Parisien)
Date: Tue, 13 Feb 2001 21:16:16 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A89E8B3.72ABD525@caveosystems.com>
References: <2756067462.982008610@[10.0.0.100]>
            <01021320064501.02849@localhost.localdomain>
            <3A89E8B3.72ABD525@caveosystems.com>
Message-ID: <01021321161600.03096@localhost.localdomain>

On Ter?a 13 Fevereiro 2001 21:08, you wrote:

> The point of this group is to make it easy to develop python apps that
> use crypto, right? We want those apps to run everywhere, without
> changes, regardless of whether the underlying host has hardware crypto,
> openssl, pure-python methods, or (most likely) some combination thereof.
>
> You might be able to hide find_alg inside an __init__.py, but I think
> pycrypto will need some localhost-config info to figure out which
> implementation modules to load.

Especially with hardware crypto implementations. How would you propose a
programmer use the find alg?

AESImplementations = crypto.find("AES")
for i in AESImplementations:
        if implementation(i) == crypto.Hardware:
                # use this

Obviously not, but maybe I would understand this more if I saw some pseudo
code using it...

> > The way to protect against this is to store the key in your mind
> > (password) and type it in everytime you want to access your keyring.
> > Rediculous, no?
>
> i gather you've never used pgp.

Oops. my bad.

> > If sharing keys in your keyring with non-python apps is important, shelve
> > is a bad solution for a keyring. The keyring solution should be simple
> > and portable. Maybe an XML doc?
>
> shelve might be perfectly fine as one keyring implementation.

So a keyring API standard should be written. (Obviously I have no experience
with keyrings, anyone else up to it?)

Dan




From rsalz at CAVEOSYSTEMS.COM  Wed Feb 14 04:21:05 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Tue, 13 Feb 2001 22:21:05 -0500
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <01021320064501.02849@localhost.localdomain>
            <3A89E8B3.72ABD525@caveosystems.com>
            <01021321161600.03096@localhost.localdomain>
Message-ID: <3A89F9A1.49BF25C6@caveosystems.com>

> Especially with hardware crypto implementations. How would you propose a
> programmer use the find alg?

Most folks would do:
        des=crypto.symmetric.factory(mechanism='3des')
which would let the local system find the "best" implementation.

Some might have an ordered list of preferences:
        AES=crypto.symmetric.factory(mechanism='AES',
prefs='hardware:openssl:pycrypto')

A high-security application, such as for a bank, might use
        rsa=crypto.asymmetric.factory(mechanism='RSA',
'prefs=Fips140-1-Level4')

Hope this helps.
        /r$




From michael at STROEDER.COM  Wed Feb 14 09:04:02 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 14 Feb 2001 09:04:02 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <01021320064501.02849@localhost.localdomain>
            <3A89E8B3.72ABD525@caveosystems.com>
            <01021321161600.03096@localhost.localdomain>
            <3A89F9A1.49BF25C6@caveosystems.com>
Message-ID: <3A8A3BF2.CB5B0019@stroeder.com>

Rich Salz wrote:
>
> > Especially with hardware crypto implementations. How would you propose a
> > programmer use the find alg?
>
> Most folks would do:
>         des=crypto.symmetric.factory(mechanism='3des')
> which would let the local system find the "best" implementation.

Yes, the "best" implementation according to the fixed order defined
by the system's admin.

> prefs='hardware:openssl:pycrypto')

This is more a package name.

> prefs='Fips140-1-Level4')

Such a parameter prefs would require that we define an extra name
space for capabilities. Hmm, could get complicated to maintain it.
I'd like to avoid that and just rely on system's configuration.

Ciao, Michael.




From michael at STROEDER.COM  Wed Feb 14 08:57:58 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 14 Feb 2001 08:57:58 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <01021320064501.02849@localhost.localdomain>
            <3A89E8B3.72ABD525@caveosystems.com>
            <01021321161600.03096@localhost.localdomain>
Message-ID: <3A8A3A86.2E43DD89@stroeder.com>

Dan Parisien wrote:
> 
> On Ter?a 13 Fevereiro 2001 21:08, you wrote:
> 
> > You might be able to hide find_alg inside an __init__.py, but I think
> > pycrypto will need some localhost-config info to figure out which
> > implementation modules to load.
> 
> Especially with hardware crypto implementations. How would you propose a
> programmer use the find alg?

For obvious reasons it's up to the system's administrator to
configure the preferred order of modules to use. (Think of security
aspects, performance vs. debugging needs etc.)

> AESImplementations = crypto.find("AES")
> for i in AESImplementations:
>         if implementation(i) == crypto.Hardware:
>                 # use this

No. System configuration is the most painless way.

> > > If sharing keys in your keyring with non-python apps is important, shelve
> > > is a bad solution for a keyring. The keyring solution should be simple
> > > and portable. Maybe an XML doc?
> >
> > shelve might be perfectly fine as one keyring implementation.
> 
> So a keyring API standard should be written.

I would call it key store API to avoid being too closely associated
to PGP. It should be possible for implementors to e.g. implement a
key store API module for Netscape's database or Win32 CryptoAPI.

I admit that I'm still very abstract...but please be a little bit
patient.

Ciao, Michael.




From stevena at neosynapse.net  Tue Feb 13 21:07:00 2001
From: stevena at neosynapse.net (Steven D. Arnold)
Date: Tue, 13 Feb 2001 15:07:00 -0500
Subject: [PYTHON-CRYPTO] ANN: Pure-Python Encryption Tools
In-Reply-To: <3A88E490.31BCBA54@stroeder.com>
References: <5.0.2.1.2.20010212133300.03a64ae0@phear.dementian.com>
Message-ID: <5.0.2.1.2.20010213150309.03b5a008@phear.dementian.com>

At 08:38 AM 2/13/2001 +0100, you wrote:
>"Steven D. Arnold" wrote:
> >
> >          http://www.neosynapse.net/free_encrypt.htm
>
>File Not Found
>
>The requested URL /free_encrypt.htm was not found on this server.

Thanks for the problem report, Michael.  There have been some DNS problems 
with the Neosynapse domain recently; these should be fixed within 24 
hours.  In the meantime, this ought to work:

         http://199.181.80.52/free_encrypt.htm

Thanks again!


--
Steven D. Arnold                   President, Neosynapse Consulting Group
stevena at neosynapse.net                          http://www.neosynapse.net





From bryan at EEVOLVED.COM  Wed Feb 14 15:34:44 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Wed, 14 Feb 2001 09:34:44 -0500
Subject: [PYTHON-CRYPTO] Hashing API
Message-ID: <01021409344400.00706@mephit>

I've been hacking through some of my crypto modules, seeing how they fit with
the proposed API PC Drew has produced. I've come across something of
interest, pertaining to the hashing API:

The old way of using hash modules was to call .new() all the time to get new
hashing contexts.

The proposed way, better in my opinion, is to simply create new hashing
objects, discarding them when no longer needed.

The best way, in my opinion, would be as mentioned above, but passing an
additional parameter to .digest() will clear the hashing context. For example:

# Create an instance of a hashing class
hasher = sha256("hash this now")

# Get the digest without clearing the context
hash = hasher.digest()

# Add a string to the running context
hasher.update("another hash string")

# Get the digest and clear the context
hash = hasher.digest(1)  # Any true boolean value should suffice here

# Add a string to a brand new hashing context
hasher.update("fresh hash again!")

I think this is more efficient than deleting and creating objects to clear
the hashing context, don't you? I've already implemented this for SHA256.
Add to the API?

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

"The universe we observe has precisely the properties we should expect if
there is, at bottom, no design, no purpose, no evil and no good, nothing but
blind pitiless indifference." -- Richard Dawkins




From bryan at EEVOLVED.COM  Wed Feb 14 16:00:06 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Wed, 14 Feb 2001 10:00:06 -0500
Subject: [PYTHON-CRYPTO] Yarrow 256 and PRNG API
Message-ID: <01021410000601.00706@mephit>

I've also coded up a CSPRNG for python that builds off of AMK's RandomPool
class in the python crypto toolkit.  I'm not entirely confident in this
assertion because I did it from memory, but I believe it is very close, if
not exactly a Yarrow 256 implementation.  Hopefully some of you can stick it
to me if I've flubbed somewhere. :) It uses SHA256 as the hash and AES at 256
bits as the cipher. It also leaves the entropy collection routines up to the
programmer, as to permit flexible future uses. Here is its API, as a basis
perhaps for discussion:

class Yarrow256:

  def __init__(self, numbytes = 256):
  """
        Numbytes is the size of the random pool buffer.

        The random pool is initially constructed with
        succesive time hashes. /dev/urandom existence
        is tested and used if available. Finally a call
        to stir() ensures at least somewhat entropic data.
        For real crypto applications, add entropic events
        directly by calling addBytes()
  """

  def useURandom(self):
   """
      If /dev/urandom is present on a given platform,
      we would be stupid not to use it. Grabs bytes and
      adds them to the pool.
   """

  def stir(self):
   """
        Critical function for ensuring the entropic
        quality of the random pool in a Yarrow-esque
        fashion. Proceeds as follows:

        o Adds the time to the random pool.

        o Taps /dev/urandom if available and adds
          it to the random pool.

        o Creates a stir "token". The token is a hash
          of the random pool and the two running counters.
          Adds the token to the random pool.

        o Encrypts the entire pool with AES using the token
          as the encryption key.

        Calling this function is relatively cheap on the
        cycles but remember that for real security, you
        must add other entropic events using addBytes().
   """
  def getBytes(self, N=32):
   """
     Return N bytes of random data, 32 being the default.
   """

  def addBytes(self, s):
   """
     XORs the contents of the string S into the random pool
   """

That's it. Entropy can be collected from any traditional Yarrow source, be it
the keyboard, mouse, or ps aux. Personally, I have implemented a thread
scheduling entropy collection mechanism to feed to addBytes() and built what
I consider to be a good CSPRNG.

When I wake up, I should have a nice tarball for you people itching for the
source... :)

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

"The universe we observe has precisely the properties we should expect if
there is, at bottom, no design, no purpose, no evil and no good, nothing but
blind pitiless indifference." -- Richard Dawkins




From jeremy at alum.mit.edu  Wed Feb 14 22:55:03 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 14 Feb 2001 16:55:03 -0500
Subject: [PYTHON-CRYPTO] CSPRNG update / pyAES-1.0 release
In-Reply-To: <01021422141001.00705@mephit>
References: <01021422141001.00705@mephit>
Message-ID: <14986.65207.214577.509096@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "BM" == Bryan Mongeau <bryan at EEVOLVED.COM> writes:

  BM> Well, I've had a chance to review Bruce's Yarrow-160
  BM> specification.  My CSPRNG is not quite a Yarrow 256
  BM> implementation and consequently, I will not name it
  BM> Yarrow256. Instead I called it EntropyPool. If any of you are
  BM> interested in it, you can grab the code at:

  BM> http://sourceforge.net/projects/pyaes

So it SourceForge accepting crypto projects these days?  Last I
checked, it was not allowed.

  BM> or a quick hit to the docs at:

  BM> http://eevolved.com/pyAES/doc

  BM> Hopefully this can stimulate exchanges regarding the development
  BM> of the Crypto API.

BTW, there is a Yarrow-160 implementation included in Pisces at
http://www.cnri.reston.va.us/software/pisces

Jeremy




From bryan at EEVOLVED.COM  Thu Feb 15 04:14:10 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Wed, 14 Feb 2001 22:14:10 -0500
Subject: [PYTHON-CRYPTO] CSPRNG update / pyAES-1.0 release
Message-ID: <01021422141001.00705@mephit>

Well, I've had a chance to review Bruce's Yarrow-160 specification.  My
CSPRNG is not quite a Yarrow 256 implementation and consequently, I will not
name it Yarrow256. Instead I called it EntropyPool. If any of you are
interested in it, you can grab the code at:

http://sourceforge.net/projects/pyaes

or a quick hit to the docs at:

http://eevolved.com/pyAES/doc

Hopefully this can stimulate exchanges regarding the development of the
Crypto API.

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

"The universe we observe has precisely the properties we should expect if
there is, at bottom, no design, no purpose, no evil and no good, nothing but
blind pitiless indifference." -- Richard Dawkins




From michael at STROEDER.COM  Thu Feb 15 08:18:32 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 15 Feb 2001 08:18:32 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <01021321161600.03096@localhost.localdomain>
            <3A89F9A1.49BF25C6@caveosystems.com>
            <01021414324300.04792@localhost.localdomain>
Message-ID: <3A8B82C8.FAD4DD1E@stroeder.com>

Dan Parisien wrote:
>
> On Tuesday 13 February 2001 22:21, you wrote:
> > > Especially with hardware crypto implementations. How would you propose a
> > > programmer use the find alg?
> >
> > Most folks would do:
> >         des=crypto.symmetric.factory(mechanism='3des')
> > which would let the local system find the "best" implementation.
> >
> > Some might have an ordered list of preferences:
> >         AES=crypto.symmetric.factory(mechanism='AES',
> > prefs='hardware:openssl:pycrypto')
> >
> > A high-security application, such as for a bank, might use
> >         rsa=crypto.asymmetric.factory(mechanism='RSA',
> > 'prefs=Fips140-1-Level4')
>
> Goodness. I see why you would want it, but I still oppose this type of
> system. It is in my opinion [of course it's in my opinion :) ] anti-pythonic.
> This type of registry should be at an OS level/programming language
> independant with python wrappers accessing it, not in the pyton crypto api :(

I do not see a problem. Yesterday evening I started on implementing
such a thing.

The module directory layout looks like this:

crypto
crypto/__init__.py
crypto/exception.py
crypto/registry.py
crypto/hash.py
crypto/cipher.py
crypto/factory.py
crypto/impl
crypto/impl/__init__.py
crypto/impl/M2Crypto/
crypto/impl/amkCrypto/
crypto/impl/Python/
crypto/impl/Python/hash.py

crypto/impl contains wrapper modules for current implementations or
new implementation modules in a flat name space.

The registry modules looks like this:

# Leave import statements untouched!
import crypto
from crypto.impl import *

# Edit this dictionary
registry = {

  # Hashes

  # MD5 implementations
  '(0 2 262 1 10 1 3 2)' : [
    Python.hash.MD5,
  ],

  # SHA1 implementations
  '(1 3 14 3 2 26)' : [
    Python.hash.SHA1,
  ],

  # Asymmetric ciphers

  # RSA implementations
  '(2 5 8 1 1)' : [
  ],

  # Key stores

} # registry

It's just a dictionary of lists of class names. The lists maintain
the preferred order. A factory function returns an instance of this
class. Very simple.

A few points:

- Anybody concerned of a system admin having to edit a Python
module? If this looks too scary we could write code generators for
the registry module later.

- Is anybody scared by OIDs at all? Do all required components
(algorithms, prng, key stores, protocols) have OIDs assigned?
(Likely not.)

Well, the dictionary also allows us to use aliases (second
dictionary for alias mapping) or assign new names for entities which
do not have an assigned OID. We could also register implementations
by opening a Python OID arc, etc.

Hopefully I will come up with a more or less complete tar.gz this
week-end.

Ciao, Michael.




From dan at eevolved.com  Wed Feb 14 20:32:43 2001
From: dan at eevolved.com (Dan Parisien)
Date: Wed, 14 Feb 2001 14:32:43 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A89F9A1.49BF25C6@caveosystems.com>
References: <2756067462.982008610@[10.0.0.100]>
            <01021321161600.03096@localhost.localdomain>
            <3A89F9A1.49BF25C6@caveosystems.com>
Message-ID: <01021414324300.04792@localhost.localdomain>

On Tuesday 13 February 2001 22:21, you wrote:
> > Especially with hardware crypto implementations. How would you propose a
> > programmer use the find alg?
>
> Most folks would do:
>         des=crypto.symmetric.factory(mechanism='3des')
> which would let the local system find the "best" implementation.
>
> Some might have an ordered list of preferences:
>         AES=crypto.symmetric.factory(mechanism='AES',
> prefs='hardware:openssl:pycrypto')
>
> A high-security application, such as for a bank, might use
>         rsa=crypto.asymmetric.factory(mechanism='RSA',
> 'prefs=Fips140-1-Level4')
>
> Hope this helps.

Goodness. I see why you would want it, but I still oppose this type of
system. It is in my opinion [of course it's in my opinion :) ] anti-pythonic.
This type of registry should be at an OS level/programming language
independant with python wrappers accessing it, not in the pyton crypto api :(

Python crypto should be more simple than this. The pseudo code above makes me
think of OBDC (which brings me back to the idea of making such a registry
OS-wide & programming language independant)... If the python crypto standard
is comprehensible and simple, it will be trivial to wrap any system to it;
especially the one you propose!

Understand that I do think what you propose is good and _extremely_ useful, I
just think that if we focus on that, python crypto will never get out the
door :(

This is just my vote,
peace,
Dan




From dan at eevolved.com  Wed Feb 14 20:56:40 2001
From: dan at eevolved.com (Dan Parisien)
Date: Wed, 14 Feb 2001 14:56:40 -0500
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
In-Reply-To: <982078033.3a895251a0607@webmail.colorado.edu>
References: <982039435.3a88bb8b658a3@webmail.colorado.edu>
            <01021300383101.00697@mephit>
            <982078033.3a895251a0607@webmail.colorado.edu>
Message-ID: <01021414564000.04866@localhost.localdomain>

On Tuesday 13 February 2001 10:27, you wrote:

(http://rtt.colorado.edu/~drewpc/PyCrypto.tar)
I have a few questions as well:

in SymmetricBase and AsymmetricBase, there are 'private' attributes for
encryption/decryption keys. There should be methods to access them (or make
them public)

I understand the rationale behind making them private and having methods to
access them, but I think that to be wasteful compared to having direct access
to the method.

Just a matter of style, also, I think that the function arguments should not
have underscores (_) prefixed to them. Named arguments are less readable and
happydoc generated documentation also suffers in the readability department.

I think APIs should also be drafted for keystores (as per Michael's
suggestion) and a csprng (Bryan was working on one all day yesterday, i think
it's pure python as well). Unfortunately, I am not the one to consult for
either of those :)

I'm hoping more code can flow out, even if it's extremely shaky code, because
where there are mistakes (especially obvious ones) they will be corrected.

Peace,
Dan




From bryan at EEVOLVED.COM  Thu Feb 15 12:15:17 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Thu, 15 Feb 2001 06:15:17 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <14986.65207.214577.509096@w221.z064000254.bwi-md.dsl.cnc.net>
References: <01021422141001.00705@mephit>
            <14986.65207.214577.509096@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <01021506151705.00705@mephit>

> So it SourceForge accepting crypto projects these days?  Last I
> checked, it was not allowed.

Arg! American export restrictions are such a pain, thanks for the reminder. I
couldn't find any docs on the site concerning this policy, so I submitted my
project anyway. Lo and behold, it was accepted, so either it was okay, or
they didn't read the words "crypto" and "AES" in the title. Nevertheless, I
posted a msg in the open forum, we'll see what develops. A quick search for
"crypto" seems to turn up many, many projects though...

> BTW, there is a Yarrow-160 implementation included in Pisces at
> http://www.cnri.reston.va.us/software/pisces

Thanks. I've been playing with Pisces for a few weeks now, my main interests
being the PKCS routines. I liked it, especially the documentation, and if it
weren't for the underlying OpenSSL dependency, I would have used it.  You
also reminded me your class is named EntropyPool as well. Whoops. I will
change the name of my CSPRNG in the next release to avoid any confusion.

As for your Yarrow-160 implementation, I examined and tested it, but
ultimately needed more entropy than it could provide. But I did have a few
questions I would like to bounce off you now that we're on that topic, if you
don't mind. These popped into my mind this morning:

1- Why doesn't anyone use a block cipher in CBC mode to make things even more
funky in the random pools? The initialization vector could be a hash slice of
a given entropy pool... The Yarrow specs uses 3des in counter mode, you use
ECB.

2- I noticed in the Yarrow 160 spec section 4.2 that entropy sources are
closely tied to a given pool, be it the fast or slow to prevent bogus entropy
sources from reseeding the PRNG continously. However, in the addSource()
method, you add an entropy source to both pools. Additionally, the addInput()
method alternates between pools, effectively leaving the PRNG open to an
iterative guessing attack should one entropy source be vastly overestimating
its contribution. Also the slowIntoFast() method calls addInput() which has a
50% chance of adding the slow pool to the slow pool... As AMK would say, it's
a Bad Thing. :)  Am I missing something here?

Don't get me wrong, I don't think your implementation is insecure in any way.
In fact I believe it to be quasi unbreakable.  I simply have issues with
Yarrow and its rigid implementation. Entropy collection routines are fine if
you're running a daemon or an entropy server that is given a period of time
to accumulate sufficient entropy, but most applications require entropy on
demand. Take for example pgp keygen that prompts you to pound the keyboard
until it's got enough randomness. Effective granted, but crude.

Here is a theory I would appreciate salient commentary on:

I take a different approach that uses thread scheduling to generate massively
parallel race conditions that operate on a common buffer.  I use this thread
entropy to add events to a Yarrow-esque pool on the fly and on demand.

This mechanism was posted to sci.crypt and the response was (expectedly)
harsh. The primary arguments raised were that the thread scheduler is a
deterministic algorithm thus cannot produce entropy and that an attacker
could cause system load to be unusually high which would result in more
deterministic scheduling.

My defense lies partly in python's GIL, which by default is acquired and
released every 10 cycles (I believe). This constant acquisition and release
process, in conjunction with the other system processes, has an effect of
making *all* system activities ( keyboard hits, mouse movements, disk and
network I/O, running hardware drivers, other processes running, etc.)
influence the overall outcome of the thread race. Iterate the algorithm for a
given number of rounds, and you have effectively created an PRNG scheme that
encompasses all the other methods of entropy accumulation.

So far this defense has met with little acceptance, but this is to be
expected in the crypto field. After all, most cryptographers will still
blindly choose RSA over Elliptic Curves simply because they feel safer all
sticking together, even though ECC is ten times as fast and has a key size
that increases exponentially in security. For example, 160 bit ECC is
equivalent to 1024 bit RSA whereas 256 bit ECC roughly equates to 4096 bits
in RSA.

I feel Yarrow has somewhat cornered the CSPRNG market in the same fashion.

I welcome the list's comments on my thoughts and opinions.

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

"The universe we observe has precisely the properties we should expect if
there is, at bottom, no design, no purpose, no evil and no good, nothing but
blind pitiless indifference." -- Richard Dawkins




From michael at STROEDER.COM  Thu Feb 15 13:46:16 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Thu, 15 Feb 2001 13:46:16 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <2756067462.982008610@[10.0.0.100]>
            <01021414324300.04792@localhost.localdomain>
            <3A8B82C8.FAD4DD1E@stroeder.com> <01021506425806.00705@mephit>
Message-ID: <3A8BCF98.8F83536A@stroeder.com>

Bryan Mongeau wrote:
>
> > # Edit this dictionary
> > registry = {
> >
> >   # Hashes
> >
> >   # MD5 implementations
> >   '(0 2 262 1 10 1 3 2)' : [
> >     Python.hash.MD5,
> >   ],
> >
> >   # SHA1 implementations
> >   '(1 3 14 3 2 26)' : [
> >     Python.hash.SHA1,
> >   ],
> >
> >   # Asymmetric ciphers
> >
> >   # RSA implementations
> >   '(2 5 8 1 1)' : [
> >   ],
> >
> >   # Key stores
> >
> > } # registry
>
> Are the numbers in the key strings the OIDs of
> implementations?

The OIDs are the unique identifiers for algortihms and protocols.
The strings above are just one possible string representation.
In the X.509-related world almost every such a component (even
single attributes of certificates) has such an OID assigned to it.
OIDs are hierarchical. Once you've registered a OID prefix (arc)
you're free to assign new OIDs to every object you might think of.

> Or do the lists maintain the order of implementation?

Yes.

> It would definitely suit your needs, but I see its applications being much
> broader than merely crypto routines. This method could be applied to all
> python modules,

Out of my scope and not necessary for most modules.

> > - Anybody concerned of a system admin having to edit a Python
> > module? If this looks too scary we could write code generators for
> > the registry module later.
>
> As long as the installer has this preconfigured for the modules it is
> installing, I do not see this as a problem at all.  It becomes more tedious
> as new modules/hardware are installed. Admins would have to be made aware of
> this.

If new implementation modules are installed the system administrator
has to manually tweak this registry. One could imagine that new
implementation modules register themselves by appending their class
names to the lists of algorithms they implement. (Note: Using
.append() as default installation method means add to *end of list*
=> lowest priority!)

> > - Is anybody scared by OIDs at all? Do all required components
> > (algorithms, prng, key stores, protocols) have OIDs assigned?
> > (Likely not.)
>
> As an extension module coder, this is the first I hear of OIDs outside of
> Zope.

Zope is using OIDs?

Ciao, Michael.




From bryan at EEVOLVED.COM  Thu Feb 15 12:42:58 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Thu, 15 Feb 2001 06:42:58 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A8B82C8.FAD4DD1E@stroeder.com>
References: <2756067462.982008610@[10.0.0.100]>
            <01021414324300.04792@localhost.localdomain>
            <3A8B82C8.FAD4DD1E@stroeder.com>
Message-ID: <01021506425806.00705@mephit>

>
> The module directory layout looks like this:
>
> crypto
> crypto/__init__.py
> crypto/exception.py
> crypto/registry.py
> crypto/hash.py
> crypto/cipher.py
> crypto/factory.py
> crypto/impl
> crypto/impl/__init__.py
> crypto/impl/M2Crypto/
> crypto/impl/amkCrypto/
> crypto/impl/Python/
> crypto/impl/Python/hash.py
>
> crypto/impl contains wrapper modules for current implementations or
> new implementation modules in a flat name space.
>
> The registry modules looks like this:
>
> # Leave import statements untouched!
> import crypto
> from crypto.impl import *
>
> # Edit this dictionary
> registry = {
>
>   # Hashes
>
>   # MD5 implementations
>   '(0 2 262 1 10 1 3 2)' : [
>     Python.hash.MD5,
>   ],
>
>   # SHA1 implementations
>   '(1 3 14 3 2 26)' : [
>     Python.hash.SHA1,
>   ],
>
>   # Asymmetric ciphers
>
>   # RSA implementations
>   '(2 5 8 1 1)' : [
>   ],
>
>   # Key stores
>
> } # registry
>
> It's just a dictionary of lists of class names. The lists maintain
> the preferred order. A factory function returns an instance of this
> class. Very simple.

This is very interesting.   Are the numbers in the key strings the OIDs of
implementations? Or do the lists maintain the order of implementation?

It would definitely suit your needs, but I see its applications being much
broader than merely crypto routines. This method could be applied to all
python modules, allowing the dynamic implementation selection you have
outlined.

>
> A few points:
>
> - Anybody concerned of a system admin having to edit a Python
> module? If this looks too scary we could write code generators for
> the registry module later.

As long as the installer has this preconfigured for the modules it is
installing, I do not see this as a problem at all.  It becomes more tedious
as new modules/hardware are installed. Admins would have to be made aware of
this.

>
> - Is anybody scared by OIDs at all? Do all required components
> (algorithms, prng, key stores, protocols) have OIDs assigned?
> (Likely not.)

As an extension module coder, this is the first I hear of OIDs outside of
Zope. So I guess your assumption is correct about the OIDs not being
assigned. Or it's just me. :)

> Hopefully I will come up with a more or less complete tar.gz this
> week-end.

Looking forward to tinkering with it... :) Hopefully I can provide more
constructive input once I've been able to poke at it a bit.

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

"The universe we observe has precisely the properties we should expect if
there is, at bottom, no design, no purpose, no evil and no good, nothing but
blind pitiless indifference." -- Richard Dawkins




From drewpc at COLORADO.EDU  Fri Feb 16 03:01:46 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Thu, 15 Feb 2001 19:01:46 -0700
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
In-Reply-To: <01021414564000.04866@localhost.localdomain>
Message-ID: <3011163372.982263706@[10.0.0.100]>

--On Wednesday, February 14, 2001 2:56 PM -0500 Dan Parisien
<dan at eevolved.com> wrote:

> On Tuesday 13 February 2001 10:27, you wrote:
>
> (http://rtt.colorado.edu/~drewpc/PyCrypto.tar)
> I have a few questions as well:
>
> in SymmetricBase and AsymmetricBase, there are 'private' attributes for
> encryption/decryption keys. There should be methods to access them (or
> make them public)
>

good point.

> I understand the rationale behind making them private and having methods
> to access them, but I think that to be wasteful compared to having direct
> access to the method.
>

I agree.  anyone else agree?

> Just a matter of style, also, I think that the function arguments should
> not have underscores (_) prefixed to them. Named arguments are less
> readable and happydoc generated documentation also suffers in the
> readability department.
>

That's fine.  I traditionally prefix my function arguments just so I can
visually see which variables are arguments and which are not.  I understand
the readability issues and will remove them.

> I think APIs should also be drafted for keystores (as per Michael's
> suggestion) and a csprng (Bryan was working on one all day yesterday, i
> think it's pure python as well). Unfortunately, I am not the one to
> consult for either of those :)

I totally agree.  I'm very intrigued by the XML key store idea...I think
that'd be really neat.

--
PC Drew

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




From drewpc at COLORADO.EDU  Fri Feb 16 03:18:26 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Thu, 15 Feb 2001 19:18:26 -0700
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <01021506151705.00705@mephit>
Message-ID: <3012162792.982264706@[10.0.0.100]>

--On Thursday, February 15, 2001 6:15 AM -0500 Bryan Mongeau
<bryan at EEVOLVED.COM> wrote:

>> So it SourceForge accepting crypto projects these days?  Last I
>> checked, it was not allowed.
>
> Arg! American export restrictions are such a pain, thanks for the
> reminder. I couldn't find any docs on the site concerning this policy, so
> I submitted my project anyway. Lo and behold, it was accepted, so either
> it was okay, or they didn't read the words "crypto" and "AES" in the
> title. Nevertheless, I posted a msg in the open forum, we'll see what
> develops. A quick search for "crypto" seems to turn up many, many
> projects though...
>

If that's a problem, does anyone on this list have a machine that they
could give people SSH access to?  Is there any way we could get something
like this?  Or, since the export restrictions have been relaxed...does
anyone know what the law says about all of this?  I read some of the law,
but like every other stupid law, I didn't understand it.

> Here is a theory I would appreciate salient commentary on:
>
> I take a different approach that uses thread scheduling to generate
> massively parallel race conditions that operate on a common buffer.  I
> use this thread entropy to add events to a Yarrow-esque pool on the fly
> and on demand.
>

I looked again, but couldn't find the exact text in the Yarrow spec, but it
mentioned accumulating entropy from places that have nothing to do with
each other.  To me, that means pick enough entropy sources such that an
attacker couldn't possibly affect each and every one of them at the same
time (or over a given period of time) enough so that it he would be able to
dictate the pseudo random output.  For instance, why not accumulate entropy
from thread scheduling (as you mentioned above), time, networking packets,
process ids, keyboard input, mouse movement, etc?

> This mechanism was posted to sci.crypt and the response was (expectedly)
> harsh. The primary arguments raised were that the thread scheduler is a
> deterministic algorithm thus cannot produce entropy and that an attacker
> could cause system load to be unusually high which would result in more
> deterministic scheduling.
>

Well yeah, we're looking for random input for a random number generator!!
At some point, we're going to have to use data from some deterministic
algorithm in order to create our random numbers!

> My defense lies partly in python's GIL, which by default is acquired and
> released every 10 cycles (I believe). This constant acquisition and
> release process, in conjunction with the other system processes, has an
> effect of making *all* system activities ( keyboard hits, mouse
> movements, disk and network I/O, running hardware drivers, other
> processes running, etc.) influence the overall outcome of the thread
> race. Iterate the algorithm for a given number of rounds, and you have
> effectively created an PRNG scheme that encompasses all the other methods
> of entropy accumulation.
>

woah.  Sorry, had to re-read that a few times :)

> So far this defense has met with little acceptance, but this is to be
> expected in the crypto field. After all, most cryptographers will still
> blindly choose RSA over Elliptic Curves simply because they feel safer all
> sticking together, even though ECC is ten times as fast and has a key size
> that increases exponentially in security. For example, 160 bit ECC is
> equivalent to 1024 bit RSA whereas 256 bit ECC roughly equates to 4096
> bits in RSA.
>

That's why we need to support all of these...so that software engineers can
make their own decisions and not be cornered into one area just because we
didn't implement RSA or something.

--
PC Drew

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




From rsalz at CAVEOSYSTEMS.COM  Fri Feb 16 03:54:02 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Thu, 15 Feb 2001 21:54:02 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
References: <3012162792.982264706@[10.0.0.100]>
Message-ID: <3A8C964A.337FEBB5@caveosystems.com>

> So far this defense has met with little acceptance, but this is to be
> expected in the crypto field. After all, most cryptographers will still
> blindly choose RSA over Elliptic Curves simply because they feel safer all
> sticking together, even though ECC is ten times as fast and has a key size
> that increases exponentially in security. For example, 160 bit ECC is
> equivalent to 1024 bit RSA whereas 256 bit ECC roughly equates to 4096
> bits in RSA.

Oh dear, you're losing credibility fast.

By the "GIL" you mean the Python interpreter lock in ceval.c?  That does
its swapping purely on user-space instructions, not hardware clock
cycles.  Seems to me the cryptographers are right.
        /r$




From bryan at EEVOLVED.COM  Fri Feb 16 04:29:17 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Thu, 15 Feb 2001 22:29:17 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <3A8C964A.337FEBB5@caveosystems.com>
References: <3012162792.982264706@[10.0.0.100]>
            <3A8C964A.337FEBB5@caveosystems.com>
Message-ID: <0102152229170B.00705@mephit>

> By the "GIL" you mean the Python interpreter lock in ceval.c?  That does
> its swapping purely on user-space instructions, not hardware clock
> cycles.  Seems to me the cryptographers are right.

This is precisely the type of constructive input I was searching for.
"Cycles" was terminology faux pas, I should have used "python virtual
instructions" instead. I believe nevertheless that this thread swarm does
produce true entropy. After all the primary goal of a CSPRNG and cryptography
in general is not to make things impossible to defaet, but so diificult as to
put it beyond everyone's reach.

> > So far this defense has met with little acceptance, but this is to be
> > expected in the crypto field. After all, most cryptographers will still
> > blindly choose RSA over Elliptic Curves simply because they feel safer
> > all sticking together, even though ECC is ten times as fast and has a key
> > size that increases exponentially in security. For example, 160 bit ECC
> > is equivalent to 1024 bit RSA whereas 256 bit ECC roughly equates to 4096
> > bits in RSA.
>
> Oh dear, you're losing credibility fast.

This is not constructive commentary. If you are referring to my CSPRNG
scheme, then granted it is imperfect if used alone. If you are referring to
my key strength approximations (which is what you quoted), then I invite you
to look at:

http://softlab.od.ua/products/ecbackup/info.html

and draw your own conclusions. I admit to an approximation for brevity's sake.
--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
http://www.eevolved.com
<==================================>

"I want to know God's thoughts; the rest are details."-- Einstein




From aarchiba at YAHOO.COM  Fri Feb 16 05:08:50 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Thu, 15 Feb 2001 23:08:50 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <0102152229170B.00705@mephit>; from bryan@EEVOLVED.COM on Thu,
              Feb 15, 2001 at 10:29:17PM -0500
References: <3012162792.982264706@[10.0.0.100]>
            <3A8C964A.337FEBB5@caveosystems.com> <0102152229170B.00705@mephit>
Message-ID: <20010215230850.B12837@hedgehog>

On Thu, Feb 15, 2001 at 10:29:17PM -0500, Bryan Mongeau wrote:
> > By the "GIL" you mean the Python interpreter lock in ceval.c?  That does
> > its swapping purely on user-space instructions, not hardware clock
> > cycles.  Seems to me the cryptographers are right.
>
> This is precisely the type of constructive input I was searching for.
> "Cycles" was terminology faux pas, I should have used "python virtual
> instructions" instead. I believe nevertheless that this thread swarm does
> produce true entropy. After all the primary goal of a CSPRNG and cryptography
> in general is not to make things impossible to defaet, but so diificult as to
> put it beyond everyone's reach.

Hmm.  Well, here's another terminological quibble:  the literature in
general seems to use "cryptographically strong pseudo-random number
generator" to mean a deterministic process which produces numbers which are
computationally infeasible to distinguish from randomness without knowing
the seed data.  (See Schneier's Applied Cryptography, p. 45, for example).

On the other hand, (drawing from the same source) a real random number
generator is one which produces genuinely unpredictable output, no matter
how much computational power is brought to bear.  Most sources are not
acutally completely random (disk timings) but do contain a few bits of
genuine unpredictability.

To get an unpredictable random number generator, you should use a CSPRNG
(using Schneier's terminology) and seed it with a genuine random number
generator.  And re-seed it, periodically, at controlled intervals and in
controlled amounts.

The key thing that seems to be missing from your scheme is any clear way to
estimate how much genuine unpredicatbility there is, coming from your race
conditions.  This is likely to depend on things like IO behaviour, platform
(are your threads pure python, OS threads, different CPUs, Java threads,
what?) and any number of other criteria which will be very difficult for
you to estimate.  So it will be very difficult to tell when you've
accumulated enough randomness to safely generate your RSA keys (for
example).

You should read the design documents for Yarrow.
http://www.counterpane.com/yarrow.html

It seems like your scheme might have some merit as a random input source
for Yarrow's generator if you could estimate how much unpredictability
it was generating.

> > > So far this defense has met with little acceptance, but this is to be
> > > expected in the crypto field. After all, most cryptographers will still
> > > blindly choose RSA over Elliptic Curves simply because they feel safer
> > > all sticking together, even though ECC is ten times as fast and has a key
> > > size that increases exponentially in security. For example, 160 bit ECC
> > > is equivalent to 1024 bit RSA whereas 256 bit ECC roughly equates to 4096
> > > bits in RSA.
> >
> > Oh dear, you're losing credibility fast.
>
> This is not constructive commentary. If you are referring to my CSPRNG
> scheme, then granted it is imperfect if used alone. If you are referring to
> my key strength approximations (which is what you quoted), then I invite you
> to look at:
>
> http://softlab.od.ua/products/ecbackup/info.html
>
> and draw your own conclusions. I admit to an approximation for brevity's sake.

Having read this and any number of other discussions of elliptic curves and
cryptography, I can agree with the statement that nobody understands
elliptic curves well enough to write good algorithms for them yet.
However, there are a great number of people looking very hard at them,
trying to understand them better.  Until people are more convinced that
there really is no faster algorithm for computing on elliptic curves, I'll
pay the minimal penalty for using mod p.

That page, by the way, is a very worrisome source of cryptographic data.
It never even hints at the possibility that a faster algorithm for
cracking ECC systems will be found.  How long did NFS take to discover
for numbers mod p?

But it would be nice to have an ECC implementation for python, to play
with.  Volunteer?

Andrew Archibald




From bryan at EEVOLVED.COM  Fri Feb 16 05:37:56 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Thu, 15 Feb 2001 23:37:56 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <20010215230850.B12837@hedgehog>
References: <3012162792.982264706@[10.0.0.100]> <0102152229170B.00705@mephit>
            <20010215230850.B12837@hedgehog>
Message-ID: <0102152337560E.00705@mephit>

> Hmm.  Well, here's another terminological quibble:  the literature in
> general seems to use "cryptographically strong pseudo-random number
> generator" to mean a deterministic process which produces numbers which are
> computationally infeasible to distinguish from randomness without knowing
> the seed data.  (See Schneier's Applied Cryptography, p. 45, for example).
>
> On the other hand, (drawing from the same source) a real random number
> generator is one which produces genuinely unpredictable output, no matter
> how much computational power is brought to bear.  Most sources are not
> acutally completely random (disk timings) but do contain a few bits of
> genuine unpredictability.

Ah, well in a perfect world, every motherboard would come with a builtin
hardware RNG and this whole issue would become academic. :)  As for CSPRNG
schemes, aren't we all striving towards the same goal of unpredictability? I
would merely like to show that predicting the outcome of race conditions is
harder than predicting other traditional entropy sources (keyboard, ps aux,
etc.)

>
> To get an unpredictable random number generator, you should use a CSPRNG
> (using Schneier's terminology) and seed it with a genuine random number
> generator.  And re-seed it, periodically, at controlled intervals and in
> controlled amounts.

Hmmm, if I had a real RNG at my disposal, I wouldn't bother feeding a CSPRNG.
These crypto cards can crank out a crapload of numbers by measuring
electrical noise, why the overhead of a CSPRNG?

> The key thing that seems to be missing from your scheme is any clear way to
> estimate how much genuine unpredicatbility there is, coming from your race
> conditions.  This is likely to depend on things like IO behaviour, platform
> (are your threads pure python, OS threads, different CPUs, Java threads,
> what?) and any number of other criteria which will be very difficult for
> you to estimate.  So it will be very difficult to tell when you've
> accumulated enough randomness to safely generate your RSA keys (for
> example).

This is an issue I am currently struggling with. Do you know of any resources
for entropy estimation routines and guidelines? Everything I have seen just
takes guesses.

> You should read the design documents for Yarrow.
> http://www.counterpane.com/yarrow.html

It's on my desk right now... :)

> It seems like your scheme might have some merit as a random input source
> for Yarrow's generator if you could estimate how much unpredictability
> it was generating.

Working on that... :)

> Having read this and any number of other discussions of elliptic curves and
> cryptography, I can agree with the statement that nobody understands
> elliptic curves well enough to write good algorithms for them yet.
> However, there are a great number of people looking very hard at them,
> trying to understand them better.  Until people are more convinced that
> there really is no faster algorithm for computing on elliptic curves, I'll
> pay the minimal penalty for using mod p.

NIST and ANSI seem to convinced of it's security. Federal agencies are now
converting to ECC and ECDSA. I could dig up some links if you are interested.
Off the top of my head I believe it's ANSI X9.62.

> That page, by the way, is a very worrisome source of cryptographic data.
> It never even hints at the possibility that a faster algorithm for
> cracking ECC systems will be found.  How long did NFS take to discover
> for numbers mod p?

Faster ways of defeating ECC have been found. Nigel smart discovered an
attack on GF2n curves where n is not prime. That's precisely why NIST has
defined a series of standards and "safe" public curves to use.

>
> But it would be nice to have an ECC implementation for python, to play
> with.  Volunteer?

Mike Rosing and I are working right now on GF^233 curves with ECDSA signing
for python. Thank Guido for the builtin unlimited precision long integers!
Stayed tuned.
--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
http://www.eevolved.com
<==================================>

"I want to know God's thoughts; the rest are details."-- Einstein




From aarchiba at YAHOO.COM  Fri Feb 16 07:55:14 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Fri, 16 Feb 2001 01:55:14 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <0102152337560E.00705@mephit>; from bryan@EEVOLVED.COM on Thu,
              Feb 15, 2001 at 11:37:56PM -0500
References: <3012162792.982264706@[10.0.0.100]> <0102152229170B.00705@mephit>
            <20010215230850.B12837@hedgehog> <0102152337560E.00705@mephit>
Message-ID: <20010216015514.C12837@hedgehog>

On Thu, Feb 15, 2001 at 11:37:56PM -0500, Bryan Mongeau wrote:
> > Hmm.  Well, here's another terminological quibble:  the literature in
> > general seems to use "cryptographically strong pseudo-random number
> > generator" to mean a deterministic process which produces numbers which are
> > computationally infeasible to distinguish from randomness without knowing
> > the seed data.  (See Schneier's Applied Cryptography, p. 45, for example).
> >
> > On the other hand, (drawing from the same source) a real random number
> > generator is one which produces genuinely unpredictable output, no matter
> > how much computational power is brought to bear.  Most sources are not
> > acutally completely random (disk timings) but do contain a few bits of
> > genuine unpredictability.
>
> Ah, well in a perfect world, every motherboard would come with a builtin
> hardware RNG and this whole issue would become academic. :)

IIRC, they do (the Intel i810 random number generator; the Linux kernel has
a driver).  Nobody trusts them, Intel, you know...

>                                                              As for CSPRNG
> schemes, aren't we all striving towards the same goal of unpredictability? I
> would merely like to show that predicting the outcome of race conditions is
> harder than predicting other traditional entropy sources (keyboard, ps aux,
> etc.)

Hmm.  No, it's an important distinction between two very different goals:
information-theoretic unpredictability and computational unpredicatbility.
To get the first, you really need all these weird hacks that talk to
hardware, and you need some way of knowing how random they are.  Look at
yarrow, perhaps as implemented in pisces.
(http://www.cnri.reston.va.us/software/pisces/manual/module-pisces.yarrow.html)

To get the second goal, you should use some well-understood bit-maching
scheme such as a stream cipher or block cipher in OFB mode.  You need to
feed it real randomness at regular intervals, just like you need to re-key
connections at regular intervals; for this you need real randomness.  You
might as well let the real randomness collect in a hash context (as yarrow
does).

> > To get an unpredictable random number generator, you should use a CSPRNG
> > (using Schneier's terminology) and seed it with a genuine random number
> > generator.  And re-seed it, periodically, at controlled intervals and in
> > controlled amounts.
>
> Hmmm, if I had a real RNG at my disposal, I wouldn't bother feeding a CSPRNG.
> These crypto cards can crank out a crapload of numbers by measuring
> electrical noise, why the overhead of a CSPRNG?

Most real RNGs (lavarand, disk seek latency, keyboard intervals, etc.)
provide far too few random bits to use straight except for the most
demanding applications.  So you would be feeding them into a CSPRNG anyway.
If all you want is a CSPRNG, run AES in OFB mode.

> This is an issue I am currently struggling with. Do you know of any resources
> for entropy estimation routines and guidelines? Everything I have seen just
> takes guesses.

That is because it is really hard to know how predictable a source is.  It
is easier (almost to the point of being doable) if the source is
well-understood (e.g., keyboard latencies, disk seek times, analog input
to a high-fidelity sound card); then you can use your own estimate of how
much entropy there should be, and weight it down using an automatic entropy
estimator that looks for patterns.  Look in pisces, for example, they have
one based on zlib.  These help a little, but you really need to know how
much unpredictability you can hope for in your application.  Network
timings, for example: dare you trust them?  Who knows whether the adversary
can mess with your network timings?  Only your application writer can tell
for sure.

Andrew




From bryan at EEVOLVED.COM  Fri Feb 16 08:51:35 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Fri, 16 Feb 2001 02:51:35 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <20010216015514.C12837@hedgehog>
References: <3012162792.982264706@[10.0.0.100]> <0102152337560E.00705@mephit>
            <20010216015514.C12837@hedgehog>
Message-ID: <01021602513501.05358@mephit>

> IIRC, they do (the Intel i810 random number generator; the Linux kernel has
> a driver).  Nobody trusts them, Intel, you know...

LOL. This is cool. If only more mobo manufacturers should adopt this attitude
towards security right at the hardware level, it would save us all alot of
headaches. :)  Aren't these RNG's also very cheap to produce?

> To get the second goal, you should use some well-understood bit-maching
> scheme such as a stream cipher or block cipher in OFB mode.  You need to
> feed it real randomness at regular intervals, just like you need to re-key
> connections at regular intervals; for this you need real randomness.  You
> might as well let the real randomness collect in a hash context (as yarrow
> does).

OFB mode? The reference ( rijndael-alg-fst.c ) implementation I obtained
supports only ECB, CBC and CFB. Is it an incomplete implementation?  I got it
straight from the site... :(

> Most real RNGs (lavarand, disk seek latency, keyboard intervals, etc.)
> provide far too few random bits to use straight except for the most
> demanding applications.  So you would be feeding them into a CSPRNG anyway.
> If all you want is a CSPRNG, run AES in OFB mode.

This got me thinking. Lavarand is a cool concept (and the guys are funny too)
but it would be cooler to distribute that entropy securely over the net.
Unfortunately all an attacker would need is a sniffer to guess that entropy.
But what if a secure connection can be established (SSL), the entropy tapped
and the connection closed. Then that entropy could be considered unguessable
by an attacker, no? A CSPRNG could be seeded and bingo... unguessable
internal state.  I can imagine a giant hardware RNG farm on the net with
simple https set up would get this working quickly. A business model selling
entropy perhaps? Anyone see a flaw in this?

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

"I want to know God's thoughts; the rest are details."-- Einstein




From aarchiba at YAHOO.COM  Fri Feb 16 09:51:55 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Fri, 16 Feb 2001 03:51:55 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <01021602513501.05358@mephit>; from bryan@EEVOLVED.COM on Fri,
              Feb 16, 2001 at 02:51:35AM -0500
References: <3012162792.982264706@[10.0.0.100]> <0102152337560E.00705@mephit>
            <20010216015514.C12837@hedgehog> <01021602513501.05358@mephit>
Message-ID: <20010216035155.F12837@hedgehog>

On Fri, Feb 16, 2001 at 02:51:35AM -0500, Bryan Mongeau wrote:
> > IIRC, they do (the Intel i810 random number generator; the Linux kernel has
> > a driver).  Nobody trusts them, Intel, you know...
>
> LOL. This is cool. If only more mobo manufacturers should adopt this attitude
> towards security right at the hardware level, it would save us all alot of
> headaches. :)  Aren't these RNG's also very cheap to produce?

All you have to do is put a couple of flaky transistors on a chip.  More or
less.

> OFB mode? The reference ( rijndael-alg-fst.c ) implementation I obtained
> supports only ECB, CBC and CFB. Is it an incomplete implementation?  I got it
> straight from the site... :(

Ah, OFB mode (in the mode that doesn't suck) is just CBC with all
zero data[1].  You then XOR the output with your plaintext (if you're
encrypting --- we're not).  You *must* use a different IV every time or
you're screwed.  (When I said this mode doesn't suck, the others are
worse --- OFB mode is not often used).  Basically it's one way[2] to make
your block cipher act like a stream cipher.  Since the whole point of a
stream cipher is to take a small hunk of real randomness (the key) and
turn it into a great whack of computational randomness (the keystream),
this is exactly what you want.  The security properties you want from a
CSPRNG are more-or-less those you want from a stream cipher, except you
don't care if anyone else can decipher it with the key since you don't
give anyone the key.  And you re-key often in case they get it.

It doesn't have to be AES; pick your favorite block cipher.  Or a stream
cipher, if you are not as repelled by them as I am.

> This got me thinking. Lavarand is a cool concept (and the guys are funny too)
> but it would be cooler to distribute that entropy securely over the net.
> Unfortunately all an attacker would need is a sniffer to guess that entropy.
> But what if a secure connection can be established (SSL), the entropy tapped
> and the connection closed. Then that entropy could be considered unguessable
> by an attacker, no? A CSPRNG could be seeded and bingo... unguessable
> internal state.  I can imagine a giant hardware RNG farm on the net with
> simple https set up would get this working quickly. A business model selling
> entropy perhaps? Anyone see a flaw in this?

Some other person might know your entropy.  Bad.  If they know all your
entropy, it doesn't matter how you massage it, they can do exactly the same
and duplicate all your key operations.

Even apart from the certification suckage of https.

Besides, it's totally unclear how much randomness lavarand produces, or how
you would know if the lights went out and you were only getting a few bits
per second, or anything like that.  And if all you get are hashes of the
data, there's no way *you* can tell.  Their physics is cool, but their
crypto is, well, not reassuring.

Now if you wanted to run a lavarand on your home machine, you might be able
to write a good entropy estimator and get some of that funky sixties decor
working for you.  A little awkward on a laptop, though.

Andrew

[1]I think.  You should check for youself in _Applied Cryptography_, page 204
or so...  Probably in _Handbook of Applied Cryptography_ too, and that's
online.  There are a bunch of other weird modes, but they're not really
recommended.

[2]yarrow uses counter mode.  The prototypical counter mode has the ith
block of keystream be E_K(i+IV).  You can get fancier, though.




From dan at eevolved.com  Fri Feb 16 05:22:35 2001
From: dan at eevolved.com (Dan Parisien)
Date: Thu, 15 Feb 2001 23:22:35 -0500
Subject: [PYTHON-CRYPTO] Interoperation with GnuPG
In-Reply-To: <20010215182457.B12768@hedgehog>
References: <20010215182457.B12768@hedgehog>
Message-ID: <01021523223501.20252@localhost.localdomain>

On Thursday 15 February 2001 18:24, you wrote:

> I am trying to write a cryptographic application that uses GnuPG keys for
> signatures.  Is there a portable way to access the GnuPG keyring and do
> signing, verification, and key import/export?

Hello Andrew.

I searched GPG on freshmeat.net and came upon

http://freshmeat.net/projects/privacyguardglue/

"Privacy Guard Glue is a well-designed library written in C to add GnuPG
support to applications. PGG was designed to provide an easy-to-use and
robust interface for GnuPG. PGG totally hides the complicated and error prone
coprocessing interface of GnuPG and frees the caller of all GnuPG specific
tasks and implementation details."

You could couple this with

http://www.swig.org

"SWIG is a software development tool that connects programs written in C,
C++, and Objective-C with a variety of high-level programming languages. SWIG
is primarily used with common scripting languages such as Perl, Python,
Tcl/Tk, Ruby, and Guile but has also been extended to include languages such
as Java and Eiffel"

Hope this helps,
Dan




From aarchiba at YAHOO.COM  Fri Feb 16 00:24:57 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Thu, 15 Feb 2001 18:24:57 -0500
Subject: [PYTHON-CRYPTO] Interoperation with GnuPG
Message-ID: <20010215182457.B12768@hedgehog>

Hi,

I am trying to write a cryptographic application that uses GnuPG keys for
signatures.  Is there a portable way to access the GnuPG keyring and do
signing, verification, and key import/export?

I have a bletcherous UN*X-specific version that works by running GnuPG (not
cmpatible with any version of PGP, alas) as a subprocess.  I especially
dislike its passphrase handling (any advice on how to handle passphrases
and other secrets less-insecurely in a python program is welcome).  If
people are interested I can post it.

Thanks,
Andrew Archibald




From ngps at POST1.COM  Thu Feb 15 16:53:19 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Thu, 15 Feb 2001 23:53:19 +0800
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A8BCF98.8F83536A@stroeder.com>; from michael@STROEDER.COM on
              Thu, Feb 15, 2001 at 01:46:16PM +0100
References: <2756067462.982008610@[10.0.0.100]>
            <01021414324300.04792@localhost.localdomain>
            <3A8B82C8.FAD4DD1E@stroeder.com> <01021506425806.00705@mephit>
            <3A8BCF98.8F83536A@stroeder.com>
Message-ID: <20010215235319.A1244@madcap.dyndns.org>

On Thu, Feb 15, 2001 at 01:46:16PM +0100, Michael Str?der wrote:
> Zope is using OIDs?

He's talking about ZODB's object ids which point to persistent
Python objects. Not the same thing.

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




From drewpc at COLORADO.EDU  Fri Feb 16 03:05:10 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Thu, 15 Feb 2001 19:05:10 -0700
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A8B82C8.FAD4DD1E@stroeder.com>
Message-ID: <3011367252.982263910@[10.0.0.100]>

--On Thursday, February 15, 2001 8:18 AM +0100 Michael Str?der <michael at STROEDER.COM> wrote:

> Dan Parisien wrote:
>>
>> On Tuesday 13 February 2001 22:21, you wrote:
>> > > Especially with hardware crypto implementations. How would you
>> > > propose a programmer use the find alg?
>> >
>> > Most folks would do:
>> >         des=crypto.symmetric.factory(mechanism='3des')
>> > which would let the local system find the "best" implementation.
>> >
>> > Some might have an ordered list of preferences:
>> >         AES=crypto.symmetric.factory(mechanism='AES',
>> > prefs='hardware:openssl:pycrypto')
>> >
>> > A high-security application, such as for a bank, might use
>> >         rsa=crypto.asymmetric.factory(mechanism='RSA',
>> > 'prefs=Fips140-1-Level4')
>>
>> Goodness. I see why you would want it, but I still oppose this type of
>> system. It is in my opinion [of course it's in my opinion :) ]
>> anti-pythonic. This type of registry should be at an OS
>> level/programming language independant with python wrappers accessing
>> it, not in the pyton crypto api :(
>
> I do not see a problem. Yesterday evening I started on implementing
> such a thing.
>
> The module directory layout looks like this:
>
> crypto
> crypto/__init__.py
> crypto/exception.py
> crypto/registry.py
> crypto/hash.py
> crypto/cipher.py
> crypto/factory.py
> crypto/impl
> crypto/impl/__init__.py
> crypto/impl/M2Crypto/
> crypto/impl/amkCrypto/
> crypto/impl/Python/
> crypto/impl/Python/hash.py
>
> crypto/impl contains wrapper modules for current implementations or
> new implementation modules in a flat name space.
>
> The registry modules looks like this:
>
> # Leave import statements untouched!
> import crypto
> from crypto.impl import *
>
> # Edit this dictionary
> registry = {
>
>   # Hashes
>
>   # MD5 implementations
>   '(0 2 262 1 10 1 3 2)' : [
>     Python.hash.MD5,
>   ],
>
>   # SHA1 implementations
>   '(1 3 14 3 2 26)' : [
>     Python.hash.SHA1,
>   ],
>
>   # Asymmetric ciphers
>
>   # RSA implementations
>   '(2 5 8 1 1)' : [
>   ],
>
>   # Key stores
>
> } # registry
>
> It's just a dictionary of lists of class names. The lists maintain
> the preferred order. A factory function returns an instance of this
> class. Very simple.
>

This looks really good, I like it.

> A few points:
>
> - Anybody concerned of a system admin having to edit a Python
> module? If this looks too scary we could write code generators for
> the registry module later.
>

Yes and no.  I think that we as a group should decide the defaults based on 
our knowledge of the package and then mention to the installer that they can edit the file if they want to.  Basically what I'm saying is that I wonder if many people would change our defaults???

> - Is anybody scared by OIDs at all? Do all required components
> (algorithms, prng, key stores, protocols) have OIDs assigned?
> (Likely not.)
>

I am.  I'd rather go with aliases than with OIDs.  Other opinions?

> Well, the dictionary also allows us to use aliases (second
> dictionary for alias mapping) or assign new names for entities which
> do not have an assigned OID. We could also register implementations
> by opening a Python OID arc, etc.
>

I like the alias better.

> Hopefully I will come up with a more or less complete tar.gz this
> week-end.
>
> Ciao, Michael.



--
PC Drew

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




From dan at eevolved.com  Fri Feb 16 04:37:36 2001
From: dan at eevolved.com (Dan Parisien)
Date: Thu, 15 Feb 2001 22:37:36 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3011367252.982263910@[10.0.0.100]>
References: <3011367252.982263910@[10.0.0.100]>
Message-ID: <01021522373600.20252@localhost.localdomain>

On Thursday 15 February 2001 21:05, you wrote:

> > # Leave import statements untouched!
> > import crypto
> > from crypto.impl import *
> >
> > # Edit this dictionary
> > registry = {
> >
> >   # Hashes
> >
> >   # MD5 implementations
> >   '(0 2 262 1 10 1 3 2)' : [
> >     Python.hash.MD5,
> >   ],
> >
> >   # SHA1 implementations
> >   '(1 3 14 3 2 26)' : [
> >     Python.hash.SHA1,
> >   ],
> >
> >   # Asymmetric ciphers
> >
> >   # RSA implementations
> >   '(2 5 8 1 1)' : [
> >   ],
> >
> >   # Key stores
> >
> > } # registry

I have a few questions for comprehension's sake. Are the keys of the
dictionary the OIDs? Where did you get those specific numbers? Are they just
examples?

> > It's just a dictionary of lists of class names. The lists maintain
> > the preferred order. A factory function returns an instance of this
> > class. Very simple.

Ok I understand this, but where is this example code going to be located? in
crypto/? or in a crypto module implementation?

> > - Is anybody scared by OIDs at all? Do all required components
> > (algorithms, prng, key stores, protocols) have OIDs assigned?
> > (Likely not.)
>
> I am.  I'd rather go with aliases than with OIDs.  Other opinions?

Agreed. Aliases are better, but we are going to run into the problem of
having to document them to solve 'rijndael' / 'aes'...

Dan




From michael at STROEDER.COM  Fri Feb 16 10:26:18 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 16 Feb 2001 10:26:18 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <3011367252.982263910@[10.0.0.100]>
            <01021522373600.20252@localhost.localdomain>
Message-ID: <3A8CF23A.1F9863A2@stroeder.com>

Dan Parisien wrote:
>
> > >   # MD5 implementations
> > >   '(0 2 262 1 10 1 3 2)' : [
> > >     Python.hash.MD5,
> > >   ],
> > >
> > >   # SHA1 implementations
> > >   '(1 3 14 3 2 26)' : [
> > >     Python.hash.SHA1,
> > >   ],
> > >
> > >   # Asymmetric ciphers
> > >
> > >   # RSA implementations
> > >   '(2 5 8 1 1)' : [
> > >   ],
>
> Are the keys of the dictionary the OIDs?

Yes.

> Where did you get those specific numbers? Are they just
> examples?

Real number grabbed from:

  http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.cfg

> > > It's just a dictionary of lists of class names. The lists maintain
> > > the preferred order. A factory function returns an instance of this
> > > class. Very simple.
>
> Ok I understand this, but where is this example code going to be located? in
> crypto/? or in a crypto module implementation?

In crypto/ or maybe in a separate configuration module directory.

> > > - Is anybody scared by OIDs at all? Do all required components
> > > (algorithms, prng, key stores, protocols) have OIDs assigned?
> > > (Likely not.)
> >
> > I am.  I'd rather go with aliases than with OIDs.  Other opinions?
>
> Agreed. Aliases are better, but we are going to run into the problem of
> having to document them to solve 'rijndael' / 'aes'...

No problem to add additional support for aliases. But the registry
itself should be OID-based. If the registry is based on aliases we
have to maintain a name space.

Ciao, Michael.




From drewpc at COLORADO.EDU  Fri Feb 16 03:22:21 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Thu, 15 Feb 2001 19:22:21 -0700
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A8BCF98.8F83536A@stroeder.com>
Message-ID: <3012397712.982264941@[10.0.0.100]>

--On Thursday, February 15, 2001 1:46 PM +0100 Michael Str?der <michael at STROEDER.COM> wrote:

> Bryan Mongeau wrote:

>> It would definitely suit your needs, but I see its applications being
>> much broader than merely crypto routines. This method could be applied
>> to all python modules,
>
> Out of my scope and not necessary for most modules.
>

It might be something to keep in mind when designing how we will implement this though...who knows, maybe you've stumbled on to something great here! Might as well make it easy enough for other people to use it too!

>> > - Anybody concerned of a system admin having to edit a Python
>> > module? If this looks too scary we could write code generators for
>> > the registry module later.
>>
>> As long as the installer has this preconfigured for the modules it is
>> installing, I do not see this as a problem at all.  It becomes more
>> tedious as new modules/hardware are installed. Admins would have to be
>> made aware of this.
>
> If new implementation modules are installed the system administrator
> has to manually tweak this registry. One could imagine that new
> implementation modules register themselves by appending their class
> names to the lists of algorithms they implement. (Note: Using
> .append() as default installation method means add to *end of list*
> => lowest priority!)
>

This really scares me.  The idea of having other people install their code into our module without us knowing it.  What I'd rather do is have people submit their implementation to us and have us integrate it into the overall 
package.  Is this too big a task?  What does everyone else think?

--
PC Drew

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




From rsalz at CAVEOSYSTEMS.COM  Fri Feb 16 03:45:10 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Thu, 15 Feb 2001 21:45:10 -0500
Subject: [PYTHON-CRYPTO] Requirements
References: <3012397712.982264941@[10.0.0.100]>
Message-ID: <3A8C9436.619C7D0B@caveosystems.com>

> This really scares me.  The idea of having other people install their code into our
> module without us knowing it.  What I'd rather do is have people submit their
> implementation to us and have us integrate it into the overall
> package.

Unh, either you believe in well-defined interfaces that allow
independant implementation, or you do not.

Being scared is silly.  Folks *are* going to do their own
implementations, and they *are not* going to turn over their code to
someone else to integrate into an official package. The best thing to do
is accept reality, believe in interfaces, and make sure you provide a
reasonable for things to work.
        /r$




From michael at STROEDER.COM  Fri Feb 16 10:29:25 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 16 Feb 2001 10:29:25 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <3012397712.982264941@[10.0.0.100]>
Message-ID: <3A8CF2F5.498993D0@stroeder.com>

PC Drew wrote:
>
> > If new implementation modules are installed the system administrator
> > has to manually tweak this registry. One could imagine that new
> > implementation modules register themselves by appending their class
> > names to the lists of algorithms they implement. (Note: Using
> > .append() as default installation method means add to *end of list*
> > => lowest priority!)
>
> This really scares me.  The idea of having other people install their
> code into our module without us knowing it.  What I'd rather do is have
> people submit their implementation to us and have us integrate it into
> the overall package.

1. I'm not keen on maintaining a crypto lib.
2. The idea behind the dynamic crypto API is to enable people to
integrate their implementations without getting other people
involved at all.

Ciao, Michael.




From michael at STROEDER.COM  Fri Feb 16 10:30:15 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 16 Feb 2001 10:30:15 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <3012397712.982264941@[10.0.0.100]>
            <3A8C9436.619C7D0B@caveosystems.com>
Message-ID: <3A8CF327.E6B2E56E@stroeder.com>

Rich Salz wrote:
>
> > This really scares me.  The idea of having other people install their code into
> > our
> > module without us knowing it.  What I'd rather do is have people submit their
> > implementation to us and have us integrate it into the overall
> > package.
>
> Unh, either you believe in well-defined interfaces that allow
> independant implementation, or you do not.

Exactly.

Ciao, Michael.




From drewpc at COLORADO.EDU  Fri Feb 16 03:53:17 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Thu, 15 Feb 2001 19:53:17 -0700
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A8C9436.619C7D0B@caveosystems.com>
Message-ID: <3014253922.982266797@[10.0.0.100]>

--On Thursday, February 15, 2001 9:45 PM -0500 Rich Salz
<rsalz at CAVEOSYSTEMS.COM> wrote:

>> This really scares me.  The idea of having other people install their
>> code into our module without us knowing it.  What I'd rather do is have
>> people submit their implementation to us and have us integrate it into
>> the overall package.
>
> Unh, either you believe in well-defined interfaces that allow
> independant implementation, or you do not.
>
> Being scared is silly.  Folks *are* going to do their own
> implementations, and they *are not* going to turn over their code to
> someone else to integrate into an official package. The best thing to do
> is accept reality, believe in interfaces, and make sure you provide a
> reasonable for things to work.
>         /r$

I can hope, can't I?? :)  Obviously you're correct, but I'd like to say
that  I'm a proponent of one big package that people contribute to, instead
of people doing their own implementation.  That's just my $0.02


--
PC Drew

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




From michael at STROEDER.COM  Fri Feb 16 10:39:27 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 16 Feb 2001 10:39:27 +0100
Subject: [PYTHON-CRYPTO] META list infor (was: CSPRNG schemes : Any
              comments?)
References: <3012162792.982264706@[10.0.0.100]>
Message-ID: <3A8CF54F.4CDD2E9@stroeder.com>

<meta>

I don't like where this thread is heading. Please use news:sci.crypt
or similar
forums for general discussions about cryptographic algorithms,
random generators etc.

I set up this list to mainly discuss a Cryptography API for Python.
Please, let us focus on this. I'm quite busy and I definitely don't
want to go through a large amount of postings to extract the
relevant details. I guess other subscribers feel the same.

Off course implementors of cryptographic modules or applications for
Python are welcome to discuss their modules/applications. And off
course discussion about security of Python implementations are
welcome.

Thank you.

</meta>

Ciao, Michael.




From bryan at EEVOLVED.COM  Fri Feb 16 11:00:28 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Fri, 16 Feb 2001 05:00:28 -0500
Subject: [PYTHON-CRYPTO] META list infor
In-Reply-To: <3A8CF54F.4CDD2E9@stroeder.com>
References: <3012162792.982264706@[10.0.0.100]> <3A8CF54F.4CDD2E9@stroeder.com>
Message-ID: <01021605002803.05358@mephit>

On Friday 16 February 2001 04:39, you wrote:
> <meta>
>
> I don't like where this thread is heading. Please use news:sci.crypt
> or similar
> forums for general discussions about cryptographic algorithms,
> random generators etc.
>
> I set up this list to mainly discuss a Cryptography API for Python.
> Please, let us focus on this. I'm quite busy and I definitely don't
> want to go through a large amount of postings to extract the
> relevant details. I guess other subscribers feel the same.
>
> Off course implementors of cryptographic modules or applications for
> Python are welcome to discuss their modules/applications. And off
> course discussion about security of Python implementations are
> welcome.
>
> Thank you.
>
> </meta>
>
> Ciao, Michael.

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

"I want to know God's thoughts; the rest are details."-- Einstein




From dan at eevolved.com  Fri Feb 16 18:35:41 2001
From: dan at eevolved.com (Dan Parisien)
Date: Fri, 16 Feb 2001 12:35:41 -0500
Subject: [PYTHON-CRYPTO] Meta-discussion
In-Reply-To: <3A8D2BDE.CDF481F@caveosystems.com>
References: <3012162792.982264706@[10.0.0.100]> <0102152229170B.00705@mephit>
            <3A8D2BDE.CDF481F@caveosystems.com>
Message-ID: <01021612354101.23401@localhost.localdomain>

On Friday 16 February 2001 08:32, you wrote:
> It would help a great deal if the mailing list elided the Reply-To
> header.
>         /r$

Are you refering to "generic crypto class API for Python" prefixed to the
reply address?

Dan




From michael at STROEDER.COM  Fri Feb 16 19:15:51 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 16 Feb 2001 19:15:51 +0100
Subject: [PYTHON-CRYPTO] Meta-discussion
References: <3012162792.982264706@[10.0.0.100]> <0102152229170B.00705@mephit>
            <3A8D2BDE.CDF481F@caveosystems.com>
            <01021612354101.23401@localhost.localdomain>
Message-ID: <3A8D6E57.FA9E08B4@stroeder.com>

Dan Parisien wrote:
>
> On Friday 16 February 2001 08:32, you wrote:
> > It would help a great deal if the mailing list elided the Reply-To
> > header.
>
> Are you refering to "generic crypto class API for Python" prefixed to the
> reply address?

Yes.

Up to now list configuration was "Reply-To=List". I changed this to
"Reply-To=Sender" to avoid that people accidently post to the list
instead of sending private e-mail.

Use the "Reply to all" function of your MUA to stay on the list with
a discussion (but don't forget to strip down the To:-lines...).

Ciao, Michael. (first time a mailing list admin...)




From aarchiba at YAHOO.COM  Fri Feb 16 16:55:31 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Fri, 16 Feb 2001 10:55:31 -0500
Subject: [PYTHON-CRYPTO] META list infor (was: CSPRNG schemes : Any
              comments?)
In-Reply-To: <3A8CF54F.4CDD2E9@stroeder.com>; from michael@STROEDER.COM on
              Fri, Feb 16, 2001 at 10:39:27AM +0100
References: <3012162792.982264706@[10.0.0.100]> <3A8CF54F.4CDD2E9@stroeder.com>
Message-ID: <20010216105531.G12837@hedgehog>

On Fri, Feb 16, 2001 at 10:39:27AM +0100, Michael Str?der wrote:
> <meta>
>
> I don't like where this thread is heading. Please use news:sci.crypt
> or similar
> forums for general discussions about cryptographic algorithms,
> random generators etc.

Sorry about that.

> Off course implementors of cryptographic modules or applications for
> Python are welcome to discuss their modules/applications. And off
> course discussion about security of Python implementations are
> welcome.

It started here but it has veered quite far from the original topic.

Thanks,
Andrew




From dan at eevolved.com  Fri Feb 16 19:03:57 2001
From: dan at eevolved.com (Dan Parisien)
Date: Fri, 16 Feb 2001 13:03:57 -0500
Subject: [PYTHON-CRYPTO] META list infor (was: CSPRNG schemes : Any
              comments?)
In-Reply-To: <3A8CF54F.4CDD2E9@stroeder.com>
References: <3012162792.982264706@[10.0.0.100]> <3A8CF54F.4CDD2E9@stroeder.com>
Message-ID: <01021613035702.23401@localhost.localdomain>

On Friday 16 February 2001 04:39, you wrote:

> I set up this list to mainly discuss a Cryptography API for Python.

You could have fooled me. There has been 0 comments from you for the draft
API PC Drew implemented. The original purpose of this list seems to be
nothing more than a forum to discuss your idea for a central python crypto
registry leaving all other API talk between a small subset of subscribers.

peace,
Dan




From dan at eevolved.com  Fri Feb 16 19:34:21 2001
From: dan at eevolved.com (Dan Parisien)
Date: Fri, 16 Feb 2001 13:34:21 -0500
Subject: META list infor (was: CSPRNG schemes : Any comments?)
In-Reply-To: <3A8D6F4E.8481C263@stroeder.com>
References: <3012162792.982264706@[10.0.0.100]> <01021613035702.23401@localhost.localdomain> <3A8D6F4E.8481C263@stroeder.com>
Message-ID: <01021613342100.23738@localhost.localdomain>

On Friday 16 February 2001 13:19, you wrote:
> Dan Parisien wrote:
> > On Friday 16 February 2001 04:39, you wrote:
> > > I set up this list to mainly discuss a Cryptography API for Python.
> >
> > You could have fooled me. There has been 0 comments from you for the
> > draft API PC Drew implemented. The original purpose of this list seems to
> > be nothing more than a forum to discuss your idea for a central python
> > crypto registry leaving all other API talk between a small subset of
> > subscribers.
>
> Ok, let's switch to private discussion about this topic:
> 1. I have a lot of work to do.
> 2. I certainly downloaded Drew's classes immediately after his
> announcment and had a look at it.
> 3. I started to write an API and I certainly tried to incorporate
> Drew's ideas.
> 4. It's not a very good behaviour you're showing by offending me
> personally on the list.
>
> Ciao, Michael.

I apologize.

Dan




From dan at eevolved.com  Fri Feb 16 19:43:38 2001
From: dan at eevolved.com (Dan Parisien)
Date: Fri, 16 Feb 2001 13:43:38 -0500
Subject: META list infor (was: CSPRNG schemes : Any comments?)
In-Reply-To: <3A8D6F4E.8481C263@stroeder.com>
References: <3012162792.982264706@[10.0.0.100]> <01021613035702.23401@localhost.localdomain> <3A8D6F4E.8481C263@stroeder.com>
Message-ID: <01021613433801.23744@localhost.localdomain>

On Friday 16 February 2001 13:19, you wrote:
> Dan Parisien wrote:
> > On Friday 16 February 2001 04:39, you wrote:
> > > I set up this list to mainly discuss a Cryptography API for Python.
> >
> > You could have fooled me. There has been 0 comments from you for the
> > draft API PC Drew implemented. The original purpose of this list seems to
> > be nothing more than a forum to discuss your idea for a central python
> > crypto registry leaving all other API talk between a small subset of
> > subscribers.
>
> Ok, let's switch to private discussion about this topic:
> 1. I have a lot of work to do.
> 2. I certainly downloaded Drew's classes immediately after his
> announcment and had a look at it.
> 3. I started to write an API and I certainly tried to incorporate
> Drew's ideas.
> 4. It's not a very good behaviour you're showing by offending me
> personally on the list.
>
> Ciao, Michael.

Sorry about the one line email...
What I meant to say was I apologize for attacking you personally. Bad 
judgement on my part. This email should have been private (which it was 
intentioned to be). At the last moment I typed in the mailing list email as 
well. In restrospect it was childish of me

again, I apologize. There is no room for constructive commentary if I let any 
relations between you and me to just be about flaming.

peace,
Dan





From dan at eevolved.com  Fri Feb 16 19:40:59 2001
From: dan at eevolved.com (Dan Parisien)
Date: Fri, 16 Feb 2001 13:40:59 -0500
Subject: [PYTHON-CRYPTO] META list infor (was: CSPRNG schemes : Any
              comments?)
In-Reply-To: <01021613035702.23401@localhost.localdomain>
References: <3012162792.982264706@[10.0.0.100]> <3A8CF54F.4CDD2E9@stroeder.com>
            <01021613035702.23401@localhost.localdomain>
Message-ID: <01021613405900.23744@localhost.localdomain>

On Friday 16 February 2001 13:03, you wrote:
> On Friday 16 February 2001 04:39, you wrote:
> > I set up this list to mainly discuss a Cryptography API for Python.
>
> You could have fooled me. There has been 0 comments from you for the draft
> API PC Drew implemented. The original purpose of this list seems to be
> nothing more than a forum to discuss your idea for a central python crypto
> registry leaving all other API talk between a small subset of subscribers.

I apologize to Michael for the previous personal attack. I let my
short temper get in the way of objective discussion. I will not let it happen
again.

Looking forward to constructive discussion in the future,
Dan




From bryan at EEVOLVED.COM  Fri Feb 16 16:29:49 2001
From: bryan at EEVOLVED.COM (Bryan Mongeau)
Date: Fri, 16 Feb 2001 10:29:49 -0500
Subject: [PYTHON-CRYPTO] Last OT reply.
In-Reply-To: <3A8D292F.D1CCED38@caveosystems.com>
References: <3012162792.982264706@[10.0.0.100]> <0102152337560E.00705@mephit>
            <3A8D292F.D1CCED38@caveosystems.com>
Message-ID: <01021610294908.05358@mephit>

> Yes, please find a link that shows a Federal agency dropping RSA for
> ECC.

Briefly, with keyword-highlighted links for your convenience:

Treasury Department's Financial Management Service [old]
http://www.google.com/search?q=cache:www.iccc.gov/document.cfm/20/6+Treasury+Department+Financial+Management+Service+secure+electronic+transaction&hl=en

USPS [newer]:
http://www.google.com/search?q=cache:poseidon.fcw.com/ref/hottopics/security/background/fcw-ECC-3-15-99.html+federal+agency+ecc+rsa+USPS&hl=en

And of course, what opened the door for widespread government use of ECC,
FIPS 186-2:
http://www.google.com/search?q=cache:csrc.nist.gov/fips/fips186-2.pdf+fips+186+ecdsa+implementation+schedule&hl=en

Please note the list moderator's above commentary about the direction of the
discussion on this list. Should you wish to continue this exchange, feel free
to mail me directly.
--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
http://www.eevolved.com
<==================================>

"There is no spirit-driven life force, no throbbing, heaving, pullulating,
protoplasmic, mystic jelly. Life is just bytes and bytes and bytes of digital
information." -- Richard Dawkins




From ngps at post1.com  Fri Feb 16 15:44:03 2001
From: ngps at post1.com (Ng Pheng Siong)
Date: Fri, 16 Feb 2001 22:44:03 +0800
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A8C10B7.76A80F56@stroeder.com>; from michael@stroeder.com on Thu, Feb 15, 2001 at 06:24:07PM +0100
References: <2756067462.982008610@[10.0.0.100]> <01021414324300.04792@localhost.localdomain> <3A8B82C8.FAD4DD1E@stroeder.com> <01021506425806.00705@mephit> <3A8BCF98.8F83536A@stroeder.com> <20010215235319.A1244@madcap.dyndns.org> <3A8C10B7.76A80F56@stroeder.com>
Message-ID: <20010216224403.C1197@madcap.dyndns.org>

On Thu, Feb 15, 2001 at 06:24:07PM +0100, Michael Str?der wrote:
> What do YOU think about using OIDs? What about the PGP world?

Sorry, it's been an intense two weeks at my day job. Reading this
late at night I can only lurk and make "easy" postings and replies.

I need to digest the discussion first.

(My day job has no Python and has crypto only very marginally.)

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





From drewpc at COLORADO.EDU  Fri Feb 16 16:57:23 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Fri, 16 Feb 2001 08:57:23 -0700
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A8CF2F5.498993D0@stroeder.com>
Message-ID: <3061300082.982313843@[10.0.0.100]>

--On Friday, February 16, 2001 10:29 AM +0100 Michael Str?der <michael at STROEDER.COM> wrote:

> PC Drew wrote:
>>
>> > If new implementation modules are installed the system administrator
>> > has to manually tweak this registry. One could imagine that new
>> > implementation modules register themselves by appending their class
>> > names to the lists of algorithms they implement. (Note: Using
>> > .append() as default installation method means add to *end of list*
>> > => lowest priority!)
>>
>> This really scares me.  The idea of having other people install their
>> code into our module without us knowing it.  What I'd rather do is have
>> people submit their implementation to us and have us integrate it into
>> the overall package.
>
> 1. I'm not keen on maintaining a crypto lib.
> 2. The idea behind the dynamic crypto API is to enable people to
> integrate their implementations without getting other people
> involved at all.
>
> Ciao, Michael.

I agree with #2, but disagree with #1.  Here's how I see it: we create a kick ass API that allows for all kinds of crypto implementation in an easy, 
well thought out manner.  That's part 1.  Part 2 is actually implimenting that.  I'd like to see this API go one step further: to actually have a big 
module to download that would have all of this functionality in it.  Maybe that's a seperate topic and seperate task, but that's what I'd like to do once we establish the API.

Anyone else interested?

--
PC Drew

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




From dan at eevolved.com  Fri Feb 16 18:17:03 2001
From: dan at eevolved.com (Dan Parisien)
Date: Fri, 16 Feb 2001 12:17:03 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3061300082.982313843@[10.0.0.100]>
References: <3061300082.982313843@[10.0.0.100]>
Message-ID: <01021612170300.23401@localhost.localdomain>

On Friday 16 February 2001 10:57, you wrote:
> I'd like to see this API go one step further: to actually have a big
> module to download that would have all of this functionality in it.  Maybe
> that's a seperate topic and seperate task, but that's what I'd like to do
> once we establish the API.
>
> Anyone else interested?

I am. That's what I thought this list was about...

Dan




From michael at STROEDER.COM  Fri Feb 16 18:46:46 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 16 Feb 2001 18:46:46 +0100
Subject: [PYTHON-CRYPTO] Requirements
References: <3061300082.982313843@[10.0.0.100]>
Message-ID: <3A8D6786.AA412EC7@stroeder.com>

PC Drew wrote:
>
> I'd like to see this API go one step further: to actually have
> a big module to download that would have all of this functionality in it.
> Maybe that's a seperate topic and seperate task,

It's definitely a separate task and too early to think about it. If
you're willing to compile and maintain a distribution of crypto API
implementation modules later (if there will ever be some) feel free
to do so.

Ciao, Michael.




From dan at eevolved.com  Fri Feb 16 19:03:57 2001
From: dan at eevolved.com (Dan Parisien)
Date: Fri, 16 Feb 2001 13:03:57 -0500
Subject: META list infor (was: CSPRNG schemes : Any comments?)
In-Reply-To: <3A8CF54F.4CDD2E9@stroeder.com>
References: <3012162792.982264706@[10.0.0.100]> <3A8CF54F.4CDD2E9@stroeder.com>
Message-ID: <01021613035702.23401@localhost.localdomain>

On Friday 16 February 2001 04:39, you wrote:

> I set up this list to mainly discuss a Cryptography API for Python.

You could have fooled me. There has been 0 comments from you for the draft 
API PC Drew implemented. The original purpose of this list seems to be 
nothing more than a forum to discuss your idea for a central python crypto 
registry leaving all other API talk between a small subset of subscribers.

peace,
Dan




From rsalz at CAVEOSYSTEMS.COM  Fri Feb 16 14:20:47 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Fri, 16 Feb 2001 08:20:47 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
References: <3012162792.982264706@[10.0.0.100]> <0102152229170B.00705@mephit>
            <20010215230850.B12837@hedgehog> <0102152337560E.00705@mephit>
Message-ID: <3A8D292F.D1CCED38@caveosystems.com>

> NIST and ANSI seem to convinced of it's security. Federal agencies are now
> converting to ECC and ECDSA. I could dig up some links if you are interested.
> Off the top of my head I believe it's ANSI X9.62.

Whoa.  ANSI is saying "if you do it, do it this way."

Yes, please find a link that shows a Federal agency dropping RSA for
ECC.
        /r$




From rsalz at CAVEOSYSTEMS.COM  Fri Feb 16 14:24:02 2001
From: rsalz at CAVEOSYSTEMS.COM (Rich Salz)
Date: Fri, 16 Feb 2001 08:24:02 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
References: <3012162792.982264706@[10.0.0.100]> <0102152337560E.00705@mephit>
            <20010216015514.C12837@hedgehog> <01021602513501.05358@mephit>
Message-ID: <3A8D29F2.B8322985@caveosystems.com>

> But what if a secure connection can be established (SSL), the entropy tapped
> and the connection closed.

In order to make an SSL connection, the client needs to create random
bytes.

So how can you trust an SSL connection to get you entropy?
        /r$




From jeremy at alum.mit.edu  Sat Feb 17 00:10:36 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 16 Feb 2001 18:10:36 -0500
Subject: [PYTHON-CRYPTO] CSPRNG schemes : Any comments?
In-Reply-To: <01021506151705.00705@mephit>
References: <01021422141001.00705@mephit>
            <14986.65207.214577.509096@w221.z064000254.bwi-md.dsl.cnc.net>
            <01021506151705.00705@mephit>
Message-ID: <14989.45932.970192.755241@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "BM" == Bryan Mongeau <bryan at EEVOLVED.COM> writes:

  >> BTW, there is a Yarrow-160 implementation included in Pisces at
  >> http://www.cnri.reston.va.us/software/pisces

  BM> As for your Yarrow-160 implementation, I examined and tested it,
  BM> but ultimately needed more entropy than it could provide. But I

The Yarrow implementation has a few trivial entropy sources, but I
didn't make any effort to provide good sources.  On the other hand,
the source of entropy is orthogonal.  You could write your own sources
and use the rest of the implementation.

  BM> did have a few questions I would like to bounce off you now that
  BM> we're on that topic, if you don't mind. These popped into my
  BM> mind this morning:

  BM> 1- Why doesn't anyone use a block cipher in CBC mode to make
  BM> things even more funky in the random pools? The initialization
  BM> vector could be a hash slice of a given entropy pool... The
  BM> Yarrow specs uses 3des in counter mode, you use ECB.

The amkCrypto implementation does provide a counter mode.  I may be
incorrect, but I thought I had implemented counter mode using ECB.
The actual cipher call is to encrypt the counter using ECB.  Is this
incorrect? (It seems correct given the defintion in Sec. 5.1 of the
Yarrow paper.)

  BM> 2- I noticed in the Yarrow 160 spec section 4.2 that entropy
  BM> sources are closely tied to a given pool, be it the fast or slow
  BM> to prevent bogus entropy sources from reseeding the PRNG
  BM> continously. However, in the addSource() method, you add an
  BM> entropy source to both pools. Additionally, the addInput()
  BM> method alternates between pools, effectively leaving the PRNG
  BM> open to an iterative guessing attack should one entropy source
  BM> be vastly overestimating its contribution.

Sec. 5.2 of the Yarrow design ("Entropy Accumulator") says:

    Once we have collected enough entropy we apply the hash functions
    h to the concatenation of all inputs.  We alternate applying
    samples from each source to each pool.

I don't understand the kind of attack you mention, but agree that an
entropy source that vastly overestimates its contribution is a bad
thing.

  BM>                                            Also the
  BM> slowIntoFast() method calls addInput() which has a 50% chance of
  BM> adding the slow pool to the slow pool... As AMK would say, it's
  BM> a Bad Thing. :) Am I missing something here?

Yes.  There are two classes with addInput methods -- the
EntropyAccumulator and the Yarrow main class.  The slowIntoFast()
method calls addInput() on the fast pool directly.  This is *not* the
addInput() method on the Yarrow instance.

  BM> Don't get me wrong, I don't think your implementation is
  BM> insecure in any way.  In fact I believe it to be quasi
  BM> unbreakable.  I simply have issues with Yarrow and its rigid
  BM> implementation.

I'm the implementor not the designer :-).

  BM>                  Entropy collection routines are fine if you're
  BM> running a daemon or an entropy server that is given a period of
  BM> time to accumulate sufficient entropy, but most applications
  BM> require entropy on demand. Take for example pgp keygen that
  BM> prompts you to pound the keyboard until it's got enough
  BM> randomness. Effective granted, but crude.

Pisces comes with a Yarrow daemon that you could use for this
purpose.  I agree that collecting entropy is hard, e.g deciding what
sources to use and how to estimate the entropy they produce.

  BM> Here is a theory I would appreciate salient commentary on:

sci.crypt is probably a better place than python-crypto.  I don't know
the backgrounds of the contributors here well enough to have much
trust in their cryptographic expertise.  I place more stock in an
opinion from sci.crypt.  I'm sure we can develop good crypto APIs, but
I don't expect we'll be development new algorithms or techniques.

  BM> My defense lies partly in python's GIL, which by default is
  BM> acquired and released every 10 cycles (I believe). This constant
  BM> acquisition and release process, in conjunction with the other
  BM> system processes, has an effect of making *all* system
  BM> activities ( keyboard hits, mouse movements, disk and network
  BM> I/O, running hardware drivers, other processes running, etc.)
  BM> influence the overall outcome of the thread race. Iterate the
  BM> algorithm for a given number of rounds, and you have effectively
  BM> created an PRNG scheme that encompasses all the other methods of
  BM> entropy accumulation.

As others have said, Python's interpreter lock is released every 10
cycles.  What happens as a result of that depends on which thread are
runnable and how the OS and thread library do scheduling.  I wouldn't
expect to get much entropy out of it.

Jeremy




From jeremy at alum.mit.edu  Fri Feb 16 23:37:11 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 16 Feb 2001 17:37:11 -0500
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
In-Reply-To: <3011163372.982263706@[10.0.0.100]>
References: <01021414564000.04866@localhost.localdomain>
            <3011163372.982263706@[10.0.0.100]>
Message-ID: <14989.43927.102560.585012@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "PCD" == PC Drew <drewpc at COLORADO.EDU> writes:

  >> I understand the rationale behind making them private and having
  >> methods to access them, but I think that to be wasteful compared
  >> to having direct access to the method.
  >>

  PCD> I agree.  anyone else agree?

Yes!  Trivial accessor methods are not Pythonic.

Jeremy




From jeremy at alum.mit.edu  Fri Feb 16 23:43:24 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 16 Feb 2001 17:43:24 -0500
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
In-Reply-To: <3011163372.982263706@[10.0.0.100]>
References: <01021414564000.04866@localhost.localdomain>
            <3011163372.982263706@[10.0.0.100]>
Message-ID: <14989.44300.242773.61724@w221.z064000254.bwi-md.dsl.cnc.net>

A few comments on the PyCrypto code.  You've got a bunch of explicit
assignments to __doc__:

class SymmetricBase:
        __doc__ = """
            All symmetric algorithms must inherit from this base class.
        """

        __encryptKey = None
        __keySize = None

        def __init__(self, _encryptKey = None):
                __doc__ = """
                    _encryptKey = default encrypt key

                    1. check the key for validity and raise an error if it's not right
                    2. set the key to be member variable
                """

The __doc__ assignment are redundant for the class and incorrect for
the functions.  For the function, you're creating a local variable
named __doc__.  The correct way to write this is:

class SymmetricBase:
        """All symmetric algorithms must inherit from this base class."""

        __encryptKey = None
        __keySize = None

        def __init__(self, _encryptKey = None):
                """"_encryptKey = default encrypt key

                1. check the key for validity and raise an error if
                   it's not right
                2. set the key to be member variable
                """

Also, it is typically to limit lines to less than 80 characters.

Jeremy




From jeremy at alum.mit.edu  Fri Feb 16 23:26:18 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 16 Feb 2001 17:26:18 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <01021321161600.03096@localhost.localdomain>
References: <2756067462.982008610@[10.0.0.100]>
            <01021320064501.02849@localhost.localdomain>
            <3A89E8B3.72ABD525@caveosystems.com>
            <01021321161600.03096@localhost.localdomain>
Message-ID: <14989.43274.415595.584500@w221.z064000254.bwi-md.dsl.cnc.net>

[Catching up on older messages; hope this is still topical.]

>>>>> "DP" == Dan Parisien <dan at eevolved.com> writes:

  >> > If sharing keys in your keyring with non-python apps is
  >> > important, shelve is a bad solution for a keyring. The keyring
  >> > solution should be simple and portable. Maybe an XML doc?
  >>
  >> shelve might be perfectly fine as one keyring implementation.

  DP> So a keyring API standard should be written. (Obviously I have
  DP> no experience with keyrings, anyone else up to it?)

This is a good plan.  There are some applications for which I would
want a keyring that uses ZODB for storage.

There was also a discussion, earlier in the thread, about security for
the keyring file.  Some kind of password-based cryptography, e.g. PKCS
#5, seems like the right approach:  The private keys should be
encrypted when they are written to disk.

I'll also mention that Pisces has a keystore (pisces.spki.keystore)
that probably isn't a good model for a general keyring :-).  The
interface is tied very closely to the SPKI mode, e.g. keys are stored
and loaded via their hashes.

Jeremy




From jeremy at alum.mit.edu  Fri Feb 16 23:31:24 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 16 Feb 2001 17:31:24 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <3A8CF23A.1F9863A2@stroeder.com>
References: <3011367252.982263910@[10.0.0.100]>
            <01021522373600.20252@localhost.localdomain>
            <3A8CF23A.1F9863A2@stroeder.com>
Message-ID: <14989.43580.547806.883229@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "MS" == Michael  Str?der <michael at STROEDER.COM>> writes:

  MS> Dan Parisien wrote:
  >>
  >> > >   # MD5 implementations
  >> > >   '(0 2 262 1 10 1 3 2)' : [
  >> > >     Python.hash.MD5,
  >> > >   ],
  >> > >
  >> > >   # SHA1 implementations
  >> > >   '(1 3 14 3 2 26)' : [
  >> > >     Python.hash.SHA1,
  >> > >   ],
  >> > >
  >> > >   # Asymmetric ciphers
  >> > >
  >> > >   # RSA implementations
  >> > >   '(2 5 8 1 1)' : [ ],
  [...]
  >> > > - Is anybody scared by OIDs at all? Do all required
  >> > >   components
  >> > > (algorithms, prng, key stores, protocols) have OIDs assigned?
  >> > > (Likely not.)
  >> >
  >> > I am.  I'd rather go with aliases than with OIDs.  Other
  >> > opinions?
  >>
  >> Agreed. Aliases are better, but we are going to run into the
  >> problem of having to document them to solve 'rijndael' / 'aes'...

  MS> No problem to add additional support for aliases. But the
  MS> registry itself should be OID-based. If the registry is based on
  MS> aliases we have to maintain a name space.

OIDs make sense to me, though I'd rather not see them as Python
strings.  Rather, something like OID(2, 5, 8, 1, 1).  

SPKI provides a module with a bunch of standard OIDs already defined,
which can be used as aliases.

algid.py:
    oid_dsa = asn1.OID((1, 2, 840, 10040, 4, 1))
    oid_dsa_sha1 = asn1.OID((1, 2, 840, 10040, 4, 3))
    oid_md5 = asn1.OID((1, 2, 840, 113549, 2, 5))

usercode:
    algid.oid_md5

Jeremy




From dan at eevolved.com  Fri Feb 16 23:42:14 2001
From: dan at eevolved.com (Dan Parisien)
Date: Fri, 16 Feb 2001 17:42:14 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <14989.43274.415595.584500@w221.z064000254.bwi-md.dsl.cnc.net>
References: <2756067462.982008610@[10.0.0.100]>
            <01021321161600.03096@localhost.localdomain>
            <14989.43274.415595.584500@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <01021617421402.31117@localhost.localdomain>

On Friday 16 February 2001 17:26, you wrote:

>   DP> So a keyring API standard should be written. (Obviously I have
>   DP> no experience with keyrings, anyone else up to it?)
>
> This is a good plan.  There are some applications for which I would
> want a keyring that uses ZODB for storage.

Cool. I think /r$ mentioned something about interoperability with other apps.
Does ZODB connect well with non-python apps? That would be cool...
(obviously I have not been initiated to ZODB yet)

I also mentioned using an XML document as a keystore. Do you see this as
having advantages/disadvantages (except for the fact that it would be XML :)?
XML interoperability is pretty universal... Has anyone implemented a
shelve-like interface to an XML file yet? That would be quite an
achievement...

Dan




From jeremy at alum.mit.edu  Sat Feb 17 00:18:02 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 16 Feb 2001 18:18:02 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <01021617421402.31117@localhost.localdomain>
References: <2756067462.982008610@[10.0.0.100]>
            <01021321161600.03096@localhost.localdomain>
            <14989.43274.415595.584500@w221.z064000254.bwi-md.dsl.cnc.net>
            <01021617421402.31117@localhost.localdomain>
Message-ID: <14989.46378.791143.753505@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "DP" == Dan Parisien <dan at eevolved.com> writes:

  DP> On Friday 16 February 2001 17:26, you wrote: So a keyring API
  DP> standard should be written. (Obviously I have no experience with
  DP> keyrings, anyone else up to it?)
  >>
  >> This is a good plan.  There are some applications for which I
  >> would want a keyring that uses ZODB for storage.

  DP> Cool. I think /r$ mentioned something about interoperability
  DP> with other apps.  Does ZODB connect well with non-python apps?
  DP> That would be cool...  (obviously I have not been initiated to
  DP> ZODB yet)

No/maybe.  ZODB doesn't interact with non-Python apps at all, except
that it has a number of storage backends.  If the backend storage is
an RDBMS, then it would be possible to interoperate with other apps
via the database.  It doesn't sound pretty to me.

If you want more info about ZODB, you could see Andrew Kuchling's
ZODB pages: http://www.amk.ca/zodb/

  DP> I also mentioned using an XML document as a keystore. Do you see
  DP> this as having advantages/disadvantages (except for the fact
  DP> that it would be XML :)?  XML interoperability is pretty
  DP> universal... Has anyone implemented a shelve-like interface to
  DP> an XML file yet? That would be quite an achievement...

XML doesn't excite me, but I suppose it's as good as format as any.
(There isn't much different between XML and SPKI S-exps.)

Jeremy




From aarchiba at YAHOO.COM  Sat Feb 17 06:32:05 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Sat, 17 Feb 2001 00:32:05 -0500
Subject: [PYTHON-CRYPTO] Requirements
In-Reply-To: <01021617421402.31117@localhost.localdomain>; from
              dan@EEVOLVED.COM on Fri, Feb 16, 2001 at 05:42:14PM -0500
References: <2756067462.982008610@[10.0.0.100]>
            <01021321161600.03096@localhost.localdomain>
            <14989.43274.415595.584500@w221.z064000254.bwi-md.dsl.cnc.net>
            <01021617421402.31117@localhost.localdomain>
Message-ID: <20010217003205.J12837@hedgehog>

On Fri, Feb 16, 2001 at 05:42:14PM -0500, Dan Parisien wrote:

> I also mentioned using an XML document as a keystore. Do you see this as
> having advantages/disadvantages (except for the fact that it would be XML :)?
> XML interoperability is pretty universal... Has anyone implemented a
> shelve-like interface to an XML file yet? That would be quite an
> achievement...

I think that you might want to encode keys in XML (but store the whole
mess in a big database) so that you could easily add new fields and
complicated structure to the key data.  But the existing key encoding
standards seem to address these issues pretty well, so it might be better
to aim for interoperability rather than snazziness.

Personally, I'd like to see a GnuPG keyring backend.

Andrew




From aarchiba at YAHOO.COM  Fri Feb 16 20:43:50 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Fri, 16 Feb 2001 14:43:50 -0500
Subject: [PYTHON-CRYPTO] Existing python APIs
Message-ID: <20010216144350.I12837@hedgehog>

Hi,

It seems like it would be useful to take a look at existing pthon APIs
before attempting to design a unified one.  Thus:

- amkCrypto (subsumes mxCrypto):  wraps openSSL, contains code for a number
    of block and stream ciphers.  Contains code for hash functions, same
    interface as python native.  Contains code for HMACs.
    Contains code for RSA, ElGamal and DSA, but the interface is not very
    nice.  Contains a grab-bag of other stuff.  No code for interoperability
    of formats.

- pisces: implements SPKI.  Lives on top of amkCrypto.  Provides a whole
    lot of interoperability and serialization functions.  Wraps yarrow.
    What do people think of the API?  I've never used it.

- M2crypto: wraps openSSL.  Contains block and stream ciphers, HMACs, RSA,
    DH, DSA.  Adds SSL and S/MIME.  Designed for use by Zope (?).

- pyAES: wraps AES sample code.  API vaguely resembles that of amkCrypto,
    but is not compatible.  Does not provide unpadded CBC mode or support
    blocksizes other than 128 bits.  Also provides SHA256; interface resembles
    old outdated python hash API (no new() method).  Also contains a random
    number generator whose reliability is unclear.

- Builtin python crypto: just provides hash functions and a goofy
    enigma-type stream cipher.

- Mojonation writes their own crypto.  It's slow.

Any others that I'm missing?

Are any of these worth emulating?  I like amkCrypto's block and stream
cipher interface, and I like python's native hash interface.  Perhaps file
wrappers for both would be nice, though.  I don't like the interface
amkCrypto has for HMACs; they should be just hashes with a creation
argument.  I think pisces is at a different layer from most of the others,
but a collection of interoperability functions would be extremely useful.

What do you think?

Andrew




From jeremy at alum.mit.edu  Fri Feb 16 23:14:13 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 16 Feb 2001 17:14:13 -0500
Subject: [PYTHON-CRYPTO] Existing python APIs
In-Reply-To: <20010216144350.I12837@hedgehog>
References: <20010216144350.I12837@hedgehog>
Message-ID: <14989.42549.390092.999544@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "AA" == Andrew Archibald <aarchiba at yahoo.com> writes:

  AA> Hi, It seems like it would be useful to take a look at existing
  AA> pthon APIs before attempting to design a unified one.

Would something based on the Java crypto APIs make sense?  I am not
familiar with them, except that I'm aware they exist.  Using the same
API for Python would certainly make life easy for Jython users.

If people who are familiar with the Java APIs don't think we should
use them, it would be interesting to know why.  Are there any lessons
learned from the Java project?

Jeremy




From michael at STROEDER.COM  Fri Feb 16 23:55:24 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Fri, 16 Feb 2001 23:55:24 +0100
Subject: [PYTHON-CRYPTO] Existing python APIs
References: <20010216144350.I12837@hedgehog>
            <14989.42549.390092.999544@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <3A8DAFDC.9AAF3975@stroeder.com>

Jeremy Hylton wrote:
>
> >>>>> "AA" == Andrew Archibald <aarchiba at yahoo.com> writes:
>
>   AA> Hi, It seems like it would be useful to take a look at existing
>   AA> pthon APIs before attempting to design a unified one.
>
> Would something based on the Java crypto APIs make sense?  I am not
> familiar with them, except that I'm aware they exist.  Using the same
> API for Python would certainly make life easy for Jython users.

Yes, JCE was my starting point. I do not plan to reinvent the wheel
completely. :-)

> If people who are familiar with the Java APIs don't think we should
> use them, it would be interesting to know why.  Are there any lessons
> learned from the Java project?

Hmm, we should check out if there are any problems with intellectual
property rights.

Ciao, Michael.




From ngps at POST1.COM  Sat Feb 17 18:03:56 2001
From: ngps at POST1.COM (Ng Pheng Siong)
Date: Sun, 18 Feb 2001 01:03:56 +0800
Subject: [PYTHON-CRYPTO] Existing python APIs
In-Reply-To: <20010216144350.I12837@hedgehog>; from aarchiba@YAHOO.COM on Fri,
              Feb 16, 2001 at 02:43:50PM -0500
References: <20010216144350.I12837@hedgehog>
Message-ID: <20010218010356.B951@madcap.dyndns.org>

On Fri, Feb 16, 2001 at 02:43:50PM -0500, Andrew Archibald wrote:
> - M2crypto: wraps openSSL.  Contains block and stream ciphers, HMACs, RSA,
>     DH, DSA.  Adds SSL and S/MIME.  Designed for use by Zope (?).

Not designed for Zope. Zope was simply a convenient real-world system to
demonstrate M2Crypto's capabilities on. ;-)


> - Mojonation writes their own crypto.  It's slow.

IIRC, Mojonation's crypto is from one of the well-known C/C++ libraries.
The crypto shouldn't be slow; it's probably the bandwidth.


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




From michael at STROEDER.COM  Sat Feb 17 19:22:55 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 17 Feb 2001 19:22:55 +0100
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
References: <01021414564000.04866@localhost.localdomain>
            <3011163372.982263706@[10.0.0.100]>
            <14989.43927.102560.585012@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <3A8EC17F.3B936082@stroeder.com>

Jeremy Hylton wrote:
>
> Yes!  Trivial accessor methods are not Pythonic.

I would like to mandate assert statements for type-checking (which
is not Pythonic either).

This is not so easy with __setattr__() and __getattr__() constructs.

Ciao, Michael.




From jeremy at alum.mit.edu  Sat Feb 17 00:41:26 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 16 Feb 2001 18:41:26 -0500
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
In-Reply-To: <3A8EC17F.3B936082@stroeder.com>
References: <01021414564000.04866@localhost.localdomain>
            <3011163372.982263706@[10.0.0.100]>
            <14989.43927.102560.585012@w221.z064000254.bwi-md.dsl.cnc.net>
            <3A8EC17F.3B936082@stroeder.com>
Message-ID: <14989.47782.53086.179818@w221.z064000254.bwi-md.dsl.cnc.net>

Asserts should not be used for typechecking.  They are intended for
internal application sanity checking.  If a library raises an
assertion error, there is a bug in the library.  If there is a problem
with user code, e.g. the wrong arguments, the user should get an
exception like TypeError or ValueError.

Jeremy




From michael at STROEDER.COM  Sat Feb 17 20:01:26 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sat, 17 Feb 2001 20:01:26 +0100
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
References: <01021414564000.04866@localhost.localdomain>
            <3011163372.982263706@[10.0.0.100]>
            <14989.43927.102560.585012@w221.z064000254.bwi-md.dsl.cnc.net>
            <3A8EC17F.3B936082@stroeder.com>
            <14989.47782.53086.179818@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <3A8ECA86.535AE2DE@stroeder.com>

Jeremy Hylton wrote:
>
> Asserts should not be used for typechecking.  They are intended for
> internal application sanity checking.  If a library raises an
> assertion error, there is a bug in the library.  If there is a problem
> with user code, e.g. the wrong arguments, the user should get an
> exception like TypeError or ValueError.

Hmm, I wanted to mandate type-checking in kind of a style guide for
implementations. Do you have an idea how to achieve this goal in a
generic way? Off course TypeError or ValueError should be raised.
But if we have no access methods for attributes it's pretty ugly to
implement the check statements.

Ciao, Michael.




From drewpc at COLORADO.EDU  Sat Feb 17 21:23:43 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Sat, 17 Feb 2001 13:23:43 -0700
Subject: [PYTHON-CRYPTO] Existing python APIs
In-Reply-To: <14989.42549.390092.999544@w221.z064000254.bwi-md.dsl.cnc.net>
References: <20010216144350.I12837@hedgehog>
            <14989.42549.390092.999544@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <982441423.3a8eddcf119b9@webmail.colorado.edu>

Quoting Jeremy Hylton <jeremy at alum.mit.edu>:

> >>>>> "AA" == Andrew Archibald <aarchiba at yahoo.com> writes:
>
>   AA> Hi, It seems like it would be useful to take a look at existing
>   AA> pthon APIs before attempting to design a unified one.
>
> Would something based on the Java crypto APIs make sense?  I am not
> familiar with them, except that I'm aware they exist.  Using the same
> API for Python would certainly make life easy for Jython users.
>
> If people who are familiar with the Java APIs don't think we should
> use them, it would be interesting to know why.  Are there any lessons
> learned from the Java project?


I think that's a great idea.  Does anyone know the URL off the top of their
head?  I'm thinking it's off of java.sun.com...anyone know?



--
PC Drew




From drewpc at COLORADO.EDU  Sat Feb 17 21:33:27 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Sat, 17 Feb 2001 13:33:27 -0700
Subject: [PYTHON-CRYPTO] not pseudo code anymore!
In-Reply-To: <14989.44300.242773.61724@w221.z064000254.bwi-md.dsl.cnc.net>
References: <01021414564000.04866@localhost.localdomain>           
            <3011163372.982263706@[10.0.0.100]>
            <14989.44300.242773.61724@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <982442007.3a8ee017738fd@webmail.colorado.edu>

Quoting Jeremy Hylton <jeremy at alum.mit.edu>:

> A few comments on the PyCrypto code.  You've got a bunch of explicit
> assignments to __doc__:
>
> class SymmetricBase:
>         __doc__ = """
>             All symmetric algorithms must inherit from this base class.
>         """
>
>         __encryptKey = None
>         __keySize = None
>
>         def __init__(self, _encryptKey = None):
>                 __doc__ = """
>                     _encryptKey = default encrypt key
>
>                     1. check the key for validity and raise an error if
> it's not right
>                     2. set the key to be member variable
>                 """
>
> The __doc__ assignment are redundant for the class and incorrect for
> the functions.  For the function, you're creating a local variable
> named __doc__.  The correct way to write this is:
>
> class SymmetricBase:
>         """All symmetric algorithms must inherit from this base
> class."""
>
>         __encryptKey = None
>         __keySize = None
>
>         def __init__(self, _encryptKey = None):
>                 """"_encryptKey = default encrypt key
>
>                 1. check the key for validity and raise an error if
>                    it's not right
>                 2. set the key to be member variable
>                 """
>
> Also, it is typically to limit lines to less than 80 characters.
>
> Jeremy
>

Thank you, I didn't know that.  I'll change that and post a revision.

--
PC Drew




From michael at STROEDER.COM  Sun Feb 18 00:56:02 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 18 Feb 2001 00:56:02 +0100
Subject: [PYTHON-CRYPTO] Existing python APIs
References: <20010216144350.I12837@hedgehog>
Message-ID: <3A8F0F92.D6843DB3@stroeder.com>

Andrew Archibald wrote:
>
> - pisces: implements SPKI.  Lives on top of amkCrypto.  Provides a whole
>     lot of interoperability and serialization functions.  Wraps yarrow.
>     What do people think of the API?  I've never used it.

IMHO it's the most Pythonic implementation of a crypto protocol.
E.g. things like RSA key classes etc. I mainly used (and patched)
the ASN.1 module for parsing X.509 certs/CRLs.

> - M2crypto: wraps openSSL.  Contains block and stream ciphers, HMACs, RSA,
>     DH, DSA.  Adds SSL and S/MIME.

I like the functionality, really feature-rich. I definitely don't
like the OpenSSL BIO interface passed through to Python by SWIG. The
BIO stuff of OpenSSL is somewhat an emulation of an object-model in
C. M2Crypto's author Ng Pheng Siong also wrote a couple of Python
wrapper classes to make it more friendly for pure Python developers
like me. ;-)

> Are any of these worth emulating?  I like amkCrypto's block and stream
> cipher interface,

I will examine that.

> and I like python's native hash interface.

It's pretty similar to the stuff JCE defines. But hashes are the
most simple thing...

Ciao, Michael.




From stevena at NEOSYNAPSE.NET  Sun Feb 18 07:17:29 2001
From: stevena at NEOSYNAPSE.NET (Steven D. Arnold)
Date: Sun, 18 Feb 2001 01:17:29 -0500
Subject: [PYTHON-CRYPTO] ANN: Pure Python Encryption [UPDATE]
Message-ID: <5.0.2.1.2.20010218011156.03cacbe8@phear.dementian.com>

We've posted an update to the Neosynapse Encryption Tools' IDEA
implementation.  There was a bug that caused incorrect encryption and
decryption, even though the test passed.  If you downloaded the previous
version, you should get the new copy.  Apologies for the inconvenience;
enjoy!  The software may be downloaded from:

         http://www.neosynapse.net/free_encrypt.htm


--
Steven D. Arnold                   President, Neosynapse Consulting Group
stevena at neosynapse.net                          http://www.neosynapse.net




From michael at STROEDER.COM  Sun Feb 18 18:57:48 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Sun, 18 Feb 2001 18:57:48 +0100
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
Message-ID: <3A900D1C.AAE48374@stroeder.com>

HI!

I started to design the module layout, wrote some base classes for
hashs and the loader mechanism for my PyCrypto proposal. I did not
get as far as I wanted (yeah, social and commercial life... ;-) but
it's a start.

Please have a look at this small archive:


http://www.stroeder.com/python/PyCrypto/PyCrypto-proposal-2001-02-18.tar.gz

I will try to continously improve the documentation found on:

 http://www.stroeder.com/python/PyCrypto/proposal.html

I would like to follow this short-time roadmap:

1. Discuss open issues of loader mechanism and module layout:
 - Which key type for registry dictionary?
   OIDs? Which representation of OIDs? String vs. tuple.
 - Should we maintain the alias registry? How? dumpasn1.cfg?
 - Passing arguments in factory function
PyCrypto.registry.getInstance()
   to __init__() methods of implementation classes.
 - Performance? (mainly startup latency)
 - Implementors here should think about how to tie their modules to
   this loader.
 - Implementation registration unambigous and thread-safe?
 - Documentation of this part.

2. Discuss class API of algorithm implementations:
 - Hashes are easy and almost complete (see sources for examples).
 - Please provide some wrapper class examples for e.g. M2Crypto.
 - Collect as many requirements for cipher class API as possible
   + key formats
   + modes
   + etc.

Ciao, Michael.




From dan at eevolved.com  Sun Feb 18 19:48:38 2001
From: dan at eevolved.com (Dan Parisien)
Date: Sun, 18 Feb 2001 13:48:38 -0500
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
In-Reply-To: <3A900D1C.AAE48374@stroeder.com>
References: <3A900D1C.AAE48374@stroeder.com>
Message-ID: <01021813483800.12757@localhost.localdomain>

On Sunday 18 February 2001 12:57, you wrote:
>
> http://www.stroeder.com/python/PyCrypto/PyCrypto-proposal-2001-02-18.tar.gz
>
> I will try to continously improve the documentation found on:
>
>  http://www.stroeder.com/python/PyCrypto/proposal.html

Nice document structure :)
Excellent initiative.

I'm not certain pyAES is pure python. Not the rijndael anyways.. it's a
swigged up c implementation.

> I would like to follow this short-time roadmap:
>
> 1. Discuss open issues of loader mechanism and module layout:
>  - Which key type for registry dictionary?
>    OIDs? Which representation of OIDs? String vs. tuple.

I agree with the tuple approach. Tuples can be used as keys in dictionaries
as well, so that simplifies lookup tasks. They can also be concatenated to
and I think I read in a previous post of yours that OIDs are prefixes and can
be extended to (so that problem is solved also).

>  - Passing arguments in factory function
> PyCrypto.registry.getInstance()
>    to __init__() methods of implementation classes.

As classes are a type just like any other, why not just return a reference to
the class and instantiate that?

>  - Performance? (mainly startup latency)

Q - Does this only apply when you need to access the implementation registry?
If you do not need the implementation registry, could you not use it?

Also, could the registry be implemented as a pickled dictionary contained in
a simple text file? Because it will be written to infrequently and read from
often... It may speed up the loading process.

>  - Implementors here should think about how to tie their modules to
>    this loader.

Add themselves to the pickled file in their setup.py distutils script?

>  - Documentation of this part.
>
> 2. Discuss class API of algorithm implementations:

I will read the code later.
Good job Michael.

Peace,
Dan




From michael at STROEDER.COM  Mon Feb 19 00:37:18 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Mon, 19 Feb 2001 00:37:18 +0100
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
References: <3A900D1C.AAE48374@stroeder.com>
            <01021813483800.12757@localhost.localdomain>
Message-ID: <3A905CAE.DE9DFAC2@stroeder.com>

Dan Parisien wrote:
>
> >  - Passing arguments in factory function
> > PyCrypto.registry.getInstance()
> >    to __init__() methods of implementation classes.
>
> As classes are a type just like any other, why not just return a reference
> to the class and instantiate that?

I already thought about just returning the class. Well, some people
might be concerned about having to instantiate the object themselves
(one extra line of code). We can provide both. No problem.

> >  - Performance? (mainly startup latency)
>
> Q - Does this only apply when you need to access the implementation
> registry?
> If you do not need the implementation registry, could you not use it?

Off course you can import the implementation modules directly.

> Also, could the registry be implemented as a pickled dictionary contained in
> a simple text file? Because it will be written to infrequently and read from
> often... It may speed up the loading process.

I did some experiments with reading pickled (binary, cPickle) config
files instead of config modules when doing CGI-BIN programming. It
was slower than importing a config modules in my case. Also the
registry itself is built by the implementation modules. The
important thing is to avoid unnecessary import's in the PyCrypto
module itself. E.g. someone just wanting to use a hash function
should not be bothered with startup latency from importing a SSL
module...

> >  - Implementors here should think about how to tie their modules to
> >    this loader.
>
> Add themselves to the pickled file in their setup.py distutils script?

No. Call PyCrypto.registerImplementation() to register compliant
implementation classes. But the cipher base classes yet have to be
defined.

> I will read the code later.

Most times my code is ahead my documentation...

Ciao, Michael.




From aarchiba at YAHOO.COM  Tue Feb 20 18:30:47 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Tue, 20 Feb 2001 12:30:47 -0500
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
In-Reply-To: <3A905CAE.DE9DFAC2@stroeder.com>; from michael@STROEDER.COM on
              Mon, Feb 19, 2001 at 12:37:18AM +0100
References: <3A900D1C.AAE48374@stroeder.com>
            <01021813483800.12757@localhost.localdomain>
            <3A905CAE.DE9DFAC2@stroeder.com>
Message-ID: <20010220123047.A16163@hedgehog>

On Mon, Feb 19, 2001 at 12:37:18AM +0100, Michael Str?der wrote:
> Dan Parisien wrote:
> >
> > >  - Passing arguments in factory function
> > > PyCrypto.registry.getInstance()
> > >    to __init__() methods of implementation classes.
> >
> > As classes are a type just like any other, why not just return a reference
> > to the class and instantiate that?
>
> I already thought about just returning the class. Well, some people
> might be concerned about having to instantiate the object themselves
> (one extra line of code). We can provide both. No problem.

Well, it's actually no extra lines of code but it looks sort of
disturbing:

machine = PyCrypto.registry.getInstance("blowfish")(mode=PyCrypto.block.CBC,
                                                    IV=my_iv,
                                                    key="seekrit")

Or, I suppose:

blowfish = PyCrypto.regstry.getInstance("blowfish")
machine = blowfish(mode=blowfish.CBC, IV=my_iv, key="seekrit")

I should point out, that if you do this, then it shouldn't be called
getImplementation.  I'd be tempted to just call it 'get'.

> > If you do not need the implementation registry, could you not use it?
>
> Off course you can import the implementation modules directly.

It is important that this have a similar interface: for example, you
shouldn't need different startup arguments, or different function
calls.

Questions I have:
What should be done about algorithms that have no OID yet?  Pick a
random one?  Put them in under some canonical name?  Presumably there
will be few implementations of such an algorithm, so it doesn't really
matter if you have the magic multiple-implementations hack, but it
would be nice to still be able to use the same code to get at it.

How hard is it to find ASN.1 OIDs for known algorithms?  I certainly
don't know where to look to find out how to register (say) arcfour in
the registry.

In your algorithm categories, is "Ciphers" supposed to cover both
symmetric and asymmetric algorithms?  Is "Hashes" supposed to cover
both keyed and unkeyed hashes?

If we provide a registerImplementation method, we should also provide
an unregisterImplementation method --- If I disintall openSSL because
it has a security hole, all my Python applications shouldn't start
dying.

An alternative would be to scan the directory structure on demand.
This is probably too slow.

Thanks,
Andrew




From drewpc at COLORADO.EDU  Tue Feb 20 20:04:28 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Tue, 20 Feb 2001 12:04:28 -0700
Subject: [PYTHON-CRYPTO] SourceForge Project Approved (fwd)
Message-ID: <3418125362.982670668@[10.0.0.100]>

Looks like we've got a home.  If people have concerns about the US's strong
encryption laws, then we can keep using this list as well.

---------- Forwarded Message ----------
Date: Tuesday, February 20, 2001 10:14 AM -0800
From: noreply at sourceforge.net
To: drewpc at colorado.edu
Subject: SourceForge Project Approved

Your project registration for SourceForge has been approved.

Project Full Name:  PyCrypto
Project Unix Name:  pycrypto
CVS Server:         cvs.pycrypto.sourceforge.net
Shell/Web Server:   pycrypto.sourceforge.net

Your DNS will take up to a day to become active on our site. Your shell
accounts will become active at the next 6-hour cron update. While
waiting for your DNS to resolve, you may try shelling into
shell.sourceforge.net and pointing CVS to cvs.sourceforge.net.

If after six hours your shell accounts still do not work, please
open a support ticket so that we may take a look at the problem.
Please note that all shell accounts are closed to telnet and only
work with SSH1.

Your web site is accessible through your shell account. Directory
information will be displayed immediately after logging in.

Please take some time to read the site documentation about project
administration. If you visit your own project page in SourceForge
while logged in, you will find additional menu functions to your left
labeled "Project Administrator".

We highly suggest that you now visit SourceForge and create a public
description for your project. This can be done by visiting your project
page while logged in, and selecting 'Project Admin' from the menus
on the left.

Your project will also not appear in the Trove software map until
you categorize it in the project administration screens. So that
people can find your project, you should do this now. Visit your project
while logged in, and select 'Project Admin' from the menus on the
left.

Enjoy the system, and please tell others about SourceForge. Let us know
if there is anything we can do to help you.

  -- the SourceForge crew

---------- End Forwarded Message ----------



--
PC Drew

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




From dan at eevolved.com  Tue Feb 20 20:00:12 2001
From: dan at eevolved.com (Dan Parisien)
Date: Tue, 20 Feb 2001 14:00:12 -0500
Subject: [PYTHON-CRYPTO] SourceForge Project Approved (fwd)
In-Reply-To: <3418125362.982670668@[10.0.0.100]>
References: <3418125362.982670668@[10.0.0.100]>
Message-ID: <01022014001100.01083@localhost.localdomain>

On Tuesday 20 February 2001 14:04, you wrote:
> Looks like we've got a home.  If people have concerns about the US's strong
> encryption laws, then we can keep using this list as well.

Here's an interesting post:
http://sourceforge.net/forum/forum.php?thread_id=76060&forum_id=2

Note that he's not a lawyer, just a sysadmin...

Peace,
Dan




From drewpc at COLORADO.EDU  Tue Feb 20 20:19:53 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Tue, 20 Feb 2001 12:19:53 -0700
Subject: [PYTHON-CRYPTO] SourceForge Project Approved (fwd)
In-Reply-To: <01022014001100.01083@localhost.localdomain>
Message-ID: <3419050252.982671593@[10.0.0.100]>

he came to the same conclusion that I did: it's kind of okay to do this.
Here's what I'm thinking...post the code and a statement saying that you
better know your own encryption regulations.  We are not responsible if you
violate them.

By the way, does anyone know a lawyer who has researched this?  It seems
that with the new change in US laws, no one knows what the hell's going on.

--On Tuesday, February 20, 2001 2:00 PM -0500 Dan Parisien
<dan at eevolved.com> wrote:

> On Tuesday 20 February 2001 14:04, you wrote:
>> Looks like we've got a home.  If people have concerns about the US's
>> strong encryption laws, then we can keep using this list as well.
>
> Here's an interesting post:
> http://sourceforge.net/forum/forum.php?thread_id=76060&forum_id=2
>
> Note that he's not a lawyer, just a sysadmin...
>
> Peace,
> Dan



--
PC Drew

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




From drewpc at COLORADO.EDU  Tue Feb 20 20:36:53 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Tue, 20 Feb 2001 12:36:53 -0700
Subject: [PYTHON-CRYPTO] Lists
Message-ID: <3420070332.982672613@[10.0.0.100]>

I've created 3 mailing lists for the PyCrypto package on Sourceforge:

PyCrypto-announce: this is for announcing new releases and security fixes
and stuff
PyCrypto-general: this is for API discussion (they wouldn't let me have
PyCrytpo-api, it wasn't long enough)

PyCrypto-discussion: this is for discussion of different implementations,
PRNGs, etc.  It is okay to discuss anything crypto related on this list.

They'll be up and running within 24 hours apparently.

--
PC Drew

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




From michael at STROEDER.COM  Wed Feb 21 09:18:54 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 21 Feb 2001 09:18:54 +0100
Subject: [PYTHON-CRYPTO] SourceForge Project Approved (fwd)
References: <3419050252.982671593@[10.0.0.100]>
Message-ID: <3A9379EE.89C59211@stroeder.com>

PC Drew wrote:
>
> he came to the same conclusion that I did: it's kind of okay to do this.
> Here's what I'm thinking...post the code and a statement saying that you
> better know your own encryption regulations.  We are not responsible if you
> violate them.
>
> By the way, does anyone know a lawyer who has researched this?  It seems
> that with the new change in US laws, no one knows what the hell's going on.

This was discussed to death on openssl-dev list. I'm not keen on a
new discussion. And I'm not in favour of hosting on SourceForge.

Guess why I started a mailing list in NL instead of A.M. Kuchling's
list hosted on eGroups (US).

Ciao, Michael.




From michael at STROEDER.COM  Wed Feb 21 09:30:53 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 21 Feb 2001 09:30:53 +0100
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
References: <3A900D1C.AAE48374@stroeder.com>
            <01021813483800.12757@localhost.localdomain>
            <3A905CAE.DE9DFAC2@stroeder.com> <20010220123047.A16163@hedgehog>
Message-ID: <3A937CBD.FFFA83A1@stroeder.com>

Andrew Archibald wrote:
>
> machine = PyCrypto.registry.getInstance("blowfish")(mode=PyCrypto.block.CBC,
>                                                     IV=my_iv,
>                                                     key="seekrit")
>
> Or, I suppose:
>
> blowfish = PyCrypto.regstry.getInstance("blowfish")
> machine = blowfish(mode=blowfish.CBC, IV=my_iv, key="seekrit")

Actually it's PyCrypto.getInstance(). I will just provide an extra
PyCrypto.getClass() to make everyone happy.

> Questions I have:
> What should be done about algorithms that have no OID yet?  Pick a
> random one?

Several options:
- Use unique string names to register (good for testing).
- Use private OID arc for testing (good for testing).
- Use a registered OID arc for assigning authorized OIDs.

> How hard is it to find ASN.1 OIDs for known algorithms?

Peter Gutmann is maintaining a config file for his dumpasn1 tool:

  http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.cfg

It's the most complete and clean list I know of.

> In your algorithm categories, is "Ciphers" supposed to cover both
> symmetric and asymmetric algorithms?

Yes. But it's just the base class. Separate derived classes
AsymmetricCipher(Cipher) and SymmetricCipher(Cipher) are defined.

>  Is "Hashes" supposed to cover
> both keyed and unkeyed hashes?

Yes. Feel free to give me reasons to separate it. Note: I focused on
the load mechanism.

> If we provide a registerImplementation method, we should also provide
> an unregisterImplementation method --- If I disintall openSSL because
> it has a security hole, all my Python applications shouldn't start
> dying.

I don't know how to do that. If your applications are running and
were using OpenSSL it seems unpossible for me to deinstall OpenSSL
without messing up the applications.

> An alternative would be to scan the directory structure on demand.

This imposes strong rules to the directory layout of implementations
which I'd like to avoid.

Ciao, Michael.




From drewpc at COLORADO.EDU  Wed Feb 21 15:32:02 2001
From: drewpc at COLORADO.EDU (PC Drew)
Date: Wed, 21 Feb 2001 07:32:02 -0700
Subject: [PYTHON-CRYPTO] SourceForge Project Approved (fwd)
In-Reply-To: <3A9379EE.89C59211@stroeder.com>
Message-ID: <3488178882.982740722@[10.0.0.100]>

--On Wednesday, February 21, 2001 9:18 AM +0100 Michael Str?der <michael at STROEDER.COM> wrote:

>
> This was discussed to death on openssl-dev list. I'm not keen on a
> new discussion. And I'm not in favour of hosting on SourceForge.
>
> Guess why I started a mailing list in NL instead of A.M. Kuchling's
> list hosted on eGroups (US).

I can certainly appreciate your position.  I'm grateful to you for setting up this list and maintaining it.  I plan on staying a member of this list as well as the new lists.  I invite everyone who feels comfortable to, to join the SourceForge list as well.  I will be posting the API and goals that we've discussed for the groups' evalutation soon.

--
PC Drew

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




From jeremy at alum.mit.edu  Wed Feb 21 15:48:44 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 21 Feb 2001 09:48:44 -0500
Subject: [PYTHON-CRYPTO] Lists
In-Reply-To: <3420070332.982672613@[10.0.0.100]>
References: <3420070332.982672613@[10.0.0.100]>
Message-ID: <14995.54604.911471.78569@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "PCD" == PC Drew <drewpc at COLORADO.EDU> writes:

  PCD> I've created 3 mailing lists for the PyCrypto package on
  PCD> Sourceforge:

Are these list intended to replace the current list (which in turned
replaced the previous list hosted by egroups/yahoo)?  There have been
new lists created at a dizzying rate in the last few weeks.  I think
I've spent more time exchaning mail with MLMs and reply-bots than I
have with the lists members.

Let's have a moratorium on new lists.

Jeremy




From aarchiba at YAHOO.COM  Wed Feb 21 18:45:29 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Wed, 21 Feb 2001 12:45:29 -0500
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
In-Reply-To: <3A937CBD.FFFA83A1@stroeder.com>; from michael@STROEDER.COM on
              Wed, Feb 21, 2001 at 09:30:53AM +0100
References: <3A900D1C.AAE48374@stroeder.com>
            <01021813483800.12757@localhost.localdomain>
            <3A905CAE.DE9DFAC2@stroeder.com> <20010220123047.A16163@hedgehog>
            <3A937CBD.FFFA83A1@stroeder.com>
Message-ID: <20010221124529.A30494@hedgehog>

On Wed, Feb 21, 2001 at 09:30:53AM +0100, Michael Str?der wrote:

> Actually it's PyCrypto.getInstance(). I will just provide an extra
> PyCrypto.getClass() to make everyone happy.

Thank you.

> Andrew Archibald wrote:
> > In your algorithm categories, is "Ciphers" supposed to cover both
> > symmetric and asymmetric algorithms?
>
> Yes. But it's just the base class. Separate derived classes
> AsymmetricCipher(Cipher) and SymmetricCipher(Cipher) are defined.

Hmm.  Well, I guess we're going to define that part of the API later, but
I'm not sure I see what parts of the interface aymmetric ciphers share with
symmetric ciphers.

> >  Is "Hashes" supposed to cover
> > both keyed and unkeyed hashes?
>
> Yes. Feel free to give me reasons to separate it. Note: I focused on
> the load mechanism.

No, that's good.

> > If we provide a registerImplementation method, we should also provide
> > an unregisterImplementation method --- If I disintall openSSL because
> > it has a security hole, all my Python applications shouldn't start
> > dying.
>
> I don't know how to do that. If your applications are running and
> were using OpenSSL it seems unpossible for me to deinstall OpenSSL
> without messing up the applications.

Well, actually what I meant was this:

Suppose I have a running system, wth a bunch of applications that work.
But it's too slow so I install openSSL as the default implementation.  Then
they find a buffer overflow in openSSL, so I de-install it.  My
applications should not fail the next time I start them.  In other words,
openSSL should be removed from the listing of possible implementations.

Thanks,
Andrew




From michael at STROEDER.COM  Wed Feb 21 18:56:42 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 21 Feb 2001 18:56:42 +0100
Subject: [PYTHON-CRYPTO] Lists
References: <3420070332.982672613@[10.0.0.100]>
            <14995.54604.911471.78569@w221.z064000254.bwi-md.dsl.cnc.net>
Message-ID: <3A94015A.5005F1CE@stroeder.com>

Jeremy Hylton wrote:
>
> Let's have a moratorium on new lists.

Yes, I'm also not pleased about this uncoordinated SourceForge
opening which subverts my intention to have a list in a
crypto-liberal country.

I see no problem to start with the API with out a CVS archive and I
will ask the mailing list provider for a possibility to host a CVS
archive either if we ever manage to produce a worth mentioning
amount of code.

Ciao, Michael.




From michael at STROEDER.COM  Wed Feb 21 19:01:06 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 21 Feb 2001 19:01:06 +0100
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
References: <3A900D1C.AAE48374@stroeder.com>
            <01021813483800.12757@localhost.localdomain>
            <3A905CAE.DE9DFAC2@stroeder.com> <20010220123047.A16163@hedgehog>
            <3A937CBD.FFFA83A1@stroeder.com> <20010221124529.A30494@hedgehog>
Message-ID: <3A940262.890FCA9F@stroeder.com>

Andrew Archibald wrote:
>
> Suppose I have a running system, wth a bunch of applications that work.
> But it's too slow so I install openSSL as the default implementation.  Then
> they find a buffer overflow in openSSL, so I de-install it.  My
> applications should not fail the next time I start them.  In other words,
> openSSL should be removed from the listing of possible implementations.

The implementation registry is created each time the configuration
module imports the implementations because the existing
implementation register themselves at startup triggered by import
statement in PyCryptoCfg (private) or PyCrypto.cfg (system-wide).

Ciao, Michael.




From aarchiba at YAHOO.COM  Wed Feb 21 19:12:19 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Wed, 21 Feb 2001 13:12:19 -0500
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
In-Reply-To: <3A93E845.1ABCA65@stroeder.com>; from michael@STROEDER.COM on
              Wed, Feb 21, 2001 at 05:09:41PM +0100
References: <3A900D1C.AAE48374@stroeder.com>
            <01021813483800.12757@localhost.localdomain>
            <3A905CAE.DE9DFAC2@stroeder.com> <20010220123047.A16163@hedgehog>
            <3A93E845.1ABCA65@stroeder.com>
Message-ID: <20010221131219.B30494@hedgehog>

On Wed, Feb 21, 2001 at 05:09:41PM +0100, Michael Str?der wrote:
> Andrew Archibald wrote:
> >
> > I should point out, that if you do this, then it shouldn't be called
> > getImplementation.  I'd be tempted to just call it 'get'.
>
> Why?

On general principles I prefer to have names be as simple and direct as
possible.  If this function is in the module PyCrypto.registry, and the
only thing that ever gets returned is classes, then all you need to know is
that the function is called get().  If there are three or four different
types of things that can be obtained, or if the name of the module doesn't
make it clear what you can expect to obtain when you call the funciton,
then by all means make it more detailed (although I still prefer
underscores (get_foo) to studlycaps (getFoo) I realize that I am in the
minority)

Thanks,
Andrew




From michael at STROEDER.COM  Wed Feb 21 17:09:41 2001
From: michael at STROEDER.COM (Michael =?iso-8859-1?Q?Str=F6der?=)
Date: Wed, 21 Feb 2001 17:09:41 +0100
Subject: [PYTHON-CRYPTO] PyCrypto Draft: Proposal 2001-02-18
References: <3A900D1C.AAE48374@stroeder.com>
            <01021813483800.12757@localhost.localdomain>
            <3A905CAE.DE9DFAC2@stroeder.com> <20010220123047.A16163@hedgehog>
Message-ID: <3A93E845.1ABCA65@stroeder.com>

Andrew Archibald wrote:
>
> I should point out, that if you do this, then it shouldn't be called
> getImplementation.  I'd be tempted to just call it 'get'.

Why?

Ciao, Michael.




From jeremy at alum.mit.edu  Wed Feb 21 18:50:23 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Wed, 21 Feb 2001 12:50:23 -0500
Subject: [PYTHON-CRYPTO] Lists
In-Reply-To: <3A94015A.5005F1CE@stroeder.com>
References: <3420070332.982672613@[10.0.0.100]>
            <14995.54604.911471.78569@w221.z064000254.bwi-md.dsl.cnc.net>
            <3A94015A.5005F1CE@stroeder.com>
Message-ID: <14995.65503.274658.12017@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "MS" == Michael  Str?der <michael at STROEDER.COM>> writes:

  MS> I see no problem to start with the API with out a CVS archive
  MS> and I will ask the mailing list provider for a possibility to
  MS> host a CVS archive either if we ever manage to produce a worth
  MS> mentioning amount of code.

I don't see a problem with hosting the code at SourceForge either.
It's well-run and has a very useful set of services.

Jeremy




From Guido.Treutwein at NBG.SIEMENS.DE  Thu Feb 22 09:25:35 2001
From: Guido.Treutwein at NBG.SIEMENS.DE (Treutwein Guido)
Date: Thu, 22 Feb 2001 09:25:35 +0100
Subject: [PYTHON-CRYPTO] A pythonic way of calling crypto algorithms
Message-ID: <05A95AAB7DF7D011832000A0C942886F05D79142@nbgv045a.nbg.siemens.de>

Hi all,

I'm not sure how settled the design is in respect to calling the algorithm,
once it is found via the mechanisms discussed here, but we found the
following approach quite useful:
        # alg() is assumed to be a cryptographic algorithm

        cipher = alg(plain="something", key=aKey)
#encrypt or signature generation or MAC computation
        plain  = alg(cipher="$#qq!", key=aKey)
#decrypt
                alg(plain="something", cipher="$#qq!", key=aKey)        #MAC
or signature verification
In the last case its a matter of taste, whether an exception results in the
mismatch case, or something true is returned in the match case (e.g.
timestamp) or both.

The advantages are
- everything can be handled within the algorithm itself (so a hashing
function would reject the decrpytion by raising an exception)
- all types of algorithms can be called uniformly
- no magic constants are needed for encryption/decryption

Guido Treutwein
guido.treutwein at nbg.siemens.de




From aarchiba at YAHOO.COM  Thu Feb 22 18:13:54 2001
From: aarchiba at YAHOO.COM (Andrew Archibald)
Date: Thu, 22 Feb 2001 12:13:54 -0500
Subject: [PYTHON-CRYPTO] A pythonic way of calling crypto algorithms
In-Reply-To: <05A95AAB7DF7D011832000A0C942886F05D79142@nbgv045a.nbg.siemens.de>; from Guido.Treutwein@NBG.SIEMENS.DE
              on Thu, Feb 22, 2001 at 09:25:35AM +0100
References: <05A95AAB7DF7D011832000A0C942886F05D79142@nbgv045a.nbg.siemens.de>
Message-ID: <20010222121353.A15892@hedgehog>

On Thu, Feb 22, 2001 at 09:25:35AM +0100, Treutwein Guido wrote:
> Hi all,

Hi,

> I'm not sure how settled the design is in respect to calling the algorithm,
> once it is found via the mechanisms discussed here, but we found the
> following approach quite useful:
>         # alg() is assumed to be a cryptographic algorithm
>
>         cipher = alg(plain="something", key=aKey)
> #encrypt or signature generation or MAC computation
>         plain  = alg(cipher="$#qq!", key=aKey)
> #decrypt
>                 alg(plain="something", cipher="$#qq!", key=aKey)        #MAC
> or signature verification
> In the last case its a matter of taste, whether an exception results in the
> mismatch case, or something true is returned in the match case (e.g.
> timestamp) or both.

Hmm.  There seem to be some problems with this approach.  A very common
mode of usage of a block cipher, for example, is to set up a cipher in CBC
mode, hand it a packet, send off the ciphertext, hand it another packet,
send off the ciphertext, etc., with appropriate chaining between packets.
In this sort of application, it is important that the cipher be able to
save some state --- key setup for some ciphers (eg, Blowfish) is very
expensive.  So it is important that it be possible to save the machine with
keys all set up.

Similarly, a very common way to use a hash function is to set up a context
and shovel data into it as it becomes available.  This interface would
require all the data we will want to hash to be stored in one string.  This
is inappropriate, for example, for the Yarrow RNG, where what is being
hashed is an ever-growing stream of data.

So these design criteria suggest (to me) that the API should make available
"cipher machine" objects that encapsulate this sort of state.

> The advantages are
> - everything can be handled within the algorithm itself (so a hashing
> function would reject the decrpytion by raising an exception)
> - all types of algorithms can be called uniformly
> - no magic constants are needed for encryption/decryption

I don't think it's actually a good thing that all algorithms are treated
uniformly.  Cryptographic algorithms do very different things; why should
one treat them the same?

As I see it, the major categories of algorithm we have to support are
these:

Symmetric Algorithms
        Hashes
                Keyed hashes
                Unkeyed hashes
        Encryption
                Block ciphers
                Stream ciphers

Asymmetric Algorithms
        Signing/Verifying
        Encrypting/Decrypting

Protocols and Other
        Key agreement (Diffie-Hellman etc.)
        Package transforms
        Secret sharing

Interoperability
        Reading/Writing cryptographic data in various formats
        Key management
                Managing secrets --- burning passphrases when no longer
                needed, for example
                Keyring manipulation
        Implementations of various standards (SSL, S/MIME, OpenPGP, etc.)

I don't think it's even a good idea to try to make these look exactly the
same.  Of course, it would be easy to argue with my hierarchy; for example,
a MAC is essentially a hash function with a key, but it is also the
symmetric equivalent of a digital signature.  Asymmetric encryption should
perhaps be lumped in with symmetric encryption, but its behaviour is very
different (doesn't operate nicely on fixed-length bitstrings, for example).

So if anyone wants to start defining a class hierarchy for cryptographic
algorithms, I'll be very interested to see how they organize it.

Thanks,
Andrew




From jeremy at alum.mit.edu  Sun Feb 18 18:22:58 2001
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Sun, 18 Feb 2001 12:22:58 -0500 (EST)
Subject: Existing python APIs
In-Reply-To: <3A8F0F92.D6843DB3@stroeder.com>
References: <20010216144350.I12837@hedgehog>
	<3A8F0F92.D6843DB3@stroeder.com>
Message-ID: <14992.1266.743418.216213@w221.z064000254.bwi-md.dsl.cnc.net>

>>>>> "MS" == Michael Str?der <michael at STROEDER.COM>> writes:

  MS> Andrew Archibald wrote:
  >>
  >> - pisces: implements SPKI.  Lives on top of amkCrypto.  Provides
  >>   a whole
  >> lot of interoperability and serialization functions.  Wraps
  >> yarrow.  What do people think of the API?  I've never used it.

  MS> IMHO it's the most Pythonic implementation of a crypto protocol.
  MS> E.g. things like RSA key classes etc. I mainly used (and
  MS> patched) the ASN.1 module for parsing X.509 certs/CRLs.

BTW, I have had some conversations with CNRI recently and think there
may be an opportunity to re-release Pisces with an OSI-approved,
GPL-compatible license.  If this happens, I'm going to start a
SourceForge project.

Keep your fingers crossed :-).

Jeremy