>>>>> "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
