From: Stephan Mueller <smueller@chronox.de> To: Simo Sorce <simo@redhat.com>, Hannes Reinecke <hare@suse.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 16:47:00 +0200 [thread overview] Message-ID: <d170c0cfcb8bbeb4fe4bed367cd4689a522ae469.camel@chronox.de> (raw) In-Reply-To: <5ec6c8d5a0259a2d632589c154093ebfbbcdb47b.camel@redhat.com> Am Dienstag, dem 20.07.2021 um 10:44 -0400 schrieb Simo Sorce: > On Tue, 2021-07-20 at 13:31 +0200, Hannes Reinecke wrote: > > On 7/20/21 12:49 PM, Simo Sorce wrote: > > > 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. > > > > > > > According to RFC7919: > > Peers using ffdhe8192 that want to optimize their key exchange with a > > short exponent (Section 5.2) should choose a secret key of at least > > 400 bits. > > > > So what is wrong with 512 bits? > > > RFC7519 is TLS Specific. > I do not know if short-exponents are safe to use in all use cases. > > If it is safe, your choice is fine and your arguments will follow, but > then a comment that explains the choice and warns about key checks if > it is changed would be a good idea. > > Otherwise the default should be to use N = len(q), which implies the > proper checks need to be applied. Agreed. Ciao Stephan > > Simo. > > > > > 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) > > > > > > > Which is what I've tried to argue. For 512 bits private key and the > > smallest possible FFDHE group (which has 2048 bits, with the top bit > > non-zero) 2^N is always smaller than (q - 1). > > As the other FFHDE groups are using even larger 'q' values, this is true > > for all FFHDE groups. > > > > > > 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. > > > > > > > And my argument here is that all zeros (and all ones) are not a value I > > would expect from our RNG. > > > > > > 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? > > > > > > > Only if (q - 2) < 2^N. And my point is that it's not. > > > > Cheers, > > > > Hannes >
WARNING: multiple messages have this Message-ID (diff)
From: Stephan Mueller <smueller@chronox.de> To: Simo Sorce <simo@redhat.com>, Hannes Reinecke <hare@suse.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 16:47:00 +0200 [thread overview] Message-ID: <d170c0cfcb8bbeb4fe4bed367cd4689a522ae469.camel@chronox.de> (raw) In-Reply-To: <5ec6c8d5a0259a2d632589c154093ebfbbcdb47b.camel@redhat.com> Am Dienstag, dem 20.07.2021 um 10:44 -0400 schrieb Simo Sorce: > On Tue, 2021-07-20 at 13:31 +0200, Hannes Reinecke wrote: > > On 7/20/21 12:49 PM, Simo Sorce wrote: > > > 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. > > > > > > > According to RFC7919: > > Peers using ffdhe8192 that want to optimize their key exchange with a > > short exponent (Section 5.2) should choose a secret key of at least > > 400 bits. > > > > So what is wrong with 512 bits? > > > RFC7519 is TLS Specific. > I do not know if short-exponents are safe to use in all use cases. > > If it is safe, your choice is fine and your arguments will follow, but > then a comment that explains the choice and warns about key checks if > it is changed would be a good idea. > > Otherwise the default should be to use N = len(q), which implies the > proper checks need to be applied. Agreed. Ciao Stephan > > Simo. > > > > > 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) > > > > > > > Which is what I've tried to argue. For 512 bits private key and the > > smallest possible FFDHE group (which has 2048 bits, with the top bit > > non-zero) 2^N is always smaller than (q - 1). > > As the other FFHDE groups are using even larger 'q' values, this is true > > for all FFHDE groups. > > > > > > 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. > > > > > > > And my argument here is that all zeros (and all ones) are not a value I > > would expect from our RNG. > > > > > > 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? > > > > > > > Only if (q - 2) < 2^N. And my point is that it's not. > > > > Cheers, > > > > Hannes > _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-07-20 15:02 UTC|newest] Thread overview: 163+ 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 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 01/11] crypto: add crypto_has_shash() Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:08 ` Sagi Grimberg 2021-07-17 6:08 ` Sagi Grimberg 2021-07-16 11:04 ` [PATCH 02/11] crypto: add crypto_has_kpp() Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:08 ` Sagi Grimberg 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-16 11:04 ` Hannes Reinecke 2021-07-17 6:14 ` Sagi Grimberg 2021-07-17 6:14 ` Sagi Grimberg 2021-07-17 13:57 ` Hannes Reinecke 2021-07-17 13:57 ` Hannes Reinecke 2021-07-17 15:03 ` Stephan Müller 2021-07-17 15:03 ` Stephan Müller 2021-07-18 12:22 ` Hannes Reinecke 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-16 11:04 ` Hannes Reinecke 2021-07-17 6:16 ` Sagi Grimberg 2021-07-17 6:16 ` Sagi Grimberg 2021-07-17 14:00 ` Hannes Reinecke 2021-07-17 14:00 ` Hannes Reinecke 2021-07-17 14:12 ` Eric Biggers 2021-07-17 14:12 ` Eric Biggers 2021-07-17 14:20 ` 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-16 11:04 ` Hannes Reinecke 2021-07-17 6:30 ` Sagi Grimberg 2021-07-17 6:30 ` Sagi Grimberg 2021-07-17 14:04 ` Hannes Reinecke 2021-07-17 14:04 ` Hannes Reinecke 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-16 11:04 ` [PATCH 06/11] nvme: Implement " Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 7:22 ` Sagi Grimberg 2021-07-17 7:22 ` Sagi Grimberg 2021-07-18 12:21 ` Hannes Reinecke 2021-07-18 12:21 ` Hannes Reinecke 2021-07-19 8:47 ` Sagi Grimberg 2021-07-19 8:47 ` Sagi Grimberg 2021-07-20 20:28 ` Vladislav Bolkhovitin 2021-07-20 20:28 ` Vladislav Bolkhovitin 2021-07-21 6:12 ` Hannes Reinecke 2021-07-21 6:12 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:43 ` Hannes Reinecke 2021-07-18 12:43 ` Hannes Reinecke 2021-07-18 12:47 ` Stephan Müller 2021-07-18 12:47 ` Stephan Müller 2021-07-20 20:27 ` Vladislav Bolkhovitin 2021-07-20 20:27 ` Vladislav Bolkhovitin 2021-07-21 6:08 ` Hannes Reinecke 2021-07-21 6:08 ` Hannes Reinecke 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-16 11:04 ` [PATCH 07/11] nvme-auth: augmented challenge support Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:27 ` Hannes Reinecke 2021-07-18 12:27 ` Hannes Reinecke 2021-07-18 12:57 ` Stephan Müller 2021-07-18 12:57 ` Stephan Müller 2021-07-19 9:21 ` Sagi Grimberg 2021-07-19 9:21 ` Sagi Grimberg 2021-07-20 13:12 ` Hannes Reinecke 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-16 11:04 ` Hannes Reinecke 2021-07-19 9:21 ` Sagi Grimberg 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-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:37 ` Hannes Reinecke 2021-07-18 12:37 ` Hannes Reinecke 2021-07-18 12:56 ` Stephan Müller 2021-07-18 12:56 ` Stephan Müller 2021-07-19 8:15 ` Hannes Reinecke 2021-07-19 8:15 ` Hannes Reinecke 2021-07-19 8:51 ` Stephan Mueller 2021-07-19 8:51 ` Stephan Mueller 2021-07-19 9:57 ` Hannes Reinecke 2021-07-19 9:57 ` Hannes Reinecke 2021-07-19 10:19 ` Stephan Mueller 2021-07-19 10:19 ` Stephan Mueller 2021-07-19 11:10 ` Hannes Reinecke 2021-07-19 11:10 ` Hannes Reinecke 2021-07-19 11:52 ` Stephan Mueller 2021-07-19 11:52 ` Stephan Mueller 2021-07-19 12:08 ` Hannes Reinecke 2021-07-19 12:08 ` Hannes Reinecke 2021-07-20 10:14 ` Hannes Reinecke 2021-07-20 10:14 ` Hannes Reinecke 2021-07-20 10:49 ` Simo Sorce 2021-07-20 10:49 ` Simo Sorce 2021-07-20 11:31 ` Hannes Reinecke 2021-07-20 11:31 ` Hannes Reinecke 2021-07-20 14:44 ` Simo Sorce 2021-07-20 14:44 ` Simo Sorce 2021-07-20 14:47 ` Stephan Mueller [this message] 2021-07-20 14:47 ` Stephan Mueller 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-18 13:26 ` Herbert Xu 2021-07-18 13:26 ` Herbert Xu 2021-07-19 20:38 ` Sagi Grimberg 2021-07-19 20:38 ` Sagi Grimberg 2021-07-20 6:08 ` Hannes Reinecke 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-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:25 ` Hannes Reinecke 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-16 11:04 ` Hannes Reinecke 2021-07-17 16:50 ` Stephan Müller 2021-07-17 16:50 ` Stephan Müller 2021-07-18 12:44 ` Hannes Reinecke 2021-07-18 12:44 ` Hannes Reinecke 2021-07-19 9:23 ` Sagi Grimberg 2021-07-19 9:23 ` Sagi Grimberg 2021-07-19 9:56 ` Hannes Reinecke 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-17 6:06 ` Sagi Grimberg 2021-07-19 10:02 ` Simo Sorce 2021-07-19 10:02 ` Simo Sorce 2021-07-19 11:11 ` Hannes Reinecke 2021-07-19 11:11 ` Hannes Reinecke 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-21 6:06 ` Hannes Reinecke 2021-07-21 6:06 ` Hannes Reinecke 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-24 11:17 ` Hannes Reinecke 2021-07-24 11:17 ` Hannes Reinecke 2022-03-23 7:12 [PATCHv9 " Hannes Reinecke 2022-03-23 7:13 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-03-28 8:08 [PATCHv10 00/11] nvme: In-band authentication support Hannes Reinecke 2022-03-28 8:08 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-03-28 13:39 [PATCHv11 00/11] nvme: In-band authentication support Hannes Reinecke 2022-03-28 13:39 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-05-18 11:22 [PATCHv12 00/11] nvme: In-band authentication support 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 2022-06-08 14:45 [PATCHv14 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-08 14:45 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-06-21 9:02 [PATCHv15 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-21 9:02 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-06-21 17:24 [PATCHv16 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-21 17:24 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-06-23 6:17 [PATCHv17 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-23 6:17 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-06-27 9:51 [PATCHv18 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-27 9:52 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke
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=d170c0cfcb8bbeb4fe4bed367cd4689a522ae469.camel@chronox.de \ --to=smueller@chronox.de \ --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=simo@redhat.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: linkBe 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.