>>>>> "Paul" == Paul Hoffman <paul.hoff...@vpnc.org> writes: Paul> +1 to "now that you understand it, please show where you were Paul> confused before" so that we can close out the document and Paul> move it to the IETF.
sorry, day job got in the way. rereading section 2.1/2.2 again. This leakage can be prevented if the recipient performs a test on the peer's public value, however this test is expensive (approximately as expensive as what reusing DH private values saves). does the stuff in () add anything? And is the word "saves" correct? In addition, the NIST standard [NIST-800-56A] requires that test (see section 5.6.2.4), hence anyone needing to conform to that standard will need to implement the test anyway. ("that test" refers to the test on the peer's public value? Visiting NIST-800-56A section 5.6.2.4.. but that section refers to private/public key pair generation, not MODP groups... but anyway. my suggested text: For a node which wishes to reuse its DH private value, in order to avoid this leakage, the following test is to be performed on the public value received from the peer before combining it with the node's private value. While this test is expensive, it is no more expensive than generating new DH private values, except that it does not require access to a high quality random value. This test is mandated by the NIST standard [NIST-800-56A] (see section 5.6.2.4), and is described here: It MUST check both that the peer's public value is in range (1 < r < p-1) and that r**q = 1 mod p (where q is the size of the subgroup, as listed in the RFC). DH private values MAY then be reused. This option is appropriate if conformance to [NIST-800-56A] is required. Alternatively, it MUST NOT reuse DH private values (that is, the DH private value for each DH exchange MUST be generated from a fresh output of a cryptographically secure random number generator), and it MUST check that the peer's public value is in range (1 < r < p-1). This option is more appropriate if conformance to [NIST-800-56A] is not required. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
pgpD5qGmekhzN.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec