Hanno Becker 70e7928d76 Add pointers to in/out CID fields to mbedtls_ssl_context ... mbedtls_ssl_context contains pointers in_buf, in_hdr, in_len, ... which point to various parts of the header of an incoming TLS or DTLS record; similarly, there are pointers out_buf, ... for outgoing records. This commit adds fields in_cid and out_cid which point to where the CID of incoming/outgoing records should reside, if present, namely prior to where the record length resides. Quoting https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-04: The DTLSInnerPlaintext value is then encrypted and the CID added to produce the final DTLSCiphertext. struct { ContentType special_type = tls12_cid; /* 25 */ ProtocolVersion version; uint16 epoch; uint48 sequence_number; opaque cid[cid_length]; // New field uint16 length; opaque enc_content[DTLSCiphertext.length]; } DTLSCiphertext; For outgoing records, out_cid is set in ssl_update_out_pointers() based on the settings in the current outgoing transform. For incoming records, ssl_update_in_pointers() sets in_cid as if no CID was present, and it is the responsibility of ssl_parse_record_header() to update the field (as well as in_len, in_msg and in_iv) when parsing records that do contain a CID. This will be done in a subsequent commit. Finally, the code around the invocations of ssl_decrypt_buf() and ssl_encrypt_buf() is adapted to transfer the CID from the input/output buffer to the CID field in the internal record structure (which is what ssl_{encrypt/decrypt}_buf() uses). Note that mbedtls_ssl_in_hdr_len() doesn't need change because it infers the header length as in_iv - in_hdr, which will account for the CID for records using such.		2019-05-20 15:32:36 +01:00
..
mbedtls	Add pointers to in/out CID fields to mbedtls_ssl_context	2019-05-20 15:32:36 +01:00
tinycrypt	Guard tinycrypt files with MBEDTLS_USE_UECC	2019-04-29 10:25:23 +03:00
.gitignore
CMakeLists.txt	Add CMake support for uecc	2019-04-24 16:17:10 +03:00