summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeff Burdges <burdges@gnunet.org>2018-05-01 20:37:05 +0200
committerJeff Burdges <burdges@gnunet.org>2018-05-01 20:37:05 +0200
commit980c6b08183bdece84ef9686ea69577844fd1c1c (patch)
tree78dc1b4e9c2e97508cf3f51f70a067acc40d8397
parent810948feaf7f900ef3a6d18f3b38eaa9d9a7662a (diff)
downloadpapers-980c6b08183bdece84ef9686ea69577844fd1c1c.tar.gz
papers-980c6b08183bdece84ef9686ea69577844fd1c1c.tar.bz2
papers-980c6b08183bdece84ef9686ea69577844fd1c1c.zip
cofacotr comments
-rw-r--r--games/games.tex23
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: