The thing that jeopardizes 2048 bit RSA keys is probably going to make all of RSA untenably risky. By all means, generate a 4096 bit key; it doesn't really cost you anything in a GPG setting. But the default is fine.
This entire blog post is an indictment on the sad state of affairs surrounding UX around crypto. There's so much intrinsic complexity around proper crypto that the focus should be on removing as much accidental complexity as possible.
Yesterday, I installed GPGMail on my Mac and had it generate a keypair, and the procedure was actually rather pleasant and clear. I did not know yet about this master- and subkey scenario, and the setup wizard did not offer this option, but I think the UI could be extended to support this without too much extra hassle.
I like those, but I really really want something which can do bt 4.0le with an existing pairing (stronger than just bluetooth 4.0 le security, though) between my host (ideally, mac/win/linux desktop/laptops, also phones) and the device, with some level of on-device logging, access control, etc.
A type 2 pinpad + openpgp smartcard might be the best practical thing right now -- a PIN on the card, plus a passphrase from the host (I think you can require both?). Type 3 showing a hash of what you sign, or a serial number of number of signs, would be even better.
The GPF cryptostick (usb) is also nice -- I think you could also take the Werner smartcard and cut it down to a smaller size for a USB stick sized reader. Sadly GPF stick 1.2 is out of stock everywhere.
Yeah, I guess I just don't trust smartcards all that much from a hardware security perspective, vs. modules with battery inside a metal envelope. I'm sad Maxim/DS killed the Crypto iButton line -- it was a great compromise between smartcard cost ($20-30) and HSM physical security. The software was never great, though.
Yeah, I think it is prudent to be extra cautious of any black box which is security specific, from closely government connected vendors (staff, sales). A CEO would probably be sued by shareholders, or even go to jail, for refusing an extralegal polite request from their 95% customer. (Gov and gov connected banking) to back door devices going to public enemies.
The solution is end user verifiable designs. Harder with hardware, but there have to be ways to do it. The risk is highest for single purpose vs general purpose devices. If safenet hsms aren't owned as fuck, I'll eat one.
well, yeah, people just --gen-key and that's it.
using subkeys is probably a good idea. using expiration properly is certainly a good idea. understanding gpg's trust structure sounds like a good idea.
However, even this guide is probably a little too long, and unfortunately many will not take the time to read it.
Oh yeah also the primary key is called, well, primary, not master. I do that mistake pretty often tho.
Ok implementing this I realized the obvious flaw: you can't use this key to sign other keys. And I can find no way to configure a subkey in GPG to do this (I suppose it might exist, GPG is dark and mysterious).
Surely, surely it would be easier to just make two keypairs, store the master and then sign your "daily driver" key? This seems like a lot of effort making gpg do things it doesn't want to do for little practical gain - the full perfect key is still ideally offline.
Lately there have been a few discussions about PGP keys and smartcards are always mentioned. Would smartcards be a solution for the client-side crypto objections? Could you make a secure version of cryptocat by just making it a wrapper around a smartcard reader? Could you use a smartcard to make secure use of PGP in webmail feasible?
A waste of time. You should be using a strong passphrase so that it doesn't matter if your laptop is stolen.
We all use osx though so if any of us become high-value targets they'll just root our machines remotely with the help of Apple software update and steal our keys from ram or log our keystrokes directly.
The problem with a strong passphrase is remembering it and entering it quickly. I can keep a few 12-14 characters passwords in my head, but that's about it.
I like the concept of passphrases, but they're too long to be manageable when you need to type them in a bunch of times.
I have used now a longer passphrase at work for my ldap login, and afer two days it didn't bothered my anymore with it's length.
(Passphrase was around the sime size as your first paragraph and was used for login, ssh, svn, git, email 82 and internal websites like bug trackers and wikis).
GPGTools (https://gpgtools.org/) can store your passphrase in the OSX keychain. It comes with GPGMail for Mail.app, which makes it very easy to encrypt email.
It's the same thing of root/intermediate TLS certificates. You basically store the root in the safe and keep the intermediate online, so you can use it sign stuff (eg: generate certificates for customers' domains). If the intermediate is compromised, you revoke it, get the root and generate a new intermediate.
