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