
Show HN: Prevent email forgery in Gmail using a Blockchain-powered architecture - xpressyoo
https://gmelius.com/email-blockchain/
======
vivan
What benefit does the anchoring give over just the signing part? Surely the
signature is enough to prove that the email is from the expected sender? I
feel like this is just an attempt to add Blockchain to an existing system for
no benefit to the user.

EDIT: After looking around a bit more, the product appears to be your standard
CRM tool (similar to Streak) but with "Blockchain" added to make it look
different (but without adding any value).

~~~
xpressyoo
Hi vivan. Thanks for your comment. Besides the signature of an email using the
robustness and persistence of the blockchain, what is different with "Email
Stamping" and especially interesting for professionals who send sensitive
emails (e.g., lawyers, insurers, brokers...) is that they have a way to show
they sent an email with a specific content at a specific time.

A decisive challenge raised by today’s email dominance in the workplace is
that the latter means of communication does not offer a built-in function to
prove the integrity and authenticity neither of its content nor of its origin.
Knowing that emails are increasingly presented as legal evidence in courts
worldwide, it becomes urgent to think of approaches that could palliate the
inherent flaws of email.

EDIT: And yes, Gmelius offers a lightweight CRM targeting SMEs that covers all
the stages of the modern communication flow: from the first interaction to the
potential signature of a contract/quote. Besides, Gmelius offers a shared
inbox making possible to follow-up on leads, stay in sync with your team.

~~~
nadaviv
How does that prove the email was sent, though? Couldn't one timestamp the
email into the blockchain, without actually sending the email to the other
party?

Edit: btw, I released something that utilizes bitcoin's blockchain for
timestamping back in 2013:
[https://news.ycombinator.com/item?id=5790382](https://news.ycombinator.com/item?id=5790382)
(the website is no longer available because better solutions came since, but
its up on github[0] and the wayback machine[1])

This has some interesting use-cases, but people tend to overestimate what
blockchain timestmaping actually gets you. You can prove that some piece of
data existed at some point in time, but that's it. It doesn't prove this data
is authentic, that this data was communicated to anyone, that no one else
timestamped this data earlier, etc.

[0] [https://github.com/shesek/btproof](https://github.com/shesek/btproof)

[1]
[http://web.archive.org/web/20140430152135/https://www.btproo...](http://web.archive.org/web/20140430152135/https://www.btproof.com/)

~~~
xpressyoo
The insertion is only done once we have received a response from Google
servers that the email has been indeed sent (without bounce or other errors).

~~~
nadaviv
So you're acting as a trusted party to get delivery confirmations from Google?
What if Google doesn't confirm delivery, but you decide to write to the
blockchain anyway?

Also, won't Google servers return a cryptographically verifiable delivery
confirmation? If so, couldn't this be used as the delivery proof directly
instead?

~~~
xpressyoo
Yes, we integrate with Gmail and communicate via the official Gmail API.

We only receive response statuses and act accordingly. Moreover, we think it's
important for this functionality to make sense to insert the hash
corresponding to the integrity of the email, and so make possible for our
customers to "prove" they have indeed sent an email with a specific
body/subject/...

~~~
nadaviv
Well, doesn't that mean that the security model is based on you acting as
trusted third party and relying on you to only write truthful data to the
blockchain?

In other words, the delivery proof is not based on trusting the blockchain
mechanics, its based on trusting Gmelius Ltd.

------
crote
Big red flag:

> The hash of an email is computed using the SHA2-512 hashing algorithm and
> signed with our own 512-bit private RSA key.

Why even bother signing it if your key is that weak?

Furthermore, they sign every message individually with the same key. This does
not make sense to me: why not just sign the root of the Merkle tree?

Other fun stuff:

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

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

~~~
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.

------
jlgaddis
Yes, because the killer feature missing from SPF + DKIM + DMARC is
"blockchain". <rolls eyes>

Every time I see some new "<reliable tech>, now with Blockchain!"
announcement, it just convinces me a little bit more that "blockchain" is
still a solution (that very few actually need) searching for a viable problem.

