- What problems does GPG/friends solve?
- Certifying authorship of source code (git commit signing)
- Certifying authenticity of packages for package managear
- Private messages on public channel
- E.g., emailing political dissidents
- Less often, these days, due to e2e-encrypted messengers)
- What building blocks do we use to solve?
- Asymmetric crypto
- Very good paper: New Directions in Cryptography by Diffie and Hellman (1976)
- But now we need a way to get the public keys to you (PKI)
- https://xkcd.com/1181/
- Root CAs
- x.509 certifiate standard
- HTTPS, DNSSEC
- Con: centralized authority can censor, get hacked, charge money, get subpoena'ed ...
- Self-signed certs
- Trust-on-first-use (TOFU)
- OpenSSH client strategy
- Cons: doesn't secure first use
- Web of trust (WoT)
- Open standard: Pretty Good Privacy (OpenPGP)
- Main implementation: Gnu Privacy Guard (GPG or GnuPG)
- Decentralized, peer-to-peer
- stronk set
- Inherent cons:
- OpenPGP Certificate Flooding
- Good paper
- Long-term keys/no forward secrecy
- Leaks metadata on "who signs who"
- How well did you verify their identity?
- Implementation cons:
- The PGP problem
- Complex, swiss-army knife with footguns, bad UX
- No AEAD
- Follows UNIX philosophy (therefore has to reparse the key database on every invocation)
- Older, weaker crypto algos CFB mode, RSA vs ED25519, the defaults suck
- Asymmetric crypto
- Practical, how to
- gpg.wtf, getting started guide to common use-cases
- GPG on ArchWiki
- GPG cheatsheet
- GPG without WoT
- Keybase.io
- Keyoxide
- Web Key Directory, put your SSH key at
www.{your-domain}.com/.well-known/openpgpkey/hu/{hash(email)}
- Web Key Directory, put your SSH key at
- GPG alternatives:
-
Never encypt email efail, quote replies, nobody knows how to use it anyway.
-
Sending files: Magic Wormhole (point-to-point, synchronous)
-
- Use SSH keys to sign Git commits
- How to get publisher's public key? What does SSH signing get you?
sigstore-
It's kind of hard to decrypt the Big Tech, Venture Cap, B2B, synergy langauge they use, but once I did, I found this:
The
cosigncommand requests a certificate from the Sigstore certificate authority, Fulcio.[Cool; it hard-depends on a centralized service]
Note that you don’t need to use a key to sign. Currently, you can authenticate with Google, GitHub, or Microsoft, which will associate your identity with a short-lived signing key.
[Because those companies would never want to censor anyone, and everyone wants to tie their Google account to their digital identity.]
-
-
Encrypting files: age
-
age is in the business of integrity and confidentiality, not authentication. This was hotly debated early on, and still is periodically....
In short, while no one can modify an encrypted age file, anyone can replace it with a completely new encrypted file.
- remember, recepient's public keys are public
-
minisign/signify- AFAIK the tools and their formats do not support streamed verification, thus they cannot simply be used together with age in command or library form in streaming use cases. It means requiring more storage/passes and opening for TOCTOU vulnerabilities. --- GitHub issue 51 comment
-
This comment on HN comes dangerously close to realizing why we had WoT in the first place.
The big problem is there are no really good ways to deal with this problem [the switcharoo problem] fully. If you use digital signatures, you have to have a trusted method of distributing the verification keys.
If you have a secure method of distributing keys, you could also just distribute the encrypted file (or its hash) via that secure method. --- Hackernews comment
Of course, the last syllogism is false. A and B could have established a secure channel a long time ago, B and C (not necessarily afterwards), C and D, A can rececive D's key with authenticity, but there was never a secure channel from A to D directly.
-
-
E2e messaging:
- Matrix, requires always-online server
- Could be used for more than just chat
- XMPP + OMEMO
- Pre-existing chat protocol
- Signal / OpenWhisper protocol
- Basically, device-local keys (aka host keys) that sign each other on a server.
- Matrix, requires always-online server
-
- Discussion questions:
- The Monkeysphere project lets you use GPG keys for users to authenticate to SSH/Web servers AND authenticate servers (the reverse). Is this a good idea?
- Are decentralized protocols inherently slow-moving and thus incompatible with up-to-date-ness?
- Is it even possible to get perfect forward secrecy for a static thing, without servers?
- In IndieWebAuth, you can authenticate to arbitary web services by proving you own a domain-name, no keys or passwords involved. When would this be sufficient, and when would you want something more?
- Indeed BlueSky, while not implementing IndieWebAuth, lets you use a verified domain name as your account name.
- Likewise, WKD and DNS-based Authentication of Named Entities (DANE) utilize DNS as a delegatable naming authority.