[PYTHON-CRYPTO] PEP-272 Deficiencies - Comments

[Paul]

At 3:54 PM -0700 12/15/01, Jason R. Mastaler wrote:
>phr-pycrypt at nightsong.com writes:
>
>>  Is a draft copy of PEP 272 actually available somewhere?
>
>http://python.sourceforge.net/peps/pep-0272.html

This api has several problems:

1) I agree with Janusz A. Urbanowicz's earlier note that symmetric
encryption should be a class.  The initialization can give it the
key.  Note that it may later need to be reinitialized, so a
      set_key(key)  method should also be available and the initialization
                    should be optional (but raise an exception on use when no
                    key is available)


2) The modes of operation should not be parameters. The modes create
new algorithms types.  It's easy to spin out new mode algorithms with
a mode "wrapper" class.

3) A class based implementation of an encryption algorithm should be
able to handle large strings or files that may not all be in a single
variable. Please consider the example of encrypting large
multi-gigabyte files. So there are a couple of possible approaches:
a) you need two or three methods for encryption
     to indicate when you have full data versus partial
b) use you a parameter in encrypt to indicate if more data might be coming

    For example:
      ct = aes.encrypt('abcdefghijklmnop')
    versus
      ct = aes.encrypt_partial('abc')
      ct = ct + aes.encrypt('defghijklmnop')

I've written all my algorithms for option "b" above, but the example
and option "a" look like they read a little better.

Note that above implementation requires that the algorithm class
store non-byte aligned data between encryption steps.  It also means
that algorithm classes have a common perception of "state".
Algorithm states might be:
"unkeyed"   - class existing, but key not set or not valid
"ready"     - good key no data has been processed
"midstream" - some data encrypted, more possible
               must store alg state and excess non-aligned bytes.
               When the final a bit of data is processed this
               state goes back to "ready" and all local stuff
               (alg state, key tables) should be reset
All of the above could be made easy for an api by creating a SymmetricCipher
Class that all specific algorithms are derived from.

4) IV should not be a parameter, but should be built into the
algorithms that require IVs.  If you ever get around to using
hardware based cryptography it is very important to have the IV
generated by the hardware.  This also ensures that a "good" IV
generation method is built into the base algorithms. This also
implies that

5) Naming conventions should be provided to allow for block oriented
algorithms to automatically provide padding.  This is a big hole in
current algorithm standards work.  In a year or so NIST may catch up.
Similar to the way a mode (like CBC) augments a base cipher, a
padding mode defines how a block aligned transformation can be
extended to be byte aligned.



Paul A. Lambert



--