View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006181 | Taler | exchange | public | 2020-04-15 10:47 | 2021-08-24 16:23 |
| Reporter | oec | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | feature | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0006181: Exchange should provide API for uniformly distributed seeds | ||||
| Description | Or: 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. | ||||
| Tags | Taler | ||||
|
|
This should have been severity "feature request". |
|
|
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. |
| 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 |
