this post was submitted on 16 Nov 2023
200 points (93.5% liked)

Privacy

30753 readers
929 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Related communities

Chat rooms

much thanks to @gary_host_laptop for the logo design :)

founded 4 years ago
MODERATORS
 

Proton Mail, the leading privacy-focused email service, is making its first foray into blockchain technology with Key Transparency, which will allow users to verify email addresses. From a report: In an interview with Fortune, CEO and founder Andy Yen made clear that although the new feature uses blockchain, the key technology behind crypto, Key Transparency isn't "some sketchy cryptocurrency" linked to an "exit scam." A student of cryptography, Yen added that the new feature is "blockchain in a very pure form," and it allows the platform to solve the thorny issue of ensuring that every email address actually belongs to the person who's claiming it.

Proton Mail uses end-to-end encryption, a secure form of communication that ensures only the intended recipient can read the information. Senders encrypt an email using their intended recipient's public key -- a long string of letters and numbers -- which the recipient can then decrypt with their own private key. The issue, Yen said, is ensuring that the public key actually belongs to the intended recipient. "Maybe it's the NSA that has created a fake public key linked to you, and I'm somehow tricked into encrypting data with that public key," he told Fortune. In the security space, the tactic is known as a "man-in-the-middle attack," like a postal worker opening your bank statement to get your social security number and then resealing the envelope.

Blockchains are an immutable ledger, meaning any data initially entered onto them can't be altered. Yen realized that putting users' public keys on a blockchain would create a record ensuring those keys actually belonged to them -- and would be cross-referenced whenever other users send emails. "In order for the verification to be trusted, it needs to be public, and it needs to be unchanging," Yen said.

Curious if anyone here would use a feature like this? It sounds neat but I don't think I'm going to be needing a feature like this on a day-to-day basis, though I could see use cases for folks handling sensitive information.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 9 points 9 months ago (2 children)

Right here:

Blockchains are an immutable ledger, meaning any data initially entered onto them can’t be altered. Yen realized that putting users’ public keys on a blockchain would create a record ensuring those keys actually belonged to them – and would be cross-referenced whenever other users send emails. “In order for the verification to be trusted, it needs to be public, and it needs to be unchanging,” Yen said.

The benefit of doing this with a blockchain instead of a privately held and maintained database is that the latter can be compromised, and you just have to trust "whoever" is maintaining that private database. Blockchain means that the ledger is distributed to many nodes, and any post-entry modification to that chain would be instantly recognized, and marked invalid by the other nodes operating the chain. Besides that, when you're looking up a public key for a recipient on such a blockchain, you would be looking it up at a number of nodes large enough that in order for a malicious entry to come through, they would all have to be modified in the same way, at the same time, and you would have to be asking before the change got flagged. Poisoning blockchain data like this is simply not possible; that's what makes this an especially secure option.

[–] [email protected] 7 points 9 months ago (1 children)

But it’s not public. It’s a private blockchain. The immutable ledger aspect only matters if everyone can see the ledger. Otherwise we take at face value all of the things you said. Assume they run one node and that one node is compromised by a malicious actor. The system fails. Extend it to a limited number of nodes all controlled by SREs and assume an SRE is compromised (this kind of spearphishing is very common). The system fails again.

Sure, you can creatively figure out a way to manage the risks I’ve mentioned and others I haven’t thought of. The core issue, that it’s not public, still remains. If I’m supposed to trust Proton telling me the person I’m emailing is not the NSA pretending to be that person (as the Proton CEO suggested), I need to trust their verification system.

[–] [email protected] 1 points 9 months ago (1 children)

It's. In. Beta. Of course it's not being offered to the general public yet. It's likely that there are very many beta nodes, in order to test scalability. When it's out of beta, you drop the beta chain and start a new one.

[–] [email protected] 3 points 9 months ago (1 children)

Did we read the same article? Emphasis mine.

Yen said Proton might move the feature to a public blockchain

I’m not interested until it’s public. Additionally, building out the chain then dropping it to rebuild a new public one is rewriting history, which violates the whole “immutable” part of “immutable ledger.”

[–] [email protected] 4 points 9 months ago (1 children)

Context matters:

Proton rolled out the beta version of Key Transparency on their own private blockchain, meaning it's not run by a decentralized series of validators, as with Bitcoin or Ethereum. Yen said Proton might move the feature to a public blockchain after the current version serves as a proof of concept.

It's not rewriting history. We're talking about validation of public keys. The exact same information can be added to a public non-beta chain, to satisfy the concerns about security that would come from maintaining a previously private beta chain into production.

[–] [email protected] 1 points 9 months ago (1 children)

… which gives a timing attack and the ability for bad actors to impersonate someone. I agree with you that, once public, this is a good idea. You cannot convince me that this is a good idea if done privately because there is no way to trust but verify, especially in the highly sensitive contexts they want trust in.

If it’s not public, I won’t trust it. You trust it blindly because it’s in beta. We’re not going to come to an agreement over these mutually exclusive positions.

[–] [email protected] 6 points 9 months ago (1 children)

I don't "trust it blindly" because it's in beta - I understand that it's a work in progress because it's in beta. Jesus christ you people and your fucking tinfoil hats.

[–] [email protected] 1 points 9 months ago (1 children)

Your only response to valid criticism about the lack of verification is pointing to the state of development as if that magically washes away all of the criticism. It doesn’t.

While I do have many tinfoil hats, basic fucking trust measures do not require me to pull them out. This is cryptography 101 shit not anything complicated.

[–] [email protected] 3 points 9 months ago (1 children)

"Hey, I'm making a cake, I think you'll like to have a piece when it's done!"

NO WAY AM I EATING THAT RAW BATTER WITH UNCOOKED EGGS IN IT YOU'RE EVIL

This is why you're not one of the beta testers.

[–] [email protected] 1 points 9 months ago (1 children)

You don’t understand basic trust relationships. I don’t really care about your opinion. I already called out that your blind trust in beta software conflicts with my security fundamentals so we’re at an impasse. Once you understand why validation is important or can show why a critical component of trust architecture is somehow not necessary, I’d be happy to be happy to reconsider your opinion.

[–] [email protected] 0 points 9 months ago (1 children)

Keep living in your weird fantasy world where applications and solutions should pop into existence fully formed, feature-rich, and bug-free, with no development or testing whatsoever.

[–] [email protected] 2 points 9 months ago (1 children)

Hey I’ve got a new scheme to validate the identity of someone for a very sensitive conversation. You wanna use it? Trust me, it’s secure.

I feel like you don’t understand the difference between a product roadmap and security fundamentals.

[–] [email protected] 0 points 9 months ago (2 children)

I feel like you don't understand how blockchains work.

[–] [email protected] 3 points 9 months ago

It doesn’t matter what the tech is, if you can’t audit it, you can’t trust it.

Also a single private blockchain owner is just a blackbox data store, not a blockchain. I’ve already explained how it’s vulnerable to very simple attacks, much less the complicated attacks that will be thrown at something like this.

[–] [email protected] 1 points 9 months ago

How do private block chains protect against 51% attacks?

[–] [email protected] -2 points 9 months ago* (last edited 8 months ago) (1 children)
[–] [email protected] 10 points 9 months ago (1 children)

As long as there is an appropriate method for adding a legitimate entry to the chain, incorrectly entered data can be handled by appending corrected data on to the chain, and marking the error as such. Sensitive data, in this case, would be along the lines of "I accidentally added my private key instead of my public key." The action necessary here is the same as if I published my private key anywhere: stop using that key pair and generate a new one.

[–] [email protected] 1 points 9 months ago* (last edited 8 months ago) (1 children)
[–] [email protected] 3 points 9 months ago (1 children)

This part:

As long as there is an appropriate method for adding a legitimate entry to the chain, ...

[–] [email protected] 0 points 9 months ago* (last edited 8 months ago) (1 children)
[–] [email protected] 5 points 9 months ago (1 children)

Well, if there's not, then the whole thing would never work at all.

[–] [email protected] 0 points 9 months ago* (last edited 8 months ago) (1 children)
[–] [email protected] 1 points 9 months ago (2 children)

Proton rolled out the beta version of Key Transparency on their own private blockchain, meaning it's not run by a decentralized series of validators, as with Bitcoin or Ethereum. Yen said Proton might move the feature to a public blockchain after the current version serves as a proof of concept.

https://finance.yahoo.com/news/blockchain-not-crypto-proton-mail-120000573.html

Because the Proton blockchain is currently private, the keys they are currently adding could easily be affected by a man in the middle attack.

No. That's not how that works. Just because a blockchain is "private" doesn't make it suddenly changeable, and it doesn't mean there's a unsafely small number of nodes. People commonly get invited to participate in beta testing; that's kind of how software development works.

And there would be no way to invalidate those keys for any of the affected users, ...

Remember when I said:

As long as there is an appropriate method for adding a legitimate entry to the chain, incorrectly entered data can be handled by appending corrected data on to the chain, and marking the error as such.

That hasn't become untrue in the last hour.

[–] [email protected] 1 points 9 months ago (1 children)

Just because a blockchain is “private” doesn’t make it suddenly changeable

This is patently false. All blockchains are changeable with enough consensus. See something like this article.

[–] [email protected] 0 points 9 months ago* (last edited 9 months ago) (1 children)

Yeah, and that's called a fork. The chain doesn't vanish; a new chain is created, forking off of the old one. That's why we have both Ethereum and Ethereum Classic.

Oh wait, you're talking about a 51% attack. Read the whole article that you linked. It is amazingly difficult to perform, and as the number of nodes goes up, it becomes even more difficult.

Has anyone successfully performed a 51% Attack on Bitcoin?
Nope, not yet.

Some miners have come close to reaching 50% or more of the total mining power over Bitcoin’s history, but nobody has actually performed a successful 51% Attack.

If Big Daddy Bitcoin hasn't suffered a 51% attack, I find the risk of that happening vanishingly low.

https://hacken.io/discover/51-percent-attack/

There have been three. BTG, ETC and VTC. All three of those are Proof of Work. PoW is going by the wayside, I'm hopeful that Proton would be using Proof of Stake, which is a much more difficult model to 51% against. (You would need to possess 51% of the tokens.) Even if someone managed to do it, it would still be noticed pretty much immediately, and then you'd fork to a new chain and move on.

[–] [email protected] 1 points 9 months ago (1 children)

A fork assumes the old chain continues to exist instead of being completely replaced. Without insight into the chain, which is we can’t have until it’s public, you can’t make any guarantees of immutability.

[–] [email protected] -1 points 9 months ago (1 children)
[–] [email protected] 1 points 9 months ago

I still don't see why that matters.

Put differently, I've got a revolutionary new financial encryption system. It can safely act as the middleware between you and any vendor. You can trust me with your credit card numbers because of my years experience and industry clout. You can't see my system and I won't do a PCI audit because it's in beta. You can totally trust me though.

[–] [email protected] -3 points 9 months ago* (last edited 8 months ago) (1 children)
[–] [email protected] 0 points 9 months ago (1 children)

You do realize that when it's out of beta, they could easily drop the beta chain and start a brand new one, right? And that the methodology for someone adding their public key as well as the blockchain node application (wallet) would be open source, so that anyone can look at the code? And that Proton isn't adding your public key to the chain, you are? And that being a beta blockchain kind of necessaily depends on having many nodes, in order to test scalability?

You're out of your depth here, and I'm not going to bother explaining any further.

[–] [email protected] -2 points 9 months ago* (last edited 8 months ago) (1 children)
[–] [email protected] 0 points 9 months ago

You're out of your depth here, and I'm not going to bother explaining any further.