diff options
author | Sascha Hauer <s.hauer@pengutronix.de> | 2021-03-05 09:11:33 +0100 |
---|---|---|
committer | Sascha Hauer <s.hauer@pengutronix.de> | 2021-07-30 19:50:36 +0200 |
commit | 610db8d457fe7f479e93fb4d88e869792133f9d5 (patch) | |
tree | 696db76a981c3d3f72edb95e6e77840326f4e259 /dts/Bindings/arm/sunxi.yaml | |
parent | bfaf09f184246e543fdb0af38b318997a8774400 (diff) | |
download | barebox-610db8d457fe7f479e93fb4d88e869792133f9d5.tar.gz barebox-610db8d457fe7f479e93fb4d88e869792133f9d5.tar.xz |
crypto: add crypto_memneq()
This adds crypto_memneq() from Linux for the same reason it is present
in Linux. From the commit message adding it:
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.
Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero value as soon as a mismatch is found. E.g,
on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
and up to ~850 cyc for a full match (cold). This early-return behavior
can leak timing information as a side channel, allowing an attacker to
iteratively guess the correct result.
This patch adds a new method crypto_memneq ("memory not equal to each
other") to the crypto API that compares memory areas of the same length
in roughly "constant time" (cache misses could change the timing, but
since they don't reveal information about the content of the strings
being compared, they are effectively benign). Iow, best and worst case
behaviour take the same amount of time to complete (in contrast to
memcmp).
Note that crypto_memneq (unlike memcmp) can only be used to test for
equality or inequality, NOT for lexicographical order. This, however,
is not an issue for its use-cases within the crypto API.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Diffstat (limited to 'dts/Bindings/arm/sunxi.yaml')
0 files changed, 0 insertions, 0 deletions