Finally, Debian has ditched OpenPGP for repository signing in favor of Ed25519 with SHA512. This is a step ahead for privacy and security. You can see the article here.
As @anon123@lemmy.ml pointed out, the following issues about PGP are not specifically related to Debian article I linked.
- No authenticated encryption.
- Receiving a signed message means nothing about who sent it to you
- Usability issues with GnuPG
- Discoverability of public keys issue.
- Bad integration with emails.
- No forward secrecy.
There’s usuful documentation about it:
Debian never used PGP. PGP is a proprietary application. Debian did however use GPG which implements the OpenPGP standard.
No authenticated encryption.
GPG did add support for AEAD algorithms in version 2.3 (which was released last April). That being said, this really does not matter as Debian never used GPG for encryption.
Edit: OpenPGP supports something called MDC which is basically an encrypted hash of the message. Think of it as a weaker and home-brew version of AEAD.
Receiving a signed message means nothing about who sent it to you
This is true but 1: this does not affect the debian usecase and 2: signify-openbsd, minisign, etc all have the same issue.
Usability issues with GnuPG
It really is not that bad. Especially when you use it for apt.
Bad integration with emails.
OpenPGP is unrelated to emails. Some do use it to send encrypted emails but it is not any different from sending zip files to people. But then again this is unrelated to the Debian usecase.
No forward secrecy.
This is not necessarily a negative. Forward secrecy requires many sacrifices. And again this is unrelated to the Debian usecase.
Note: GPG has supported signing data with ed25519 for a few years now.
There are however real issues with GPG, such as how libgcrypt somehow managed to implement ed25519 in a way that allows for side-channel attacks.
They ditched PGP because of Stallman and their politics.
Oof that’s just plain stupid
Please elaborate.
I am not sure what to tell, if you do not know about the RMS, FSF and the SJW reactionary controversy regarding disinformation claims of RMS supporting pedophilia.
Are you saying that they are removing GPG from debian apt due to GPG being a GNU project? Do you have any reason to believe that this is the case?
It sounds especially weird because the GPG maintainer, Werner Koch, is a member of the GNU assembly (see https://gnu.tools/en/people/) and he also signed the old anti-stallman open letter at https://guix.gnu.org/blog/2019/joint-statement-on-the-gnu-project/ so I really doubt that this is related to any anti-GNU policy.
It is a major reason, considering the kind of menacing push they tried with the open letter, being one of the leading organisations behind trying the cancel culture on RMS and all of his GNU projects.
You can look at the open letter and the RMS support letter, both will have some Debian devs, so this is a matter of nuances what you are trying to say here.
Hi. I didn’t know that. Nonetheless, the weaknesses i linked about PGP still remain. Since there are better alternatives, its not bad replace PGP when possible.
I doubt PGP is bad. It is used for email encryption and secure communications over Tor as well.
There is no doubt. Along with Whonix many cryptography experts pointed out the weaknesses of PGP, for example:
About email encryption:
Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext. If you needed another reason, read the Efail paper. The GnuPG community, which mishandled the Efail disclosure, talks this research down a lot, but it was accepted at Usenix Security (one of the top academic software security venues) and at Black Hat USA (the top industry software security venue), was one of the best cryptographic attacks of the last 5 years, and is a pretty devastating indictment of the PGP ecosystem. As you’ll see from the paper, S/MIME isn’t better. This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending? Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety.
including the subject (which is literally message content)
All email clients with OpenPGP support that I am aware of encrypt the subject and have been doing so for years.
PGP email is forward-insecure
Forward secrecy is not a panacea.
The GnuPG community, which mishandled the Efail disclosure
This is misinformation. Rather it was only the GPG and the Kmail developers that handled the situation appropriately. (It was also not a vulnerability in GPG)
Recommending email encryption to at-risk users is malpractice
Yet he instead suggests signal which also leaks metadata and puts users in a much worse risk.
Hi, thank for your response. I understand your point; the issues I linked about PGP are not specifically related tod Debian article, I should have been more clear about it. Nonetheless, the weaknesses about PGP still remain.
Forward secrecy is not a panacea.
The weakness about PGP still remains. Forward secrecy it’s not a panacea, but it’s a useful feature. The approach Is way better than PGP.
All email clients with OpenPGP support that I am aware of encrypt the subject and have been doing so for years.
Even with OpenPGP support the subject of emails are not encrypted.
Yet he instead suggests signal which also leaks metadata and puts users in a much worse risk.
Can you elaborate please, maybe with source? As far as I understand signal minimize metadata
Forward secrecy is a panacea for emails. Emails do not work like instant messenger protocols.
ProtonMail is not an ideal example of encrypted email. If you could explain it with an email that allows custom PGP encryption, it would be a valid example.
Signal is most likely a government op, considering it has its servers exclusively in USA, which are governed by US CLOUD Act, and Elon Musk nd Snowden promoted Signal. Similar actions happened with Wire Messenger, which was in Switzerland before, but later moved to USA. Wire was also promoted by Snowden and others in the same fashion.
Forward secrecy is a panacea for emails. Emails do not work like instant messenger protocols.
I understand your point. However, that’s why email are not recommended as secure way to send/receive messages. Email, even when encrypted leaks metadata and lacks security features like forward secrecy. Email was not created with security in mind.
ProtonMail is not an ideal example of encrypted email. If you could explain it with an email that allows custom PGP encryption, it would be a valid example.
As far as I know, ProtonMail is considered the gold standard. Even then, encrypt subject in email it’s not possible even with custom PGP encryption. However, maybe I’m wrong here. Glad to be corrected.
Signal is most likely a government op, considering it has its servers exclusively in USA, which are governed by US CLOUD Act, and Elon Musk nd Snowden promoted Signal. Similar actions happened with Wire Messenger, which was in Switzerland before, but later moved to USA. Wire was also promoted by Snowden and others in the same fashion
I’m sorry but this statement doesn’t prove anything. Just because it’s plausible and common sense ( I don’t think this is the case to be honest) it doesn’t mean its also the truth. Signal has a good end to end encryption protocol with minimization of metadata. There are no evidence of backdoors.
Forward secrecy it’s not a panacea, but it’s a useful feature
With a lot of drawbacks (using it with multiple devices sucks) for too little gain and you can’t use it in non-interactive protocols such as OpenPGP. Or rather, you can if you do it manually, but it requires interaction.
Even with OpenPGP support the subject of emails are not encrypted.
Because Protonmail sucks. It works fine in Thunderbird.
Can you elaborate please, maybe with source? As far as I understand signal minimize metadata
I admit that it has been a while since I checked the signal protocol so I might be wrong. The page that you linked seems fine.
Because Protonmail sucks. It works fine in Thunderbird.
Even if protonMail sucks, email will always leaks meatada.
When using end-to-end encryption (E2EE) technology like OpenPGP, email will still have some metadata that is not encrypted in the header of the email, including; To, From, Cc, Date, Subject.
Email metadata is crucial to the most basic functionality of email (where it came from, and where it has to go). E2EE was not built into the email protocols originally and is also optional, therefore, only the message content is protected.
When emails travel between email providers an encrypted connection is negotiated using Opportunistic TLS. This protects the metadata from outside observers, but as it is not E2EE, server administrators can snoop on the metadata of an email.
With a lot of drawbacks (using it with multiple devices sucks) for too little gain and you can’t use it in non-interactive protocols such as OpenPGP. Or rather, you can if you do it manually, but it requires interaction.
Acutally, forward secrecy it’s very useful.
OpenPGP also does not support Forward secrecy, which means if either your or the recipient’s private key is ever stolen, all previous messages encrypted with it will be exposed. How do I protect my private keys?
Interesting. I know it is forward insecure, but this paper seems to be intriguing.
Err no it isn’t, you’ve just found a possible option written up on the wiki. There is exactly one mention of it on the apt maintainers list. You can expect a lot more discussion before this format is even officially supported, nevermind ditching the OpenPGP part.
More comments : https://lobste.rs/s/sraszh/ditching_openpgp_new_approach_signing
This spec page reads like Debian might not have ditched OpenPGP for repository signing yet but outlines ideas how to implement their new approach in the future.
