Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Throw Away Galois/Counter Mode as Committing Encryption #1

Closed
marcoonroad opened this issue Jul 28, 2019 · 4 comments

Comments

@marcoonroad
Copy link
Owner

commented Jul 28, 2019

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.

@marcoonroad

This comment has been minimized.

Copy link
Owner Author

commented Jul 28, 2019

The paper also states that the encryption key, HMAC secret and input vector must be generated/derived from a good KDF for the Encrypt-then-MAC authenticated encryption be a committing encryption as well.

@marcoonroad marcoonroad changed the title Throw Away Galois/Counter Mode as Commiting Encryption Throw Away Galois/Counter Mode as Committing Encryption Jul 28, 2019

@marcoonroad

This comment has been minimized.

Copy link
Owner Author

commented Aug 4, 2019

BUMP:

The nocoiner encryption algorithm resembles the recommended algorithm from the paper/article (snapshot/print-screen below):

Screenshot from 2019-08-04 16-04-34

We have a master key, and from that we derive an encryption key and a MAC key. The input vector is randomly generated and appended on the final commitment/cipher. Our header is the hashed process/context fingerprint. This fingerprint could not be used to associate/detect the commitment issuer 'cause these fingerprints are public, it is only used to provide a randomization context which reduces the probabilities of the distributed commitment collision. They must not be used for any kind of authentication, proof, identification, whatever...

This patch is tracked on the branch patch/throw-away-gcm.

@marcoonroad

This comment has been minimized.

Copy link
Owner Author

commented Aug 4, 2019

Future plans might include to split this AEAD (Authenticated Encryption with Associated Data) module in a separate library. The benefits are clear, the community can use an AEAD encryption directly without relying on this library for commitment schemes and accessing the internals here.

This issue will be closed once the PR on OPAM repository is approved and merged.

@marcoonroad

This comment has been minimized.

Copy link
Owner Author

commented Aug 5, 2019

The PR on OPAM repository was already closed.

@marcoonroad marcoonroad closed this Aug 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.