[PYTHON-CRYPTO] PEP (was Re: [PYTHON-CRYPTO] aes library)

[Phil Mayers]

There seems to be an opinion:

"None of these applications actually *need* more than one cipher, therefore no
application would ever need more than one cipher, and all new applications will
be using AES anyway, because. So, we don't need a crypto interface."

I (and others, it seems) disagree with this entirely.

Kerberos can and does require two (A DES variant and MS ARCFOUR) or even three
(DES, 3DES, ARCFOUR) or four (DES, 3DES, ARCFOUR, AES) depending on how many
legacy systems you have to interoperate with. It is possible (and not
unreasonable) to get a TGT in ARCFOUR in a Win2K realm, then get a service
ticket in 3DES for a MIT machine in that realm. Or, a TGT in AES, and a
user2user ticket in ARCFOUR for a downlevel user. And so on...

There's another point as well. If there isn't a standard interface, anyone who
wants pluggable crypto systems (a reasonable amount of people) will just have
to write, debug and maintain their own each time. Python is supposed to
be "batteries included" - but not crypto included?

The area of DB adaptors has been mentioned - several of those (e.g. psycopg)
implement extensions. If any algorithm has problems with the standard interface
being too limiting, it can provide an extension. It can provide a whole other
class in it's module, or a whole other module. But that doesn't eliminate the
utility of having a standard interface.

--
Regards,
Phil

+------------------------------------------+
| Phil Mayers                              |
| Network & Infrastructure Group           |
| Information & Communication Technologies |
| Imperial College                         |
+------------------------------------------+


Quoting Paul Rubin <phr-pycrypt at nightsong.com>:

>     It's not very clear to me quite what this means, but I think we should
>     take as a typical sort of task implementing the TLS or SSH protocols;
>     for such a task we want a list of good ciphers, hash functions, and
>     MACs, callable similarly; and in particular we need to be able to
>     control exactly how padding is done and IVs are computed (the SSH
>     protocol, for example, gives an algorithm for computing all IVs from
>     the initial connection secret and the shared secret obtained from it).
>     So doing the IVs for the poor dumb user is not necessarily a good
>     idea.
>
> In practice, 3DES and RC4 are the only ciphers anyone uses in these
> protocols, with AES starting to be used in SSH.  All conformant TLS
> implementations are required to support 3DES, so everything else can
> be ignored, unless you're trying to write a protocol analyzer rather
> than a communication stack.  I believe the same is true of SSH.
>


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/