[xpressyoo]

Thanks for your comments.

"They both supply email tracking, and protect your privacy by blocking email tracking."

> This is mainly offered to prevent false positives for our own trackers. But point taken :)

"It doesn't prove that the email has been sent, it just proves that it has been submitted to Gmelius for signing."

> The insertion is done when we have received a response from Google servers.

"SHA-512"

> Long debate but this was the most natural solution for a Merkle architecture.

[crote]

"The insertion is done when we have received a response from Google servers"

But GMelius is a client-side application, right? According to your whitepaper, the insertion is done when the _client_ receives the response, I don't see anything about validation from the GMelius servers to GMail.

"SHA-512"

It's not the SHA part which is the problem, it's the RSA part. 512-bit RSA is well-known to be broken and there have already been multiple exploits. 2048 bits is the bare minimum anyone should use nowadays.

[xpressyoo]

All the logic happens at the back-end level via our API communicating with Gmail's one. Nothing is done on the client-side (i.e., extension) besides the integration of our buttons/features within Gmail's UI.

The RSA key is just used to show that what has been inserted was through our service. Note that the final hash resulting from the mixer is done without any RSA.