[PYTHON-CRYPTO] things missing from PEP 272

[Paul]

At 8:00 PM -0800 3/22/02, Bram Cohen wrote:
>Well, that's the current plan. Does anyone have any comments? I'd like to
>get any feedback people may have before doing a rewrite.


A few comments on PEP 272:

1) it seems a little odd to have the different modes built into the
api.  It seems more reasonable to simply have a bunch of named
algorithms and modes.

2) IV should not be required.  Perhaps optional if there were some
good reason to control the IV.  In general it's best to hide this
from applications.

3) Why only support multiples of block sizes.  This is a pain.  Both
padding and IV (addition and removal) should be automatic.  Padding
for each algorithm could use a default padding mechanism, with an
optional parameter allowing the selection of alternative padding
mechanisms.

4) The interface/methods should support the encryption of large data
and data streams.  This means that you need keep track of state in
the class so that a stream of data can be encrypted in small pieces.
The default behavior should allow encryption with a single method
(e.g aes.encrypt("foo") ).  Methods to encrypt a stream require
either two or three methods (encryptFirst, encryptMiddle,
encryptLast) or a parameter that indicates than the stream is not
complete (e.g. a "more" flag).  Either approach works, I'm partial to
the latter.

5) The stream encryption, automatic IV, automatic padding could allow
be handled by defining a Cipher class that provides keeps track of
the state and blocking information.  Block algorithms would then
inherit the base encrypt and decrypt methods.  The less useful basic
block oriented operations would then be encrypt_block and
decrypt_block methods that would be used by the Cipher class.

6) Not all algorithms need IV or padding ... so we might want every
algorithm to provide the minimum and maximum data expansion (IV +
padding).

7) Each algorithm should have a unique asci name (uniqueness could be
a problem to manage)

8) OIDs should be considered ... they belong either as part of the
algorithm class or will need to be collected separately.  Seems
easier to design them in from the start so that every algorithm knows
it's OID(s).

9) Counter mode or other combination encryption/integrity algorithms
should be build on Cipher, but have some additional methods and
parameters.  Recent work on 802.11i with AES-OCB or AES-CCM should
serve as a good example.  I suggest we give these algorithms some
type of new name since they are not the same as a "Cipher".  New
methods (or assertions) are needed to check the integrity of the
decryption process.

10) On AES-OCB and AES-CCM ... these integrity checking algorithms
are also being used in a way that allows parts of the unencrypted
header of PDUs to be combined into the processing.  This means that
that encrypting with integrity checking of headers has two parameters:
    ct=aes-ocb.encrypt_with_integrity("plain header","body to encrypt")
    (suggestions for shorter name for above method would be greatly appreciated)




Paul








>
>Well, that's the current plan. Does anyone have any comments? I'd like to
>get any feedback people may have before doing a rewrite.
>
>-Bram Cohen
>
>"Markets can remain irrational longer than you can remain solvent"
>                                         -- John Maynard Keynes


--