Commit e3e5f118 authored by Niels Möller's avatar Niels Möller

Merge branch 'curve25519-rfc7748'

parents c3952e2d 70b8344a
2016-05-02 Niels Möller <nisse@lysator.liu.se>
* nettle.texinfo: Update Curve25519 documentation.
* testsuite/curve25519-dh-test.c: Test that inputs bits which must
be ignored really are ignored.
2016-04-25 Niels Möller <nisse@lysator.liu.se>
* curve25519-mul.c (curve25519_mul): Ignore top bit of the input x
coordinate, as required by RFC 7748.
2016-03-30 Niels Möller <nisse@lysator.liu.se>
From Nikos Mavrogiannopoulos.
......
......@@ -72,7 +72,11 @@ curve25519_mul (uint8_t *q, const uint8_t *n, const uint8_t *p)
itch = ecc->p.size * 12;
scratch = gmp_alloc_limbs (itch);
/* Note that 255 % GMP_NUMB_BITS == 0 isn't supported, so x1 always
holds at least 256 bits. */
mpn_set_base256_le (x1, ecc->p.size, p, CURVE25519_SIZE);
/* Clear bit 255, as required by RFC 7748. */
x1[255/GMP_NUMB_BITS] &= ~((mp_limb_t) 1 << (255 % GMP_NUMB_BITS));
/* Initialize, x2 = x1, z2 = 1 */
mpn_copyi (x2, x1, ecc->p.size);
......
......@@ -4304,30 +4304,38 @@ random octets and store them at @code{dst}. For advice, see
@subsubsection Curve25519
@c FIXME: Make 2^255 pretty in all output formats. Use @sup?
@c There are other places too (2^32, 2^130).
Curve25519 is an elliptic curve of Montgomery type, @math{y^2 = x^3 +
486662 x^2 + x @pmod{p}}, with @math{p = 2^255 - 19}. Montgomery curves
have the advantage of simple and efficient point addition based on the
x-coordinate only. This particular curve was proposed by D.~J.~Bernstein
in 2006, for fast Diffie-Hellman key exchange. The group generator is
defined by @math{x = 9} (there are actually two points with @math{x =
9}, differing by the sign of the y-coordinate, but that doesn't matter
for the curve25519 operations which work with the x-coordinate only).
x-coordinate only. This particular curve was proposed by D. J. Bernstein
in 2006, for fast Diffie-Hellman key exchange, and is also described in
@cite{RFC 7748}. The group generator is defined by @math{x = 9} (there
are actually two points with @math{x = 9}, differing by the sign of the
y-coordinate, but that doesn't matter for the curve25519 operations
which work with the x-coordinate only).
The curve25519 functions are defined as operations on octet strings,
which are interpreted as x-coordinates in little-endian byte order.
Of all the possible input strings, only about half correspond to points
on curve25519, i.e., a value that can be produced by
@code{curve25519_mul_g}. The other half corresponds to points on a
related ``twist curve''. The current implementation of
representing 255-bit scalars or x-coordinates, in little-endian byte
order. The most significant input bit, i.e, the most significant bit of
the last octet, is always ignored.
For scalars, in addition, the least significant three bits are ignored,
and treated as zero, and the second most significant bit is ignored too,
and treated as one. Then the scalar input string always represents 8
times a number in the range @math{2^251 <= s < 2^252}.
Of all the possible input strings, only about half correspond to
x-coordinates of points on curve25519, i.e., a value @math{x} for which
the the curve equation can be solved for @math{y}. The other half
correspond to points on a related ``twist curve''. The function
@code{curve25519_mul} uses a Montgomery ladder for the scalar
multiplication, as suggested in the curve25519 literature, and produces
a well defined output for all possible inputs, no matter if points are
on the proper curve or on its twist. However, at the time of writing, it
is not yet ruled out that other implementations could be faster, and
therefore the behaviour for inputs corresponding to points on the twist
curve must be considered an implementation idiosyncrasy, and may change
in future versions.
multiplication, as suggested in the curve25519 literature, and required
by @cite{RFC 7748}. Its the output is therefore well defined for
@emph{all} possible inputs, no matter if the input string represents a
valid point on the curve or not.
@defvr Constant CURVE25519_SIZE
The size of the strings representing curve25519 points and scalars, 32.
......@@ -4351,10 +4359,6 @@ argument @var{q} use a little-endian representation of the scalar and
the x-coordinates, respectively. They are all of size
@code{CURVE25519_SIZE}.
The output value is defined only when the input @var{p} is a string
produced by @code{curve25519_mul_g}. (See discussion above, about the
twist curve).
This function is intended to be compatible with the function
@code{crypto_scalar_mult} in the NaCl library.
@end deftypefun
......@@ -4362,7 +4366,7 @@ This function is intended to be compatible with the function
@subsubsection EdDSA
@cindex eddsa
EdDSA is a signature scheme proposed by D.~J.~Bernstein et al. in 2011.
EdDSA is a signature scheme proposed by D. J. Bernstein et al. in 2011.
It is defined using a ``Twisted Edwards curve'', of the form @math{-x^2
+ y^2 = 1 + d x^2 y^2}. The specific signature scheme Ed25519 uses a
curve which is equivalent to curve25519: The two groups used differ only
......
......@@ -75,9 +75,7 @@ test_a (const uint8_t *s, const uint8_t *b, const uint8_t *r)
void
test_main (void)
{
/* From draft-turner-thecurve25519function-00 (same also in
draft-josefsson-tls-curve25519-05, but the latter uses different
endianness). */
/* From RFC 7748. */
test_g (H("77076d0a7318a57d3c16c17251b26645"
"df4c2f87ebc0992ab177fba51db92c2a"),
H("8520f0098930a754748b7ddcb43ef75a"
......@@ -100,4 +98,44 @@ test_main (void)
"0dbf3a0d26381af4eba4a98eaa9b4e6a"),
H("4a5d9d5ba4ce2de1728e3bf480350f25"
"e07e21c947d19e3376f09b3c1e161742"));
/* Check that the least significant three bits (first octet) of the
scalar are ignored by mul_g. */
test_g (H("70076d0a7318a57d3c16c17251b26645"
"df4c2f87ebc0992ab177fba51db92c2a"),
H("8520f0098930a754748b7ddcb43ef75a"
"0dbf3a0d26381af4eba4a98eaa9b4e6a"));
/* Check that the most significant two bits (last octet) of the
scalar are ignored by mul_g. */
test_g (H("5dab087e624a8a4b79e17f8b83800ee6"
"6f3bb1292618b6fd1c2f8b27ff88e02b"),
H("de9edb7d7b7dc1b4d35b61c2ece43537"
"3f8343c85b78674dadfc7e146f882b4f"));
/* Check that the least significant three bits (first octet) of the
scalar are ignored by mul_a. */
test_a (H("5aab087e624a8a4b79e17f8b83800ee6"
"6f3bb1292618b6fd1c2f8b27ff88e0eb"),
H("8520f0098930a754748b7ddcb43ef75a"
"0dbf3a0d26381af4eba4a98eaa9b4e6a"),
H("4a5d9d5ba4ce2de1728e3bf480350f25"
"e07e21c947d19e3376f09b3c1e161742"));
/* Check that the most significant two bits (last octet) of the
scalar are ignored by mul_g. */
test_a (H("77076d0a7318a57d3c16c17251b26645"
"df4c2f87ebc0992ab177fba51db92cea"),
H("de9edb7d7b7dc1b4d35b61c2ece43537"
"3f8343c85b78674dadfc7e146f882b4f"),
H("4a5d9d5ba4ce2de1728e3bf480350f25"
"e07e21c947d19e3376f09b3c1e161742"));
/* Check that the most significant bit (last octet) of the x
coordinate is ignored. */
test_a (H("77076d0a7318a57d3c16c17251b26645"
"df4c2f87ebc0992ab177fba51db92c2a"),
H("de9edb7d7b7dc1b4d35b61c2ece43537"
"3f8343c85b78674dadfc7e146f882bcf"),
H("4a5d9d5ba4ce2de1728e3bf480350f25"
"e07e21c947d19e3376f09b3c1e161742"));
}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment