{"push_id":1461094390,"size":2,"distinct_size":2,"ref":"refs/heads/master","head":"99484859357b9e653e2b528965e70dffbd1c93e6","before":"957d1f6ddb55d083ecf15547589b6dafea0f3704","commits":[{"sha":"d3d66a340bbe7fee3042137dd04f259034e9e2d1","author":{"name":"James Yonan","email":"01cfcc75cc77e42d1369b51ffa1aaa70069d0f46@openvpn.net"},"message":"crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks\n\nWhen comparing MAC hashes, AEAD authentication tags, or other hash\nvalues in the context of authentication or integrity checking, it\nis important not to leak timing information to a potential attacker,\ni.e. when communication happens over a network.\n\nBytewise memory comparisons (such as memcmp) are usually optimized so\nthat they return a nonzero value as soon as a mismatch is found. E.g,\non x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch\nand up to ~850 cyc for a full match (cold). This early-return behavior\ncan leak timing information as a side channel, allowing an attacker to\niteratively guess the correct result.\n\nThis patch adds a new method crypto_memneq (\"memory not equal to each\nother\") to the crypto API that compares memory areas of the same length\nin roughly \"constant time\" (cache misses could change the timing, but\nsince they don't reveal information about the content of the strings\nbeing compared, they are effectively benign). Iow, best and worst case\nbehaviour take the same amount of time to complete (in contrast to\nmemcmp).\n\nNote that crypto_memneq (unlike memcmp) can only be used to test for\nequality or inequality, NOT for lexicographical order. This, however,\nis not an issue for its use-cases within the crypto API.\n\nWe tried to locate all of the places in the crypto API where memcmp was\nbeing used for authentication or integrity checking, and convert them\nover to crypto_memneq.\n\ncrypto_memneq is declared noinline, placed in its own source file,\nand compiled with optimizations that might increase code size disabled\n(\"Os\") because a smart compiler (or LTO) might notice that the return\nvalue is always compared against zero/nonzero, and might then\nreintroduce the same early-return optimization that we are trying to\navoid.\n\nUsing #pragma or __attribute__ optimization annotations of the code\nfor disabling optimization was avoided as it seems to be considered\nbroken or unmaintained for long time in GCC [1]. Therefore, we work\naround that by specifying the compile flag for memneq.o directly in\nthe Makefile. We found that this seems to be most appropriate.\n\nAs we use (\"Os\"), this patch also provides a loop-free \"fast-path\" for\nfrequently used 16 byte digests. Similarly to kernel library string\nfunctions, leave an option for future even further optimized architecture\nspecific assembler implementations.\n\nThis was a joint work of James Yonan and Daniel Borkmann. Also thanks\nfor feedback from Florian Weimer on this and earlier proposals [2].\n\n  [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html\n  [2] https://lkml.org/lkml/2013/2/10/131\n\nSigned-off-by: James Yonan <james@openvpn.net>\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nCc: Florian Weimer <fw@deneb.enyo.de>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/lab/commits/d3d66a340bbe7fee3042137dd04f259034e9e2d1"},{"sha":"99484859357b9e653e2b528965e70dffbd1c93e6","author":{"name":"Noxxx","email":"f1d9dce37f258e1f51cd12aa10899fab40433275@hotmail.com"},"message":"deconfig enable crypto","distinct":true,"url":"https://api.github.com/repos/Noxxxious/lab/commits/99484859357b9e653e2b528965e70dffbd1c93e6"}]}
{"actor":{"display_login":"Noxxxious"}}