All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thorsten Blum <thorsten.blum@linux.dev>
To: "Marek Behún" <kabel@kernel.org>
Cc: Bill Cox <waywardgeek@gmail.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	Linus Walleij <linusw@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	stable@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A
Date: Tue, 28 Apr 2026 14:32:52 +0200	[thread overview]
Message-ID: <afCo9PbDpTYeqGd4@linux.dev> (raw)
In-Reply-To: <25ntssyy6t5uwxlwfpmrpzpcq6xv62l643hflf26hxi6lv5wqu@6vub6ysczjvd>

Hi Marek,

On Tue, Apr 28, 2026 at 01:18:08PM +0200, 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.
> 
> 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?
> 
> Marek
> 
> [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023857.html
> [2] https://www.metzdowd.com/pipermail/cryptography/2014-December/023870.html
> [3] https://www.metzdowd.com/pipermail/cryptography/2014-December/023879.html
> [4] https://www.metzdowd.com/pipermail/cryptography/2014-December/023886.html

Bill wrote in his review:

  "If I made no mistake (and I do make a lot), the "random" data from
   the Atmel ATSHA204A is highly predictable when you disable the seed
   update to EEPROM."

However, the atmel-sha204a driver doesn't operate the device in that
mode. It uses the Random command with seed updates enabled, which is
also what the datasheet recommends for highest security:

  "Microchip recommends that the EEPROM seed always be updated."

So the reported behavior doesn't reflect how the driver uses the device.

Thanks,
Thorsten


  parent reply	other threads:[~2026-04-28 12:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-28 10:14 [PATCH v2] crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A Thorsten Blum
2026-04-28 10:18 ` Ard Biesheuvel
2026-04-28 11:18 ` Marek Behún
2026-04-28 12:18   ` Ard Biesheuvel
2026-04-28 12:32   ` Thorsten Blum [this message]
2026-04-28 13:24     ` Marek Behún
2026-04-28 16:30       ` Ard Biesheuvel
2026-05-05  9:30 ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afCo9PbDpTYeqGd4@linux.dev \
    --to=thorsten.blum@linux.dev \
    --cc=alexandre.belloni@bootlin.com \
    --cc=ardb@kernel.org \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=kabel@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=stable@vger.kernel.org \
    --cc=waywardgeek@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.