View Issue Details

IDProjectCategoryView StatusLast Update
0006181Talerexchangepublic2021-08-24 16:23
Reporteroec Assigned ToChristian Grothoff  
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.8Fixed in Version0.8 
Summary0006181: Exchange should provide API for uniformly distributed seeds
DescriptionOr: The Debian Effect on GNU Taler

One implicit assumption in the GNU Taler system is the uniformly random
distribution of all public keys, for coins and reserves. The likelihood
that two customers generate the same ED25519-keypair for their coins
must be negligible. In other words, there is an implicit assumption
about the quality of the PRNG's on each of the customer's devices.

However, history shows that this is assumption is false in reality:
F.e., due to a severe bug introduced by Debian into their openssl
package in 2008, customers of GNU Taler back then would very probably
have had plenty of collisions of those coins. They would have withdrawn
them from the exchange successfully (and thereby moving money from their
banks to the reserve and paying fees), but not everybody would be able
to use them afterwards because of detected "double-spending". And it
seems that there is not much the customer could do about this right now.

This is not per se a security problem for the exchange, but certainly an
issue for the acceptance of the GNU Taler system for customers and
merchants. And as we boldy assume that 300M Europeans are soon going to
use GNU Taler, creating billions of coins a year on systems with unknown
entropy of their PRNG's, the key distribution will be unknown and
probably non-uniform.

As a potential remedy, an exchange could offer an additional
API-endpoint /seed (GET) to provide random seeds (32bytes maybe) for the
wallet software to use as a seed when generating coins. This would
establish two things:

   1. The exchange would guarantee (==become responsible) to provide
      uniformly distributed seeds for all customers.

   2. The exchange could then statistically/rightfully argue to not
      accept any claims of collisions of coins.

Note also that, depending on the requirements from the regulator, an auditor
might also be able to evaluate the entropy of the PRNG of the exchange.



2020-04-15 10:53

developer   ~0015654

This should have been severity "feature request".

Christian Grothoff

2020-05-01 19:53

manager   ~0015839

Documented (docs.git, master) and implemented in the protocolv8 branch. Note that to keep it simple (and portable!), I'm using nothing fancy and just the libgnunetutil/libgcrypt PRNG and also no sendfile() in this implementation.

Issue History

Date Modified Username Field Change
2020-04-15 10:47 oec New Issue
2020-04-15 10:47 oec Status new => assigned
2020-04-15 10:47 oec Assigned To => Christian Grothoff
2020-04-15 10:47 oec Tag Attached: Taler
2020-04-15 10:53 oec Note Added: 0015654
2020-04-15 10:57 Christian Grothoff Severity major => feature
2020-04-15 10:57 Christian Grothoff Product Version => git (master)
2020-04-15 10:57 Christian Grothoff Target Version => 0.9
2020-04-15 23:58 Christian Grothoff Assigned To Christian Grothoff =>
2020-04-15 23:58 Christian Grothoff Status assigned => confirmed
2020-05-01 19:53 Christian Grothoff Assigned To => Christian Grothoff
2020-05-01 19:53 Christian Grothoff Status confirmed => resolved
2020-05-01 19:53 Christian Grothoff Resolution open => fixed
2020-05-01 19:53 Christian Grothoff Fixed in Version => 0.8
2020-05-01 19:53 Christian Grothoff Note Added: 0015839
2020-05-01 19:54 Christian Grothoff Target Version 0.9 => 0.8
2021-08-24 16:23 Christian Grothoff Status resolved => closed