Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
B
belenios
Project overview
Project overview
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
belenios
belenios
Commits
af424a97
Commit
af424a97
authored
Dec 06, 2019
by
GAUDRY Pierrick
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Minor modifications in the specification document
parent
174acf27
Changes
2
Hide whitespace changes
Inline
Sidebyside
Showing
2 changed files
with
36 additions
and
27 deletions
+36
27
doc/references.bib
doc/references.bib
+10
7
doc/specification.tex
doc/specification.tex
+26
20
No files found.
doc/references.bib
View file @
af424a97
@In
book
{BeleniosMeadows2019,
@In
Proceedings
{BeleniosMeadows2019,
author="Cortier, V{\'e}ronique
and Gaudry, Pierrick
and Glondu, St{\'e}phane",
...
...
@@ 11,7 +11,8 @@ pages="214238",
@InProceedings{BeleniosEasycryptCSF18,
author = {V\'eronique Cortier and Constantin Catalin Dragan and PierreYves Strub and Francois Dupressoir and Bogdan Warinschi},
title = {Machinechecked proofs for electronic voting: privacy and verifiability for Belenios},
title = {Machinechecked proofs for electronic voting: privacy
and verifiability for {B}elenios},
booktitle = {{P}roceedings of the 31st {IEEE} {C}omputer {S}ecurity {F}oundations {S}ymposium ({CSF} 2018)},
year = {2018},
pages = {298312},
...
...
@@ 19,7 +20,8 @@ pages="214238",
@InProceedings{wpes2013,
author = {V\'eronique Cortier and David Galindo and St\'ephane Glondu and Malika Izabachene},
title = {Distributed ElGamal \`a la Pedersen  Application to Helios},
title = {Distributed {ElGamal} \`a la {P}edersen  {A}pplication
to {H}elios},
booktitle = {Workshop on Privacy in the Electronic Society (WPES 2013)},
OPTpages = {},
year = {2013},
...
...
@@ 29,7 +31,7 @@ pages="214238",
@InProceedings{CGGIesorics14,
author = {V\'eronique Cortier and David Galindo and St\'ephane Glondu and Malika Izabachene},
title = {Election Verifiability for
H
elios under Weaker Trust Assumptions},
title = {Election Verifiability for
{H}
elios under Weaker Trust Assumptions},
booktitle = {Proceedings of the 19th European Symposium on Research in Computer Security (ESORICS 2014)},
pages = {327344},
year = {2014},
...
...
@@ 43,7 +45,7 @@ pages="214238",
@misc{CHVote,
author = {Rolf Haenni and Reto E. Koenig and Philipp Locher and Eric Dubuis},
title = {
CHV
ote System Specification},
title = {
{CHV}
ote System Specification},
howpublished = {Cryptology ePrint Archive, Report 2017/325},
year = {2017},
note = {\url{https://eprint.iacr.org/2017/325}},
...
...
@@ 52,7 +54,8 @@ pages="214238",
@InProceedings{asiacrypt12,
author = {David Bernhard and Bogdan Warinschi and Olivier Pereira},
title = {How Not to Prove Yourself: Pitfalls of FiatShamir and Applications to Helios},
title = {How Not to Prove Yourself: {P}itfalls of
{F}iat{S}hamir and Applications to {H}elios},
booktitle = {Advances in Cryptology (AsiaCrypt 2012)},
year = {2012},
OPTeditor = {Springer Verlag},
...
...
@@ 80,7 +83,7 @@ pages="214238",
}
@unpublished{notePierrick,
TITLE = {
{Some ZK security proofs for Belenios}
},
TITLE = {
Some {ZK} security proofs for {B}elenios
},
AUTHOR = {Gaudry, Pierrick},
URL = {https://hal.inria.fr/hal01576379},
NOTE = {working paper or preprint},
...
...
doc/specification.tex
View file @
af424a97
...
...
@@ 9,6 +9,7 @@
\usepackage
{
framed
}
\usepackage
{
stmaryrd
}
\usepackage
{
xcolor
}
\usepackage
{
placeins
}
\newcommand
{
\version
}{
1.10
}
...
...
@@ 68,12 +69,12 @@ based on a ``folklore'' scheme:
Pedersen’s~
\cite
{
Pedersen
}
Distributed Key Generation (DKG) that has several variations.
The variant considered in Belenios is described in~
\cite
{
wpes2013
}
and
proved in~
\cite
{
wpes2013,asiacrypt12
}
.
\item
Ballots are
form
ed of an ElGamal encryption of the votes and a
\item
Ballots are
compos
ed of an ElGamal encryption of the votes and a
zeroknowledge proof of wellformedness, as for the Helios
protocol~
\cite
{
Helios
}
. Compared to Helios, we support blank votes,
which required to adapt the zeroknowledge proofs, as specified and
proved in~
\cite
{
notePierrick
}
. Addition
n
ally, ballots are signed to
avoid ballot stuffing, as introduced in~
\cite
{
CGGIesorics14
}
but
also
proved in~
\cite
{
notePierrick
}
. Additionally, ballots are signed to
avoid ballot stuffing, as introduced in~
\cite
{
CGGIesorics14
}
and
also
described in~
\cite
{
BeleniosMeadows2019
}
.
\item
During the tally phase, Belenios supports two modes. Ballots are either combined
homomorphically or shuffled and randomized, using mixnets. The
...
...
@@ 92,19 +93,19 @@ $k_2$ candidates out of $k$ candidates. This case is called
homomorphic because the result of the election for such questions is
the number of votes received for each candidate. No more information
is leaked.
In the
\emph
{
non
homomorphic case
}
, voters can give a number to each
In the
\emph
{
non

homomorphic case
}
, voters can give a number to each
candidate. This can be used to rank candidates or grade them. Then the
(raw) result of the election is simply the list of votes, as emitted
by the voters, in
a random order, to preserve privacy.
Any cou
ting method can be then
applied
Any cou
nting method can then be
applied
(e.g. Condorcet, STV, or majority judgement) although Belenios does
not offer support for this.
The non
homomorphic case therefore offers much more flexibility, at
The non

homomorphic case therefore offers much more flexibility, at
the cost of extra steps during the tally (in order to securely shuffle
the ballots).
Belenios supports both types of questions and an election can even
mix homomorphic and non
homomorphic questions.
mix homomorphic and non

homomorphic questions.
% and slightly less privacy
\medskip
...
...
@@ 165,7 +166,7 @@ consists of:
$
c
_
1
,
\dots
,c
_
n
$
and computes
$
L
=
\shuffle
(
\public
(
c
_
1
)
,
\dots
,
\public
(
c
_
n
))
$
\item
for
$
j
\in
[
1
\dots
n
]
$
,
$
\mathcal
{
C
}$
sends
$
c
_
j
$
to
$
\mathcal
{
V
}_
j
$
\item
\label
{
itemforget
}
(option
n
al)
$
\mathcal
{
C
}$
forgets
$
c
_
1
,
\dots
,c
_
n
$
\item
\label
{
itemforget
}
(optional)
$
\mathcal
{
C
}$
forgets
$
c
_
1
,
\dots
,c
_
n
$
\item
$
\mathcal
{
C
}$
sends
$
L
$
to
$
\mathcal
{
A
}$
\item
$
\mathcal
{
A
}$
and
$
\mathcal
{
T
}_
1
,
\dotsc
,
\mathcal
{
T
}_
m
$
run a key establishment protocol
(either
\ref
{
nothreshold
}
or
\ref
{
threshold
}
)
...
...
@@ 176,7 +177,7 @@ consists of:
{$
\uuid
$}
$
u
$
.
\end{enumerate}
Step~
\ref
{
itemforget
}
is optional. It offers a better protection
against ballot stuffng in case
$
\mathcal
{
C
}$
unintentionally leaks
against ballot stuff
i
ng in case
$
\mathcal
{
C
}$
unintentionally leaks
private credentials.
\subsubsection
{
Basic decryption support
}
...
...
@@ 203,7 +204,7 @@ all need to contribute to the tally.
\subsubsection
{
Threshold decryption support
}
\label
{
threshold
}
The trustees jointly compute the public election key such that
only a sub
group
of
$
t
+
1
$
of them will be needed to compute the tally.
only a sub
set
of
$
t
+
1
$
of them will be needed to compute the tally.
\begin{enumerate}
\item
for
$
z
\in
[
1
\dots
m
]
$
,
...
...
@@ 273,7 +274,7 @@ voters), credentials can be recovered:
encrypted tally (see
section~
\ref
{
shuffles
}
):
\[
\tilde\Pi
_
0
=
\textsf
{
nh
\_
ciphertexts
}
(
\Pi
_
0
)
\]
\item
if the election contains a non
homomorphic part, that is, if
\item
if the election contains a non

homomorphic part, that is, if
$
\tilde\Pi
_
0
\neq
[]
$
,
then for
$
z
\in
[
1
\dots
m
]
$
:
\begin{enumerate}
...
...
@@ 317,7 +318,7 @@ always record at least the last audited board. Then:
\begin{enumerate}
\item
she retrieves the election data
$
D
=
(
E,PK,L,B,r
)
$
where
$
B
$
is the list of ballots;
\begin{itemize}
\item
she records
$
B
$
;
\item
she records
$
D
$
;
\item
for
$
b
\in
B
$
, she checks that the proofs of
$
b
$
are valid and that
the signature of
$
b
$
is valid and corresponds to one of the keys in
$
L
$
;
...
...
@@ 343,15 +344,15 @@ There is no tool support on the web interface for these checks,
instead the command line tool
\texttt
{
verifydiff
}
can be used.
\subsubsection
{
After the tally
}
The auditor retrieve the election data
$
D
$
and in
The auditor retrieve
s
the election data
$
D
$
and in
particular the list
$
B
$
of ballots and the
\hyperref
[electionresult]
{
\result
}
$
r
$
. Then:
\begin{enumerate}
\item
she checks consistency of
$
B
$
, that is, perform all
\item
she checks consistency of
$
B
$
, that is, perform
s
all
the checks described at step 1 of section~
\ref
{
sec:auditvoting
}
;
\item
she checks that
$
B
$
corresponds to the board
monitored so far thus performs all
monitored so far
,
thus performs all
the checks described at step 2 of section~
\ref
{
sec:auditvoting
}
;
\item
she checks that the proofs of the result
$
r
$
are valid
w.r.t.
$
B
$
.
...
...
@@ 1023,6 +1024,9 @@ vector of integers will be encoded into a single ciphertext:
\[
\Hash
_{
\textsf
{
raweg
}}
(
S,y,
\alpha
,
\beta
,A
)=
\shatwo
(
\verb
=
raweg
=
S
\verb
=

=
y
\verb
=
,
=
\alpha\verb
=
,
=
\beta\verb
=

=
A
)
\mod
q
\]
where
\verb
=
raweg
=
, the vertical bars and the commas are verbatim and
numbers are written in base 10. The result is interpreted as a 256bit
bigendian number.
\end{itemize}
The proof is verified as follows:
\begin{enumerate}
...
...
@@ 1316,8 +1320,8 @@ question:
C
_{
i,k
}
=
\choices
(
\answers
(
B
_
k
)
_
i
)
\]
\end{itemize}
In the end,
the encrypted tally is isomorphic to an array of arrays of
ciphertexts:
In the end,
in both cases, the encrypted tally is isomorphic to an
array of arrays of
ciphertexts:
\[
\etally\approx\ciphertext
^
\ast
{}^
\ast
\]
...
...
@@ 1327,7 +1331,7 @@ ciphertexts:
If the election has nonhomomorphic questions, let us say
$
n
$
out of
$
m
$
(
$
1
\leq
n
\leq
m
$
), nonhomomorphic ciphertexts must be
shuffled. They are first extracted from the encrypted tally
$
a
$
: if
shuffled. They are first extracted from the encrypted tally
~
$
a
$
: if
$
i
_
1
,
\dots
,i
_
n
$
are the indices of the nonhomomorphic questions,
\[
b
=
\textsf
{
nh
\_
ciphertexts
}
(
a
)=[
a
_{
i
_
1
}
,
\dots
,a
_{
i
_
n
}
]
...
...
@@ 1341,8 +1345,8 @@ Shuffles are done in the same way as the CHVote system\footnote{See
version 1.3.2 of the CHVote System Specification at~
\cite
{
CHVote
}}
.
% \url{https://eprint.iacr.org/2017/325}}.
For each nonhomomorphic
question, its ciphertexts are reencrypted and
applied a random
permut
ation
, and a zeroknowledge proof of the permutation is
question, its ciphertexts are reencrypted and
randomly
permut
ed
, and a zeroknowledge proof of the permutation is
computed. All these shuffles are then assembled into a
$
\texttt
{
shuffle
}$
structure:
\begin{gather*}
...
...
@@ 1995,6 +1999,8 @@ algorithms, please refer to the CHVote System Specification.
\label
{
getnizkpchallenge
}
\end{table}
\FloatBarrier
\bibliographystyle
{
abbrv
}
\bibliography
{
references
}
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment