You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Decryption/authentication of (D)TLS record encrypted with legacy CBC (that is CBC without EtM) includes comparing the peer's HMAC value to our computed value without leaking the position of the peer's HMAC value in the buffer (as this would leak information about the padding, exploited y the Lucky 13 attack.
Currently we do this by using dummy reads to the entire region than may contain the MAC, making the synchronization requirements for an attacker so tight as to be impractical. However, attacks only get better, so we want to pro-actively switch to a more robust, properly constant-flow strategy, such as the one described in this blog post, section "Extracting the MAC from the record".
This task is to create a function with a prototype for example like:
as long as min_offset <= offset_secret <= max_offset, but with to branches of memory access patterns depending on offset_secret.
This function must come with unit tests. In the development branch, it should probably be defined in ssl_msg.c and be declared MBEDTLS_STATIC_TESTABLE. In the LTS branches, it should probably be defined in ssl_tls.c and declared in ssl_internal.h.
Note: this task is just about creating the function and its unit tests, not necessarily integrating it in ssl_decrypt_buf() yet. This is to avoid a dependency on #3469 (negative testing of ssl_decrypt_buf()). However if #3469 is ready before this one, then creating this function and integrating it in ssl_decrypt_buf() can be done in the same PR.
The text was updated successfully, but these errors were encountered:
Decryption/authentication of (D)TLS record encrypted with legacy CBC (that is CBC without EtM) includes comparing the peer's HMAC value to our computed value without leaking the position of the peer's HMAC value in the buffer (as this would leak information about the padding, exploited y the Lucky 13 attack.
Currently we do this by using dummy reads to the entire region than may contain the MAC, making the synchronization requirements for an attacker so tight as to be impractical. However, attacks only get better, so we want to pro-actively switch to a more robust, properly constant-flow strategy, such as the one described in this blog post, section "Extracting the MAC from the record".
This task is to create a function with a prototype for example like:
that is functionally equivalent to:
as long as
min_offset <= offset_secret <= max_offset
, but with to branches of memory access patterns depending onoffset_secret
.This function must come with unit tests. In the development branch, it should probably be defined in
ssl_msg.c
and be declaredMBEDTLS_STATIC_TESTABLE
. In the LTS branches, it should probably be defined inssl_tls.c
and declared inssl_internal.h
.Note: this task is just about creating the function and its unit tests, not necessarily integrating it in
ssl_decrypt_buf()
yet. This is to avoid a dependency on #3469 (negative testing ofssl_decrypt_buf()
). However if #3469 is ready before this one, then creating this function and integrating it inssl_decrypt_buf()
can be done in the same PR.The text was updated successfully, but these errors were encountered: