Hmm, I think this may be getting too far off-topic for IPSec, since IKE mostly 
uses ephemeral keys ...

> -----Original Message-----
> From: Dan Harkins [mailto:dhark...@lounge.org]
> Sent: Tuesday, December 11, 2012 5:02 PM
> 
>   That's interesting. Your paper "Validating EC Public Keys" (Antipa,
> Brown, Menezes, Struik and Vanstone) says in section 3 that the
> steps to validate an EC public key, W=(xw, yw), are:
> 
>   1. W != infinity
>   2. xw and yw are properly represented elements of the finite field
>   3. W satisfies the defining equation of the curve; and
>   4. nW = infinity
> 
> It then says that "if h=1, then condition 4 is implied by the other
> three conditions. In some protocols the check that nW = infinity may
> either be embedded in the protocol computations or replaced by the
> check that hW != infinity."

[DB] Sorry about that mistake in the paper.  That paper was mostly about 
skipping the check number 3, not step 4.

> 
>   Can you explain why hQ != infinity is insufficient and not equivalent
> to nQ = infinity?
> 

[DB] I should first correct myself when I said "insufficient for security".  
This only really applies for very large h, which would be a very unusual case. 

Now suppose that G has order n and H has order h.  Then Q=G+H has order hn, not 
h.  In particular, it would pass the simpler test of hQ != inf.  

Suppose s is a static private key s, and P = sG is the corresponding public 
key.  

The shared secret is s applied to Q is Z = sQ = sG + sH = P + sH.  Therefore, Z 
is confined to a small set, and can leak information about s, which is the main 
security problem.

So, log_2(h) bits of the private key can be leaked.  For most curves, h is 
small, and this is not too big a deal.  

Anyway, the hQ != infinity test is not equivalent to the nQ = infinity test. 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to