All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Peter Huewe <peterhuewe@gmx.de>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	linux-integrity@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] tpm: Compare HMAC values in constant time
Date: Thu, 31 Jul 2025 20:02:10 -0700	[thread overview]
Message-ID: <20250801030210.GA1495@sol> (raw)
In-Reply-To: <3ed1ae7e7f52afe53ce2ff00f362ed153b3eec20.camel@HansenPartnership.com>

On Thu, Jul 31, 2025 at 10:28:49PM -0400, James Bottomley wrote:
> On Thu, 2025-07-31 at 14:52 -0700, Eric Biggers wrote:
> > To prevent timing attacks, HMAC value comparison needs to be constant
> > time.  Replace the memcmp() with the correct function,
> > crypto_memneq().
> 
> Um, OK, I'm all for more security but how could there possibly be a
> timing attack in the hmac final comparison code?  All it's doing is
> seeing if the HMAC the TPM returns matches the calculated one.  Beyond
> this calculation, there's nothing secret about the HMAC key.

I'm not sure I understand your question.  Timing attacks on MAC
validation are a well-known issue that can allow a valid MAC to be
guessed without knowing the key.  Whether it's practical in this
particular case for some architecture+compiler+kconfig combination is
another question, but there's no reason not to use the constant-time
comparison function that solves this problem.

Is your claim that in this case the key is public, so the MAC really
just serves as a checksum (and thus the wrong primitive is being used)?

- Eric

  reply	other threads:[~2025-08-01  3:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31 21:52 [PATCH 0/2] tpm: HMAC fix and cleanup Eric Biggers
2025-07-31 21:52 ` [PATCH 1/2] tpm: Compare HMAC values in constant time Eric Biggers
2025-08-01  2:28   ` James Bottomley
2025-08-01  3:02     ` Eric Biggers [this message]
2025-08-01 11:36       ` James Bottomley
2025-08-01 17:11         ` Eric Biggers
2025-08-01 18:03           ` James Bottomley
2025-08-01 18:40             ` Eric Biggers
2025-08-01 18:53               ` James Bottomley
2025-08-01 19:03                 ` Eric Biggers
2025-08-01 19:20                   ` James Bottomley
2025-08-01 20:14                     ` Eric Biggers
2025-07-31 21:52 ` [PATCH 2/2] tpm: Use HMAC-SHA256 library instead of open-coded HMAC Eric Biggers

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=20250801030210.GA1495@sol \
    --to=ebiggers@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.