marcoonroad / nocoiner

A Commitment Scheme library for Coin Flipping/Tossing algorithms and sort. :four_leaf_clover: :camel: :lock: :key:

nocoiner

A Commitment Scheme library for Coin Flipping/Tossing algorithms and sort.

---

NOTICE: The previous version (0.0.1) of this API used the Galois/Counter Mode encryption. This authenticated encryption algorithm is not a committing encryption (that's, a lockable box). The main reason is the weakness of the internal GCM hash against Collision Attacks (a hash with 256-bits or 512-bits images would be likely resistant, but GCM uses 128-bits of output/digest images). For more details, please refer to the historical issue here. The new API, therefore, breaks if you try to reveal/open commitments generated by the previous API.

---

About

This project implements Commitment Schemes using the Encrypt-then-MAC approach of authenticated encryption. Because this kind of encryption algorithm provides both Message Confidentiality and Integrity, it fits perfectly the Hiding and Binding properties of Commitment Schemes. Confidentiality protects the message against passive attacks while integrity protects it from active attacks.

The hiding property states that it is impossible to discover the secret with the commitment data left alone, that is, the commitment receiver can't know the secret until the commitment sender reveals that through her opening key.

The binding property, on the other hand, ensures invariants on the commitment sender side. It disallows the sender to change the secret by using a different opening key. While the sender can refuse to reveal her secret, she can't cheat on the game. There's a variant of commitment schemes called Timed Commitments where the receiver can brute-force the commitment in the case of the sender aborting the game by refusing to send the opening key, tho. Another variant called Fuzzy Commitments accepts some noise during opening phase.

Commitment Schemes are one of the many Secure Multiparty Computation protocols/primitives, Secret Sharing is other famous cryptographic primitive in such field.

Installation

For the stable release, just type:

$ opam install nocoiner

To install/test the unstable version on this repository (assuming you're inside the project's root directory):

$ make install # 'make uninstall' reverts the changes

Testing

$ make test

Usage

As library (assuming you have linked the package nocoiner below):

let secret = "I have nothing to hide."
let (c, o) = Nocoiner.commit secret

assert (secret = Nocoiner.reveal ~commitment:c ~opening:o)

Here, the Nocoiner.commit operation is non-deterministic and the Nocoiner.reveal is deterministic. The Nocoiner.reveal operation may throw the following exceptions:

• Nocoiner.Reasons.InvalidCommitment, if the parsing of commitment fails.
• Nocoiner.Reasons.InvalidOpening, if the opening key contains invalid data.
• Nocoiner.Reasons.BindingFailure, if both commitment & opening are unrelated.

As the command-line interface (ignore all the $ below while typing):

$ echo "Something not really secret..." > secret.txt
$ cat secret.txt | nocoiner commit \
  --commitment-file=commitment-box.txt \
  --opening-file=opening-key.txt
$ nocoiner reveal \
  --commitment-file=commitment-box.txt \
  --opening-file=opening-key.txt > secret-output.txt
$ cat secret-output.txt

The complete API reference is available here. Coverage reports are generated too, please refer to the respective page.

Disclaimer

This library was not fully tested against side-channel attacks. Keep in mind that the use cases of this library is for Secure Multiparty games such as online Gambling and Auctions. With other use cases, the security of this cryptographic primitive can be deemed as flawed.

Note that players can abort in the middle of a Commit-and-Reveal game, so you should as well deal with that on your code logic. The random encryption key and input vector only ensure the uniqueness locally, it's also possible to happen collisions of both random data on a distributed setting (it's due the sources of entropy being remote and different - so commitments and openings would be identical, think on that even if this probability is small). In such case, you can either take a fingerprint of the host machine and a timestamp nonce into account, in the same sense of Elliott's CUID library (we already cover that issue of distributed collisions by using a fingerprint of hashed process context).

nocoiner's Issues

Throw Away Galois/Counter Mode as Committing Encryption

Following the article Message Franking via Committing Authenticated Encryption, the internal hash of GCM used for MAC is not collision-resistant, and thus, breaking the binding property (the sender can brute-force a MAC collision in feasible amount of time/space). It's possibly 'cause the hash of GCM is 128-bits, most 128-bits are already broken too nowadays.

Due that vector attack, I must replace AES-GCM entirely. I should use instead better options, such as AES-CBC + Blake2B 512-bits keyed mode, for instance. In the case, it would be an instance of the Encrypt-then-MAC approach of Authenticated Encryption algorithms.

Backwards compatibility will be broken, and I must report that on top of documentation. There's some mitigation on the nocoiner implementation against the GCM hash vector attack. Internally, we use null-padding and Base64 encoding, so it's an hardened hack -- the sender should find a GCM tag collision which still makes the decrypted text "Base64-encoding parseable".

This issue is open to possibly track further discussion.

Encryption of opening key on CLI/API usage

The CLI executable would write & read the plain opening key on disk. This is an undesirable security issue. Therefore, I should reuse the internals regarding KDF and AEAD to store this opening key encrypted. We can use an $NOCOINER_PASSWORD environment variable as the end-user input password for our KDF-then-Encrypt-then-MAC for the random opening key. We can too validate this end-user password against minimal security requirements for strong passwords even with a KDF applied (the number of cycles of KDF vs. the strength/entropy of end-user password is a tradeoff to match).

It's desirable as well to expose this encryption/decryption of opening under an API interface for development & integration from developers/maintainers. This should be optional due possible internal requirements from corporations regarding encryption/storage of keys (in the case, the opening key). The interface could be something like:

module OpeningEncryption : sig
  type opening = string
  val encrypt : password:string -> opening -> string
  val decrypt : password:string -> string -> opening  
end

Issue open for more discussions.