All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
To: Eric Biggers <ebiggers@kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: RE: ghash
Date: Fri, 19 Jul 2019 23:25:31 +0000	[thread overview]
Message-ID: <MN2PR20MB297363B1B642361BBBBF28FACACB0@MN2PR20MB2973.namprd20.prod.outlook.com> (raw)
In-Reply-To: <20190719223505.GF1422@gmail.com>

> 
> Hmm, NIST SP 800-38D actually defines GHASH to take one argument, same as the
> Linux version.  So even outside Linux, there is no consensus on whether "GHASH"
> refers to the one argument or two argument versions.
> 
Funny, I just stumbled upon that 2007 NIST specification myself minutes ago, before I
saw this mail. So yes, it looks like they redefined GHASH from the original 2005 
McGrew/Viega definition there, although I don't have a clue as to why ...
Must've been after our initial hardware implementation though, since all of our 
hardware strictly implements it according to the original McGrew/Viega definition
(which is also still surviving on Wikipedia)

> I.e. even if we had an API where the AAD and ciphertext were passed in
> separately, which is apparently what you'd prefer, people would complain that it
> doesn't match the NIST standard version.
> 
Prefer is a big word ... it's just that our hardware cannot do unformatted GHASH
that way as that was not the specification at the time we implemented it.
And that redefinition went totally unnoticed.

> Of course, in the end the actually important thing is that everyone agrees on
> GCM, not that they agree on GHASH.
> 
As long as GHASH is not being used for much else, probably. And in either case,
the crypto API implementation is flexible as it just pushes all the formatting out.
Our hardware, on the other hand :-(

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com

  reply	other threads:[~2019-07-19 23:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19 14:05 ghash Pascal Van Leeuwen
2019-07-19 16:16 ` ghash Eric Biggers
2019-07-19 19:26   ` ghash Pascal Van Leeuwen
2019-07-19 19:56     ` ghash Eric Biggers
2019-07-19 20:49       ` ghash Pascal Van Leeuwen
2019-07-19 21:48         ` ghash Eric Biggers
2019-07-19 22:35           ` ghash Eric Biggers
2019-07-19 23:25             ` Pascal Van Leeuwen [this message]
2019-07-19 23:09           ` ghash Pascal Van Leeuwen

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=MN2PR20MB297363B1B642361BBBBF28FACACB0@MN2PR20MB2973.namprd20.prod.outlook.com \
    --to=pvanleeuwen@verimatrix.com \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@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.