15 ms·

GnuPG can now be used to perform notarial acts in the State of Washington

711 points by Boulth 8y ago

AceJohnny2 8y ago
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).
jwr 8y ago
Incidentally, I've been working with digital signatures which are legally equivalent to traditional ones in my country (Poland) and comparing them to a GnuPG setup with private keys stored on a YubiKey. It seems to me that my YubiKey setup (done following https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide) is substantially better in almost every respect than the state-provided smartcard. I intend to publish a signed PDF document (signed with the state-certified RSA key) that says that my GnuPG keys are really mine.
- Boulth 8y ago
  > It seems to me that my YubiKey setup (done following https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide) is substantially better in almost every respect than the state-provided smartcard. Would you care to explain the differences in detail? As far as I know the EU qualified certs are also required to be stored on smartcards so the only difference vs Yubikey would be Yubikey's portable format (it is a smartcard reader and a smartcard in one device).
  - jwr 8y ago
    Perhaps not in detail, but in general outline: * I was able to generate my GnuPG keys myself and I know (to the extent that I trust my computing environment) that I am the only one to have access to the secret key(s), * the state-approved qualified cert is only a single RSA key, for signatures, * you don't get to make a backup of that key, * as a result, it can't really be used for anything else than signing documents, so forget about encrypting data or using it for authentication for example (cases where you really do need to have backups), * the key is stored on a physically inconvenient device (smartcard) and you need to have one and only one of those, Plus, of course you get the whole beauty of crappy PKI infrastructure (why does every company dealing with certs have to be shady, have a crappy website and in general be a mess?). But that is beside the point, I guess.
    - dcbadacd 8y ago
      Just for comparison the Estonian system: * As far as I know upon cert renewal the new cert is generated on your computer, uploaded to the card and then deleted - you could theoretically intercept that but I don't see why you would - the key is more secure on the card * The state-approved certs one is for e-identification (when PIN is entered also authentication), other for signing (AFAIK not RSA but EC) * See point one * Encrypting data can be done but as the software warns, it's to protect the data during transit not when idle and nothing is stopping me from using the card daily to log into my bank and other services I need to use * The key is stored on the smart card but you can get multiple (AFAIK at least for e-identification). Don't know much about the Estonian PKI infrastructure though and it seems stable enough for daily use without any noticeable hiccups.
scrollaway 8y ago
This sounds huge. There's entire businesses centered around very specific state laws like this (cf. notarize.com). I hope this spreads. As long as notarization remains important, digital notarization is important.
ZainRiz 8y ago
Notarizing documents sounds like it could actually benefit from blockchain technology. Have a set of Established Authorities who can grant notary status. They give notary status to people according to their own set of requirements. The notaries can then add a record on the block chain saying roughly "I do notarization act X on document Y" (It'll be the equivalent of what they enter in their log books today and there will be some corresponding stamp that they'll stamp the physical document with, like they do today). They could now even notarize digital documents by including a hash of the digitized document in their record. Finally, the agency receiving the notarized document (digital or electronic) can easily go onto the blockchain and verify that the document was indeed notarized as claimed and that the notarization is not a forgery. Each agency that receives the notarized document could have their own subset of Established Authorities who's notaries they will accept. This means anyone could become an Established Authority, but individual agencies like the US Federal Government could publicly say "hey, our Authority Id is 'USRoxs'" but it'll be up to the receiving agencies like England's government to decide "We trust the system the US uses to validate it's notiaries, so we'll add 'USRoxs' to our list of accepted Established Authorities (along with 'TheEnglish' of course)"
- onli 8y ago
  Notarizing documents is a great example where some people think blockchain is a good use case, and it's never true. Where would be the advantage of the scheme you describe to the current system? There is none. The system already works: people are given power to validate documents by the authority. The authority stores that centrally. The validation is mostly collected centrally. All stuff you can do perfectly fine without needing to run replicated servers storing an evergrowing immutable blockchain sipping authority from the real authority. The current scheme allows things like secret notarization and revocation, stuff a blockchain is very bad at. > it'll be up to the receiving agencies like England's government to decide "We trust the system the US uses to validate it's notiaries, so we'll add 'USRoxs' to our list of accepted Established Authorities (along with 'TheEnglish' of course)" Countries already have systems in place to accept documents made in other countries. Works with official translators and stamps/seals of authenticity. In better and funny: Blockchains Are a Bad Idea (James Mickens), https://www.youtube.com/watch?v=15RTC22Z2xI https://www.youtube.com/watch?v=15RTC22Z2xI
otohp 8y ago
Matthew Green had a good post on what is wrong with PGP: https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma...
- confounded 8y ago
  GnuPGP can be used for a lot more than encrypted emails (the subject of that post). Is there anything wrong with notaries being able to use GnuPGP?
  - otohp 8y ago
    No idea.
sam0x17 8y ago
This is extremely cool, but I wonder in practice whether people in Washington who accept notarized documents/etc would know this is a valid way of doing things? Education seems important here.
badrabbit 8y ago
PGP is an alright protocol but I cannot recommend gpg for daily use by non-technical users. They make it extremely difficult to use long-term and simple issues like gpg-agent running as a background process become controversies where they could have just made it optional. Honestly,I think it's an alright piece of software but the project became the way it is as a result of the massive gnupg adoption in the *nix world and lack of competition. If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen. As much as the cryptonerd in me likes this news,Gnupg as it is shouldn't be used for official matters. Most lawyers and judges would struggle to use it.
- x220 8y ago
  >If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen You will never have cross-platform and user friendly signing software that also has bulletproof security. Let the people who are skilled enough to know what they are doing continue using GnuPG.
  - lfam 8y ago
    Why won't we ever have cross-platform and usre friendly signing software that also has bulletproof security? We already have many programs that are cross-platform and user-friendly while also addressing way more complicated use cases than cryptographic singing.
  - packet_nerd 8y ago
    This is the exact attitude that has gotten us where we are today (as in, pervasive bad security). "Do what you've always done, you'll get what you always got."
    - x220 8y ago
      I disagree. It is possible to make decent, good, and perhaps great security that is easy to teach and not too inconvenient that users will rebel. I think it is unreasonable to keep someone from using GnuPG in a legal fashion because average people cannot use it. You will never find signing software with sufficiently bulletproof security that average people can use. To suggest such also implies that average people need to regularly perform notarial acts, which I think is imaginative.
dcbadacd 8y ago
I've used both GNPG and Estonian eID. I have to say Estonian eID is way more usable when one needs to sign anything. The (digidoc4) software is just way more usable, nicer and designed for the task. I wish GNUPG were as good
lrvick 8y ago
Dupe of: https://news.ycombinator.com/item?id=18013182 https://news.ycombinator.com/item?id=18013182
unixhero 8y ago
All it needs now is a solid blockchain. Vechain could be one perhaps.
- DINKDINK 8y ago
  What do you need a blockchain for? Blockchains are necessary when you need: Proof of publication Trustless time stamping Trustless transaction execution.
  - toomanybeersies 8y ago
    Trustless time stamping seems to be a good thing to have for notarising.
    - confounded 8y ago
      Isn’t trusting the notary the whole point?
      - toomanybeersies 8y ago
        Quis custodiet ipsos custodes? Who will watch the watchmen?
    - DINKDINK 8y ago
      If one needs proof of existence features, bitcoin already delivers this trustlessly at scale: https://opentimestamps.org/ https://opentimestamps.org/ You merkle hash effectively limitless data into a single bitcoin transaction. No need to spin up a new (and likely inefficient blockchain) to do notary tasks.
  - leumas 8y ago
    You would use it to add a dimension of time to the signatures. This allows for revoking/replacing keys while still keeping past messages valid. At work we've ben implementing a system like this where an identity is made up of a hierarchy of keys. Let's say you have 2 key pairs as part of your identity. You sign a message with key 2 and publish it on the blockchain at block height H. Then at some point in the future, you lose the private part of key 2 or it becomes compromised. So now you sign a message with key 1 that says "replace key 2 with key 3 from this point on" and you publish it to the blockchain. Now, any messages signed with key 2 before the replacement can still be deemed valid, but any future messages signed with the compromised key will not be valid.
aj7 8y ago
In theory, FedEx overnight envelopes, their most lucrative business, just died in Washington state. Am I right?
openloop 8y ago
I like it.
nwroot 8y ago
This is great progress for other locations as well!
sabujp 8y ago
tldr; do i still need to pay a notary or can i self attest using a gpg key tied to my email address?
djsumdog 8y ago
Docusign has been allowed to be used a notary in Washington; or at least Seattle for notary requirements around housing documents. (Seattle law requires notarization on leases over 12 months). There's a PGP short ID listed on the e-signed document, but it's not yours. There is no point where Docusign checks your ID.
cjcollier 8y ago
That's pretty cool, bro.

711 points by Boulth 8y ago

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).

jwr 8y ago

Incidentally, I've been working with digital signatures which are legally equivalent to traditional ones in my country (Poland) and comparing them to a GnuPG setup with private keys stored on a YubiKey. It seems to me that my YubiKey setup (done following https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide) is substantially better in almost every respect than the state-provided smartcard. I intend to publish a signed PDF document (signed with the state-certified RSA key) that says that my GnuPG keys are really mine.

Boulth 8y ago
> It seems to me that my YubiKey setup (done following https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide) is substantially better in almost every respect than the state-provided smartcard. Would you care to explain the differences in detail? As far as I know the EU qualified certs are also required to be stored on smartcards so the only difference vs Yubikey would be Yubikey's portable format (it is a smartcard reader and a smartcard in one device).
- jwr 8y ago
  Perhaps not in detail, but in general outline: * I was able to generate my GnuPG keys myself and I know (to the extent that I trust my computing environment) that I am the only one to have access to the secret key(s), * the state-approved qualified cert is only a single RSA key, for signatures, * you don't get to make a backup of that key, * as a result, it can't really be used for anything else than signing documents, so forget about encrypting data or using it for authentication for example (cases where you really do need to have backups), * the key is stored on a physically inconvenient device (smartcard) and you need to have one and only one of those, Plus, of course you get the whole beauty of crappy PKI infrastructure (why does every company dealing with certs have to be shady, have a crappy website and in general be a mess?). But that is beside the point, I guess.
  - dcbadacd 8y ago
    Just for comparison the Estonian system: * As far as I know upon cert renewal the new cert is generated on your computer, uploaded to the card and then deleted - you could theoretically intercept that but I don't see why you would - the key is more secure on the card * The state-approved certs one is for e-identification (when PIN is entered also authentication), other for signing (AFAIK not RSA but EC) * See point one * Encrypting data can be done but as the software warns, it's to protect the data during transit not when idle and nothing is stopping me from using the card daily to log into my bank and other services I need to use * The key is stored on the smart card but you can get multiple (AFAIK at least for e-identification). Don't know much about the Estonian PKI infrastructure though and it seems stable enough for daily use without any noticeable hiccups.

scrollaway 8y ago

This sounds huge. There's entire businesses centered around very specific state laws like this (cf. notarize.com). I hope this spreads. As long as notarization remains important, digital notarization is important.

ZainRiz 8y ago

Notarizing documents sounds like it could actually benefit from blockchain technology. Have a set of Established Authorities who can grant notary status. They give notary status to people according to their own set of requirements. The notaries can then add a record on the block chain saying roughly "I do notarization act X on document Y" (It'll be the equivalent of what they enter in their log books today and there will be some corresponding stamp that they'll stamp the physical document with, like they do today). They could now even notarize digital documents by including a hash of the digitized document in their record. Finally, the agency receiving the notarized document (digital or electronic) can easily go onto the blockchain and verify that the document was indeed notarized as claimed and that the notarization is not a forgery. Each agency that receives the notarized document could have their own subset of Established Authorities who's notaries they will accept. This means anyone could become an Established Authority, but individual agencies like the US Federal Government could publicly say "hey, our Authority Id is 'USRoxs'" but it'll be up to the receiving agencies like England's government to decide "We trust the system the US uses to validate it's notiaries, so we'll add 'USRoxs' to our list of accepted Established Authorities (along with 'TheEnglish' of course)"

onli 8y ago
Notarizing documents is a great example where some people think blockchain is a good use case, and it's never true. Where would be the advantage of the scheme you describe to the current system? There is none. The system already works: people are given power to validate documents by the authority. The authority stores that centrally. The validation is mostly collected centrally. All stuff you can do perfectly fine without needing to run replicated servers storing an evergrowing immutable blockchain sipping authority from the real authority. The current scheme allows things like secret notarization and revocation, stuff a blockchain is very bad at. > it'll be up to the receiving agencies like England's government to decide "We trust the system the US uses to validate it's notiaries, so we'll add 'USRoxs' to our list of accepted Established Authorities (along with 'TheEnglish' of course)" Countries already have systems in place to accept documents made in other countries. Works with official translators and stamps/seals of authenticity. In better and funny: Blockchains Are a Bad Idea (James Mickens), https://www.youtube.com/watch?v=15RTC22Z2xI https://www.youtube.com/watch?v=15RTC22Z2xI

otohp 8y ago

Matthew Green had a good post on what is wrong with PGP: https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma...

confounded 8y ago
GnuPGP can be used for a lot more than encrypted emails (the subject of that post). Is there anything wrong with notaries being able to use GnuPGP?
- otohp 8y ago
  No idea.

sam0x17 8y ago

This is extremely cool, but I wonder in practice whether people in Washington who accept notarized documents/etc would know this is a valid way of doing things? Education seems important here.

badrabbit 8y ago

PGP is an alright protocol but I cannot recommend gpg for daily use by non-technical users. They make it extremely difficult to use long-term and simple issues like gpg-agent running as a background process become controversies where they could have just made it optional. Honestly,I think it's an alright piece of software but the project became the way it is as a result of the massive gnupg adoption in the *nix world and lack of competition. If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen. As much as the cryptonerd in me likes this news,Gnupg as it is shouldn't be used for official matters. Most lawyers and judges would struggle to use it.

x220 8y ago
>If it isn't cross-platform and user friendly,it shouldn't be used by the average citizen You will never have cross-platform and user friendly signing software that also has bulletproof security. Let the people who are skilled enough to know what they are doing continue using GnuPG.
- lfam 8y ago
  Why won't we ever have cross-platform and usre friendly signing software that also has bulletproof security? We already have many programs that are cross-platform and user-friendly while also addressing way more complicated use cases than cryptographic singing.
- packet_nerd 8y ago
  This is the exact attitude that has gotten us where we are today (as in, pervasive bad security). "Do what you've always done, you'll get what you always got."
  - x220 8y ago
    I disagree. It is possible to make decent, good, and perhaps great security that is easy to teach and not too inconvenient that users will rebel. I think it is unreasonable to keep someone from using GnuPG in a legal fashion because average people cannot use it. You will never find signing software with sufficiently bulletproof security that average people can use. To suggest such also implies that average people need to regularly perform notarial acts, which I think is imaginative.

dcbadacd 8y ago

I've used both GNPG and Estonian eID. I have to say Estonian eID is way more usable when one needs to sign anything. The (digidoc4) software is just way more usable, nicer and designed for the task. I wish GNUPG were as good

lrvick 8y ago

Dupe of: https://news.ycombinator.com/item?id=18013182 https://news.ycombinator.com/item?id=18013182

unixhero 8y ago

All it needs now is a solid blockchain. Vechain could be one perhaps.

DINKDINK 8y ago
What do you need a blockchain for? Blockchains are necessary when you need: Proof of publication Trustless time stamping Trustless transaction execution.
- toomanybeersies 8y ago
  Trustless time stamping seems to be a good thing to have for notarising.
  - confounded 8y ago
    Isn’t trusting the notary the whole point?
    - toomanybeersies 8y ago
      Quis custodiet ipsos custodes? Who will watch the watchmen?
  - DINKDINK 8y ago
    If one needs proof of existence features, bitcoin already delivers this trustlessly at scale: https://opentimestamps.org/ https://opentimestamps.org/ You merkle hash effectively limitless data into a single bitcoin transaction. No need to spin up a new (and likely inefficient blockchain) to do notary tasks.
- leumas 8y ago
  You would use it to add a dimension of time to the signatures. This allows for revoking/replacing keys while still keeping past messages valid. At work we've ben implementing a system like this where an identity is made up of a hierarchy of keys. Let's say you have 2 key pairs as part of your identity. You sign a message with key 2 and publish it on the blockchain at block height H. Then at some point in the future, you lose the private part of key 2 or it becomes compromised. So now you sign a message with key 1 that says "replace key 2 with key 3 from this point on" and you publish it to the blockchain. Now, any messages signed with key 2 before the replacement can still be deemed valid, but any future messages signed with the compromised key will not be valid.

aj7 8y ago

In theory, FedEx overnight envelopes, their most lucrative business, just died in Washington state. Am I right?

openloop 8y ago

I like it.

nwroot 8y ago

This is great progress for other locations as well!

sabujp 8y ago

tldr; do i still need to pay a notary or can i self attest using a gpg key tied to my email address?

djsumdog 8y ago

Docusign has been allowed to be used a notary in Washington; or at least Seattle for notary requirements around housing documents. (Seattle law requires notarization on leases over 12 months). There's a PGP short ID listed on the e-signed document, but it's not yours. There is no point where Docusign checks your ID.

cjcollier 8y ago

That's pretty cool, bro.