Re: [CFRG] Millions of dollars of hashing

"D. J. Bernstein" <djb@cr.yp.to> Sat, 24 February 2024 15:53 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F28C14F6A3 for <cfrg@ietfa.amsl.com>; Sat, 24 Feb 2024 07:53:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxjyrCFDwBru for <cfrg@ietfa.amsl.com>; Sat, 24 Feb 2024 07:53:15 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 96035C14F69F for <cfrg@irtf.org>; Sat, 24 Feb 2024 07:53:15 -0800 (PST)
Received: (qmail 14132 invoked by uid 1010); 24 Feb 2024 15:53:14 -0000
Received: from unknown (unknown) by unknown with QMTP; 24 Feb 2024 15:53:14 -0000
Received: (qmail 1076003 invoked by uid 1000); 24 Feb 2024 15:53:03 -0000
Date: Sat, 24 Feb 2024 15:53:03 -0000
Message-ID: <20240224155303.1076001.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@irtf.org
Mail-Followup-To: cfrg@irtf.org
In-Reply-To: <SY4PR01MB62514DC28D92CAD4BA8D1416EE542@SY4PR01MB6251.ausprd01.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/KpW92DdzxureHaqPNpMJQtJM6j8>
Subject: Re: [CFRG] Millions of dollars of hashing
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://mailman.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://mailman.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Feb 2024 15:53:19 -0000

Peter Gutmann writes:
> I was thinking of (EC)DH on an STM32F4.

Just to fill in some STM32F4 quantification for those of us who prefer
to work with numbers rather than trying to figure out the dividing line
between "expensive" and "very fast": The 2019 paper

   https://tches.iacr.org/index.php/TCHES/article/view/7384/6556

reports 655891 X25519 cycles on a STM32F407 running at 168MHz (i.e., 3.9
milliseconds), or 847048 cycles at 168MHz (i.e., 5.0 milliseconds) if
you turn off flash prefetch, or 625358 cycles if you scale down to 16MHz
(so 39.1 milliseconds).

STM32F407VET6TR includes 512KB of flash and is currently $7.42 in bulk
from Mouser. STM32F407VGT7TR includes 1MB and is $9.24 in bulk. If 80MHz
and 64KB are enough then an STM32L412K8U6TR is $1.85 in bulk. There are
many more options.

For people thinking about the post-quantum situation, pqm4 (which uses
an STM32F407VGT6 running at 24MHz) reports 863343 cycles for Kyber-768
enc and 783369 cycles for Kyber-768 dec.

If keys are used only once, then Kyber-768 adds 706531 cycles for
keygen; meanwhile X25519 keygen multiplies CPU cycles on each side by
something between 1.3 and 1.5 for typical table sizes (I'm estimating
here), or by 2 to minimize code size if speed isn't actually an issue.
The one-time scenario also means that these aren't long-term identity
keys, so there's a further cost for another layer of public-key
operations---e.g., encrypting to a long-term key.

Another cost is the network. A 1088-byte Kyber-768 ciphertext takes more
than 10 milliseconds to transmit with the smartcard communication rates
listed in, e.g., slide 6 here ("Communication rates ... < 100 kB/s"):

   https://csrc.nist.gov/CSRC/media/Presentations/smartcard-and-post-quantum-crypto/images-media/session-5-greuet-smartcard-pqc.pdf

That slide also describes a "high-end smartcard" as having a Cortex-M3
CPU running at 100MHz; that was a few years ago. The Cortex-M4 cycle
counts listed above are smaller than Cortex-M3 cycle counts for the same
operations. I don't know how to get data on the distribution of
smartcard CPUs sold today.

---D. J. Bernstein