Cryptography Reference
In-Depth Information
point. The implementation presented here is hardcoded to return the generator
point * 4. A proper, secure implementation would naturally choose much larger
numbers, and choose them randomly. The resulting point is encoded in ANSI
X9.62 format; this is the handshake message itself. This same “secret” value 4 is
then multiplied by the server's point; this is the shared, premaster secret. You
may want to compare this to
dh_key_exchange
in Listing 6-43. In effect, the
mod_pow
calls are replaced by point multiplication calls, and the shared secret is
retrieved from the x-coordinate of the shared point. Otherwise, these routines
are very similar.
ECC Client Hello Extensions
As you might imagine, it would be a shame if the client and the server went to
all the trouble to try to perform an ECC key exchange only to fi nd out that the
server wanted to use a named curve that the client didn't support. It would be
even worse to fi nd out that the client and the server
do
share a named curve,
but the server keeps picking the wrong one because it doesn't know which one
the client supports.
To address this, RFC 4492 defi nes a new client hello extension, extension 10,
which enables the client to list the named curves it supports. It uses the same
two-byte characters for the curves that the server key exchange uses. The special
values
0xFF01
and
0xFF02
denote explicit prime curves and explicit characteristic
2 curves, respectively. If either of these two values appears in the supported
curves extension, this indicates that the client can accept explicit curves. The
specifi cation is silent on what the server should do if the client presents an
elliptic-curve cipher suite, but does not indicate which named curves it supports.
OpenSSL currently just defaults to secp256r1 in this case.
In addition, RFC 4492 defi nes a second client hello extension, extension 11,
that enables the client to indicate what point formats it supports — compressed,
uncompressed, or both. It would be strange for a client to support compressed
but not uncompressed, and the specifi cation states that all implementations
must support uncompressed points, so it's somewhat redundant for the client
to inform the server that it can support uncompressed points, but you can do
so if you like.
The Current State of TLS 1.2
One thing you may have noticed about this chapter was the conspicuous lack
of examples. TLS 1.2 is still very new and hasn't found its way into very many
TLS implementations yet. OpenSSL doesn't yet support it, although all the pieces
are in place. GnuTLS does support TLS 1.2, but it's not enabled by default. To
run a TLS 1.2-aware server:
Search WWH ::
Custom Search