summaryrefslogtreecommitdiff
path: root/taler-fc19/paper.tex
diff options
context:
space:
mode:
authorJeff Burdges <burdges@gnunet.org>2018-09-18 22:04:35 +0200
committerJeff Burdges <burdges@gnunet.org>2018-09-18 22:05:39 +0200
commitbf4c9d05b9de4572478b6b7b10bd1188cb738c36 (patch)
tree18a0984ade27d76015a00a70145c3c44377881b4 /taler-fc19/paper.tex
parente325d4bbd80a3f6efb37c2bad2d2d63e08f64f51 (diff)
downloadpapers-bf4c9d05b9de4572478b6b7b10bd1188cb738c36.tar.gz
papers-bf4c9d05b9de4572478b6b7b10bd1188cb738c36.tar.bz2
papers-bf4c9d05b9de4572478b6b7b10bd1188cb738c36.zip
More TODOs in proofs and clean up RSA section
Diffstat (limited to 'taler-fc19/paper.tex')
-rw-r--r--taler-fc19/paper.tex30
1 files changed, 20 insertions, 10 deletions
diff --git a/taler-fc19/paper.tex b/taler-fc19/paper.tex
index 89684d6..f861259 100644
--- a/taler-fc19/paper.tex
+++ b/taler-fc19/paper.tex
@@ -1172,6 +1172,7 @@ with the generic instantiation.
\kappa, b)$ is at most $1/2 + \epsilon(\lambda)$, where $\epsilon$ is a
negligible function.
\end{proof}
+% RSA ratios vs CDH in BLS below
\subsection{Conservation}
@@ -1231,6 +1232,7 @@ with calls to the challenger's signing oracle in \ora{WithdrawPickup} and
unforgeability game would produce a blind signature forgery with probability $1/n$.
\end{proof}
+%TODO: RSA-KTI
\subsection{Income Transparency}
\begin{theorem}
@@ -1277,6 +1279,7 @@ Our instantiation satisfies {weak income transparency}.
The last case can be excluded, because it would violate the key exchange
completeness assumption.
+ % TODO: Wrong
We shall prove
\begin{equation}\label{eq:income-transparency-proof}
@@ -1286,6 +1289,7 @@ Our instantiation satisfies {weak income transparency}.
any probability space used by the adversary and challenger.
We shall optimiz our adversary in ways that maximize $p \over b + p$.
+ %TODO: Explain
As a reminder, if a refresh operation is initiated using a false commitment
that is detected by the exchange, then the new coin cannot be obtained, and
@@ -1396,20 +1400,26 @@ As for $F = \emptyset$, the return value of the game must be $0$, we conclude
We now give a concrete instantiation that is used in our implementation
for the schemes \textsc{BlindSign}, \textsc{CoinSignKx} and \textsc{Sign}.
-For \textsc{BlindSign}, we use RSA blind signatures~\cite{chaum1983blind}. From
-the information theoretically secure blinding, the computational blindness property
-follows directly. For the unforgeability property, we additionally rely on
-the RSA-KTI assumption as discussed in \cite{bellare2003onemore}. Note
-that since the blinding step in RSA blind signatures is non-interactive,
-storage and verification of the transcript is omitted in refresh and link.
+For \textsc{BlindSign}, we use RSA-FDH blind signatures~\cite{chaum1983blind}
+with blinding factors produced by FD-PRF constructed from a hash
+function with range the full RSA domain $[0,pq)$. An adversary who
+defeats the blindness property can recognise blinding factors,
+violating this PRF assumption. For the unforgeability property,
+we require the RSA-KTI assumption as discussed in \cite{bellare2003onemore}.
+%TODO: Jeff always cited multoiiple papers for RSA-KTI, but forgets why.
+As the blinding step in RSA blind signatures is non-interactive, storage
+and verification of the transcript is omitted in refresh and link.
+We envision BLS blind signatures working equally well.
We instantiate \textsc{CoinSignKx} with signatures and key exchange operations
on elliptic curves in Edwards form, where the same key is used for signatures
and the Diffie--Hellman key exchange operations. In practice, we use Ed25519
-\cite{bernstein2012high} / Curve25519 \cite{bernstein2006curve25519} for
-$\lambda=256$. We caution that some other elliptic curve key exchange
-implementation might not satisfy the completeness property that we require, due
-to the lack of complete addition laws.
+signatures \cite{bernstein2012high} and scalar multiplication for the Edwards
+curve, which gives $\lambda=128$. % Curve25519 \cite{bernstein2006curve25519}
+We caution that some other elliptic curve key exchange implementations might
+not satisfy the robustness property that we require, due to the lack of
+complete addition laws.
+% and that both robustness and honest key generation become tricky when ..
For \textsc{Sign}, we use elliptic-curve signatures, concretely Ed25519.