linux-kernel - Re: [PATCH RFC 1/2] crypto: ti: Add support for SHA224/256/384/512 in DTHE V2 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <104cdd15-8763-49fc-9f4b-9b21020bd6a1@ti.com>
Date: Thu, 3 Apr 2025 13:58:47 +0530
From: T Pratham <t-pratham@...com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: "David S. Miller" <davem@...emloft.net>, <linux-crypto@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, Vignesh Raghavendra <vigneshr@...com>,
        Praneeth Bajjuri <praneeth@...com>,
        Kamlesh Gurudasani <kamlesh@...com>,
        Manorit Chawdhry <m-chawdhry@...com>
Subject: Re: [PATCH RFC 1/2] crypto: ti: Add support for SHA224/256/384/512 in
 DTHE V2 driver

Hi Herbert

On 02/04/25 19:01, T Pratham wrote:
> Hi Herbert
>
> On 02/03/25 13:39, Herbert Xu wrote:
>> On Tue, Feb 18, 2025 at 04:19:42PM +0530, T Pratham wrote:
>>> +struct dthe_hash_ctx {
>>> +	enum dthe_hash_algSel mode;
>>> +	u16 block_size;
>>> +	u8 digest_size;
>>> +	u8 phash_available;
>>> +	u32 phash[SHA512_DIGEST_SIZE / sizeof(u32)];
>> Is this format identical to the software sha512 hash? If so please
>> make the export/import functions translate to and from struct
>> sha512_state.
>>
>> That way we can export and resume using the software sha512 in case
>> something goes wrong (e.g., memory allocation failure).
>>
>> Ditto with all the other hash algorithms.
>>
>> Thanks,
> [...]
>
> You are correct in the sense that the format is /mostly/ identical to
> struct sha512_state. phash[], data_buf[] and digestcnt are same as in
> sha512_state. Rest of the members I can reinitialize at import. The only
> one which stores some kind of state is *buflen*, which requires its
> value to be restored while importing. The current driver implementation
> processes input in multiples of block size and stores the remainder data
> in data_buf[] if the input is not a multiple of block size. buflen has
> the length of data in data_buf[].
>
> [...]
>
I'm so sorry, for it slipped out of my mind that `u8 phash_available`
also needs to be restored at import. It's just stores a boolean 0/1. How
to go about handling this?
Thanks for your help.

Regards
T Pratham <t-pratham@...com>