Re: [PATCH v2] crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A

["Ard Biesheuvel" <ardb@kernel.org>]

Hi Marek,

On Tue, 28 Apr 2026, at 13:18, Marek Behún wrote:
> Adding Bill Cox (waywardgeek) to the conversation.
>
> In the meantime Nack from me on this patch.
>
> From the original messages by Bill, it seems to me the part he was reviewing
> was the ATSHA204A.
>

According to Landon Cox, the Atmel engineer, the hashlet has a ATSHA204 not
ATSHA204A ([2] in the original post)

> In subsequent reply [1] Bill states
>
>   While there is some evidence, there is still no convincing proof that there
>   is an entropy source in this device at all.  There is some evidence that
>   Atmel has inserted a back-door.  My advice is to avoid this line of parts
>   from Atmel for cryptographic use.
>
> In another message Peter Gutmann asks about ATECC108 [2] and Bill replies [3]
>
>   This part uses the same language to describe the random number generator.
>   It is "high quality".  I think that's pretty funny.
>   I would be interested in seeing if the new part can generate random numbers
>   continuously, or if it fails after it's EEPROM wears out like their other
>   parts.  The use of an EEPROM seed is for PWN-ing your RNG, not making it
>   more secure.
>
> IMO the comments from the actual reviewer are more relevant than those of the
> engineer working for the company which was accused of creating low quality
> / backdoored TRNG, at least until the Atmel engineer provides some evaluation
> code for the device (which they suggested they might do [4], but never did as
> far as I can find).
>
> Maybe we can instead change the ATECC quality to something like 32? Does that
> even make sense?
>

So Bill recommends against using the ATSHA204 based on his hands-on experience,
and extrapolates this to ATSHA204A/ATECC/etc based on the fact that the wording
in the data sheet description looks similar.

OTOH, the Atmel engineer claiming to have been involved in constructing these
parts acknowledges the ATSHA204 issue, and claims that the other parts are not
affected in the same way.

I don't think we should be using the quality field as a reflection of our
assessment whether this engineer is lying or speaking the truth, or the
likelihood that the RNG is backdoored. It is a quality metric not a trust metric.

So if the RNG is flawed and does not produce perfect entropy, we should set
the quality value to reflect this. If the device is compromised, it should
be avoided entirely, and what the driver does is irrelevant.

IOW, let the user decide - if they choose to use the device, don't cripple
it based on our skepticism alone.