linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).