Use the enc_flags field to determine whether we should use explicit IV,
signature algorithms or SHA256 default PRF instead of hard coding which
versions support each requirement.
Revise DTLS code. There was a *lot* of code duplication in the
DTLS code that generates records. This makes it harder to maintain and
sometimes a TLS update is omitted by accident from the DTLS code.
Specifically almost all of the record generation functions have code like
this:
some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
... Record creation stuff ...
set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);
...
write_handshake_message(ssl);
Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
in some cases has very minor differences.
By adding a few fields to SSL3_ENC to include the header length, some flags
and function pointers for handshake header setting and handshake writing the
code can cope with both cases.
Note: although this passes "make test" and some simple DTLS tests there may
be some minor differences in the DTLS code that have to be accounted for.
If an ASN1_INTEGER structure is allocated but not explicitly set encode
it as zero: don't generate an invalid zero length INTEGER.
(cherry picked from commit 1643edc63c3e15b6db5a15a728bc288f2cc2bbc7)
Add DTLS record header parsing, different client hello format and add
HelloVerifyRequest message type.
Add code to d1_pkt.c to send message headers to the message callback.
Add code to support GCM an CCM modes in evp_test. On encrypt this
will compare the expected ciphertext and tag. On decrypt it will
compare the expected plaintext: tag comparison is done internally.
Add a simple CCM test case and convert all tests from crypto/modes/gcm128.c
Add CMS_RecipientInfo_encrypt: this function encrypts an existing content
encryption key to match the key in the RecipientInfo structure: this is
useful if a new recpient is added to and existing enveloped data structure.
Add documentation.
