ietf-openpgp
[Top] [All Lists]

Re: extensibility & code bloat (Re: PGP cipher tags)

1997-08-09 09:13:23

Peter Gutmann <pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> writes:
Death rays from Mars made Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> 
write:
I was kind of toying with the idea of creating a human readable formal 
grammar which describes algorithm combinations.  
 
This gets ugly real quick.  I thought of doing this for cryptlib, something 
like: 
 
  cryptAlgorithm = 3des { mode = cbc, padding = PKCS#5, noKeys = 2 }
  cryptAlgorithm = safer { mode = cfb, keysize = 128, useSaferSK = TRUE }
           
(and even wrote most of a parser for it) but dropped it for a number of 
reasons:
 
1. The code to parse this starts to get scary, because when a (say)
dlopen()'d module registers a new algorithm it also has to register
a grammar to allow its config settings to be parsed.  Some of the
parsing code may have to reside in the crypto module, because the
general parser won't be aware of every conceivable type of config
option and setting in advance.

Yup.  Interesting that you gave it a go also.  I was thinking of using
perl... the eval function plus a bit of hacking around would mean that
the extension language was almost perl code, and you'd pass it through
various filtering rules to make good perl code before evaling it.

As you say you'd have the extensions signed by people, and users could
base their trust on that in a distributed fashion.  If PRZ signs
El-Gamal and CAST well then a lot of people would use that
recommendation.  But if I'm paranoid, and the random number generator
is good enough to not become the weak point, I can request 

        R = RANDOM( sizeof(M) ), C = 5DES(M) xor 3IDEA(M XOR R)

(With 2x expansion of message size -- the simple way to have something
as good as the better of two ciphers -- now if someone finds a new
type of attack which means 3IDEA turns out to be naff, I'm OK so long
as 5DES doesn't fall.  All presuming the RANDOM function is good
enough).

I also consider that it would be interesting for the sender to be able
to request replies using the senders chosen cipher set.

3. Virtually noone will ever use this capability.  I know from
feedback from cryptlib users that virtually noone uses the InitEx()
functions (which allow you to specify special-case parameters), and
I can't see this as being any different from PGP.

Sure.  It's not a main stream issue -- PGP isn't going to get involved
in all the extra complexity because it's not commercially justifiable.
Was just pleading the case to make it flexible so that there was room
for expasion in un-predicted directions.

Adam

<Prev in Thread] Current Thread [Next in Thread>