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: <f7105c10-7e36-4914-a9e8-e83eb61f0189@ti.com>
Date: Wed, 2 Apr 2025 19:01:25 +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/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,

I noticed that you are making changes to the export format of hash
algorithms (s390 hmac
<https://lore.kernel.org/linux-crypto/Z-AJFwndherQBH2W@gondor.apana.org.au/#r>,
caam hashing
<https://lore.kernel.org/linux-crypto/Z-AJx1oPRE2_X1GE@gondor.apana.org.au/#r>).
I was in process of finalizing my driver for a v2 and had some queries
about the above feedback from you.

In my dthe_hash_ctx struct below:

+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)]; + u32 phash_size; + u32 digestcnt; + u8
data_buf[SHA512_BLOCK_SIZE]; + u8 buflen; + struct completion
hash_compl; +};

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[].

How are you planning to restore such states in import if the export is
to be made compatible with sha512_state? Do you have any pointers for me
on how to change the import/export before sending the next revision of
my driver?

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