On Mon, Oct 05, 2026 at 05:04:25PM +0000, Ousherovitch, Alex wrote: > > > Please also elaborate what you mean by opaque checkpoint, does it > > contain the entire hash state or not? > > It holds everything needed to resume, but not in a portable layout. The > SAVE output is a fixed-size hardware container (600 bytes worst case) > holding the core's internal state, the buffered partial block, the block > counters, the mode and a CRC. The state portion varies by algorithm: > > - SHA-3/SHAKE: the 200-byte Keccak state is stored as two shares (the > core is DPA/side-channel protected), so it is not the canonical > state. > - SHA-2: a single 64-byte register block plus the partial block and > byte count, in a hardware-internal layout. > - Keyed SHA-3 HMAC state cannot be saved by the hardware at all.
So it sounds like the info is there. Is it possible to transform this to the format that we use? > None of these is the canonical export format the API needs, so the > fallback/digest-only model above is the right fit and we are not pursuing > incremental hashing upstream. That's we have the export and import functions, to transcribe the hardware hash state into a standard format. > One process question, if you don't mind: we would like to fold as much as > possible into v6 rather than spinning several revisions. Have you had a > chance to look at the rest of the series, or should we expect further > comments on the remaining patches? No rush at all -- it would just help > us decide whether to post v6 now or hold it until the rest of your > feedback has landed. I would appreciate it if you can break the series into smaller chunks. Perhaps add the algorithms which are the least problematic first. Thanks, -- Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
