Subject: Re: Plausible deniability (a feature to think about)

From: Jon Callas <[email-masked]>
Date: Mon, 3 Oct 2005 16:43:09 -0700

On 22 Sep 2005, at 6:56 AM, Daniel A. Nagy wrote:

>>> Now, there exists a cryptographic solution for this problem,  
>>> moreover,
>>> RFC2440 even hints that it might be implemented in OpenPGP,  
>>> though I have
>>> never seen it used: X9.42 Diffie-Hellman key agreement (see also  
>>> RFC2630,
>>> RFC2631 and RFC2633).
>>>
>>
>> X9.42 was only added to S/MIME for political reasons.  AFAIK only one
>> implementation ever supported it, and that was the USG-funded  
>> reference
>> implementation that was required to support it.  In addition, MS  
>> supported a
>> read-only implementation just so they couldn't be accused of not  
>> supporting
>> it.
>>
>
> What political reasons? And why is there a reserved ID in OpenPGP?
>

Peter explained the political reasons around X9.42 in S/MIME. There  
are a different set of political things in OpenPGP.

Remember that at the time, the RSA algorithm was patented in the US,  
and the US had export restrictions. Consequently, this created an  
amusing window in which what you could do where had very little to do  
with rationality, let alone good technical decisions. Actually, to be  
complete, *all* public key crypto was patented in the US, and nowhere  
else, but the discrete log patents all expired in late '97, and the  
RSA patent in late '00. Add to this the zaniness of The Internet Boom.

The IETF as a whole decided in Munich in July '97 that all standards  
had to have discrete-log algorithms as MUST-implement algorithms,  
because of patent concerns. Just about everyone picked DSA for  
signing, but there was differences in ideas about what to pick for  
encryption.

OpenPGP is based on PGP 3, which already had been built using Elgamal  
keys. That was decided. Other protocols, which had been RSA-only,  
looked around for what to do. The S/MIME people picked X9.42.

Another factor in various discussions has been how to deal with  
certificate formats. It's pretty trivial to come up with an  
isomorphism between X.509 certs and OpenPGP certs for RSA keys.  
However, with OpenPGP using Elgamal, and S/MIME using X9.42, there  
was a difference. Consequently, to bridge any gap, we put in  
identifiers for X9.42 in OpenPGP, so that if they became popular, we  
could support them. As Peter Gutmann has said, it isn't clear that  
anyone ever used a single X9.42 key outside of interop testing. There  
aren't that many people using DSA certs, either. I don't think I've  
ever seen one in the wild. At PGP, we don't do any X.509/OpenPGP  
unification for discrete log keys. If you want that, you use RSA.

>
>> (I remember having a conversation with a rather baffled security  
>> application
>>  developer who wanted to see X9.42 in an S/MIME toolkit and just  
>> couldn't
>>  understand that although the spec had it as a MUST requirement,  
>> all the
>>  implementors knew that you should ignore it).
>>
>
> X9.42 may be flawed (is it?), but DH key agreement is one of the  
> strongest
> primitives in asymmetric cryptography.

There's nothing wrong with X9.42 technical. Its non-use (and DSA's)  
are all layer 8 and 9 issues.

     Jon

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 04 Oct 2005 15:49:07 +1300

Jon Callas <[email-masked]> writes:

>There's nothing wrong with X9.42 technical. Its non-use (and DSA's) are all
>layer 8 and 9 issues.

Actually X9.42 is a pretty awkward way to do key exchange.  You can use
Elgamal as a drop-in replacement for RSA, but X9.42 requires both sender and
receiver certs to establish a key, and mixes in a large pile of other (largely
unnecessary) complexity and extra parameters and data values for no good
reason.  It seems to have been heavily influenced by the Fortezza KEA
mechanism.  It's just a royal pain to implement no matter how you look at it.

While I'm commenting on this, there isn't much problem with key formats, X9.42
and DSA are both from the DLP family so they use the same key generation and
format.  Well, almost, the X9.42 guys copied the DSA spec wrong and reversed
two of the parameters, but apart from that they're identical.

Peter.