OpenSSL 1.1.1 KAS for TLS 1.2.
openssl-users at dukhovni.org
Fri Jul 28 22:44:23 UTC 2023
On Fri, Jul 28, 2023 at 09:32:48PM +0000, Malkin, Vlad wrote:
> We're trying to determine what KAS is provided by OpenSSL 1.1.1 when
> using TLS 1.2 with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
The one specified for use with TLS 1.2:
All ECDH calculations for the NIST curves (including parameter and
key generation as well as the shared secret calculation) are
performed according to [IEEE.P1363] using the ECKAS-DH1 scheme with
the identity map as the Key Derivation Function (KDF) so that the
premaster secret is the x-coordinate of the ECDH shared secret
elliptic curve point represented as an octet string. Note that this
octet string (Z in IEEE 1363 terminology), as output by FE2OSP (Field
Element to Octet String Conversion Primitive), has constant length
for any given field; leading zeros found in this octet string MUST
NOT be truncated.
(Note that this use of the identity KDF is a technicality. The
complete picture is that ECDH is employed with a non-trivial KDF
because TLS does not directly use the premaster secret for anything
other than for computing the master secret. In TLS 1.0 and 1.1, this
means that the MD5- and SHA-1-based TLS Pseudorandom Function (PRF)
serves as a KDF; in TLS 1.2, the KDF is determined by ciphersuite,
and it is conceivable that future TLS versions or new TLS extensions
introduced in the future may vary this computation.)
> Is the KAS configurable and how?
For interoperability of applications using the TLS protocol, the KAS is
fixed by TLS specification, and is not "configurable".
More information about the openssl-users