61–70 of 261 posts
1. “gpgv”, a stand-alone minimal binary to only verify PGP signatures. https://gnupg.org/documentation/manuals/gnupg/gpgv.html#gpgv
2. “symcryptrun” – simple symmetric encryption tool: https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...
No mention of an agent. One of the nice features of GPG/PGP is gpg-agent which lets me use GPG without having to type in a passphrase every time.
Earlier quoted context omitted.
I feel like this is asking past the point. Without a web of trust, how are you securely signing? You can go with somewhat centralized trust, but that only gets you do far. Or, rather, that forces everyone to deal with that centralized source. Much like the web of trust.
If you own a domain and have a webserver running ssl you can distribute your public key in a secure manner. What situations are you encountering in 2019 where you really need a distributed web of trust?
That means that I'd be trusting GUANG DONG CERTIFICATE AUTHORITY and every other CA not to issue a fraudulent certificate against my domain. I don't think that's very secure.
A problem I have run into with x25519 and ed25519 is that in Nacl, both use different public key 'formats'. While they are the same curve, you cannot use an x25519 for signing (ed25519 only) and you cannot use an ed25519 for encryption. PGP allows binding encryption and signing keys together in a profile. So far I have not been able to 'bind' an ed25519/x25519 key in a similar configuration.
> No one was sending you encrypted emails anyway Guess what! Since I moved to Germany (from the Netherlands), I noticed that people send a lot of encrypted mail. Not random Germans, sure, but where in the Netherlands the security and broader hacker community was hard to convince, in Germany it's quite widespread. My colleagues (security firm) and friendly security firms (when we collaborate) expect nothing less, and…
> I wonder what it's caused by and how we can encourage it Probably because many Germans have a relatively recent memory of the Stasi in the DDR.
But yeah it's the only thing I can think of as well. I still can't pinpoint what argument it is that they are implicitly taught that we aren't.
Earlier quoted context omitted.
Keybase is one version of a modern take on Web of Trust. https://keybase.io/
Keybase is centralized. The GPG keyserver pool is a decentralized gossip network of volunteer servers (I run one). https://sks-keyservers.net/status/
As long as you're ok with relying on the keybase service being reachable and functional, trust is still decentralized and verifiable.
I feel like the one thing that keeps me from abandoning GPG completely is the general lack of smartcard support in any other system. Are there any examples of using yubikeys to store your libsodium keys?
A problem I have run into with x25519 and ed25519 is that in Nacl, both use different public key 'formats'. While they are the same curve, you cannot use an x25519 for signing (ed25519 only) and you cannot use an ed25519 for encryption. PGP allows binding encryption and signing keys together in a profile. So far I have not been able to 'bind' an ed25519/x25519 key in a similar configuration.
It is not recommended to use any keys for more than one purpose any more, this can allow attacks. So this is by design.
A problem I have run into with x25519 and ed25519 is that in Nacl, both use different public key 'formats'. While they are the same curve, you cannot use an x25519 for signing (ed25519 only) and you cannot use an ed25519 for encryption. PGP allows binding encryption and signing keys together in a profile. So far I have not been able to 'bind' an ed25519/x25519 key in a similar configuration.
How hard is it to cat two keys together in a profile?
Earlier quoted context omitted.
My point is that you need to roll your own cryptosystem, whereas PGP, for all its flaws, is a working, IND-CCA2 secure cryptosystem (provided you use the correct primitives). This whole blog is justification for removing PGP from Golang stdlib. I dont agree with Valsorda deprecating this.
Its never been part of the stdlib, its part of x/crypto. They also aren't going to remove it, just deprecate it.