Show HN: Prevent email forgery in Gmail using a Blockchain-powered architecture • Hacker News Board

Re: Show HN: Prevent email forgery in Gmail using a Blockchain-powered architecture

#11

Post by nadaviv » Thu, Jul 05, 2018, 2:49 PM UTC

xpressyoo wrote: post #10

nadaviv wrote: post #9

Earlier quoted context omitted.

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?

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

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.

Re: Show HN: Prevent email forgery in Gmail using a Blockchain-powered architecture

#12

Post by xpressyoo » Thu, Jul 05, 2018, 2:58 PM UTC

xpressyoo wrote: post #10

nadaviv wrote: post #9

Earlier quoted context omitted.

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?

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

EDIT: reply to your last comment. The whole idea is to propose a "hybrid" architecture that bridges the gap between a centralized technology such as the Email with the benefits of a decentralized one, the blockchain.

This hybrid process implies you will need to trust parties at some points, e.g., Google and Gmelius. However, the point here is to offer a means to store in a robust way the trace that a specific email communication existed at a point in time, including its context/content.

Re: Show HN: Prevent email forgery in Gmail using a Blockchain-powered architecture

#13

Post by crote » Thu, Jul 05, 2018, 3:06 PM UTC

xpressyoo wrote: post #8

crote wrote: post #4

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 bloc…

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 deb…

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

Re: Show HN: Prevent email forgery in Gmail using a Blockchain-powered architecture

#14

Post by xpressyoo » Thu, Jul 05, 2018, 3:14 PM UTC

crote wrote: post #13

xpressyoo wrote: post #8

Earlier quoted context omitted.

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 deb…

"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 a…

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.

Re: Show HN: Prevent email forgery in Gmail using a Blockchain-powered architecture

#15

Post by jlgaddis » Thu, Jul 05, 2018, 7:12 PM UTC

Yes, because the killer feature missing from SPF + DKIM + DMARC is "blockchain".

Every time I see some new ", 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.