4 ms·

> PGP is bloated and complex, trying to be the Swiss Army Chainsaw of encryption and verification. It lacks modern features of encryption tools such as channel

> PGP is bloated and complex, trying to be the Swiss Army Chainsaw of encryption and verification. It lacks modern features of encryption tools such as channel binding (which opens whole categories of exploits) and perfect forward secrecy (instead preferring to use long-lived keys, which are a nightmare of their own). Strong identity and long lived keys are a requirement. Perfect forward secrecy does not make sense in a world were I want to prove that all things signed by me are in fact signed by me. If I generated a new key, how do I distribute that key to someone else in a way they can trust that key? And if you have that secure channel working and trust worthy, why do you even need to sign anything? Even in the case of debian apt signing changes, all the key signing happens in the public view, there is nothing secret about it. Perfect forward secrecy is only for encryption and does not make sense in the case of signatures, but even in the case of encryption (age) you have a similar key distribution problem. If you are constantly making ephemeral keys that's great, but it also means you need the receiver to make a new key on every file the sender wants to send. This means people will still have long lived keys, and perfect forward secrecy does not apply. Lastly, in most async communication, like email, PFS is very difficult because you don't have channels that can easily negotiate channels. There is autocrypt which gets pretty far, but has it's own troubles. For any real time communication, TLS and Olm are the way to go. But at this point we are very very far away from minsign which. > PGP also allows a host of insecure options without mandating secure ones: while it does offer good algos and distribution mechanisms (e.g. WKD), it also offers poor/deprecated algos and disasters like keyserver pools. PGP has been around for a long long time. None of the options were insecure when they were implemented. Minsign and age have decided that their tools will only have 1 algo, the correct and most secure one. However that can change in just a few years. At which point it will either become more like PGP or we will have to migrate everyone to the new best tool. This is madness. A PGP implementation that was more aggressive at deprecating weak methods is far better than this new pointy tools. > As for Signify: Minisign supports trusted and untrusted comments in signatures to supply metadata. As you say this data is untrusted and unsigned. Having it proves nothing about the ownership of the private key. > Some distributions like OpenBSD and Void Linux have finally upgraded their package signing from PGP to Signify; Debian is in the process of migrating from PGP to Ed25519 sigs (https://wiki.debian.org/Teams/Apt/Spec/AptSign https://wiki.debian.org/Teams/Apt/Spec/AptSign). If we manage to switch enough distros off PGP, maybe we can remove the need to have PGP installed by default. I have read their reasoning on this several, and I firmly believe this is a huge mistake. Or at the very least a lot of work that provides no actual value. However the keys here are distributed by packages, so there is already a TOFU when you install the system. In the end there is not actual end user impact here, besides making it much more difficult to know if the signature of a package is valid manually.

Seirdy 5y ago
> Strong identity and long lived keys are a requirement. Perfect forward secrecy does not make sense in a world were I want to prove that all things signed by me are in fact signed by me. If I generated a new key, how do I distribute that key to someone else in a way they can trust that key? And if you have that secure channel working and trust worthy, why do you even need to sign anything? A communication platform should handle this for you. Every modern E2EE platform offers out-of-band verification. The problem with PGP is it's used as a "go-to" encryption and verification tool for other situations where PFS is necessary (e.g. communication) due to its network effect ("it's already installed"). Minisign/Signify, in comparison, are used just for verification; they are a better fit for this because they don't try to be anything else. > but even in the case of encryption (age) you have a similar key distribution problem. If you are constantly making ephemeral keys that's great, but it also means you need the receiver to make a new key on every file the sender wants to send. This means people will still have long lived keys, and perfect forward secrecy does not apply. Age is for file encryption. An E2EE communication protocol/platform should have provisions to automate this process. > PGP has been around for a long long time. None of the options were insecure when they were implemented. Minsign and age have decided that their tools will only have 1 algo, the correct and most secure one. However that can change in just a few years. At which point it will either become more like PGP or we will have to migrate everyone to the new best tool. This is madness. It is better to have new versions of a standard than to extend a standard to include all possibilities. The equivalent would be making all TLS and SSL versions just extensions of the original SSL standard; a client talking to a server would negotiate between a plethora of secure and insecure cipher suites. Age uses 256-bit AES keys and the HKDF; Signify uses Ed25519 signatures. If these are found to be insecure in the coming decades, the solution would be to release a spec for Age 2 or Signify 2 instead of just adding an option to use a different combination of algos/curves/KDFs. > As you say this data is untrusted and unsigned. Having it proves nothing about the ownership of the private key. No, I didn't say that. I said that it supports both trusted and untrusted comments. Trusted comments are signed. > In the end there is not actual end user impact here, besides making it much more difficult to know if the signature of a package is valid manually. Given a source, sig, and pubkey, verification can be done with the following command: minisign -V -m %{SOURCE} -x %{SIG} -P %{public_key} This isn't any harder than using GPG unless you're using the "it's already installed" argument, which kinda proves my point about the network effects exacerbated by having a "do-it-all" tool instead of a "do-one-thing" tool. Minisign dogfoods this to sign its releases, and you can see Fedora's RPM spec use it quite easily to verify its tarball: https://src.fedoraproject.org/rpms/minisign/blob/rawhide/f/minisign.spec#_26 https://src.fedoraproject.org/rpms/minisign/blob/rawhide/f/m...

Seirdy 5y ago

> Strong identity and long lived keys are a requirement. Perfect forward secrecy does not make sense in a world were I want to prove that all things signed by me are in fact signed by me. If I generated a new key, how do I distribute that key to someone else in a way they can trust that key? And if you have that secure channel working and trust worthy, why do you even need to sign anything? A communication platform should handle this for you. Every modern E2EE platform offers out-of-band verification. The problem with PGP is it's used as a "go-to" encryption and verification tool for other situations where PFS is necessary (e.g. communication) due to its network effect ("it's already installed"). Minisign/Signify, in comparison, are used just for verification; they are a better fit for this because they don't try to be anything else. > but even in the case of encryption (age) you have a similar key distribution problem. If you are constantly making ephemeral keys that's great, but it also means you need the receiver to make a new key on every file the sender wants to send. This means people will still have long lived keys, and perfect forward secrecy does not apply. Age is for file encryption. An E2EE communication protocol/platform should have provisions to automate this process. > PGP has been around for a long long time. None of the options were insecure when they were implemented. Minsign and age have decided that their tools will only have 1 algo, the correct and most secure one. However that can change in just a few years. At which point it will either become more like PGP or we will have to migrate everyone to the new best tool. This is madness. It is better to have new versions of a standard than to extend a standard to include all possibilities. The equivalent would be making all TLS and SSL versions just extensions of the original SSL standard; a client talking to a server would negotiate between a plethora of secure and insecure cipher suites. Age uses 256-bit AES keys and the HKDF; Signify uses Ed25519 signatures. If these are found to be insecure in the coming decades, the solution would be to release a spec for Age 2 or Signify 2 instead of just adding an option to use a different combination of algos/curves/KDFs. > As you say this data is untrusted and unsigned. Having it proves nothing about the ownership of the private key. No, I didn't say that. I said that it supports both trusted and untrusted comments. Trusted comments are signed. > In the end there is not actual end user impact here, besides making it much more difficult to know if the signature of a package is valid manually. Given a source, sig, and pubkey, verification can be done with the following command: minisign -V -m %{SOURCE} -x %{SIG} -P %{public_key} This isn't any harder than using GPG unless you're using the "it's already installed" argument, which kinda proves my point about the network effects exacerbated by having a "do-it-all" tool instead of a "do-one-thing" tool. Minisign dogfoods this to sign its releases, and you can see Fedora's RPM spec use it quite easily to verify its tarball: https://src.fedoraproject.org/rpms/minisign/blob/rawhide/f/minisign.spec#_26 https://src.fedoraproject.org/rpms/minisign/blob/rawhide/f/m...