dedis / cothority

Scalable collective authority
Other
425 stars 106 forks source link

How do I get user and sig arguments in evoting-admin commands? #1692

Closed omidraha closed 5 years ago

omidraha commented 5 years ago

Hi, There are -user and -sig arguments in this cmd of Readme file:

$ ./evoting-admin -admins 0,1,2,3,4,5,6 -pin bf6... -roster public.toml -key 0d75... -id 39df... -user 12345 -sig e16953...

But how can I find the values of them? or How to generate them?

I installed my own conodes, you can see configuration of them here.

The status app works well, you can see the output of them here.

The signing app works as well, and you can see output of signing here.

I also create a new master chain:

$ evoting-admin -roster roster.toml -pin f810aac19b690830d3e0c79a6c00a279 -admins 0,1,2,3

    I : (main.main:  83) - Auth-server private key: 4fba8025c5ba783fe30bdb2bab653307a1fa23e29f9f42fe9fbaca93dbf05d09
    I : (main.main: 114) - Auth-server public  key: 87e1df80e37bd624c3a0a5852f28cf97d0705017c5da0bb7b0a047137db5d6ed
    I : (main.main: 115) - Master ID: cf5f2f9bc05fc115e4d2ef869405a3e0841dff80bc8b36183f5f9d4142470b0c

The output of conode server is here.

But I don't know how to achieve and set user and sig arguments:

evoting-admin -roster roster.toml -pin f810aac19b690830d3e0c79a6c00a279 -admins 0,1,2,3 -key 87e1df80e37bd624c3a0a5852f28cf97d0705017c5da0bb7b0a047137db5d6ed -id cf5f2f9bc05fc115e4d2ef869405a3e0841dff80bc8b36183f5f9d4142470b0c    -user ???? -sig ?????
omidraha commented 5 years ago

Also some more question for next step, what is command for managing election such as create election, add questions and answers? And how users cast the votes? Which services needs to installed on conodes servers? Dose this docker file have them? Current available services on this docker file are:

Generic.Available_Services: Identity,PoPServer,Skipchain,Status,evoting,ftCoSiService

How about byzcoin? Do I need this for creating election?

jeffallen commented 5 years ago

(sorry I won't get to this until Thursday)

jeffallen commented 5 years ago

The system as currently written is completely dependent on the EPFL authentication system. Once the user's web browser is redirected through the authentication system, we find out their user ID (known as a SCIPER for historical reasons), which is a number in the range of 1 to 99999. These numbers are used all through the voting system, for example after the -admins argument, and in the ballots themselves. Due to the form of homomorphic encryption we use, the ballot is limited to 29 bytes. A ballot for SCIPERs 1 and 2 is encoded as 0x000001000002, thus each SCIPER on the ballot is encoded into 3 bytes, and they are appended. The maximum number of SCIPERs on a ballot is 9 (2 * 9 = 27 < 29).

The -user and -sig arguments are used when attempting to update the configuration for the master skipchain. This feature was not used in the production voting app, and is probably buggy. You should create a new master chain if you need to change the roster or the admin list.

Elections are edited using the web user interface (https://github.com/dedis/epfl-evoting/tree/master/evoting/frontend) or via the APIs in cothority/evoting/api.go. One thing we've wanted to do in the past was define a textfile version of the election, and then add a new command to the evoting-admin CLI tool that takes the textfile as input, and calls the API to create the election. Then the editing of the election could be done in an offline way, and the "source code" for the election could be checked into git.

Until you replace the authentication system with something that works for you, you will not be able to use the web frontend. As a first step, while you are exploring what's possible, you might be able to run the auth server in test mode (see https://github.com/dedis/epfl-evoting/blob/master/evoting/server/index.js#L121) and then you can specify which SCIPER you want to be logged in as on the URL passed to the auth server. (I don't recall where that gets set, you'll have to dig around for it.)

As you can see, this system was not designed to be flexible and usable outside of EPFL. It was more of a progression of student project -> prototype -> production (but only for EPFL). You are now considering the next evolution, which would be how to adapt it to general purpose use. We will also be working on it during this spring to make sure we can run an election in June. We have not yet planned what to do, but the likeliest scenario is that we do the minimum to use it exactly as is.