Proton Mail - Privacy Update thread

https://theregister.com/2021/09/...

Can’t trust anyone ffs!

Gotta start doing pigeon messages again!

I can understand why people might be angry about the change of text.

But to be honest, if you have a tiny shroud of sanity in your brain and some understanding of international laws, it should be evident that _no_ service can legally be fully anonymous.

There might be popular services still running claiming anonymity, but as soon as they gain interest from the origin countries government it will be over.

Net neutrality is dead.

Anonymity in the internet is dead.

And no - VPN isn't anonymous per se, as some company / provider is behind it and bound to it's countries origin law.

I'm not liking it - don't get me wrong... But I'll find the hysteria / fuss wrong.

This is not something the company has any influence on - they can choose to comply or be taken legally down.

It's a choice of the government.

Their clarification post.

https://protonmail.com/blog/...

@Floydimus

I like that answer.

It is not only transparent but also clarifies a lot of the legal troubles.

Which has become rare in my opinion.

Thx for the update

@IntrusionCM they have to abide by the law.

Also, many fail to understand the difference between privacy and anonymity.

I think their clarification post makes sense.

@IntrusionCM I love such incidents because it allows me to see how a company responds and handles the situation, especially the PR.

@Floydimus Yes.

Though it pains me how much press (in general, not the company) has become completely fucked up.

Some press articles, even technical press, start a witch hunt. Press has become really sensationalist, without focusing on facts / empathy.

@IntrusionCM media is all about trp these days.

Sadly tech industry is going down that lane. All we do is track and improve metrics and no longer add value.

The real problem here isn't that they complied with the legally binding request, that's inevitable.
The problems are
1. That they had the details in question to begin with. Although there are laws that can force you to provide information you have, I believe there are no laws in Switzerland that would force you to keep information other than tax related stuff
2. That they lied about having the details.

Also if you're doing very illegal stuff or stick it to powerful people, get a good technician. That's common sense in the 21st century.

Yeah now they can definitely track everything you people do instead of providing a smorgasbord intentionally to foreign affairs offices everywhere lol

@lbfalvy in truth stay off the internet and use couriers and drops if you’re trying to blow up that chomo retirement home

1. One time pass. Gigabytes of OTP.

2. Distributed over usb.

3. Standard encryption on top

4. User encrypts their message using standard PGP in the background, and then applies entropy from the OTP. We do not keep copies of the one time pass after they are distributed. This is explcitly made *part* of the product and product advertisement, and also part of the contract of service.

5. Our service is offered free, only used to advertise endpoints for sending and recieving. The one time pass on isb or other device, are where we make money, combine with access to the message system for discovering other users.

7. User selects someone to send a message.

8. User sends the now pgp and OTP encrypted message.

9. End users software receives message, applies their own otp, and then sends the message back.

10.
Originating sender removes their own OTP, and sends the message to the receiver.

11. Reciever removes their own otp, and decrypts the pgp encryption.

Best of all, at no point is the message sent over the wire without *someones* onetime pad applied. At no point does anyone in the exchange know the other persons one time pad.

@Wisecrack How are the OTP operations commutative? Do you just XOR or is it more complicated?

@Wisecrack I'm not very familiar with security, only maths.

@Wisecrack Because if it's an XOR and you have messages 1 and 2 from the procedure you can XOR them to get the recipient's OTP and use that to decode message 4.

@lbfalvy not exactly. The message is encrypted with pgp *before* any one time pad is ever applied.

So even a man in the middle couldnt retrieve the original message by recording the traffic between sender and recipient.

This setup is designed so that even a centralize system or man in the middle, recording the traffic, wouldnt have enough to be useful.

If course you could do it the other way around:

1. Data+too = message
2. Apply pgp and send
3. Decrypt on the other side. Recipient applies their own otp
4. Recipient reencrypts message with pgp
5. Original sender receives message, decrypts pgp, removes their first otp, renencrypts in pgp, and sends to recipient
6. Recipient unencrypts packet, removes their own otp, and finally at last has the intended message.

God damn typos "of" not "if" for ffs.
And a half dozen others.

Cant type for shit on this phone.

@Wisecrack I know that, my point was that the OTP step is redundant. If the PGP isn't compromised it's completely useless, and if the PGP is compromised all it achieves is that the attacker gains access to the output of both OTPs, which - given a couple gigabytes of samples - might even compromise the OTP.

@lbfalvy no, I mean the one time pad itself is x amount of gigabytes.

It's to solve the distribution issue: cant get past having to distribute them physically, but we can reduce the frequency of those deliveries by making the pad huge.

Actually, as long as each user had a hardware randomizer, theres no need for an otp. It's just to add entropy.

The pgp "covers over" the one time pad encrypted message, so MITM and Xoring doesnt work.

Unless I'm misunderstanding something you wrote.

@Wisecrack My question is, why do you need OTP? PGP is secure in itself and doesn't have holes that need patching, so the only purpose for another layer of security can be in case the keys are compromised. But because of the vulnerability I described earlier, if the PGP keys are compromised then the OTP in itself isn't secure at all. Therefore I believe that there's no situation in your setup where the OTP would provide any level of security.

@Wisecrack I just realized that PGP private keys are compromised separately, so by stealing either key you can only gain access to either messages 1&3 (recipient privkey) or 2 (sender privkey). (I also just noticed that I accidentally referenced a message 4 previously which doesn't exist). 2 in itself is obviously useless, and 1&3 together are only enough to obtain the combination of the OTPs that you could use to decrypt 2, which is however encrypted with the PGP privkey you don't have.

@lbfalvy I made a follow up post on this before but fucked up and just copy pasted a subsection instead of the whole reasoning. Got disgusted and deleted the entire thing.

In any case, the thinking goes, that with the advent of quantum, pgp, like other factorization based methods, will soon not be secure enough.

In any case, that's my fault for not explaining it.

One time pads themselves can be handled a number of ways instead of a simple xor.

This is for example one-time-pads with zero sharing of pads if hardware randomizers are involved.

There are also methods for decentralizing and anonymizing the communication senders and receivers, which approach zero-trust at scale by treating relays as indistinguishable from destinations and vice-versa. Or publishing to a public ledger, so long as there is some mechanism to prevent 51% attacks and to remove/censor illegal material from the chain, such as through network consensus.

And more importantly at scale, randomly-generated round-Robin relay circuits could also be effective at defeating man in the middle attacks.

@Wisecrack I know there are other algorithms, but your procedure implies that the algorithm is commutative, that is, given

pt = dec(key, enc(key, pt))

the claim that

dec(key1, enc(key2, enc(key1, pt))) =

= enc(key2, dec(key1, enc(key1, pt))) =

= enc(key2, pt)

This identity is far from obvious, I can't think of any cryptographic process that involves commutativity because it's a massive footgun and it's a distinct property of XOR, which is why I assumed XOR.

@lbfalvy yes but you understand how a one time pad works right?

You know how if you want to sample audio you have to sample at twice the frequency so you dont miss anything?

The same principle applies to high entropy random data. Effectively the information content, or low entropy rate of your data, is the "frequency."
When you combine it with high entropy data or "noise", what you have effectively done is lowered the "sampling rate" to below the frequency of the original data.

Theres other metaphors that arent as stilted but that's what I could come up with.

In short, if every byte from your one time pad is noise, then the key length is always equivalent to your message length. And because of the randomness of the bits is much higher than your low entropy data, and the distribution of entropy bits isnt spread across your data, decoding the key is *equivalent* either to having the key outright, or having the message outright.

And again, because the entropy is high (low information content), effectively your encrypted message is *also* mathematically indistinguishable from noise.

This has actually been proven specifically about one time pads ages ago, and I encourage you to look it up for yourself because the subject matter is absolutely fascinating once you dig into it.

In other words, even with man in the middle attacks, as long as byte streams taken from a pad are not reused, the one time pad is mathematically and cryptographically unbreakable because its mathematically equivalent to a noise signal who's entropy mixes with low entropy information in the message proper. In fact you could say the one time pad or randomness specifies a function that also doubles as the key in a one to one ratio between the operations of the function and the bits of the key.

@Wisecrack I know that, but I don't understand what any of that has to do with commutativity. Your method depends on
text = dec(key2, dec(key1, enc(key2, enc(key1, text))))
Which requires commutativity or some other odd algebraic assertions.