Main class: threshold.parties.brokers.ThresholdCryptographyEngine
Source code origin: https://github.com/CRISES-URV/eVerification-2/source/thresholdLib
Original author: CRISES group
Disclaimer: some functionalities are also based on the code of the cryptographic 
  library BouncyCastle

This project enables the centralized communication of entities known as Brokers with
the purpose of testing threshold cryptography approaches. Currently, there are three
kinds of brokers supporting two different protocols. Different brokers implementing 
the same protocol are exchangeable.

Protocol: standard ElGamal
Broker classes: threshold.parties.brokers.BasicElGamalJavaBroker
Threshold: NO
Description: this broker depicts the behavior of broker-oriented implementation
  by implementing basic integer-group ElGamal.

Protocol: Threshold ElGamal with DKG without trusted dealer (see thesis document)
Broker classes: threshold.parties.brokers.ThresholdElGamalJavaBroker, 
  threshold.parties.brokers.ThresholdElGamalJavaCardBroker
Threshold: Yes. Requires t out of n shares. The decryption CALCULATES the secret.
Description: the protocol is implemented to support both Java Card and pure Java
  implementations. Each of the [n] parties generates a part of the secret. The 
  public key is calculated as a mixture of the shares produced by all the parties.
  
************************************************************
EXECUTION
************************************************************

The current implementation of the main class executes the second protocol. If there 
  are [n'] <= [n] cards connected, it creates [n'] ThresholdElGamalJavaCardBroker. The
  remaining [n-n'] brokers are instances of ThresholdElGamalJavaBroker.
  
The execution is non interactive and the parameters are embedded in the code. All the
  parametrization occurs in the main class.
  
The current parameters are:
  t,n = 3, 5
  p,q,g = Parameters for 2048-bit ElGamal
  
************************************************************
COMMUNICATION (communication.bulletinboard)
************************************************************

The only communication channel between the brokers is the BulletinBoard singleton
 instance. This is an append-only container of BulletinSubject objects. A 
 BulletinSubject contains a tag of type BBT and a list of messages. New protocols or
 variants might require the creation of new BBT elements. The message structure
 is defined to support one instance of a protocol running at a given moment.
 
The synchronization is supported by a different structure, the FlagTupleSpace. On it,
  a broker can post a request for a flag and blocks until another broker posts it.
  The use of the tuple space must be careful, as deadlocks are possible. Currently, the 
  only threaded part of the system is the interactive key generation.

************************************************************
SUGGESTED FEATURES
************************************************************

These section covers different suggestions for future work over this set of projects,
  including both new feature suggestions and improvements upon the existing model.
  
  - To move more of the security critical responsibilities into the card.
  
  - Enable commitment generation and verification (for both ThresholdElGamal brokers).
    The original smart card implementation already included some commitment support.
    
  - Introduce a control interface. Enable to encrypt and add arbitrary messages, and 
    define in running time the values of T and N, as well as the specific brokers 
    performing the decryption.
  
  - Introduce exception management.
  
  - Implement a truly SecretMessage approach (i.e. using encrypted and signed
    messages). For the Java Card approach, the decryption of messages MUST happen
    inside the card. The implementation of the corresponding ShareholderInfo is 
    necessary. The implementation can be specific (e.g. RSAShareholderInfo, 
    RSAEncryptedMessage) or generic (StrongShareholderInfo, EncryptedMessage, 
    SignedMessage).
    
  - Support more flexibly different key sizes. The CRISES project had constants defined 
    for different common key sizes.

  - The current scheme has the Engine creating the Broker instances. The Engine is 
    protocol agnostic, while the broker represents just one participant in the
    protocol. An intermediate class should be created to support the role of the
    trusted centralized tool in the protocol. In particular, for the threshold protocol,
    PublicKey merge should not done by a specific broker, but is not general enough to
    be performed by the Engine.
    
  - Support decryption without reconstructing the secret key.

  - The brokers can be parallelized (given the correct syncronization e.g. for opening 
    the commitments).

  - For the Java Card broker, avoid any posibility of having the private key outside
    the card.
  
  - Fix the behavior of FlagTupleSpace. It should only enable the increase/decrease
    of flag values, instead of adding arbitrary tuples to the tuple space. That 
    behavior is exclusive of the LocalTupleSpace.
    
  - Related with the previous point: consider if merging the functionality of the
    FlagTupleSpace and the BulletinBoard makes sense. Both are similar structures,
    although one exists for concurrency and the other for providing append-only
    functionality.
    
  - Review the consistency of the notation for ElGamal throughout the project, and
    in relation to the thesis document.
    
  - Separate the JavaCard communication tasks from the logic of the protocol.
  
  - There is a lot of code duplication in the ThreadThresholdElGamal*KeyGenerator classes.
    Evaluate alternatives to enable reuse.