Subject: [Ipsec] short question about KE format in IKEv2

From: Francis Dupont <[email-masked]>
Date: Mon, 20 Mar 2006 23:18:15 +0100

Quoting RFC 4306 section 3.4 page 56:

   The length of the Diffie-Hellman public value MUST be equal to the
   length of the prime modulus over which the exponentiation was
   performed, prepending zero bits to the value if necessary.

Why such a MUST? Does it make sense for "groups" which are not MODP?

Regards

[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Charlie Kaufman <[email-masked]>
Date: Thu, 30 Mar 2006 23:32:18 -0800

The text may have to be clarified for groups that are not MODP.

The reason for the MUST is to save implementers some work.

When a Diffie-Hellman private/public pair is chosen at random, there is a 1/256 chance that the high order 8 bits of the public pair will all be zeros (actually slightly more than that because the prime modulus is less than 2^n) and a 1/(2^16) chance the high order 18 bits will all be zeros.

In some implementations (depending on the interface to the crypto library), it would be more natural to trim off the high order zero bytes and send a shorter KE value in that case. For others, it would be more natural to send a fixed size buffer even if the high order bits are all zero.

If the specification did not say whether to trim off the high order zero bytes or not, then all implementations would have to be prepared to receive either full size or truncated KE values and pad them out. By saying that the padded value MUST be sent, we make it simpler for recipients at the expense of making it a little harder for some senders.

There is probably an equivalent problem with ECC Diffie-Hellman - if the ECC public number is thought of as an integer, some crypto libraries might truncate it. Mathematically, I believe the ECC public number is a bit string rather than an integer, so it might be "obvious" that an implementation MUST always send a KE value whose length is the largest size possible given the negotiated ECC group.

        --Charlie

-----Original Message-----
From: Francis Dupont [mailto:[email-masked]]
Sent: Monday, March 20, 2006 2:18 PM
To: [email-masked]
Subject: [Ipsec] short question about KE format in IKEv2

Regards

---

From: <[email-masked]>
Date: Fri, 31 Mar 2006 14:29:10 +0300

At least the "Field Element to Octet String" conversion function in
X9.62-2005 Section A.5.4 always produces an output of the same length
(padding the octet string with zeroes if necessary). Thus, it seems
the requirement does make sense for ECC as well.

Best regards,
Pasi

> From: ext Charlie Kaufman [mailto:[email-masked]] 
> Sent: 31 March, 2006 10:32
> To: Francis Dupont; [email-masked]
> Subject: RE: [Ipsec] short question about KE format in IKEv2
> 
> When a Diffie-Hellman private/public pair is chosen at 
> random, there is a 1/256 chance that the high order 8 bits of 
> the public pair will all be zeros (actually slightly more 
> than that because the prime modulus is less than 2^n) and a 
> 1/(2^16) chance the high order 18 bits will all be zeros.
> 
> In some implementations (depending on the interface to the 
> crypto library), it would be more natural to trim off the 
> high order zero bytes and send a shorter KE value in that 
> case. For others, it would be more natural to send a fixed 
> size buffer even if the high order bits are all zero.
> 
> If the specification did not say whether to trim off the high 
> order zero bytes or not, then all implementations would have 
> to be prepared to receive either full size or truncated KE 
> values and pad them out. By saying that the padded value MUST 
> be sent, we make it simpler for recipients at the expense of 
> making it a little harder for some senders.
> 
> There is probably an equivalent problem with ECC 
> Diffie-Hellman - if the ECC public number is thought of as an 
> integer, some crypto libraries might truncate it. 
> Mathematically, I believe the ECC public number is a bit 
> string rather than an integer, so it might be "obvious" that 
> an implementation MUST always send a KE value whose length is 
> the largest size possible given the negotiated ECC group.
> 
>         --Charlie
>