Subject: Re: [PATCHv5 00/12] nvme: In-band authentication support
To:     Hannes Reinecke <hare@suse.de>
Cc:     Christoph Hellwig <hch@lst.de>, Keith Busch <keith.busch@wdc.com>,
        linux-nvme@lists.infradead.org,
        Herbert Xu <herbert@gondor.apana.org.au>,
        David Miller <davem@davemloft.net>,
        linux-crypto@vger.kernel.org
References: <20211112125928.97318-1-hare@suse.de>
 <74db7c77-7cbf-4bc9-1c80-e7c42acaea64@grimberg.me>
 <f67ca46e-f421-33f7-da8b-ff6e47acf8c2@suse.de>
 <8553266f-005c-f947-4737-2108cb7062d1@grimberg.me>
 <a7363853-05af-9d7f-4d6f-b02ec756ce6b@suse.de>
From:   Sagi Grimberg <sagi@grimberg.me>
Message-ID: <50095ec8-3825-efa5-98bb-76b0f0fdc21e@grimberg.me>
Date:   Tue, 16 Nov 2021 12:18:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <a7363853-05af-9d7f-4d6f-b02ec756ce6b@suse.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


>>>>> - Transform secret with correct hmac algorithm
>>>>
>>>> Is that what I reported last time? Can you perhaps
>>>> point me to the exact patch that fixes this?
>>>
>>> Well, no, not really; the patch itself got squashed in the main patches.
>>> But problem here was that the key transformation from section 8.13.5.7
>>> had been using the hash algorithm from the initial challenge, not the
>>> one specified in the key itself.
>>> This lead to decoding errors when using a key with a different length
>>> than the hash algorithm.
>>
>> That is exactly what I reported, changing the key length leads to
>> authentication errors.
> 
> Right-o. So it should be sorted then.

Hannes, was the issue on the host side or the controller side?

I'm a little lost into what was the actual fix...