4 ms·

This has a lot of issues on even a quick skim. 1. Uses plaintext private keys in memory and has no support for yubikeys, nitrokeys, or other smartcards 2. Bin

by lrvick 4y ago

This has a lot of issues on even a quick skim. 1. Uses plaintext private keys in memory and has no support for yubikeys, nitrokeys, or other smartcards 2. Binary/commits are not signed, so there is no supply chain integrity to build or install this. Readme recommends blind execution of crypto code off the internet that may or may not be what the authors actually wrote. 3. No code review seems to be happening per git history, at least no signed code review publicly accessible. 4. Breaks OpenPGP spec and conventions for seemingly no reasons at all? 5. Rightfully mentions that you should not put a plaintext password on the CLI, then proceeds to recommend you use pass in a way that puts the password back in plaintext on the CLI via a subshell which is still totally plaintext in the proc filesystem, in ps, etc, to all processes on the system running as any user. (Unless you mount /proc with hidepid=2 but this is never a default and almost no one does it) 6. No support for Git, ssh, etc so you still need to use Sequoia or GnuPG anyway (as readme points out) This seems like a really fun and educational hobby project, but I would not seriously suggest anyone use this for anything actually security critical in its current state. To anyone that wants this functionality best-effort safely today: Get a Yubikey 5 or Nitrokey 3, put an ECC PGP keychain on it, enable touch requirements for all slots, export your keys on keyoxide, then set it up with git, ssh, pass, your email client of choice, etc. Today you can do all this with GnuPG though admittedly this is a rotting, buggy, and badly maintained c codebase. The well tested Rust replacement, Sequoia, is almost at feature parity now, so keep a close eye on that or try it today instead and see if it already meets your needs.

Ciantic 4y ago
I wish more of these alternate CLIs could act as wrappers for GPG. I would be happy to use enc if it just called GPG cli commands (or gpg agent*) underneath to do it's tasks. I know it's a boring to do wrappers, but I can't imagine using something that doesn't support GPG agent and YubiKeys / Smart cards. That infrastructures is why I think GnuPG is so much ahead of it's competition like Filippo Valsorda's age. * I have an example how to use GPG-agent to decrypt and sign things, it's almost voodoo, because there is no instructions how to do it anywhere. I had to read the GnuPG's C code to understand how to do those: https://github.com/Ciantic/gpg-ed25519-to-cv25519/blob/master/example-pkdecrypt-pksign/run.sh https://github.com/Ciantic/gpg-ed25519-to-cv25519/blob/maste...
- loudmax 4y ago
  Thanks for providing those instructions. Encryption is inherently complicated, but it seems to me that GPG is far more complicated than it should be. Extra complexity isn't just an inconvenience, it is precisely where mistakes and bugs and security breaches come from. For example, GPG has an entire logic around photo IDs. I can see the logic of using photo ID's with some authentication mechanism, but this should be in conjunction with GPG, not built into the tool itself. GPG shouldn't have a concept of photos, it's complicated enough already. Just reading the amount of options in the man page suggests that gpg ought to be broken into smaller more easily digestible components. So while I like to see wrappers around GPG (eg. Jason Donenfeld's `pass` password manager), I worry that the underlying complexity of GPG hides security holes that may surface in the future.
  - kreetx 4y ago
    What do you mean by "encryption is inherently complicated"? Conceptually, and thus in a cli frontend it should be pretty simple: you specify a message, a public key and a destination to encrypt, and then a ciphertext and a private key to decrypt. What is complicated?
    - naasking 4y ago
      The very first post in this thread you're responding to describes exactly why securing encryption is complicated.
      - kreetx 4y ago
        Does it? It says how managing keys in public key cryptography is complicated. As also signing and verification, and x509 certificates rely on this then one might say they too are complicated - as is everything else that builds on asymmetric crypto. I.e why encryption specifically is complicated? (Or am I just dense and missing something? :))
        naasking 4y ago
djha-skin 4y ago
> Today you can do all this with GnuPG though admittedly this is a rotting, buggy, and badly maintained c codebase. I don't understand why this would be called "rotting". Sure, it's old, but it's actively maintained by its original author, a Gmbh has been established around its maintenance and it retains a few developers for the purpose. We do not call the Linux operating system rotting, which is a project in a similar position to gpg, nor do we call the git project rotting. All of these are old C code bases but are actively maintained. They are in c, but they've squashed a lifetime's worth of bugs. Git is notoriously bad on the command line to use, but we still use both gpg and git because they're both useful and super stable. Calling something rotting just because it's not written in Rust ignores the years and years that their maintainers have put into it. This is to say nothing of geopolitics. It's difficult for Europe to trust anything made in America. It was for this reason that Richard Stallman encouraged Germans to make encryption software, the import of which America allowed but the import of American encryption software in the Germany was illegal. This is why Werner Koch started gpg. Sequoia seems to be made by a foundation based in America. I doubt a significant following in Europe will pick it up. Too often this sensitive topic is ignored, particularly with regard to encryption. Just recently gitea was taken over by an American corporation. The project was soft forked because the community was outraged. But they didn't change the license to AGPL, they just maintain the soft fork under a European company. The problem clearly isn't the license then, it's the country of origin. And that's just for source control. Using the original gpg is a great way to show more international unity, but we all know that's a secondary reason to use software. The primary reason is that it's a quality piece of work that will be very difficult to reproduce.
- worksonmine 4y ago
  > It's difficult for Europe to trust anything made in America. It was for this reason that Richard Stallman encouraged Germans to make encryption software, the import of which America allowed but the import of American encryption software in the Germany was illegal. This is why Werner Koch started gpg. Nitpicking but I think you got this part the wrong way around. The US had export restrictions on encryption including PGP so Europe had to create their own.
  - 4y ago
wizeman 4y ago
> 5. Rightfully mentions that you should not put a plaintext password on the CLI, then proceeds to recommend you use pass in a way that puts the password back in plaintext on the CLI via a subshell which is still totally plaintext in the proc filesystem, in ps, etc, to all processes on the system running as any user. Not to mention that the password will also get stored in plaintext in the shell's history file if the shell is in interactive mode.
TacticalCoder 4y ago
> To anyone that wants this functionality best-effort safely today: Get a Yubikey 5 or Nitrokey 3, put an ECC PGP keychain on it, enable touch requirements for all slots, export your keys on keyoxide, then set it up with git, ssh, pass, your email client of choice, etc. But SSH now supports U2F for any FIDO or FIDO2 security key AFAICT (no need to specifically a Yubikey 5 or Nitrokey 3): it's unrelated to GPG. Isn't it better to directly use this new SSH functionality inside of using the more complicated GnuPG+SSH thing? (I'm asking: I've got no clue how the later works). Any thoughts/explanation on this is most welcome. > (Unless you mount /proc with hidepid=2 but this is never a default and almost no one does it) Ah! I do it on all my systems! (not that it'd be a reason to have passwords in plaintext everywhere)
- lrvick 4y ago
  > Isn't it better to directly use this new SSH functionality inside of using the more complicated GnuPG+SSH thing? (I'm asking: I've got no clue how the later works). If the only thing you need from a smartcard is ssh, and you do not need to convince others your public key is really yours, then FIDO2 ssh is great. That said, if someone is to add my key to their server, exporting my ssh key from my published, and well signed PGP keychain is the easiest way to form trust they got the correct key. Also you cannot do things like file decryption or signed commits with a fido2 device. Since virtually every developer (imo) needs those coming from a hardware anchor, and they require PGP, might as well use one spec that does everything and publishes one public keychain for others to trust.
khalidx 4y ago
Disclaimer: excuse my ignorance but this is an honest question. Regarding “1. Uses plaintext private keys in memory and has no support for yubikeys, nitrokeys, or other smartcards”. What is the alternative? Aren’t secrets in memory always plaintext unless you are using something external like a hardware security module chip?
- lrvick 4y ago
  Using a yubikey, nitrokey, etc as I suggest would ensure the private key never leaves the external device. Those are personal HSMs.
zikduruqe 4y ago
> To anyone that wants this functionality best-effort safely today: Get a Yubikey 5 or Nitrokey 3, put an ECC PGP keychain on it, enable touch requirements for all slots, export your keys on keyoxide, then set it up with git, ssh, pass, your email client of choice, etc. Welp, my machine must be comprised, because you just described it. But you left out Age...
- lrvick 4y ago
  Age is actually -worse- than enc by pretty much all the same criteria I outlined. Working with established interoperable standards and conventions for hardware support, software support, key discovery, and supply chain integrity and implementing them well with careful team code review and extensive compatibility test suite is the hard but necessary road in security. Age does not even attempt to do any of this, and IMO only has very niche use cases, if any, compared to a reasonable OpenPGP spec implementation like Sequoia.

by lrvick 4y ago

Ciantic 4y ago

I wish more of these alternate CLIs could act as wrappers for GPG. I would be happy to use enc if it just called GPG cli commands (or gpg agent*) underneath to do it's tasks. I know it's a boring to do wrappers, but I can't imagine using something that doesn't support GPG agent and YubiKeys / Smart cards. That infrastructures is why I think GnuPG is so much ahead of it's competition like Filippo Valsorda's age. * I have an example how to use GPG-agent to decrypt and sign things, it's almost voodoo, because there is no instructions how to do it anywhere. I had to read the GnuPG's C code to understand how to do those: https://github.com/Ciantic/gpg-ed25519-to-cv25519/blob/master/example-pkdecrypt-pksign/run.sh https://github.com/Ciantic/gpg-ed25519-to-cv25519/blob/maste...

loudmax 4y ago
Thanks for providing those instructions. Encryption is inherently complicated, but it seems to me that GPG is far more complicated than it should be. Extra complexity isn't just an inconvenience, it is precisely where mistakes and bugs and security breaches come from. For example, GPG has an entire logic around photo IDs. I can see the logic of using photo ID's with some authentication mechanism, but this should be in conjunction with GPG, not built into the tool itself. GPG shouldn't have a concept of photos, it's complicated enough already. Just reading the amount of options in the man page suggests that gpg ought to be broken into smaller more easily digestible components. So while I like to see wrappers around GPG (eg. Jason Donenfeld's `pass` password manager), I worry that the underlying complexity of GPG hides security holes that may surface in the future.
- kreetx 4y ago
  What do you mean by "encryption is inherently complicated"? Conceptually, and thus in a cli frontend it should be pretty simple: you specify a message, a public key and a destination to encrypt, and then a ciphertext and a private key to decrypt. What is complicated?
  - naasking 4y ago
    The very first post in this thread you're responding to describes exactly why securing encryption is complicated.
    - kreetx 4y ago
      Does it? It says how managing keys in public key cryptography is complicated. As also signing and verification, and x509 certificates rely on this then one might say they too are complicated - as is everything else that builds on asymmetric crypto. I.e why encryption specifically is complicated? (Or am I just dense and missing something? :))
      - naasking 4y ago

djha-skin 4y ago

> Today you can do all this with GnuPG though admittedly this is a rotting, buggy, and badly maintained c codebase. I don't understand why this would be called "rotting". Sure, it's old, but it's actively maintained by its original author, a Gmbh has been established around its maintenance and it retains a few developers for the purpose. We do not call the Linux operating system rotting, which is a project in a similar position to gpg, nor do we call the git project rotting. All of these are old C code bases but are actively maintained. They are in c, but they've squashed a lifetime's worth of bugs. Git is notoriously bad on the command line to use, but we still use both gpg and git because they're both useful and super stable. Calling something rotting just because it's not written in Rust ignores the years and years that their maintainers have put into it. This is to say nothing of geopolitics. It's difficult for Europe to trust anything made in America. It was for this reason that Richard Stallman encouraged Germans to make encryption software, the import of which America allowed but the import of American encryption software in the Germany was illegal. This is why Werner Koch started gpg. Sequoia seems to be made by a foundation based in America. I doubt a significant following in Europe will pick it up. Too often this sensitive topic is ignored, particularly with regard to encryption. Just recently gitea was taken over by an American corporation. The project was soft forked because the community was outraged. But they didn't change the license to AGPL, they just maintain the soft fork under a European company. The problem clearly isn't the license then, it's the country of origin. And that's just for source control. Using the original gpg is a great way to show more international unity, but we all know that's a secondary reason to use software. The primary reason is that it's a quality piece of work that will be very difficult to reproduce.

worksonmine 4y ago
> It's difficult for Europe to trust anything made in America. It was for this reason that Richard Stallman encouraged Germans to make encryption software, the import of which America allowed but the import of American encryption software in the Germany was illegal. This is why Werner Koch started gpg. Nitpicking but I think you got this part the wrong way around. The US had export restrictions on encryption including PGP so Europe had to create their own.
- 4y ago

wizeman 4y ago

> 5. Rightfully mentions that you should not put a plaintext password on the CLI, then proceeds to recommend you use pass in a way that puts the password back in plaintext on the CLI via a subshell which is still totally plaintext in the proc filesystem, in ps, etc, to all processes on the system running as any user. Not to mention that the password will also get stored in plaintext in the shell's history file if the shell is in interactive mode.

TacticalCoder 4y ago

> To anyone that wants this functionality best-effort safely today: Get a Yubikey 5 or Nitrokey 3, put an ECC PGP keychain on it, enable touch requirements for all slots, export your keys on keyoxide, then set it up with git, ssh, pass, your email client of choice, etc. But SSH now supports U2F for any FIDO or FIDO2 security key AFAICT (no need to specifically a Yubikey 5 or Nitrokey 3): it's unrelated to GPG. Isn't it better to directly use this new SSH functionality inside of using the more complicated GnuPG+SSH thing? (I'm asking: I've got no clue how the later works). Any thoughts/explanation on this is most welcome. > (Unless you mount /proc with hidepid=2 but this is never a default and almost no one does it) Ah! I do it on all my systems! (not that it'd be a reason to have passwords in plaintext everywhere)

lrvick 4y ago
> Isn't it better to directly use this new SSH functionality inside of using the more complicated GnuPG+SSH thing? (I'm asking: I've got no clue how the later works). If the only thing you need from a smartcard is ssh, and you do not need to convince others your public key is really yours, then FIDO2 ssh is great. That said, if someone is to add my key to their server, exporting my ssh key from my published, and well signed PGP keychain is the easiest way to form trust they got the correct key. Also you cannot do things like file decryption or signed commits with a fido2 device. Since virtually every developer (imo) needs those coming from a hardware anchor, and they require PGP, might as well use one spec that does everything and publishes one public keychain for others to trust.

khalidx 4y ago

Disclaimer: excuse my ignorance but this is an honest question. Regarding “1. Uses plaintext private keys in memory and has no support for yubikeys, nitrokeys, or other smartcards”. What is the alternative? Aren’t secrets in memory always plaintext unless you are using something external like a hardware security module chip?

lrvick 4y ago
Using a yubikey, nitrokey, etc as I suggest would ensure the private key never leaves the external device. Those are personal HSMs.

zikduruqe 4y ago

lrvick 4y ago
Age is actually -worse- than enc by pretty much all the same criteria I outlined. Working with established interoperable standards and conventions for hardware support, software support, key discovery, and supply chain integrity and implementing them well with careful team code review and extensive compatibility test suite is the hard but necessary road in security. Age does not even attempt to do any of this, and IMO only has very niche use cases, if any, compared to a reasonable OpenPGP spec implementation like Sequoia.