9 ms·

So I get the impression GnuPG is considered obsolete by the security community. I'm unclear for which of the many possible scenarios it can be used for. Is the

So I get the impression GnuPG is considered obsolete by the security community. I'm unclear for which of the many possible scenarios it can be used for. Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)?

shittyadmin 8y ago
It seems to me there's 2 reasons some people view it this way: - It's hard to use for normal people, it's a lot easier to hand someone Signal - It allows cipher suite changes, some of which may be weak Basically, for the purposes you're talking about, ease of use isn't a major concern, but the second one is. A dead simple Ed25519-only signing tool would be viewed as better... does such a thing exist? Certainly it's fairly easy to create one using NaCl or even the reference implementation, but nothing has the popularity of GPG.
- xur17 8y ago
  Somewhat offtopic, but I'd love something like gnupg to support deterministic key generation, similar to what BIP39 did for crypto. I currently generate keys on an offline computer, back them up to a usb driver, and the copy the keys to yubikeys. It works, but it's a PITA, and I'm always worried that I'll lose my backups despite going through a lot of effort to keep them. Deterministic key generation is one thing crypto has gotten right.
  - shittyadmin 8y ago
    It's pretty handy, but doing it for RSA and other crypto systems which rely on large primes is much harder than doing it for crypto systems which can basically use random numbers with a few safety checks just due to the nature of key derivation functions. It is possible though, I seem to remember seeing a paper on it a while back and it should be entirely achievable to do something simple like seed the rng you use for generating RSA keys with an explicit value like that. For basic signing and verifying purposes I believe Electrum and a few other clients actually include functionality for this which could be used as an alternative to PGP.
    - Leace 8y ago
      For the record GnuPG supports ed25519 keys for some time so there is no need to use RSA.
  - LeoPanthera 8y ago
    "crypto" is not short for "cryptocurrency", which is what I assume you mean. For many people it is short for "cryptography", and if read as such, makes your comment very confusing.
    - barbecue_sauce 8y ago
      It's short for both at this point. The cryptography community doesn't get to dictate the meaning of ambiguous abbreviations, despite their frustrations. I agree that its confusing in context, though.
      - SahAssar 8y ago
        In this context it'd be more prudent to use the full "cryptocurrency" though, and not use the "crypto" shortening at all.
    - xur17 8y ago
      Apologies - in this context cryptocurrencies would definitely make more sense.
- arianvanp 8y ago
  There is OpenBSDs signify which is used for their packaging: https://www.openbsd.org/papers/bsdcan-signify.html https://www.openbsd.org/papers/bsdcan-signify.html https://man.openbsd.org/signify.1 https://man.openbsd.org/signify.1 There's also a NIH version of this that I and a friend put together: https://github.com/ruuda/tako https://github.com/ruuda/tako
  - lfam 8y ago
    This is a port of OpenBSD's code: https://github.com/aperezdc/signify/ https://github.com/aperezdc/signify/
jrockway 8y ago
I feel like the whole "web of trust" thing failed, but otherwise, it's fine for signing things. Debian packages use it for that, for example (with a trusted way of bootstrapping the trusted keys).
Slackwise 8y ago
> So I get the impression GnuPG is considered obsolete by the security community. This is news to me, but I'm not in "the Security Community". I can't find anything that corroborates this. Why do you say that?
- extrapickles 8y ago
  The underlying crypto is fine (provided you don’t pick the weak algorithms) and use it correctly. What makes it ‘obsolete’ is that it lets you do bad things, like encryption without signing, messages can be partially encrypted/signed, etc. There are too many settings/options that amount to “change this to reduce security for no other benefit”. The current ideal is software that is only capable of being secure no matter how you use it.
  - tptacek 8y ago
    The underlying crypto is not really "fine". For instance, compare the PGP MDC construction to a modern authenticated cryptosystem.
    - extrapickles 8y ago
      What I meant was that the crypto primitives (the implementation of the math) is good enough for the application, the use/assembly of them (eg: the system) leaves much to be desired. This also only applies to the algorithms that are currently considered not weak.
      - tptacek 8y ago
        I'm talking about constructions, which are part of "the math".
    - sneak 8y ago
      The PBKDFs for symmetric (secring at rest and gpg -c) are also terrible. I'd love to be able to donate a few thousand dollars to a bounty to get this fixed.
rthomas6 8y ago
Can you use Keybase for this?
- bhhaskin 8y ago
  Keybase uses gpg at it's core.
  - digitaLandscape 8y ago
    Nope. Keybase supports GPG keys, but they haven't been used or generated by default for three years: https://keybase.io/blog/keybase-new-key-model https://keybase.io/blog/keybase-new-key-model There's no real reason to use GPG. Make an arbitrary scheme on top of something like NaCl and you'll probably be safer.
    - jkaplowitz 8y ago
      Please, nobody who isn't a cryptographer (to be clear: I'm not one either) should be arbitrarily inventing schemes of combining cryptographic primitives and hoping they're secure in production use cases. We'd often be wrong in such hopes, regardless of how good the underlying primitives are. We should listen to the experts in that regard, and preferably use higher-level libraries written by the experts when performing common crypto operations. This stuff is easy to get wrong.
      - tptacek 8y ago
        Nacl was designed by cryptographers for exactly this problem.
        moosingin3space 8y ago
        Additionally, NaCl/libsodium is actually designed as a misuse-resistant API to perform real-world tasks, unlike GPG, where the API is "call this binary and use its crappy out-of-band signaling mechanism to figure out if anything went wrong".
PuffinBlue 8y ago
I'm beginning to wonder if this is an artificially created theme. In every discussion about GnuPG this type of thread begins and has this type of sentiment. Maybe it is obsolete, maybe it isn't, maybe my tin foil hat is firmly in place. But it just seems like a thing people like to say to almost make sure other people don't bother trying it or using it. Maybe that's because it's difficult to use, maybe it's because it works and does do things securely and some people don't want that. There's so many sophisticated TLA's out there influencing 'the conversation' that who knows what to think anymore.
- daviross 8y ago
  I keep on seeing this sentiment of "TLAs/short-sellers/Russian content-bots/pick-a-boogeyman could possibly have an interest in this topic, so they're probably manipulating the conversation (conveniently against me and never in my favor). Who knows what to believe?, so I'm just going to continue believing what I believed before." And it's increasingly odd to me. It makes sense to an extent, it lines up with a lot of what we already know about aligned interests, what happens when you challenge someone, etc. But at the same time, it's like the possibility of 'false flag'/Sybil/conversational manipulation is letting people double down on prior beliefs (which could in itself be the goal of the same level of "maybe everyone who disagrees with me is being manipulated").
  - boomboomsubban 8y ago
    We know the intelligence agencies have had an interest in this particular topic for a long time, and that they use a variety of means to discourage the use of encryption. Whether this is one of those means is unclear, but you're still probably better off using some form of free software for your encryption, and any encryption is still better than none.
  - lmm 8y ago
    It is odd, I agree. But on this specific topic I saw a) this weird tone shift seemingly overnight - while I really don't want to make this personal, a prominent individual adopting a quite different communication style to what they'd used before. And it came coupled with b) these inconsistent arguments that just don't make sense. Signal pushers smear those who disagree as "crypto nerds" and yet perfect forward secrecy, the one advantage their system has and the thing they use to argue for all the compromises they made in every other area, is the ultimate "crypto nerd" property: it's elegant and theoretically exciting but practically almost useless (I don't think I've ever seen a threat model where it actually makes sense).
sk_hazratali 8y ago
U r right. https://marketcapcoin.blogspot.com/2018/09/bitcoin-to-money.html https://marketcapcoin.blogspot.com/2018/09/bitcoin-to-money....
blacksmith_tb 8y ago
It's certainly useful for signing github commits[1]. 1: https://help.github.com/articles/signing-commits/ https://help.github.com/articles/signing-commits/
tptacek 8y ago
For simple operations like encrypting individual files or applying a signature to a document --- where the alternatives is already insecure --- PGP is fine, if clunky. For modern message encryption, PGP is inferior to alternatives and generally should be avoided: 1. It lacks any native notion of forward secrecy or meaningful compromise recovery, which is table stakes for modern protocols. 2. Partly as a result of (1), it leaks meta-information; in particular, it's difficult to send deniable messages with it. 3. The most compatible subset of its protocols are built on 1990s cryptography, including non-AE bulk ciphers and RSA. 4. Its tooling is difficult to use, even more difficult to use with what we'd now consider adequate opsec, and far more difficult still for an ordinary person to use that way. 5. That tooling is of wildly variable quality; PGP sees somewhat routine vulnerabilities in its tools, which invariably get downplayed ("that's not a bug in PGP!"). 6. Its most mainstream use is to attempt to layer modern message security on top of email, which is its own can of worms. Generally, you should use Signal or maybe Wire (if you're a Signalphobe) in preference to PGP. For an application where it really mattered, you'd want to see a signature system derived from SHA2 and Ed25519, with no backwards-compatibility towards archaic cryptography. There's nothing mainstream that really gives you this right now, but really there isn't much (outside of blockchainia, which is already hipster-deep in modern crypto esoterica) that really demands secure digital signatures.
- nabla9 8y ago
  What are PGP alternatives for signing a document or encrypting individual files?
  - atmosx 8y ago
    Signify: https://www.openbsd.org/papers/bsdcan-signify.html https://www.openbsd.org/papers/bsdcan-signify.html
- tanderson92 8y ago
  Can you elaborate on what you mean by (1-2) leaking meta-information and making deniability difficult? Do you mean that even when choosing to encrypt but not sign I am leaking definite proof (like a signature) of my private key information in the encrypted message? That seems hard to believe unless I am misunderstanding you, because my experience is that any private key use requires auth from my Yubikey and yet I can do encryption without my yubikey plugged in at all. edit: If by deniability you're talking about PFS, then, well, don't sign something you want to be able to deny having signed. I feel your comment might be misinterpreted to be a critique of PGP encryption when really it's a critique of PFS of PGP signatures+encryption.
lmm 8y ago
> So I get the impression GnuPG is considered obsolete by the security community. This is overstated, and at the risk of tinfoil-hattery, I suspect that the NSA would very much like you to think that. > I'm unclear for which of the many possible scenarios it can be used for. It can be used for symmetric encryption, public-key encryption, and non-repudiable public-key signatures (analogous to signing a letter: you prove you signed it, but the recipient can publish that proof), with dedicated support for signing the identities of other keys ("web of trust"). Issues you may want to be aware of when using GPG in a security-critical context: Do not use non-repudiable signing protocols for signatures that you want to be repudiable, obviously. For communications where you can rely on both being online (a much narrower niche than it gets presented as, IMO) there are ratchet-based protocols for notionally non-repudiable signatures ("off the record", intended to be analogous to a phone conversation: the other party can verify that it's you at the time, but doesn't get a signature they can publish in the future) which you might prefer, though I struggle to imagine any use case in which they give a real advantage (they mean there is no cryptographic proof that you signed the messages that were seen to come from you, but there will be as much proof as there is with an unencrypted email, which in practice is usually enough for even western courts, and would certainly be enough for despotic regimes rounding up rebels etc.) Do not use obsolete algorithms (and GPG is rather more flexible about algorithm selection than it should be). There is no good library for the GPG protocol, and wrapping the binary is error-prone. For e.g. email client plugins, make sure you're using a reputable codebase that has been subject to code review. GPG's MAC construction is, while notionally sound, not as good as it should be. Where practical, avoid feeding input to GPG in an automated way and don't decrypt suspicious/unexpected messages. Cryptographic best practice is to rotate in-use keys frequently; GPG offers you the tools to do this (subkeys) but does not automate their use. Ideally you should keep your master key in cold storage and use it only to sign subkeys, which you rotate in the same way you'd rotate e.g. HTTPS certificates. While GPG has technical support for a "web of trust" it's not clear what signing a key should actually mean to a user. You should implement your own policies for which keys you trust, and be sure that anyone who you trust to attest to the validity of someone else's key is following a sufficiently stringent protocol before they sign things. Encrypted email is of course still vulnerable to traffic analysis (and public keyservers by their nature publish even more information about who may be communicating with whom); when using the ascii-based format the subject field is also unencrypted. > Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)? Not really. The above list may sound intimidating, but it's around the edges: the core of GPG is as good as it gets, and I'd trust it more than anything from the present decade. HTTPS with client certificates is probably a little better audited if you can make the client/server arrangement fit your use case and you trust the 200-odd root certificate authorities.
drdaeman 8y ago
Disclaimer: I'm not a security expert. For GnuPG there's an effort with NeoPG, although I don't know how it's regarded. Just heard the name and it is said to strive to resolve some GnuPG issues. For OpenPGP itself, I don't think it's considered obsolete. I think there are fair concerns about OpenPGP-encrypted emails (when an alternative technology is an option), but I don't have the impression PGP itself is considered obsolete.
packet_nerd 8y ago
> GnuPG is considered obsolete Not in banking anyway. It is widely used to protect ACH files and many other exchanges between banks (at least in the US).

shittyadmin 8y ago

It seems to me there's 2 reasons some people view it this way: - It's hard to use for normal people, it's a lot easier to hand someone Signal - It allows cipher suite changes, some of which may be weak Basically, for the purposes you're talking about, ease of use isn't a major concern, but the second one is. A dead simple Ed25519-only signing tool would be viewed as better... does such a thing exist? Certainly it's fairly easy to create one using NaCl or even the reference implementation, but nothing has the popularity of GPG.

xur17 8y ago
Somewhat offtopic, but I'd love something like gnupg to support deterministic key generation, similar to what BIP39 did for crypto. I currently generate keys on an offline computer, back them up to a usb driver, and the copy the keys to yubikeys. It works, but it's a PITA, and I'm always worried that I'll lose my backups despite going through a lot of effort to keep them. Deterministic key generation is one thing crypto has gotten right.
- shittyadmin 8y ago
  It's pretty handy, but doing it for RSA and other crypto systems which rely on large primes is much harder than doing it for crypto systems which can basically use random numbers with a few safety checks just due to the nature of key derivation functions. It is possible though, I seem to remember seeing a paper on it a while back and it should be entirely achievable to do something simple like seed the rng you use for generating RSA keys with an explicit value like that. For basic signing and verifying purposes I believe Electrum and a few other clients actually include functionality for this which could be used as an alternative to PGP.
  - Leace 8y ago
    For the record GnuPG supports ed25519 keys for some time so there is no need to use RSA.
- LeoPanthera 8y ago
  "crypto" is not short for "cryptocurrency", which is what I assume you mean. For many people it is short for "cryptography", and if read as such, makes your comment very confusing.
  - barbecue_sauce 8y ago
    It's short for both at this point. The cryptography community doesn't get to dictate the meaning of ambiguous abbreviations, despite their frustrations. I agree that its confusing in context, though.
    - SahAssar 8y ago
      In this context it'd be more prudent to use the full "cryptocurrency" though, and not use the "crypto" shortening at all.
  - xur17 8y ago
    Apologies - in this context cryptocurrencies would definitely make more sense.
arianvanp 8y ago
There is OpenBSDs signify which is used for their packaging: https://www.openbsd.org/papers/bsdcan-signify.html https://www.openbsd.org/papers/bsdcan-signify.html https://man.openbsd.org/signify.1 https://man.openbsd.org/signify.1 There's also a NIH version of this that I and a friend put together: https://github.com/ruuda/tako https://github.com/ruuda/tako
- lfam 8y ago
  This is a port of OpenBSD's code: https://github.com/aperezdc/signify/ https://github.com/aperezdc/signify/

jrockway 8y ago

I feel like the whole "web of trust" thing failed, but otherwise, it's fine for signing things. Debian packages use it for that, for example (with a trusted way of bootstrapping the trusted keys).

Slackwise 8y ago

> So I get the impression GnuPG is considered obsolete by the security community. This is news to me, but I'm not in "the Security Community". I can't find anything that corroborates this. Why do you say that?

extrapickles 8y ago
The underlying crypto is fine (provided you don’t pick the weak algorithms) and use it correctly. What makes it ‘obsolete’ is that it lets you do bad things, like encryption without signing, messages can be partially encrypted/signed, etc. There are too many settings/options that amount to “change this to reduce security for no other benefit”. The current ideal is software that is only capable of being secure no matter how you use it.
- tptacek 8y ago
  The underlying crypto is not really "fine". For instance, compare the PGP MDC construction to a modern authenticated cryptosystem.
  - extrapickles 8y ago
    What I meant was that the crypto primitives (the implementation of the math) is good enough for the application, the use/assembly of them (eg: the system) leaves much to be desired. This also only applies to the algorithms that are currently considered not weak.
    - tptacek 8y ago
      I'm talking about constructions, which are part of "the math".
  - sneak 8y ago
    The PBKDFs for symmetric (secring at rest and gpg -c) are also terrible. I'd love to be able to donate a few thousand dollars to a bounty to get this fixed.

rthomas6 8y ago

Can you use Keybase for this?

bhhaskin 8y ago
Keybase uses gpg at it's core.
- digitaLandscape 8y ago
  Nope. Keybase supports GPG keys, but they haven't been used or generated by default for three years: https://keybase.io/blog/keybase-new-key-model https://keybase.io/blog/keybase-new-key-model There's no real reason to use GPG. Make an arbitrary scheme on top of something like NaCl and you'll probably be safer.
  - jkaplowitz 8y ago
    Please, nobody who isn't a cryptographer (to be clear: I'm not one either) should be arbitrarily inventing schemes of combining cryptographic primitives and hoping they're secure in production use cases. We'd often be wrong in such hopes, regardless of how good the underlying primitives are. We should listen to the experts in that regard, and preferably use higher-level libraries written by the experts when performing common crypto operations. This stuff is easy to get wrong.
    - tptacek 8y ago
      Nacl was designed by cryptographers for exactly this problem.
      - moosingin3space 8y ago
        Additionally, NaCl/libsodium is actually designed as a misuse-resistant API to perform real-world tasks, unlike GPG, where the API is "call this binary and use its crappy out-of-band signaling mechanism to figure out if anything went wrong".

PuffinBlue 8y ago

I'm beginning to wonder if this is an artificially created theme. In every discussion about GnuPG this type of thread begins and has this type of sentiment. Maybe it is obsolete, maybe it isn't, maybe my tin foil hat is firmly in place. But it just seems like a thing people like to say to almost make sure other people don't bother trying it or using it. Maybe that's because it's difficult to use, maybe it's because it works and does do things securely and some people don't want that. There's so many sophisticated TLA's out there influencing 'the conversation' that who knows what to think anymore.

daviross 8y ago
I keep on seeing this sentiment of "TLAs/short-sellers/Russian content-bots/pick-a-boogeyman could possibly have an interest in this topic, so they're probably manipulating the conversation (conveniently against me and never in my favor). Who knows what to believe?, so I'm just going to continue believing what I believed before." And it's increasingly odd to me. It makes sense to an extent, it lines up with a lot of what we already know about aligned interests, what happens when you challenge someone, etc. But at the same time, it's like the possibility of 'false flag'/Sybil/conversational manipulation is letting people double down on prior beliefs (which could in itself be the goal of the same level of "maybe everyone who disagrees with me is being manipulated").
- boomboomsubban 8y ago
  We know the intelligence agencies have had an interest in this particular topic for a long time, and that they use a variety of means to discourage the use of encryption. Whether this is one of those means is unclear, but you're still probably better off using some form of free software for your encryption, and any encryption is still better than none.
- lmm 8y ago
  It is odd, I agree. But on this specific topic I saw a) this weird tone shift seemingly overnight - while I really don't want to make this personal, a prominent individual adopting a quite different communication style to what they'd used before. And it came coupled with b) these inconsistent arguments that just don't make sense. Signal pushers smear those who disagree as "crypto nerds" and yet perfect forward secrecy, the one advantage their system has and the thing they use to argue for all the compromises they made in every other area, is the ultimate "crypto nerd" property: it's elegant and theoretically exciting but practically almost useless (I don't think I've ever seen a threat model where it actually makes sense).

sk_hazratali 8y ago

U r right. https://marketcapcoin.blogspot.com/2018/09/bitcoin-to-money.html https://marketcapcoin.blogspot.com/2018/09/bitcoin-to-money....

blacksmith_tb 8y ago

It's certainly useful for signing github commits[1]. 1: https://help.github.com/articles/signing-commits/ https://help.github.com/articles/signing-commits/

tptacek 8y ago

For simple operations like encrypting individual files or applying a signature to a document --- where the alternatives is already insecure --- PGP is fine, if clunky. For modern message encryption, PGP is inferior to alternatives and generally should be avoided: 1. It lacks any native notion of forward secrecy or meaningful compromise recovery, which is table stakes for modern protocols. 2. Partly as a result of (1), it leaks meta-information; in particular, it's difficult to send deniable messages with it. 3. The most compatible subset of its protocols are built on 1990s cryptography, including non-AE bulk ciphers and RSA. 4. Its tooling is difficult to use, even more difficult to use with what we'd now consider adequate opsec, and far more difficult still for an ordinary person to use that way. 5. That tooling is of wildly variable quality; PGP sees somewhat routine vulnerabilities in its tools, which invariably get downplayed ("that's not a bug in PGP!"). 6. Its most mainstream use is to attempt to layer modern message security on top of email, which is its own can of worms. Generally, you should use Signal or maybe Wire (if you're a Signalphobe) in preference to PGP. For an application where it really mattered, you'd want to see a signature system derived from SHA2 and Ed25519, with no backwards-compatibility towards archaic cryptography. There's nothing mainstream that really gives you this right now, but really there isn't much (outside of blockchainia, which is already hipster-deep in modern crypto esoterica) that really demands secure digital signatures.

nabla9 8y ago
What are PGP alternatives for signing a document or encrypting individual files?
- atmosx 8y ago
  Signify: https://www.openbsd.org/papers/bsdcan-signify.html https://www.openbsd.org/papers/bsdcan-signify.html
tanderson92 8y ago
Can you elaborate on what you mean by (1-2) leaking meta-information and making deniability difficult? Do you mean that even when choosing to encrypt but not sign I am leaking definite proof (like a signature) of my private key information in the encrypted message? That seems hard to believe unless I am misunderstanding you, because my experience is that any private key use requires auth from my Yubikey and yet I can do encryption without my yubikey plugged in at all. edit: If by deniability you're talking about PFS, then, well, don't sign something you want to be able to deny having signed. I feel your comment might be misinterpreted to be a critique of PGP encryption when really it's a critique of PFS of PGP signatures+encryption.

lmm 8y ago

> So I get the impression GnuPG is considered obsolete by the security community. This is overstated, and at the risk of tinfoil-hattery, I suspect that the NSA would very much like you to think that. > I'm unclear for which of the many possible scenarios it can be used for. It can be used for symmetric encryption, public-key encryption, and non-repudiable public-key signatures (analogous to signing a letter: you prove you signed it, but the recipient can publish that proof), with dedicated support for signing the identities of other keys ("web of trust"). Issues you may want to be aware of when using GPG in a security-critical context: Do not use non-repudiable signing protocols for signatures that you want to be repudiable, obviously. For communications where you can rely on both being online (a much narrower niche than it gets presented as, IMO) there are ratchet-based protocols for notionally non-repudiable signatures ("off the record", intended to be analogous to a phone conversation: the other party can verify that it's you at the time, but doesn't get a signature they can publish in the future) which you might prefer, though I struggle to imagine any use case in which they give a real advantage (they mean there is no cryptographic proof that you signed the messages that were seen to come from you, but there will be as much proof as there is with an unencrypted email, which in practice is usually enough for even western courts, and would certainly be enough for despotic regimes rounding up rebels etc.) Do not use obsolete algorithms (and GPG is rather more flexible about algorithm selection than it should be). There is no good library for the GPG protocol, and wrapping the binary is error-prone. For e.g. email client plugins, make sure you're using a reputable codebase that has been subject to code review. GPG's MAC construction is, while notionally sound, not as good as it should be. Where practical, avoid feeding input to GPG in an automated way and don't decrypt suspicious/unexpected messages. Cryptographic best practice is to rotate in-use keys frequently; GPG offers you the tools to do this (subkeys) but does not automate their use. Ideally you should keep your master key in cold storage and use it only to sign subkeys, which you rotate in the same way you'd rotate e.g. HTTPS certificates. While GPG has technical support for a "web of trust" it's not clear what signing a key should actually mean to a user. You should implement your own policies for which keys you trust, and be sure that anyone who you trust to attest to the validity of someone else's key is following a sufficiently stringent protocol before they sign things. Encrypted email is of course still vulnerable to traffic analysis (and public keyservers by their nature publish even more information about who may be communicating with whom); when using the ascii-based format the subject field is also unencrypted. > Is there, right now, a better (security-wise and usability-wise) way to digitally authenticate a message (document/binary/payload)? Not really. The above list may sound intimidating, but it's around the edges: the core of GPG is as good as it gets, and I'd trust it more than anything from the present decade. HTTPS with client certificates is probably a little better audited if you can make the client/server arrangement fit your use case and you trust the 200-odd root certificate authorities.

drdaeman 8y ago

Disclaimer: I'm not a security expert. For GnuPG there's an effort with NeoPG, although I don't know how it's regarded. Just heard the name and it is said to strive to resolve some GnuPG issues. For OpenPGP itself, I don't think it's considered obsolete. I think there are fair concerns about OpenPGP-encrypted emails (when an alternative technology is an option), but I don't have the impression PGP itself is considered obsolete.

packet_nerd 8y ago

> GnuPG is considered obsolete Not in banking anyway. It is widely used to protect ACH files and many other exchanges between banks (at least in the US).