ietf-smime
[Top] [All Lists]

Some comments on the use of DH in S/MIME

1998-12-20 23:45:19
Well OK, a bit of a rant rather than just comments...
 
I've had a go at implementing this, and after stuffing around with it for 
awhile I've come to the conclusion that this option must have been designed by 
RSADSI to make the alternative of getting a patent license to use 
KeyTransRecipientInfo look good[0].  What a mess!  Consider the most obvious 
use for DH keying material, which is to use it in Elgamal as per the existing 
KeyTransRecipientInfo and RFC TBA, the X.509 profile for Elgamal.  All it 
takes is a few lines of code to use it with existing mechanisms.
 
Now let's look at the way it's applied here.  A rough outline of what's 
contained in KeyAgreeRecipientInfo is:
 
  originatorDH  -- Originators DH values p, g, y = g^x mod p
  recipientDH   -- Recipients fixed DH values p, g, y' = g^x' mod p
  nonce         -- Extra material to mix in to ensure different keys are 
                   produced
 
First of all, both sender and recipient need to somehow agree on using the 
same p and g values, which means either everyone shares the same values 
(presumably these will be ones for which the NSA et al have performed the 
necessary precomputations to make solving the DLP easier), or alternatively 
you need to get a new certificate for each users values (OK, looks like 
Verisign were in on designing this thing as well).  As a result you either end 
up with a solution which is of questionable security due to use and re-use of 
widely-shared public values, or which is extremely expensive and practically 
impossible to manage because you need to have a certified DH public key 
corresponding to each recipients DH key (CMS tries to kludge around this by 
requiring the use of originatorKey, an uncertified, unauthenticated DH public 
value).
 
Anyway, moving past this, you either have a DH static key (inexpensive but 
insecure due to reuse), a DH ephemeral key (expensive since you need a new 
cert issued for each key), or the abovementioned unauthenticated DH public 
value (again, CMS explicitly requires the use of a static key for the 
recipient).  Since the DH exchange with fixed parameters always produces the 
same output, you also need to mix in extra keying material in a further kludge 
to try and shoehorn straight DH into functioning as a form of key transport 
mechanism.
                "To walk right past the correct solution and come up with this 
                 takes some beating" 
                        - Comment from someone who reviewed this rant
 
I realise there's probably some sort of motivation to try and do something 
with X9.42, but do we really have to jump off a cliff just because X9.42 does 
as well?  
                "Just because it's possible to push a pea up a mountain with 
                 your nose doesn't mean that this is a good way of getting it 
                 there"
                        - Chris Strachey
 
Why not just change the requirements to:
 
  "Implementations MUST support key transport using Elgamal.  Implementations 
   MAYM[1] include key agreement using X9.42 Ephemeral-Static Diffie Hellman".
 
This provides a straightforward nonpatented alternative to RSA which uses DH 
keys just as KeyTransRecipientInfo does (so it's possible to claim compliance 
to X9.42 or reference it in the spec or include it in the product advertising 
or whatever the rationale for working with it is) while still having something 
which is practical and simple to implement.
 
Peter (and I made it right through that without including the "looks like the 
       winning candidate from a 'Worst way to apply DH to a key management 
       problem' competition" comment :-).
 
[0] This is satire folks, not intended as a slight on RSADSI.
[1] "MAY if the implementors are Masochists".  An alternative is MAYEURKW, 
    "MAY if they Enjoy Unnecessary Root Canal Work".