Sender | Message | Time |
---|---|---|
23 Oct 2022 | ||
(unless it stores SSH, in which case potential thieves can check your sourcehut/github/gitlab username, but that's overthinking) | 11:49:56 | |
I use a yubikey (with GPG) for SSH. All I need to do is plugin my Yubikey, open Kleopatra (to start the agent - if I didn't do so yet), type in my pin once and tap it every time I need to re-log or something (like Wiktor has basically). One upside it has for me personally (some may care more about this than others), is that I only really need to care about 1 key. If I have that key with me, I can login on every server I have (portability). Previously (back when I still used software keys like a dummkopf), I ran into scenarios quite often where I forgot to add my key to that one specific server I needed to login to... Also makes it easier to revoke that key from all machines (instead of having to go through a list of keys and revoke just the right one). | 16:28:06 | |
* I use a yubikey (with GPG) for SSH. All I need to do is plugin my Yubikey, open Kleopatra (to start the agent - if I didn't do so yet), type in my pin once and tap it every time I need to re-log or something (like Wiktor has basically). One upside it has for me personally (some may care more about this than others), is that I only really need to care about 1 key. If I have that key with me, I can login on every server I have (portability). Previously (back when I still used software keys like a dummkopf), I ran into scenarios quite often where I forgot to add my key to that one specific server I needed to login to... Also makes it easier to revoke that key from all machines (instead of having to go through a list of keys and revoke just the right one). | 16:28:58 | |
is gpg keygrip a part of the public key? if so, can I track it together with my dotfiles with git? | 20:24:14 | |
(it's used at least in sshcontrol file) | 20:25:46 | |
Key grip is calculated from the public key. This is similar to fingerprint but the fingerprint also uses timestamp and is part of the OpenPGP spec while key grip is just a proprietary gnupg thing. | 20:58:37 | |
24 Oct 2022 | ||
(probably a GPG-specific thing) what's the difference between exporting GPG_TTY=$(tty) and gpg-connect-agent updatestartuptty /bye ? they seem to do the same thing - setting current terminal for pinentry (and therefore belong to .*shrc ) | 06:13:31 | |
20:25:43 | ||
28 Oct 2022 | ||
16:04:07 | ||
I'm using a Yubikey and have two UIDs. I also use subkeys for signing, encryption, and auth. When I attempt to sign emails with the "non-default" UID, clients are unable to verify the signature. Signature verification works fine when using the "default" UID. This isn't an issue when using local keys not on a Yubikey. Any idea if there is a fix for this? Or if it's a common issue? | 16:10:28 | |
Are you sure you fony have two completely different keys with the same non default UID? Check with gpg -K | 16:54:57 | |
Or gpg -K non-default@email.com | 16:55:16 | |
Also what does it mean they are unable to verify signature? Please share the exact error message. | 16:56:05 | |
Yeah....gpg -K non-default@email.com does show the correct key. Kmail says the "Message was signed with an unknown key 0xFA6F...." (which refers to the correct key. Thunderbird says it's an "Invalid Digital Signature". | 17:36:48 | |
I'm not sure if this is a Yubikey issue....I could re-do the Yubikey bits and see if that corrects it. | 17:37:08 | |
OpenPGP cards like the yubikey don't contain the user ids at all | 17:54:58 | |
That mapping is done by your pgp software, outside the yubikey | 17:55:20 | |
Maybe you need to re-import your key into Thunderbird? | 18:30:30 | |
30 Oct 2022 | ||
12:00:41 | ||
I sort of figured this out. In Kmail, changing the preferred format from "OpenPGP/MIME" to "Inline OpenPGP (depricated)" for that secondary email address seems to resolve the issue. It looks like it's an Office365 problem. Sending signed emails from secondary email accounts that aren't hosted on Office365 presents no issue. I'm not sure how to adjust other clients to make that work. Anyway, thanks to all for your help! | 22:00:59 | |
7 Nov 2022 | ||
21:28:50 | ||
30 Oct 2022 | ||
* I sort of figured this out. In Kmail, changing the preferred format from "OpenPGP/MIME" to "Inline OpenPGP (deprecated)" for that secondary email address seems to resolve the issue. It looks like it's an Office365 problem. Sending signed emails from secondary email accounts that aren't hosted on Office365 presents no issue. I'm not sure how to adjust other clients to make that work. Anyway, thanks to all for your help! | 22:03:32 | |
2 Nov 2022 | ||
05:26:40 | ||
9 Nov 2022 | ||
04:47:55 | ||
12 Nov 2022 | ||
10:49:23 | ||
22:05:30 | ||
13 Nov 2022 | ||
04:50:28 | ||
19:14:35 | ||
Are there any quantum-resistant algo available on GPG? | 19:15:17 | |
In reply to @cccttt:matrix.org The only post-quantum ciphers I'm aware off are XSalsa20 and XChacha20, which, after accounting for Grover's algorithm, gives of a post-quantum security of about 128-bits, which is considered plenty for now. So no, no post-quantum security for now. | 20:20:29 |