FW: Zero-Knowledge proofs for valid decryption !!

2001-07-09 Thread Andy Neff


The problem posed is actually a special case of the problem solved
in a paper that was recently accepted at ACM-CCS (Philadelphia, 
November 2001.)

C. Andrew Neff.  Verifiable, Secret Shuffles of ElGamal Encrypted 
Data for Secure Multi-Authority Elections

(For various reasons, the title uses the terms "ElGamal" and
"Secure Multi-Authority Elections", but the real content of the paper
is a solution to a "shuffle problem" which has broader context.)

I believe the Dodis, Halevi, Rabin paper mainly cites the work of
Abe (M. Abe.  Universally Verifiable Mix-net with Verification Work
Independent on the number of Mix-centers.  EUROCRYPT 98, pp. 437-447,
1998).  (Someone please correct me if I am wrong about this.)
Another very elegant paper which can provide a solution is
 
   R. Cramer, I. Damgaard, and B. Schoenmakers.  Profs of partial knowledge
   and simplified design of witness hiding protocols.  Crypto 94, volume
839,
   Springer-Verlag LNCS, pages 174-187.

which tackles a far more general problem -- Boolean combinations of ZK
proofs.
Both of these results are very important, but from a practical perspective,
they have limited use.  The main problem is with the overall "proof 
complexity" -- the data size of the proof, as well as the number
of computations required both to construct it and then verify it as
a function of the number of elements to be permuted.  Secondarily, these 
are somewhat complicated protocols to implement, and they are at least 
tricky, if not difficult, to make non-interactive.  (The same can be
said for other approaches I know based on cut-and-choose.)

The technique in the ACM-CCS paper (above) is a surprisingly simple 
extension of the well known Chaum-Pederson proof of knowledge for
the relation $log_g X = log_h Y$.  The extension follows fairly 
easily from the fact that two monic polynomials of degree $k$ over a
field $F$ that agree on $k$ points must be identical.  We have
implemented code in Crypto++ to generate the proof and do the verification.

The ACM-CCS paper does not have detailed complexity analysis (that is,
$O(n)$ notation is used without explicit calculation of the constant
factor), however, this analysis is fairly easy to add.  Moreover, emphasis
is placed on presentation rather than optimization -- an optimized version
can do the proof/verification with a bit more than 1/3 the exponentiations.
(The total computation can then be reduced even more by using good crypto 
numerical techniques.)

Further, a paper to appear in Crypto 2001 by Furukawa and Sako will also
address
this problem.  (I know this since they asked permission to cite my
work.)  They too were motivated to reduce the complexity of the 
basic mix problem to practical sizes.  It is a bit early to do any
careful comparisons of the performance of the two approaches since,
in any case, the over all difference in performance seems to be small.  

I am happy to try to answer more detailed questions about the problem
and/or the relevant complexity measures.


C. Andrew Neff
VoteHere, Inc.
[EMAIL PROTECTED]




-Original Message-
From: Helger Lipmaa [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 6:50 AM
To: Emmanouil Magkos
Cc: [EMAIL PROTECTED]
Subject: Re: Zero-Knowledge proofs for valid decryption !!


One reference out of my mind is:

*  Yevgeniy Dodis, Shaih Halevi and Tal Rabin,  "A Cryptographic Solution
   to a Game Theoretic Problem" , CRYPTO 2000.
   http://www.toc.lcs.mit.edu/~yevgen/ps/game-abs.html
   (See Appendix A, esp A.1, and references therein)

Helger Lipmaa
http://www.tcs.hut.fi/~helger/

On Mon, 9 Jul 2001, Emmanouil Magkos wrote:

> There is a list of encrypted messages, published on a bulletin board.
Rackel
> and only Rackel can decrypt this messages. Encryption is probabilistic,
for
> instance ElGamal: E(m)=(g^r, h^r  m), where h=g^s with {s} be the private
> key of Racel and {r} be a randomness chosen by the sender.
>
> Rackel decrypts E(m_1), E(m_2), E(m_3), and publish the decrypted results
in
> random order, say (m_2, m_1, m_3). Is there a way for Rackel to prove that
> the list of m_i contains only correct open values of the list of E(m_i),
> without revealing:
>
> 1) the linkage between [E(m_i), m_i]
> 2) the private decryption key s
>
> (note that she doesn't know the randomness {r})
>
> Does anybody know whether there exists such solution ??.






-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]



Re: FW: Zero-Knowledge proofs for valid decryption !!

2001-07-10 Thread lcs Mixmaster Remailer

Andy Neff writes:

> The problem posed is actually a special case of the problem solved
> in a paper that was recently accepted at ACM-CCS (Philadelphia, 
> November 2001.)
>
> C. Andrew Neff.  Verifiable, Secret Shuffles of ElGamal Encrypted 
> Data for Secure Multi-Authority Elections

Do you use cut and choose with an intermediate permutation, showing
that it either maps to the one or to the other?

Cut and choose in this way goes back to the very earliest work on ZK
proofs; it is the classic way to show in ZK that two graphs are identical.

> I believe the Dodis, Halevi, Rabin paper mainly cites the work of
> Abe (M. Abe.  Universally Verifiable Mix-net with Verification Work
> Independent on the number of Mix-centers.  EUROCRYPT 98, pp. 437-447,
> 1998).  (Someone please correct me if I am wrong about this.)

Interesting point, that this problem arises very naturally in the case
of mix-nets.  They want to prove that they are operating correctly so
want to show that their outputs are the decryptions of their inputs
without revealing the correspondence.  Probably that's what motivated
the problem from the questioner?  Note to people asking questions,
as payment for the hard work of your responders you should give some
background about why your question is interesting.

> Another very elegant paper which can provide a solution is
>  
>R. Cramer, I. Damgaard, and B. Schoenmakers.  Profs of partial knowledge
>and simplified design of witness hiding protocols.  Crypto 94, volume
> 839,
>Springer-Verlag LNCS, pages 174-187.
>
> which tackles a far more general problem -- Boolean combinations of ZK
> proofs.

I guess in this case, you'd have say (A, B, C) mapping to (1, 2, 3) and
you'd prove something like:

(A->1  OR  A->2  OR  A->3)
AND (B->1  OR  B->2  OR  B->3)
AND (C->1  OR  C->2  OR  C->3)

This could be faster than cut and choose for small permutations, depending
on the security factor.  Unlike cut and choose the size of the proof does
not depend on the security parameter.

> Both of these results are very important, but from a practical perspective,
> they have limited use.  The main problem is with the overall "proof 
> complexity" -- the data size of the proof, as well as the number
> of computations required both to construct it and then verify it as
> a function of the number of elements to be permuted.  Secondarily, these 
> are somewhat complicated protocols to implement, and they are at least 
> tricky, if not difficult, to make non-interactive.  (The same can be
> said for other approaches I know based on cut-and-choose.)

It seems that with cut and choose, the size of the proof is linear in the
number of texts being permuted, and linear in the security factor.  So that
does not sound too bad, although of course if you have thousands of texts
then it could get out of hand.

An interesting point with regard to the security parameter when dealing
with the Schnorr heuristic to make them non-interactive:  Often the
security parameter can be much lower in an interactive proof than in
the non-interactive form.

In an interactive proof you will probably be happy with a security
parameter of 20 bits, corresponding to 1 chance in a million of successful
cheating by the prover.  Or even 10 bits for 1 chance in a thousand may
be acceptable if the punishment for cheating is significant.  Few cheaters
would try it if they have a .999 chance of being caught and punished.

However when we turn these into non-interactive proofs using the Schnorr
heuristic (pre-commit to all values, hash them and use that to produce the
challenge bits), the equation changes.  Instead of probability of being
caught, the security parameter now represents the work necessary to find
a hash value that lets you cheat.  A security parameter of 10 means the
server needs to try 1024 times on the average to find a set of values that
satisfy the proof even though he is cheating.  A parameter of 20 means
that the server needs to try a million values to find some that work.

If the protocol is acceptably efficient in one iteration, iterating
it a thousand or even a million times may well be an acceptable cost
for a server if that allows it to cheat undetectably.  So when using
non-interactive proofs, verifiers probably will demand security parameters
of at least 40, 60 or even 80 bits.  This makes the proofs correspondingly
more expensive.



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]



Re: FW: Zero-Knowledge proofs for valid decryption !!

2001-07-12 Thread Emmanouil Magkos

The background of my question was an auction application where encrypted
bids are published on a bulletin board. All bids are authenticated, i.e.
signed by the bidders. Since there is no anonymity, (there are reasons for
this), the link between the encrypted bids and the decrypted results, which
will be published for verifiability, must be hidden. Note that in electronic
voting, which is a similar application to auctions, the homorphism of the
encryption scheme may allow an observer to "gather" the encrypted results,
and then only verify the "sum" of encrypted votes. However, in an auction
application, this is not the case. So there is a need for the Auctioneers
(they are distributed, for bid-secrecy) to publish a shuffle of the
decrypted bids, and then prove correctness of the decryption in
zero-knowledge.

Although I have read a few papers about mix-nets (in the e-voting context),
I had not realized that the mix idea answered my question (although I should
have :). Thanx for all folks who answered my question !!


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]