Making Code Voting Secure against Insider Threats using Unconditionally Secure MIX Schemes and Human PSMT Protocols

Code voting was introduced by Chaum as a solution for using a possibly infected-by-malware device to cast a vote in an electronic voting application. Chaum's work on code voting assumed voting codes are physically delivered to voters using the mail system, implicitly requiring to trust the mail system. This is not necessarily a valid assumption to make - especially if the mail system cannot be trusted. When conspiring with the recipient of the cast ballots, privacy is broken. It is clear to the public that when it comes to privacy, computers and "secure" communication over the Internet cannot fully be trusted. This emphasizes the importance of using: (1) Unconditional security for secure network communication. (2) Reduce reliance on untrusted computers. In this paper we explore how to remove the mail system trust assumption in code voting. We use PSMT protocols (SCN 2012) where with the help of visual aids, humans can carry out $\mod 10$ addition correctly with a 99\% degree of accuracy. We introduce an unconditionally secure MIX based on the combinatorics of set systems. Given that end users of our proposed voting scheme construction are humans we \emph{cannot use} classical Secure Multi Party Computation protocols. Our solutions are for both single and multi-seat elections achieving: \begin{enumerate}[i)] \item An anonymous and perfectly secure communication network secure against a $t$-bounded passive adversary used to deliver voting, \item The end step of the protocol can be handled by a human to evade the threat of malware. \end{enumerate} We do not focus on active adversaries

A Verifiable Secret Shuffle of Homomorphic Encryptions

We suggest an honest verifier zero-knowledge argument for the correctness of a shuffle of homomorphic encryptions. A shuffle consists of a rearrangement of the input ciphertexts and a re-encryption of them. One application of shuffles is to build mix-nets. Our scheme is more efficient than previous schemes in terms of both communication and computational complexity. Indeed, the HVZK argument has a size that is independent of the actual cryptosystem being used and will typically be smaller than the size of the shuffle itself. Moreover, our scheme is well suited for the use of multi-exponentiation techniques and batch-verification. Additionally, we suggest a more efficient honest verifier zero-knowledge argument for a commitment containing a permutation of a set of publicly known messages. We also suggest an honest verifier zero-knowledge argument for the correctness of a combined shuffle-and-decrypt operation that can be used in connection with decrypting mix-nets based on ElGamal encryption. All our honest verifier zero-knowledge arguments can be turned into honest verifier zero-knowledge proofs. We use homomorphic commitments as an essential part of our schemes. When the commitment scheme is statistically hiding we obtain statistical honest verifier zero-knowledge arguments, when the commitment scheme is statistically binding we obtain computational honest verifier zero-knowledge proofs

Cryptographic Shuffles and Their Applications

학위논문 (박사)-- 서울대학교 대학원 : 수리과학부, 2012. 8. 천정희.For anonymization purposes, one can use a mix-net. A mix-net is a multi-party protocol to shuffle elements so that neither of the parties knows the permutation linking the input and output. One way to construct a mix-net is to let a set of mixers, so called mix-servers, take turns in permuting and re-encrypting or decrypting the inputs. If at least one of the mixers is honest, the input data and the output data can no longer be linked. In this role, shuffling constitutes an important building block in anonymization protocols and voting schemes. The problem is that the standard shuffle requires anyone who shuffles the input messages to keep his random permutation and randomizers secret. The assumption of a party keeping the secret information may be in some ways quite strong. Secondly, for this anonymization guarantee to hold we do need to ensure that all mixers act according to the protocol. In general, zero-knowledge proofs (ZKPs) are used for this purpose. However, ZKPs requires the expensive cost in the light of computation and communication. In TCC 2007, Adida and Wikstr\"{o}m proposed a novel approach to shuffle, called a public shuffle, in which a shuffler can perform shuffle publicly without needing information kept secret. Their scheme uses an encrypted permutation matrix to shuffle ciphertexts publicly. This approach significantly reduces the cost of constructing a mix-net to verifiable joint decryption. Though their method is successful in making shuffle to be a public operation, their scheme still requires that some trusted parties should choose a permutation to be encrypted and construct zero-knowledge proofs on the well-formedness of this permutation. In this dissertation, we study a method to construct a public shuffle without relying on permutations generated privately: Given an $n$-tuple of ciphertext $(c_1,\dots,c_n)$, our shuffle algorithm computes $f_i(c_1,\dots,c_n)$ for $i=1,\dots,\ell$ where each $f_i(x_1,\dots,x_n)$ is a symmetric polynomial in $x_1,\dots,x_n$. Depending on the symmetric polynomials we use, we propose two concrete constructions. One is to use ring homomorphic encryption with a constant ciphertext complexity and the other is to use simple ElGamal encryption with a linear ciphertext complexity in the number of users. Both constructions are free of zero-knowledge proofs and publicly verifiable.Abstract i 1 Introduction 1 1.1 ABriefHistoryofShuffles .................... 1 1.2 WhyShufflinginPublicHard?.................. 2 1.3 CryptographicShuffleSchemes.................. 4 1.4 ContributionsofThisWork ................... 6 1.4.1 OurDefinitionalApproach................ 6 1.4.2 OurConstructions .................... 6 1.5 Organization ........................... 8 2 Preliminaries 9 2.1 Basics ............................... 9 2.2 PublicKeyEncryption...................... 10 2.2.1 IND-CPASecurity .................... 11 2.2.2 IND-CCASecurity .................... 14 2.3 HomomorphicPublic-keyEncryption . . . . . . . . . . . . . . 15 2.4 Zero-KnowledgeProofs...................... 18 2.4.1 Zero-KnowledgeVariants................. 19 2.4.2 ProofofKnowledge.................... 20 2.5 Public-KeyObfuscation ..................... 21 3 Verifiable Secret Shuffles: A Review 24 3.1 Introduction............................ 24 3.2 NotationandDefinitions..................... 25 3.3 Security .............................. 27 3.3.1 VerifiabilityforSecretShuffles.............. 27 3.3.2 UnlinkabilityExperiments ................ 28 3.4 SelectedPriorWork ....................... 29 3.4.1 Furukawa-SakoProtocol ................. 30 3.4.2 GrothProtocol ...................... 31 3.5 PublicShuffleswithPrivatePermutation . . . . . . . . . . . . 33 3.5.1 Introduction........................ 33 3.5.2 AdidaandWikstro ̈mProtocol.............. 33 4 Verifiable Public Shuffles 36 4.1 Introduction............................ 36 4.2 GeneralizedShuffle ........................ 38 4.2.1 SyntaxofGeneralizedShuffle .............. 38 4.2.2 SecurityModel ...................... 39 4.2.3 CryptographicAssumption................ 43 4.3 Constructions from Ring Homomorphic Encryption . . . . . . 44 4.3.1 Construction from (n,n−1)-E . . . . . . . . . . 44 4.3.2 Construction from (1,n)-E ................ 45 4.4 Constructions from Group Homomorphic Encryption . . . . . 47 4.4.1 BuildingBlocks...................... 47 4.4.2 A Generalized Public Shuffle Scheme Based on Poly- nomialFactorization ................... 50 4.4.3 A Generalized Public Shuffle Scheme Based on Integer Factorization ....................... 58 5 Conclusion and Further Work 63 Abstract (in Korean) 72 Acknowledgement (in Korean) 74Docto

Verifiable Elections That Scale for Free

In order to guarantee a fair and transparent voting process, electronic voting schemes must be verifiable. Most of the time, however, it is important that elections also be anonymous. The notion of a verifiable shuffle describes how to satisfy both properties at the same time: ballots are submitted to a public bulletin board in encrypted form, verifiably shuffled by several mix servers (thus guaranteeing anonymity), and then verifiably decrypted by an appropriate threshold decryption mechanism. To guarantee transparency, the intermediate shuffles and decryption results, together with proofs of their correctness, are posted on the bulletin board throughout this process. In this paper, we present a verifiable shuffle and threshold decryption scheme in which, for security parameter k, L voters, M mix servers, and N decryption servers, the proof that the end tally corresponds to the original encrypted ballots is only O(k(L + M + N)) bits long. Previous verifiable shuffle constructions had proofs of size O(kLM + kLN), which, for elections with thousands of voters, mix servers, and decryption servers, meant that verifying an election on an ordinary computer in a reasonable amount of time was out of the question. The linchpin of each construction is a controlled-malleable proof (cm-NIZK), which allows each server, in turn, to take a current set of ciphertexts and a proof that the computation done by other servers has proceeded correctly so far. After shuffling or partially decrypting these ciphertexts, the server can also update the proof of correctness, obtaining as a result a cumulative proof that the computation is correct so far. In order to verify the end result, it is therefore sufficient to verify just the proof produced by the last server

Malleable Proof Systems and Applications

Malleability for cryptography is not necessarily an opportunity for attack, but in many cases a potentially useful feature that can be exploited. In this work, we examine notions of malleability for non-interactive zero-knowledge (NIZK) proofs. We start by defining a malleable proof system, and then consider ways to meaningfully control the malleability of the proof system, as in many settings we would like to guarantee that only certain types of transformations can be performed. We also define notions for the cases in which we do not necessarily want a user to know that a proof has been obtained by applying a particular transformation; these are analogous to function/circuit privacy for encryption. As our motivating application, we consider a shorter proof for verifiable shuffles. Our controlled-malleable proofs allow us for the first time to use one compact proof to prove the correctness of an entire multi-step shuffle. Each authority takes as input a set of encrypted votes and a controlled-malleable NIZK proof that these are a shuffle of the original encrypted votes submitted by the voters; it then permutes and re-randomizes these votes and updates the proof by exploiting its controlled malleability. As another application, we generically use controlled-malleable proofs to realize a strong notion of encryption security. Finally, we examine malleability in existing proof systems and observe that Groth-Sahai proofs are malleable. We then go beyond this observation by characterizing all the ways in which they are malleable, and use them to efficiently instantiate our generic constructions from above; this means we can instantiate our proofs and all their applications using only the Decision Linear (DLIN) assumption. Work done as an intern at Microsoft Research Redmon

Dudle: Mehrseitig sichere Web 2.0-Terminabstimmung

Es existiert eine Vielzahl an Web 2.0-Applikationen, welche es einer Gruppe von Personen ermöglichen, einen gemeinsamen Termin zu finden (z. B. doodle.com, moreganize.ch, whenisgood.net, agreeadate.com, meetomatic.com, etc.) Der Ablauf ist simpel: Ein Initiator legt eine Terminumfrage an und schickt den Link zu der Umfrage zu den potentiellen Teilnehmern. Nachdem jeder Teilnehmer der Anwendung seine Verfügbarkeiten mitgeteilt hat, kann anhand dieser Informationen ein Termin gefunden werden, der am besten passt. Maßnahmen um die Vertraulichkeit und Integrität der Daten zu schützen finden in allen bestehenden Applikationen zu wenig Beachtung. In dieser Dissertation wurde eine Web 2.0-Applikation entwickelt, welche es zulässt Terminabstimmungen zwischen mehreren Teilnehmern durchzuführen und dabei möglichst wenige Vertrauensannahmen über alle Beteiligten zu treffen.:1. Einleitung 1 2. Anforderungsanalyse 3 2.1. Begriffsdefinitionen/Primärfunktionalität . . . . . . . . . . . . . . . . . . . 3 2.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Mehrseitige Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3. Beziehungen der Anforderungen . . . . . . . . . . . . . . . . . . . . 13 3. Abstimmungsverfahren mit mindestens einer vertrauenswürdigen Entität 15 3.1. Existierende Verfahren mit vertrauenswürdigem Serveradministrator . . . 15 3.1.1. Ohne Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.2. Schutz gegen außenstehende Angreifer . . . . . . . . . . . . . . . . 16 3.1.3. Schutz gegen angreifende Teilnehmer . . . . . . . . . . . . . . . . . 18 3.1.4. Schutz gegen den Netzwerkbetreiber . . . . . . . . . . . . . . . . . 20 3.1.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Neue Verfahren mit vertrauenswürdigen Teilnehmern . . . . . . . . . . . . 20 3.2.1. Allen Teilnehmern vertrauen . . . . . . . . . . . . . . . . . . . . . 22 3.2.2. Nur dem Umfrageinitiator vertrauen . . . . . . . . . . . . . . . . . 23 3.2.3. Ausblick auf Schemata ohne vertrauenswürdige Entitäten . . . . . 25 3.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4. Abstimmungsverfahren ohne vertrauenswürdige Entitäten 29 4.1. Existierende Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.1. E-Voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.2. Verteilte Constraint-Optimierung . . . . . . . . . . . . . . . . . . . 33 4.1.3. Spezifische Terminplanungsprotokolle . . . . . . . . . . . . . . . . . 34 4.2. Einfaches Schema für protokolltreue Teilnehmer . . . . . . . . . . . . . . . 34 4.2.1. Umfrageerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.2. Stimmenabgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2.3. Ergebnisveröffentlichung . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. Erweiterung des Schemas auf protokollverletzende Angreifer innerhalb der Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.1. Angriffe erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.2. Angreifer identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.1. Integrität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.2. Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.3. Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.4. Blockierende Protokollrunden . . . . . . . . . . . . . . . . . . . . . 57 4.4.5. Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4.6. Installationsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.4.7. Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.5. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.5.1. Teilnehmer dynamisch hinzufügen/entfernen . . . . . . . . . . . . . 64 4.5.2. Präferenzwahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.5.3. Stimmenupdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5. Implementierung 69 5.1. Verfahren mit vertrauenswürdigem Serveradministrator . . . . . . . . . . . 69 5.1.1. YATA – Yet Another Terminabstimmungsapplikation . . . . . . . . 69 5.1.2. Schutz gegenüber dem Netzwerkbetreiber . . . . . . . . . . . . . . 75 5.2. Verfahren ohne vertrauenswürdigem Serveradministrator . . . . . . . . . . 77 5.2.1. Symmetrische Verschlüsselung, symmetrische Authentifikation . . . 78 5.2.2. Symmetrische Verschlüsselung, digitale Signatur . . . . . . . . . . . 80 5.2.3. Asymmetrische Verschlüsselung an den Initiator . . . . . . . . . . . 81 5.2.4. Minimal benötigtes Vertrauen in alle Entitäten . . . . . . . . . . . 83 5.3. Kryptographie mit JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.1. Schlüsselspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.2. Blockieren der JavaScript-Berechnungen vermeiden . . . . . . . . . 94 5.3.3. Performanceverbesserung der JavaScript-Berechnungen . . . . . . . 96 5.3.4. JavaScript-Code vertrauen . . . . . . . . . . . . . . . . . . . . . . . 97 6. Zusammenfassung und Ausblick 99 Literatur xvii A. Entropie eines Verfügbarkeitsvektors xxv A.1. Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv A.2. Allgemeine Berechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv B. Stimmenabgabe (min. Vertrauen) xxvii C. Ergebnisveröffentlichung (min. Vertrauen) xxix D. Schlüsseltransportmechanismus 2 nach ISO/EIC 1170-3 xxxiApplications which help users to schedule events are becoming more and more important. A drawback of most existing applications is, that the preferences of all participants are revealed to the others. We propose a schemes, which are able to schedule events in a privacy-enhanced way. In addition, Dudle, a Web 2.0 application is presented which implements these schemes.:1. Einleitung 1 2. Anforderungsanalyse 3 2.1. Begriffsdefinitionen/Primärfunktionalität . . . . . . . . . . . . . . . . . . . 3 2.2. Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. Mehrseitige Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3. Beziehungen der Anforderungen . . . . . . . . . . . . . . . . . . . . 13 3. Abstimmungsverfahren mit mindestens einer vertrauenswürdigen Entität 15 3.1. Existierende Verfahren mit vertrauenswürdigem Serveradministrator . . . 15 3.1.1. Ohne Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.2. Schutz gegen außenstehende Angreifer . . . . . . . . . . . . . . . . 16 3.1.3. Schutz gegen angreifende Teilnehmer . . . . . . . . . . . . . . . . . 18 3.1.4. Schutz gegen den Netzwerkbetreiber . . . . . . . . . . . . . . . . . 20 3.1.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Neue Verfahren mit vertrauenswürdigen Teilnehmern . . . . . . . . . . . . 20 3.2.1. Allen Teilnehmern vertrauen . . . . . . . . . . . . . . . . . . . . . 22 3.2.2. Nur dem Umfrageinitiator vertrauen . . . . . . . . . . . . . . . . . 23 3.2.3. Ausblick auf Schemata ohne vertrauenswürdige Entitäten . . . . . 25 3.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4. Abstimmungsverfahren ohne vertrauenswürdige Entitäten 29 4.1. Existierende Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.1. E-Voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.2. Verteilte Constraint-Optimierung . . . . . . . . . . . . . . . . . . . 33 4.1.3. Spezifische Terminplanungsprotokolle . . . . . . . . . . . . . . . . . 34 4.2. Einfaches Schema für protokolltreue Teilnehmer . . . . . . . . . . . . . . . 34 4.2.1. Umfrageerstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.2. Stimmenabgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2.3. Ergebnisveröffentlichung . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. Erweiterung des Schemas auf protokollverletzende Angreifer innerhalb der Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.1. Angriffe erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.2. Angreifer identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.1. Integrität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.2. Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.3. Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.4.4. Blockierende Protokollrunden . . . . . . . . . . . . . . . . . . . . . 57 4.4.5. Reaktionszeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.4.6. Installationsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.4.7. Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.5. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.5.1. Teilnehmer dynamisch hinzufügen/entfernen . . . . . . . . . . . . . 64 4.5.2. Präferenzwahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.5.3. Stimmenupdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5. Implementierung 69 5.1. Verfahren mit vertrauenswürdigem Serveradministrator . . . . . . . . . . . 69 5.1.1. YATA – Yet Another Terminabstimmungsapplikation . . . . . . . . 69 5.1.2. Schutz gegenüber dem Netzwerkbetreiber . . . . . . . . . . . . . . 75 5.2. Verfahren ohne vertrauenswürdigem Serveradministrator . . . . . . . . . . 77 5.2.1. Symmetrische Verschlüsselung, symmetrische Authentifikation . . . 78 5.2.2. Symmetrische Verschlüsselung, digitale Signatur . . . . . . . . . . . 80 5.2.3. Asymmetrische Verschlüsselung an den Initiator . . . . . . . . . . . 81 5.2.4. Minimal benötigtes Vertrauen in alle Entitäten . . . . . . . . . . . 83 5.3. Kryptographie mit JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.1. Schlüsselspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.3.2. Blockieren der JavaScript-Berechnungen vermeiden . . . . . . . . . 94 5.3.3. Performanceverbesserung der JavaScript-Berechnungen . . . . . . . 96 5.3.4. JavaScript-Code vertrauen . . . . . . . . . . . . . . . . . . . . . . . 97 6. Zusammenfassung und Ausblick 99 Literatur xvii A. Entropie eines Verfügbarkeitsvektors xxv A.1. Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv A.2. Allgemeine Berechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv B. Stimmenabgabe (min. Vertrauen) xxvii C. Ergebnisveröffentlichung (min. Vertrauen) xxix D. Schlüsseltransportmechanismus 2 nach ISO/EIC 1170-3 xxx