A bug there was fixed in a previous commit, but without complete tests
or a ChangeLog entry. This commit completes the fix.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The documentation says "or another error code", so it's OK to change the
error code returned here for a more correct one.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Arguably the value returned by Everest was more precise, but considering
we're in an LTS branch, I'd rather not change the value returned by
ecdh.c, and align the special case on the general case.
The added tests made it apparent that Everest and the generic code were
not returning the same value here. Alignment between the two values is
desirable to keep the test code simple and sweet.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Wiping out our private key is OK if we're only doing ephemeral ECDH, but
our API also supports static Diffie-Hellman, where our private key is
long term and should not be wiped out on first use...
Found accidentally with the new test that try calling `calc_secret()`
again with a larger output buffer and expect the same result.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is probably a leftover from ancient times where the premaster
buffer was always that size (for FFDH). But these days it can be smaller
depending on the compile-time config. So, use the correct size macro.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
We were not comparing the size of the output buffer with the actual
number of bytes we were going to write to it, but with something
possibly smaller.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The values were generated using the script in the message of the
previous commit.
Currently all 4 new tests are failing: without sanitizers, the function
returns 0 instead of an error; with sanitizers, the buffer overwrite is
caught.
This will be fixed in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The goal is to catch possible bugs where we would compute the output
length based on the bitlength of the shared secret MPI. So, what matters
is the most significant byte, even for Montgomery curves where the
all values are written out little endian.
The values were generated by the following sage script. The script could
be a bit more compact by using E.random_point() instead of the
conventional base point G as the peer's key, but I prefered making the
script deterministic so its output can easily be checked.
p256 = {
"name": "p256",
"p": 2^224 * (2^32 - 1) + 2^192 + 2^96 - 1,
"a": -3,
"b": 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b,
"gx": 0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296,
"gy": 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5,
}
p521 = {
"name": "p521",
"p": 2^521 - 1,
"a": -3,
"b": 0x0051953eb9618e1c9a1f929a21a0b68540eea2da725b99b315f3b8b489918ef109e156193951ec7e937b1652c0bd3bb1bf073573df883d2c34f1ef451fd46b503f00,
"gx": 0x00c6858e06b70404e9cd9e3ecb662395b4429c648139053fb521f828af606b4d3dbaa14b5e77efe75928fe1dc127a2ffa8de3348b3c1856a429bf97e7e31c2e5bd66,
"gy": 0x011839296a789a3bc0045c8a5fb42c7d1bd998f54449579b446817afbd17273e662c97ee72995ef42640c550b9013fad0761353c7086a272c24088be94769fd16650,
}
x255 = {
"name": "x25519",
"p": 2^255 - 19,
"a": 486662,
"gx": 9,
"gy": 14781619447589544791020593568409986887264606134616475288964881837755586237401,
}
x448 = {
"name": "x448",
"p": 2^448 - 2^224 - 1,
"a": 156326,
"gx": 5,
"gy": 355293926785568175264127502063783334808976399387714271831880898435169088786967410002932673765864550910142774147268105838985595290606362,
}
def byte_len(i):
return (i.bit_length() + 7) // 8
def leading0(name, p, gx, gy, a, b=None):
is_montgomery = b is None
if is_montgomery:
E = EllipticCurve(GF(p), [0, a, 0, 1, 0])
increment = 8 # x22519 scalars have the low 3 bits unset
else:
E = EllipticCurve(GF(p), [a, b])
increment = 1
G = E(gx, gy)
s = 2^(p.bit_length() - 1) # x25519 scalars have bit 254 set
Z = G * s
while byte_len(Z.x().lift()) >= byte_len(p):
s += increment
Z += increment * G
print(name)
if is_montgomery:
nbytes = byte_len(p)
print(f"s: {s.to_bytes(nbytes, "little").hex()}")
print(f"G: {G.x().lift().to_bytes(nbytes, "little").hex()}")
print(f"Z: {Z.x().lift().to_bytes(nbytes, "little").hex()}")
else:
nibbles = byte_len(p) * 2
print(f"s: {s:0{nibbles}x}")
print(f"G: 04{G.x().lift():0{nibbles}x}{G.y().lift():0{nibbles}x}")
print(f"Z: {Z.x().lift():0{nibbles}x}")
leading0(**p256)
leading0(**p521)
leading0(**x255)
leading0(**x448)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
For each received ClientHello fragment, check
that its epoch is zero and update the
record-level sequence number.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In DTLS reassembly tests, the server may receive a close_notify alert at the
end of a test. In this case, the Mbed TLS server logs an error, so these tests
should not check for the absence of the string "error" in the server logs.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
