ietf-openpgp
[Top] [All Lists]

extensibility & code bloat (Re: PGP cipher tags)

1997-08-08 14:53:51

Assar Westerlund <assar(_at_)sics(_dot_)se> writes:
- Do we really need more than 256 algorithms _in PGP_?

[...]
6.2 Symmetric Key Algorithms

0     -       Plaintext
1     -       IDEA
2     -       Triple-DES (DES-EDE, 168 bit key)
                            ^^^^^^^^^^^^^^^^^^^^ 

I think this answers your question: yes.  There are lots of modes, key
sizes, etc.  And a variable length algorithm description string costs
almost nothing and offers ultimate flexibility, so why not do it.

- If there's a need for more than 256 algorithms, how should these be
coded?  In binary or in ascii?  Fixed length or variable length?

ASCII, variable length.

I was kind of toying with the idea of creating a human readable formal
grammar which describes algorithm combinations.  Might save multiple
entries for DES (DES CBC, DES CFB, DES OFB, 3DES-EDE, etc.,etc), and
would allow you to "implement" a chosen mode just by specifying what
mode you wanted DES, and how to combine that to mutliple key DES.
Anyone for outer-CBC 5DES?

Plus how to deal with short last blocks, how you want the IV
constructed etc.

PGP seems pretty big as it is.

This could stop reinvention of the wheel, and hence reduce more code
bloat when new algorithms are added by providing a more flexible plug
in.  You provide the code for the encryption and decryption of one
block (ie ECB style).  You then describe the mode you want using the
grammar, and you're done.  If you want a new mode, or new short end
block treatment, you add one of those too.

So if I get bored one day and go implement that lot, your 2 byte field
might be pretty painful for me.  But a variable length string would be
a handy way for me not to confuse implementations without this
ability, without having to design whole new formats.


Don't worry about the above example ... but please lets have variable
length fields for some future proofing of the message layout.

PGP message spec already went through one set of fudging to work
around some pgp2.x message spec limitations which made it difficult to
extend in such a way as not to cause earlier implementations to barf,
lets use the experience to avoid doing the same thing with pgp3.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`