aboutsummaryrefslogtreecommitdiffstats
path: root/src/libstrongswan/utils/utils.c
diff options
context:
space:
mode:
authorMartin Willi <martin@revosec.ch>2015-04-11 14:59:22 +0200
committerMartin Willi <martin@revosec.ch>2015-04-14 11:51:54 +0200
commit39e1ddec2ed3480e0edc07bbabfacbf907dc4e3f (patch)
treed628a5fd4c1c89dbc1fa9fe15d45d2605ad63833 /src/libstrongswan/utils/utils.c
parentb17f0beda805a8096de6a381a4845711a64a500e (diff)
downloadstrongswan-39e1ddec2ed3480e0edc07bbabfacbf907dc4e3f.tar.bz2
strongswan-39e1ddec2ed3480e0edc07bbabfacbf907dc4e3f.tar.xz
scripts: Add a tool that tries to guess MAC/ICV values using validation times
This tool shows that it is trivial to re-construct the value memcmp() compares against by just measuring the time the non-time-constant memcmp() requires to fail. It also shows that even when running without any network latencies it gets very difficult to reconstruct MAC/ICV values, as the time variances due to the crypto routines are large enough that it gets difficult to measure the time that memcmp() actually requires after computing the MAC. However, the faster/time constant an algorithm is, the more likely is a successful attack. When using AES-NI, it is possible to reconstruct (parts of) a valid MAC with this tool, for example with AES-GCM. While this is all theoretical, and way more difficult to exploit with network jitter, it nonetheless shows that we should replace any use of memcmp/memeq() with a constant-time alternative in all sensitive places.
Diffstat (limited to 'src/libstrongswan/utils/utils.c')
0 files changed, 0 insertions, 0 deletions