5 ms·

Some problems PGP (these days, this means GnuPG) solves pretty well for me: - offline encryption; - distributed web of trust; - digital signature (for messag

Some problems PGP (these days, this means GnuPG) solves pretty well for me: - offline encryption; - distributed web of trust; - digital signature (for messages and software packages); - batch processing; - certification of other users without a server at all; - ability to use a completely "offline" infrastructure; - sending messages without revealing the actual recipient (i.e. --hidden-recipient) - multiplatform; - easy to integrate in another applications and scripts; - allowing independent encryption, signature and certification keys but using them together (i.e. I receive an encrypted message that was signed with a key certified by another key. The system must correctly detect and use the certification-only key already in my keystore); - allows copying and pasting the data (messages, keys, etc.) in an email; - open source and well tested implementations; - not forcing me to use it in a mobile phone; - for god sake, not being an Electron app! - ideally, all this in a single package. People keep distilling an irrational hate on OpenPGP but their proposals can't handle all these use cases. Of course, they handle some small subset very well, but none covers all of them (e.g. Signal does pretty good when I need to exchange short mobile messages, but it is of no help when I need to push a few 30 MB files from my mobile phone to GDrive without giving Google all their contents).

tptacek 8y ago
Of your list, the alternatives that George provided check off: - offline encryption - digital signatures - batch processing - no server - offline infrastructure - "hidden recipient" (which, ironically, is a command line flag to mitigate a flaw in PGP, and not in fact a feature of PGP) - multiplatform - easy to integrate - copying and pasting ciphertext - open source and well-tested - not bound to phones - not being an electron app The things you don't get with these alternatives are flaws, not features, like "all being in one application". You're making George's case for him. I'd recommend reading his article again, and then following the links.
- pera 8y ago
  > The things you don't get with these alternatives are flaws, not features, like "all being in one application". I believe what the parent likes about "all in a single package" is the practicality and simplicity that this brings to the user: you could either just install gpg and read the man, or review tens of different relatively new applications (none of them widely used, yet) for each step of your normal workflow, learning their different interfaces and quirks, and then keeping yourself updated of any new disclosed vulnerability that may affect your custom crypto tool set. Obviously a small application that only do one thing hopefully right should be, at least in principle, easier to maintain and audit (and therefor safer) than the ol' swiss army knife of cryptographic communications, but the convenience of all-in-one is also a reality that shouldn't be overlooked.
- AgentME 8y ago
  My frustration is that a lot of the solutions provided are raw libraries rather than end-user tools. For offline encryption, how do I encrypt a file with a password (or a keyfile)? The solutions provided are a few Go libraries, saltpack (which I think is only a spec? I couldn't find an executable), and then the Keybase service. None of these work as a simple no-strings-attached end-user replacement for `gpg -c`. This article didn't give enough for me to take `gpg -c` out of my bag of tricks. (And I do want something to replace it with! It frustrates me that it defaults to a weak password hash and AES-128 without authentication.) Maybe the article should mention scrypt (https://www.tarsnap.com/scrypt.html https://www.tarsnap.com/scrypt.html) as a tool for password-based offline encryption/decryption. That tool seems like it might be a good replacement for `gpg -c`. It is frustrating though because its name is almost un-googleable (most results just talk about "scrypt" as a hashing function, rather than "scrypt" the encryption tool! It really needs a better name) and I rarely see it mentioned. It doesn't even seem to have a recommend file extension for encrypted data, which bothers me possibly more than it should. Its files aren't recognizable. Magic wormhole is extremely cool though and does replace a big subset of my GPG usage.
  - ahazred8ta 8y ago
    And https://github.com/postboy/cpwd https://github.com/postboy/cpwd is a full password manager that uses tarsnap's scrypt. O:-) So at least we know it can be done. The scrypt utility describes itself as a demo with some rough edges, ymmv.
  - cperciva 8y ago
    It is frustrating though because its name is almost un-googleable (most results just talk about "scrypt" as a hashing function, rather than "scrypt" the encryption tool! It really needs a better name) and I rarely see it mentioned. Don't blame me! The encryption tool came first!
  - acqq 8y ago
    > That tool seems like it might be a good replacement for `gpg -c` The tool still can't be compiled under MinGW-w64: ./libcperciva/util/getopt.h:35:2: error: unknown type name 'sigjmp_buf'; did you mean 'jmp_buf'? That is, there's no executable that can run natively on Windows. To compare, Git compiles and runs natively. (I've once tried to remove the dependencies in the code, step by step, but after each step something more would be visible, so I gave up. I also don't know if it would run under Cygwin.) Of course I don't expect the compatibility from the author, I just state that I'm not aware that the Windows version even exists, and that it limits the possibilities of the use of the tool. > My frustration is that a lot of the solutions provided are raw libraries rather than end-user tools. I fully agree with you. There's effectively no replacement for gpg -c as far as I see. https://godoc.org/golang.org/x/crypto/nacl/secretbox https://godoc.org/golang.org/x/crypto/nacl/secretbox "It is the caller's responsibility to ensure the uniqueness of nonces" "Thus large amounts of data should be chunked so that each message is small. (Each message still needs a unique nonce.) If in doubt, 16KB is a reasonable chunk size." It's far from being anything that can be immediately and safely used even if one were willing to use Go to compile it. Which is sad, as gpg -c is such a basic functionality, and gpg is definitely too big and potentially problematic tool for that purpose (for years defaults of gpg -c were almost insecure, and even now it's hard, or maybe impossible, to achieve the quality that some much smaller tool could, if it existed). My own wish: a tool that fits into single binary so that it can be easily inspected, ideally the binary itself is also as small as possible and doesn't depend on unnecessary shared libraries, uses only one algorithm of everything, but according to the best knowledge we have today. If the algorithms have to be changed to the level of incompatibility, a new tool is released (e.g tool has compatible versions 1.x until the produced files can be opened with the new version, as soon as the format changes the versions go 2.x etc, but every format version is a self contained tool which can be completely easily inspected because it supports only one format and one algorithm per purpose). And it's truly multiplatform. gpg is just too big now, but I don't know what can replace it at this moment.
- thaumasiotes 8y ago
  > "hidden recipient" (which, ironically, is a command line flag to mitigate a flaw in PGP, and not in fact a feature of PGP) I don't understand. --encrypt and --decrypt are command line flags too, but surely those count as features.

tptacek 8y ago

Of your list, the alternatives that George provided check off: - offline encryption - digital signatures - batch processing - no server - offline infrastructure - "hidden recipient" (which, ironically, is a command line flag to mitigate a flaw in PGP, and not in fact a feature of PGP) - multiplatform - easy to integrate - copying and pasting ciphertext - open source and well-tested - not bound to phones - not being an electron app The things you don't get with these alternatives are flaws, not features, like "all being in one application". You're making George's case for him. I'd recommend reading his article again, and then following the links.

pera 8y ago
> The things you don't get with these alternatives are flaws, not features, like "all being in one application". I believe what the parent likes about "all in a single package" is the practicality and simplicity that this brings to the user: you could either just install gpg and read the man, or review tens of different relatively new applications (none of them widely used, yet) for each step of your normal workflow, learning their different interfaces and quirks, and then keeping yourself updated of any new disclosed vulnerability that may affect your custom crypto tool set. Obviously a small application that only do one thing hopefully right should be, at least in principle, easier to maintain and audit (and therefor safer) than the ol' swiss army knife of cryptographic communications, but the convenience of all-in-one is also a reality that shouldn't be overlooked.
AgentME 8y ago
My frustration is that a lot of the solutions provided are raw libraries rather than end-user tools. For offline encryption, how do I encrypt a file with a password (or a keyfile)? The solutions provided are a few Go libraries, saltpack (which I think is only a spec? I couldn't find an executable), and then the Keybase service. None of these work as a simple no-strings-attached end-user replacement for `gpg -c`. This article didn't give enough for me to take `gpg -c` out of my bag of tricks. (And I do want something to replace it with! It frustrates me that it defaults to a weak password hash and AES-128 without authentication.) Maybe the article should mention scrypt (https://www.tarsnap.com/scrypt.html https://www.tarsnap.com/scrypt.html) as a tool for password-based offline encryption/decryption. That tool seems like it might be a good replacement for `gpg -c`. It is frustrating though because its name is almost un-googleable (most results just talk about "scrypt" as a hashing function, rather than "scrypt" the encryption tool! It really needs a better name) and I rarely see it mentioned. It doesn't even seem to have a recommend file extension for encrypted data, which bothers me possibly more than it should. Its files aren't recognizable. Magic wormhole is extremely cool though and does replace a big subset of my GPG usage.
- ahazred8ta 8y ago
  And https://github.com/postboy/cpwd https://github.com/postboy/cpwd is a full password manager that uses tarsnap's scrypt. O:-) So at least we know it can be done. The scrypt utility describes itself as a demo with some rough edges, ymmv.
- cperciva 8y ago
  It is frustrating though because its name is almost un-googleable (most results just talk about "scrypt" as a hashing function, rather than "scrypt" the encryption tool! It really needs a better name) and I rarely see it mentioned. Don't blame me! The encryption tool came first!
- acqq 8y ago
  > That tool seems like it might be a good replacement for `gpg -c` The tool still can't be compiled under MinGW-w64: ./libcperciva/util/getopt.h:35:2: error: unknown type name 'sigjmp_buf'; did you mean 'jmp_buf'? That is, there's no executable that can run natively on Windows. To compare, Git compiles and runs natively. (I've once tried to remove the dependencies in the code, step by step, but after each step something more would be visible, so I gave up. I also don't know if it would run under Cygwin.) Of course I don't expect the compatibility from the author, I just state that I'm not aware that the Windows version even exists, and that it limits the possibilities of the use of the tool. > My frustration is that a lot of the solutions provided are raw libraries rather than end-user tools. I fully agree with you. There's effectively no replacement for gpg -c as far as I see. https://godoc.org/golang.org/x/crypto/nacl/secretbox https://godoc.org/golang.org/x/crypto/nacl/secretbox "It is the caller's responsibility to ensure the uniqueness of nonces" "Thus large amounts of data should be chunked so that each message is small. (Each message still needs a unique nonce.) If in doubt, 16KB is a reasonable chunk size." It's far from being anything that can be immediately and safely used even if one were willing to use Go to compile it. Which is sad, as gpg -c is such a basic functionality, and gpg is definitely too big and potentially problematic tool for that purpose (for years defaults of gpg -c were almost insecure, and even now it's hard, or maybe impossible, to achieve the quality that some much smaller tool could, if it existed). My own wish: a tool that fits into single binary so that it can be easily inspected, ideally the binary itself is also as small as possible and doesn't depend on unnecessary shared libraries, uses only one algorithm of everything, but according to the best knowledge we have today. If the algorithms have to be changed to the level of incompatibility, a new tool is released (e.g tool has compatible versions 1.x until the produced files can be opened with the new version, as soon as the format changes the versions go 2.x etc, but every format version is a self contained tool which can be completely easily inspected because it supports only one format and one algorithm per purpose). And it's truly multiplatform. gpg is just too big now, but I don't know what can replace it at this moment.
thaumasiotes 8y ago
> "hidden recipient" (which, ironically, is a command line flag to mitigate a flaw in PGP, and not in fact a feature of PGP) I don't understand. --encrypt and --decrypt are command line flags too, but surely those count as features.