From: James Yonan <james@openvpn.net>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Daniel Borkmann <dborkman@redhat.com>,
Marcelo Cerri <mhcerri@linux.vnet.ibm.com>,
linux-crypto@vger.kernel.org, herbert@gondor.hengli.com.au
Subject: Re: [PATCH] crypto_mem_not_equal: add constant-time equality testing of memory regions
Date: Sun, 15 Sep 2013 10:59:43 -0600 [thread overview]
Message-ID: <5235E77F.1050807@openvpn.net> (raw)
In-Reply-To: <878uyyks0e.fsf@mid.deneb.enyo.de>
On 15/09/2013 09:45, Florian Weimer wrote:
> * James Yonan:
>
>> + * Constant-time equality testing of memory regions.
>> + * Returns 0 when data is equal, non-zero otherwise.
>> + * Fast path if size == 16.
>> + */
>> +noinline unsigned long crypto_mem_not_equal(const void *a, const void *b, size_t size)
>
> I think this should really return unsigned or int, to reduce the risk
> that the upper bytes are truncated because the caller uses an
> inappropriate type, resulting in a bogus zero result. Reducing the
> value to 0/1 probably doesn't hurt performance too much. It also
> doesn't encode any information about the location of the difference in
> the result value, which helps if that ever leaks.
The problem with returning 0/1 within the function body of
crypto_mem_not_equal is that it makes it easier for the compiler to
introduce a short-circuit optimization.
It might be better to move the test where the result is compared against
0 into an inline function:
noinline unsigned long __crypto_mem_not_equal(const void *a, const void
*b, size_t size);
static inline int crypto_mem_not_equal(const void *a, const void *b,
size_t size) {
return __crypto_mem_not_equal(a, b, size) != 0UL ? 1 : 0;
}
This hides the fact that we are only interested in a boolean result from
the compiler when it's compiling crypto_mem_not_equal.c, but also
ensures type safety when users test the return value. It's also likely
to have little or no performance impact.
James
next prev parent reply other threads:[~2013-09-15 16:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 18:38 [PATCH] crypto_memcmp: add constant-time memcmp James Yonan
2013-09-10 18:57 ` Daniel Borkmann
2013-09-11 12:19 ` Marcelo Cerri
2013-09-11 17:20 ` James Yonan
2013-09-13 8:33 ` Daniel Borkmann
2013-09-15 15:32 ` [PATCH] crypto_mem_not_equal: add constant-time equality testing of memory regions James Yonan
2013-09-15 15:45 ` Florian Weimer
2013-09-15 16:59 ` James Yonan [this message]
2013-09-16 7:56 ` Daniel Borkmann
2013-09-16 17:10 ` James Yonan
2013-09-17 19:07 ` Daniel Borkmann
2013-09-19 0:13 ` James Yonan
2013-09-19 8:37 ` Daniel Borkmann
2013-09-16 17:25 ` Florian Weimer
2013-09-15 15:38 ` [PATCH] crypto_memcmp: add constant-time memcmp James Yonan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5235E77F.1050807@openvpn.net \
--to=james@openvpn.net \
--cc=dborkman@redhat.com \
--cc=fw@deneb.enyo.de \
--cc=herbert@gondor.hengli.com.au \
--cc=linux-crypto@vger.kernel.org \
--cc=mhcerri@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).