diff options
author | Jeff Burdges <burdges@gnunet.org> | 2018-05-01 20:37:05 +0200 |
---|---|---|
committer | Jeff Burdges <burdges@gnunet.org> | 2018-05-01 20:37:05 +0200 |
commit | 980c6b08183bdece84ef9686ea69577844fd1c1c (patch) | |
tree | 78dc1b4e9c2e97508cf3f51f70a067acc40d8397 | |
parent | 810948feaf7f900ef3a6d18f3b38eaa9d9a7662a (diff) | |
download | papers-980c6b08183bdece84ef9686ea69577844fd1c1c.tar.gz papers-980c6b08183bdece84ef9686ea69577844fd1c1c.tar.bz2 papers-980c6b08183bdece84ef9686ea69577844fd1c1c.zip |
cofacotr comments
-rw-r--r-- | games/games.tex | 23 |
1 files changed, 8 insertions, 15 deletions
diff --git a/games/games.tex b/games/games.tex index 1f0f57f..31556c6 100644 --- a/games/games.tex +++ b/games/games.tex @@ -894,8 +894,8 @@ variant of the refresh during withdrawal, but we feel the user's commitment to buy from a particular merchant would prove constraining enough to limit applicability.} -Also Ed25519 verification must already checks that $C$ lies on the -Ed25519 curve, not some quadratic twist. +Also, Ed25519 verification necessarily already checks that $C$ lies on +the Ed25519 curve, not some quadratic twist. % https://en.wikipedia.org/wiki/EdDSA % https://safecurves.cr.yp.to/twist.html If signature verification permitted using points on the twist, like @@ -916,11 +916,14 @@ advantage for producing a failure. In Taler's refresh, we avoid key exchange failures entirely because the Edwards addition law is complete abelian group operation on the curve, -and the signature scheme verifies that $C$ lies on the curve. +and the signature scheme verifies that the point lies on the curve. % https://safecurves.cr.yp.to/refs.html#2007/bernstein-newelliptic % https://safecurves.cr.yp.to/complete.html We warn however that Weierstrass curves have incomplete addition formulas that permit an adversarial merchant to pick transfer keys that yields failures. +There are further implementation mistakes that might enable collaborative +key exchange failures, like if the exchange does not enforce the transfer +private key being a multiple of the cofactor. In this vein, almost all post-quantum key exchanges suffer from key exchange failures that permit invalid key attacks against non-ephemeral keys. @@ -931,16 +934,6 @@ We cannot reveal the old coin's private key to the exchange when verifying the transfer private keys though, which complicates verifying honest key generation of the old coin's key. -\comment{TODO: Abstract key exchange, also below. Explain key exchange failures elsewhere.} -\comment{In theory, our scalar multiplication should be injective, preventing - the second case where $t C' \neq c' T$. In practice, our exchange - might incorrectly have multiple scalar representatives $t$ yield the - same curve point $t C'$, while the user's canonical computation of - $c' T$ yields a distinct point, like perhaps the exchange accepts and - uses an incorrectly clamped scalar $t$ without correcting the clamping itself. -} - - \begin{theorem} Assume Taler both satisfies unforgeability and the refresh is instantiated with \begin{enumerate} @@ -1064,8 +1057,8 @@ We could weaken our assumption that the adversary cannot find any key exchange failures, primarily by requiring the customer cannot produce the same failure with another algorithm. There is no immediate advantage to this extra generality because -integrating with post-quantum key exchange requires considerably -more effort. +integrating with post-quantum key exchange requires solving those +schemes key validation problems. As it turns out, there is a simple hash-based solutions that provides post-quantum anonymity without additional assumptions though: |