[PYTHON-CRYPTO] SIG thoughts.

[Bryan Mongeau]

<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