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>
The compile time guards were too restrictive, excluding builds with
drivers, updating them will allow driver tests to run as well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
When we are doing PSK, we'd like to set verify_result to
0 to indicate success. Previously this was done in
mbedtls_ssl_set_hs_psk() but this is inadequate since this function may
be called for early data (where certificate verification happens later
in the handshake).
Instead, set this value after writing / processing the encrypted
extensions on the server / client respectively, so that we know whether
we are doing certificate verification or not for sure. This change is
effective only for TLS 1.3 as TLS 1.2 sets verify_result for PSK in
ssl_parse_certificate_coordinate().
Signed-off-by: David Horstmann <david.horstmann@arm.com>
