I was noticing the recent security advisory is signed with a PGP key using GnuPG. Is this used very widely?
Unfortunately not very much companies especially outside of the IT market properly implemented PGP/GPG for email. At least signing is properly understood nowadays (no more "your email couldn't be read, it had some weird stuff at the end") and some even sign their outgoing mail.
Our hosting provider fully supports and uses GPG for all email contact; so billing and support mails are all encrypted once you provided them with your public key (i.e. you've sent them a signed mail with the public key being properly published on keyservers so it can be verified).
ssh uses its own keys and key directory <
GPG keys can be used for SSH; just run the gpg-agent with
--enable-ssh-support
ssl uses its own keys and key directory << this is how my email now authenticates as well as web browser.
SSL/TLS is
NOT authentication! It is only securing the transport channel, as the name TLS (Transport Layer Security) clearly indicates. If you refer to X.509 certificates - they are part of a private/public key infrastructure (relatively) similar but incompatible to GPG/PGP. However, almost all IMAP/POP and SMTP servers can use various backends for user authentication. E.g. postfix can even just run some script that returns some boolean value to authenticate users; so using GPG for authentication at the mailserver should also be possible.
IIRC radius can support GPG for authentication too, so might also be a viable option especially within a network with multiple services that require authentication/authorization.
SASL can also be used with/by a multitude of backends, so regarding mailservers "everything is possible"™ nowadays
pkg uses its own keys. <<I beleive these are know as fingerprints in pkg parlance.
These are also not for authentication but only for signing and verifying the packages. This can be done by just providing and verifying a checksum or by signing the file(s) with the private part of a keypair (e.g. GPG).
Signing is basically just encrypting a file with only a private key - the file can be only decrypted by the public key if it hasn't been tampered with, so it is guaranteed the file a) comes from the person that holds the private key and b) hasn't been modified in transit.
WPA2-EAP uses radius server for keys. <
IEEE802.11i specifies a protocol/mechanism for authentication directly with GPG keys. Although most plastic-routers and consumer-APs surely won't support that - they usually lack every authentication method except PSK or at best they have (usually very crippled) support for radius or some "wpa-enterprise" variation...
I'm using GPG-keys on a yubikey for encryption, signing and authentication. My passwords are managed by
sysutils/password-store, which is basically a wrapper around GPG and git, so it uses the GPG-keys on my yubikey for de/encrypting the files and for ssh-login to my private git server where I store the password repository (additionally to storing it on my private keybase storage).
The firefox plugin is a bit quirky to set up (well, it's written in python...
), but it works reasonably well once it's set up manually.
2FA would/should be possible with the yubikey directly, but I've never managed to get it working reliably on all my systems. I also haven't tried the TOTP plugin for password-store yet; I still use a minimalistic 2FA app on my phone for that.
Main reason for my lack of enthusiasm to try getting other variants to work: the percentage of sites/services that actually support 2FA is _very_ low. Also the services you'd *really* want to be secured by stronger authentication usually have by far the worst security standards - banks often haven't even heard about 2FA and force you to use insecure passwords by arbitrarily limiting them to only alphanumeric characters and a very short password length (often as low as 5 characters!!).
Same goes for GPG encrypted email - even phone companies still send invoices (some even with detailed history containing all called phone numbers!) via unencypted email.
My general impression: The older a company, the more antique is their view on security (even if they are "tech/IT" companies!) and the more horrifying are their security standards and also their statements if you ask them about it. (Including the often occuring bullsh*t about "we don't need SSL/TLS for the web portal, we store the passwords very secure on our server")
