add facilities to build a subset of a roster containing the nodes that are part of a particular DAGA context.
given DAGA context, every participant, client or conodes MUST be able to obtain the serverIdentity of any DAGA server in the context (or everything needed to contact any other DAGA server in the context)

remove all the marshalling related things out of kyber
(and the scenario test)

current API is...bof..

to me they are only used to sign/verify + in the server non-interactive proof
(only one way)
and if an hash function is secure etc.. IMO we can replace bytes(data) by hash(data) where data are the various messages.

// FIXME blindly trust Leader that request is legitimate for us (part of a context we as node accept to handle ??)
// FIXME or have leader send original request with annouce for us to check here ! ?
// What can go wrong ? : maybe dishonest or buggy leader can forward request
// from expired context or context for which we are not authoritative BUT we are part of the servers of context (if we are not part of original context then client cannot verify our signature => abort ok)
// (it means that the signatures will be correct)
// then what ? mhh maybe not an issue leader and client still obtained a perfectly valid honest random challenge...
// and when client proceeds to send its meesage with proof to some server either server accept context and can verify proof or server doesnt accept context and cannot verify proof
// => seems this is not an issue finally, but maybe keep in mind
// I fear they may be issues if context change during auth request lifetime

ok I won't lose more time doing this now,
but still this is the only real and good choice to make I would say,
I would feel a lot more safer to use it instead of bloating the DAGA code and tests (as it is the case now) with all the obscure server proof related code.

less code => less hidden bugs,
better readability using higher level vocabulary (prove verify etc..)
+
kyber.proof is listed as one of the main features of kyber on godoc, I feel like it is absurd to not use it in DEDIS projects.

protocols need to have access to at least the Authentication contexts accepted by the nodes + the daga Server struct

instead of the procedure -- described in DAGA paper or the one the previous student derived from it -- to generate the random challenge,

investigate the possibility to use randherd => means have the servers become a randherd+daga cothority

and / while doing that, sketch a first view of the architecture of the new DAGA service,
the protagonists, the protocols, the service and its exposed API

• first step adapt previous code that used ECDSA/schnorr to use EdDSA
• then maybe much later don't know.. when writing server and server protocol see if makes sense to use something like CoSi ?!

cb5b869

Implement something in a similar way as https://github.com/dedis/kyber/blob/master/share/dkg/rabin/dkg.go
into the student_18_daga/sign/daga directory.
Only main structures - no networking / json methods
port it to dedis/kyber#master: https://github.com/dedis/kyber/wiki/Migration-from-gopkg.in-dedis-crypto.v0
Define methods on these structure
Write (or copy) the corresponding tests

add facilities to build subset of full roster that contains all nodes that are part (are servers) of a particular DAGA auth. context.
Given DAGA context, every participant, client or conodes/DAGA servers MUST be able to obtain the serverIdentity of every other DAGA server in auth. context. (or whatever needed to contact every other server.)

with for now 3 main sections:

1. overall goals and motivations, convince etc..

2. eventual DAGA improvements and ideas etc

3. larger architecture
   i) DAGA protocol
   ii) login service

   • how to generate contexts etc.. (pop-party transcript ? our own procedure using public ledger ? etc..)
   • how to actually log etc..

design issue, if we follow the paper to the letter, it induce some practical issues, need to manage state on the servers to verify auth. message because we cannot blindly trust the proof transcript that is sent with auth. message, need to verify that proof commitments and challenge are same as the one that were sent during PKClient sigma protocol run....
(... and this can not be avoided I'd say because we have multiple servers and if we move the proof verification to be live/direct then the next server cannot trust it, we just moved the problem..)

Alternative solutions (vs keeping and managing state in a sound way, bad and difficult and bug prone IMO)

• maybe that would be a perfect use case for a blockchain !! ? have the proof be conducted/transcripted in a public ledger

• OR maybe simpler ! we can have the servers collectively sign the commitments they received during challenge generations protocol, and then send them back to client with master challenge => then the client would need to include those signed commitments in its proof transcript => servers can now verify they have not been altered (correct signature)
  AKA store state in clients in RESTFull terminology

these considerations (check commitments and challenge at verification time) are not addressed in the paper (have I missed something ?)
TODO write those in the draft for Ewa Syta

and instead define functions Hash1() and Hash2() that should behave like RO's and returns Scalar of the groupS.

because this is what we want, we don't need a Hash.hash, and by doing so we can fulfill more easily the stated goal of the suite which is to easily switch implementations.

currently there is hash related code all over the place that do things that work only with SuiteEC or that is "over-complex"

currently we assume that clients and servers are provided everything they need to work with DAGA.
they all have access to a well formed daga context.

real life, need ways to

1. build such auth context
2. make the context evolve (add members, etc..)
3. transmit/publish the context to participants
4. for servers, ways to manage maybe more than one context at a time (and more than one daga server identity)
5. manage expiry of contexts
   (servers can decide to stop accepting requests part of a auth context/round)
   => fine but not very polite for the others..

etc. etc.

• need to address all of these practical considerations in a way that doesn't destroy DAGA purposes