taler-www

Main taler.net website
Log | Files | Refs | Submodules | README | LICENSE

commit e02f0bfdc398c99a24fe83046beb6b726b961dc7
parent 0d460969d9f58c9e548a088334d694bcb7768520
Author: Christian Grothoff <christian@grothoff.org>
Date:   Sat, 26 Sep 2026 13:00:03 +0200

typos

Diffstat:
Mtemplate/news/2026-12.html.j2 | 13++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/template/news/2026-12.html.j2 b/template/news/2026-12.html.j2 @@ -13,7 +13,7 @@ analyze it to derive what its implications are on how one should configure a GNU Taler exchange, after all forging RSA signatures would enable an attacker to print money and bankrupt Taler exchange operators! - What follows is a coarse back-of-the-envelope extrapolation of the cost + What follows is a coarse back-of-the-envelope rough extrapolation of the cost of the attack against the standard GNU Taler configuration. </p> <p> @@ -56,9 +56,12 @@ so the computational cost of the attack would be about 4.6 trillion USD, or about 10% of the current US national debt. There is a little problem with provisioning the compute though: a random Internet search suggests we have about - 2 billion (suitable, high-performance) CPU cores available in data centers on the plant, - so at current compute capacity this calculation would require 23 years, and - by default GNU Taler's blind signatures expire after about 2 years. + 2 billion (suitable, high-performance) CPU cores available in data centers on the planet + (an alternative quick plausibility check suggested AMSL production limits + resulting in about 4-8 billion suitable CPU cores having been produced in total by 2026). + Taking the 2 billion number as available compute capacity, + the computational part of the attack would require 23 years, and + in the default configuration GNU Taler's blind signatures expire after about 2 years. Hence, for a practical attack, an attacker would also have to scale global available data center capacity by a factor of 10, and then use all of it for two years. @@ -70,7 +73,7 @@ banks for China, the US or Europe that require additional safety margins are advised to increase the key rotation frequency for their rCBDC GNU Taler deployments to once per day or even per hour. GNU Taler - also supports RSA-4092, but at this point we see no reason for anyone + also supports RSA-4096, but at this point we see no reason for anyone to use settings beyond RSA-2048. </p>