From: Simo Sorce <simo@redhat.com>
To: Hannes Reinecke <hare@suse.de>,
Stephan Mueller <smueller@chronox.de>,
Christoph Hellwig <hch@lst.de>
Cc: Sagi Grimberg <sagi@grimberg.me>,
Keith Busch <keith.busch@wdc.com>,
linux-nvme@lists.infradead.org,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH 09/11] nvmet: Implement basic In-Band Authentication
Date: Tue, 20 Jul 2021 06:49:47 -0400 [thread overview]
Message-ID: <11ab4001f580a6b2c3cce959282259c1f9095f63.camel@redhat.com> (raw)
In-Reply-To: <aac9448e-29e9-6d03-1077-148be3c10f50@suse.de>
On Tue, 2021-07-20 at 12:14 +0200, Hannes Reinecke wrote:
> On 7/19/21 1:52 PM, Stephan Mueller wrote:
> > Am Montag, dem 19.07.2021 um 13:10 +0200 schrieb Hannes Reinecke:
> > > On 7/19/21 12:19 PM, Stephan Mueller wrote:
> > > > Am Montag, dem 19.07.2021 um 11:57 +0200 schrieb Hannes Reinecke:
> > > > > On 7/19/21 10:51 AM, Stephan Mueller wrote:
> [ .. ]
> > > > > >
> > > > > > Thank you for clarifying that. It sounds to me that there is no
> > > > > > defined protocol (or if there, I would be wondering how the code would have
> > > > > > worked
> > > > > > with a different implementation). Would it make sense to first specify
> > > > > > a protocol for authentication and have it discussed? I personally think
> > > > > > it is a bit difficult to fully understand the protocol from the code and
> > > > > > discuss protocol-level items based on the code.
> > > > > >
> > > > > Oh, the protocol _is_ specified:
> > > > >
> > > > >
> > > > > https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2_0-2021.06.02-Ratified-5.pdf
> > > > >
> > > > > It's just that I have issues translating that spec onto what the kernel
> > > > > provides.
> > > >
> > > > according to the naming conventions there in figures 447 and following:
> > > >
> > > > - x and y: DH private key (kernel calls it secret set with dh_set_secret
> > > > or
> > > > encoded into param.key)
> > > >
> > >
> > > But that's were I got confused; one needs a private key here, but there
> > > is no obvious candidate for it. But reading it more closely I guess the
> > > private key is just a random number (cf the spec: g^y mod p, where y is
> > > a random number selected by the host that shall be at least 256 bits
> > > long). So I'll fix it up with the next round.
> >
> > Here comes the crux: the kernel has an ECC private key generation function
> > ecdh_set_secret triggered with crypto_kpp_set_secret using a NULL key, but it
> > has no FFC-DH counterpart.
> >
> > That said, generating a random number is the most obvious choice, but not the
> > right one.
> >
> > The correct one would be following SP800-56A rev 3 and here either section
> > 5.6.1.1.3 or 5.6.1.1.4.
> >
> Hmm. Okay. But after having read section 5.6.1.1.4, I still do have some
> questions.
>
> Assume we will be using a bit length of 512 for FFDHE, then we will
> trivially pass Step 2 for all supported FFDHE groups (the maximum
> symmetric-equivalent strength for ffdhe8192 is 192 bits).
N = 512 is not a good choice, minimum length these days for DH should
be 2048 or more.
> From my understanding, the random number generator will fill out all
> available bytes in the string (and nothing more), so we trivially
> satisfy step 3 and 4.
>
> And as q is always larger than the random number, step 6 reduces to
> 'if (c > 2^N - 2)',
Where is this coming from ?
It seem you assume M = 2^N but M = min(2^N, q)
The point here is to make sure the number X you return is:
0 < X < (q-1)
> ie we just need to check if the random number is a
> string of 0xff characters. Which hardly is a random number at all, so
> it'll be impossible to get this.
>
> Which then would mean that our 'x' is simply the random number + 1,
This is an artifact due to the random number being 0 <= c < 2^N - 1,
therefore 1 needs to be added to make sure you never return 0.
> which arguably is slightly pointless (one more than a random number is
> as random as the number itself), so I do feel justified with just
> returning a random number here.
>
> Am I wrong with that reasoning?
Looks to me you are not accounting for the fact that N = 512 is too
small and a random number falling in the interval (q - 2) < X < 2^N is
unsuitable?
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
next prev parent reply other threads:[~2021-07-20 10:55 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-16 11:04 [RFC PATCH 00/11] nvme: In-band authentication support Hannes Reinecke
2021-07-16 11:04 ` [PATCH 01/11] crypto: add crypto_has_shash() Hannes Reinecke
2021-07-17 6:08 ` Sagi Grimberg
2021-07-16 11:04 ` [PATCH 02/11] crypto: add crypto_has_kpp() Hannes Reinecke
2021-07-17 6:08 ` Sagi Grimberg
2021-07-16 11:04 ` [PATCH 03/11] crypto/ffdhe: Finite Field DH Ephemeral Parameters Hannes Reinecke
2021-07-17 6:14 ` Sagi Grimberg
2021-07-17 13:57 ` Hannes Reinecke
2021-07-17 15:03 ` Stephan Müller
2021-07-18 12:22 ` Hannes Reinecke
2021-07-16 11:04 ` [PATCH 04/11] lib/base64: RFC4648-compliant base64 encoding Hannes Reinecke
2021-07-17 6:16 ` Sagi Grimberg
2021-07-17 14:00 ` Hannes Reinecke
2021-07-17 14:12 ` Eric Biggers
2021-07-17 14:20 ` Eric Biggers
2021-07-16 11:04 ` [PATCH 05/11] nvme: add definitions for NVMe In-Band authentication Hannes Reinecke
2021-07-17 6:30 ` Sagi Grimberg
2021-07-17 14:04 ` Hannes Reinecke
2021-07-20 20:26 ` Vladislav Bolkhovitin
2021-07-16 11:04 ` [PATCH 06/11] nvme: Implement " Hannes Reinecke
2021-07-17 7:22 ` Sagi Grimberg
2021-07-18 12:21 ` Hannes Reinecke
2021-07-19 8:47 ` Sagi Grimberg
2021-07-20 20:28 ` Vladislav Bolkhovitin
2021-07-21 6:12 ` Hannes Reinecke
2021-07-17 16:49 ` Stephan Müller
2021-07-18 12:43 ` Hannes Reinecke
2021-07-18 12:47 ` Stephan Müller
2021-07-20 20:27 ` Vladislav Bolkhovitin
2021-07-21 6:08 ` Hannes Reinecke
2021-07-21 12:10 ` Vladislav Bolkhovitin
2021-07-16 11:04 ` [PATCH 07/11] nvme-auth: augmented challenge support Hannes Reinecke
2021-07-17 16:49 ` Stephan Müller
2021-07-18 12:27 ` Hannes Reinecke
2021-07-18 12:57 ` Stephan Müller
2021-07-19 9:21 ` Sagi Grimberg
2021-07-20 13:12 ` Hannes Reinecke
2021-07-16 11:04 ` [PATCH 08/11] nvmet: Parse fabrics commands on all queues Hannes Reinecke
2021-07-19 9:21 ` Sagi Grimberg
2021-07-16 11:04 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke
2021-07-17 16:49 ` Stephan Müller
2021-07-18 12:37 ` Hannes Reinecke
2021-07-18 12:56 ` Stephan Müller
2021-07-19 8:15 ` Hannes Reinecke
2021-07-19 8:51 ` Stephan Mueller
2021-07-19 9:57 ` Hannes Reinecke
2021-07-19 10:19 ` Stephan Mueller
2021-07-19 11:10 ` Hannes Reinecke
2021-07-19 11:52 ` Stephan Mueller
2021-07-19 12:08 ` Hannes Reinecke
2021-07-20 10:14 ` Hannes Reinecke
2021-07-20 10:49 ` Simo Sorce [this message]
2021-07-20 11:31 ` Hannes Reinecke
2021-07-20 14:44 ` Simo Sorce
2021-07-20 14:47 ` Stephan Mueller
2021-07-23 20:02 ` Vladislav Bolkhovitin
2021-07-18 13:26 ` Herbert Xu
2021-07-19 20:38 ` Sagi Grimberg
2021-07-20 6:08 ` Hannes Reinecke
2021-07-16 11:04 ` [PATCH 10/11] nvmet-auth: implement support for augmented challenge Hannes Reinecke
2021-07-17 16:49 ` Stephan Müller
2021-07-18 12:25 ` Hannes Reinecke
2021-07-16 11:04 ` [PATCH 11/11] nvme: add non-standard ECDH and curve25517 algorithms Hannes Reinecke
2021-07-17 16:50 ` Stephan Müller
2021-07-18 12:44 ` Hannes Reinecke
2021-07-19 9:23 ` Sagi Grimberg
2021-07-19 9:56 ` Hannes Reinecke
2021-07-17 6:06 ` [RFC PATCH 00/11] nvme: In-band authentication support Sagi Grimberg
2021-07-19 10:02 ` Simo Sorce
2021-07-19 11:11 ` Hannes Reinecke
2021-07-20 20:26 ` Vladislav Bolkhovitin
2021-07-21 6:06 ` Hannes Reinecke
2021-07-21 12:10 ` Vladislav Bolkhovitin
2021-07-23 20:02 ` Vladislav Bolkhovitin
2021-07-24 11:17 ` Hannes Reinecke
2022-05-18 11:22 [PATCHv12 " Hannes Reinecke
2022-05-18 11:22 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke
2022-05-22 11:44 ` Max Gurtovoy
2022-05-23 6:03 ` Hannes Reinecke
2022-05-25 10:42 ` Sagi Grimberg
2022-06-07 10:46 ` Christoph Hellwig
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=11ab4001f580a6b2c3cce959282259c1f9095f63.camel@redhat.com \
--to=simo@redhat.com \
--cc=davem@davemloft.net \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=herbert@gondor.apana.org.au \
--cc=keith.busch@wdc.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=smueller@chronox.de \
/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).