From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Emil Lenngren <emil.lenngren@gmail.com>,
Emmanuel Grumbach <egrumbach@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
Kalle Valo <kvalo@codeaurora.org>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
LKML <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
David Howells <dhowells@redhat.com>,
David Safford <safford@us.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
Gilad Ben-Yossef <gilad@benyossef.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Gustavo Padovan <gustavo@padovan.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Jeff Layton <jlayton@poochiereds.net>,
Johan Hedberg <johan.hedberg@gmail.com>,
Johannes Berg <johannes@sipsolutions.net>,
Marcel Holtmann <marcel@holtmann.org>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Trond Myklebust <trond.myklebust@primarydata.com>,
keyrings@vger.kernel.org,
Bluez mailing list <linux-bluetooth@vger.kernel.org>,
"open list:NFS, SUNRPC, AND..." <linux-nfs@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important
Date: Mon, 12 Jun 2017 09:33:24 +0200 [thread overview]
Message-ID: <5595d4bc-a43e-7a89-eb86-fa77556cd7af@broadcom.com> (raw)
In-Reply-To: <CAO1O6see6yDr-hDVNPi9Kv9wO6p-98w7YhsnnwnVOVCSEGVksw@mail.gmail.com>
On 6/11/2017 11:30 PM, Emil Lenngren wrote:
> 2017-06-11 22:48 GMT+02:00 Emmanuel Grumbach <egrumbach@gmail.com>:
>> On Sun, Jun 11, 2017 at 4:36 PM, Kees Cook <keescook@chromium.org> wrote:
>>>
>>> On Sun, Jun 11, 2017 at 1:13 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>>>> "Jason A. Donenfeld" <Jason@zx2c4.com> writes:
>>>>
>>>>> Whenever you're comparing two MACs, it's important to do this using
>>>>> crypto_memneq instead of memcmp. With memcmp, you leak timing information,
>>>>> which could then be used to iteratively forge a MAC.
>>>>
>>>> Do you have any pointers where I could learn more about this?
>>>
>>> While not using C specifically, this talks about the problem generally:
>>> https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html
>>>
>>
>> Sorry for the stupid question, but the MAC address is in plaintext in
>> the air anyway or easily accessible via user space tools. I fail to
>> see what it is so secret about a MAC address in that code where that
>> same MAC address is accessible via myriads of ways.
>
> I think you're mixing up Media Access Control (MAC) addresses with
> Message Authentication Code (MAC). The second one is a cryptographic
> signature of a message.
While this may be obvious to those who are in the know this mixup is
easily made outside the crypto domain and especially in the (wireless)
networking domain (my mind wandered towards the same error path). As
this series is touching stuff outside crypto it is good to be explicit
and not use such abbreviations that can be misinterpreted. The article
Kees referred to is also useful to get into the proper context here and
at least worth mentioning this or other useful references in the cover
letter.
Regards,
Arend
next prev parent reply other threads:[~2017-06-12 7:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-10 2:59 Jason A. Donenfeld
2017-06-10 2:59 ` [PATCH 1/6] sunrpc: use constant time memory comparison for mac Jason A. Donenfeld
2017-06-10 2:59 ` [PATCH 2/6] net/ipv6: " Jason A. Donenfeld
2017-06-10 2:59 ` [PATCH 3/6] ccree: use constant time memory comparison for macs and tags Jason A. Donenfeld
2017-06-10 7:43 ` Gilad Ben-Yossef
2017-06-10 10:54 ` Jason A. Donenfeld
2017-06-10 21:43 ` Henrique de Moraes Holschuh
2017-06-10 2:59 ` [PATCH 4/6] security/keys: use constant time memory comparison for macs Jason A. Donenfeld
2017-06-14 8:47 ` [kernel-hardening] " James Morris
2017-06-10 2:59 ` [PATCH 5/6] bluetooth/smp: use constant time memory comparison for secret values Jason A. Donenfeld
2017-06-10 13:49 ` Marcel Holtmann
2017-06-10 2:59 ` [PATCH 6/6] mac80211/wpa: use constant time memory comparison for MACs Jason A. Donenfeld
2017-06-13 8:20 ` Johannes Berg
2017-06-13 13:28 ` Jason A. Donenfeld
2017-06-11 8:13 ` [PATCH 0/6] Constant Time Memory Comparisons Are Important Kalle Valo
2017-06-11 13:36 ` Kees Cook
2017-06-11 20:48 ` Emmanuel Grumbach
2017-06-11 21:30 ` Emil Lenngren
2017-06-12 5:03 ` Emmanuel Grumbach
2017-06-12 7:33 ` Arend van Spriel [this message]
2017-06-11 21:06 ` Stephan Müller
2017-06-11 21:21 ` Jason A. Donenfeld
2017-06-11 21:20 ` [PATCH] rsa-pkcs1pad: use constant time memory comparison for MACs Jason A. Donenfeld
2017-06-20 3:38 ` Herbert Xu
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=5595d4bc-a43e-7a89-eb86-fa77556cd7af@broadcom.com \
--to=arend.vanspriel@broadcom.com \
--cc=Jason@zx2c4.com \
--cc=anna.schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=egrumbach@gmail.com \
--cc=emil.lenngren@gmail.com \
--cc=gilad@benyossef.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo@padovan.org \
--cc=jlayton@poochiereds.net \
--cc=johan.hedberg@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=keyrings@vger.kernel.org \
--cc=kvalo@codeaurora.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=netdev@vger.kernel.org \
--cc=safford@us.ibm.com \
--cc=trond.myklebust@primarydata.com \
--cc=zohar@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
Powered by JetHome