[2] https://blog.mozilla.org/security/2013/02/13/using-cryptosti...
Edit: Also, does this have gpg-agent / ssh support?
But, yes, it does work with gpg-agent with ssh support.
Note that (at least in the method described in that document), the Yubikey does not _generate_ the private key, it merely stores it securely. You need to generate it on a computer, which should preferably be a brand new laptop, airgapped, purchased from a physical store and not online (continue to layer defenses up to your desired level of paranoia).
Note that the key is intended to be difficult to extract from the device and there is not intended to be an interface for doing so.
If you are using it with RSA key, you need to decide if you trust that it is generating the key properly. Keep in mind Yubikeys are built on GlobalPlatform/JavaCard which is an extremely high value target. There would definitely be the economic incentive for a well-funded adversary to backdoor the RNG system.
If you are using a Yubikey with EC cryptography, the security analysis gets even more complicated. The curve used need to be a safe one.
And, if the RNG has been tampered with or incorrectly designed, EC signatures can actually leak the private key.
Which is to say that if there is a flaw in the Yubikey, JavaCard, GlobalPlatform, or the specific chips they are using, and you are either (A) having it generate the private RSA keys, or (B) using it with elliptic curves, then there is the potential that the device is not at all secure.
Note that backdooring crypto-specific chips is a thing. TPM and other special-purpose crypto chips have been discovered to have been both backdoored and vulnerable to implementation issues.
Which is completely unacceptable - "you had one job".
The source to the actual Javacard applet that implements is available on Github: https://github.com/Yubico/ykneo-openpgp
This is not the case. They report their product as tamper evident but not tamper proof.
Is there any FDE software that supports keeping decryption keys on a network server? You would still need to enter user authentication to obtain the decryption key of course.
Use case: We are a HIPAA environment, I want a hard drive to be useless if it is removed from the building.
http://viccuad.me/blog/secure-yourself-part-1-airgapped-comp...
http://blog.josefsson.org/2014/06/23/offline-gnupg-master-ke...
Not that 2048 is flawed as such: it's still north of 100 bits workfactor at the moment, as far as I gather. 3072 would be equivalent to about 128 (similar to the EC algorithms secp256r1 or Curve25519), and 4096 is some extra insurance on top. (As a benchmark: Snowden used 4096-bit RSA keys for GnuPG.) Anything bigger than that could introduce OpenPGP compatibility troubles.
All of these are secure when correctly implemented. (Yubikey use NXP chips. I don't have much to say beyond that, I haven't audited them.) All of them will fall to Shor's algorithm on a quantum computer of sufficient size, but we're not likely to have one of those for a good few years, if they're possible.
"8192 bit keys are horrible insane from all POVs: There is no extra security because the security is based on the weakest link and this is definitely not the length of the RSA modulus, they make encryption really slow and thereby reducing the likeliness of widespread encryption use, they only help spreading FUD about the security of the RSA or other algorithms."
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=137824#10
I suspect the author intended to say Signing by default is a good idea.
I've been thinking about it, but it's a bit confusing figuring out what cards are compatible and donating to the foundation is nice but a bit expensive.
1. RSA is a slow algorithm and gets slower as you increase the key size.
2. Increasing the key size gets diminishing returns on the security margin. Given the performance and compatibility issues, the relatively minor improvement in security once you go beyond a certain key size is not worth it (you should switch to a better algorithm instead).
3. Anything over 4096 (possibly anything over 3072) is overkill anyway - if you could break a 4096-bit RSA key, you've probably found a fundamental weakness in RSA that means you should move to a different algorithm entirely.
I use it for generating 2FA codes, Yubico Authenticator works like Google Authenticator except that it requires touching the YubiKey to the phone before it shows the 2FA codes. The codes are computed on the YubiKey: https://github.com/Yubico/yubioath-android/blob/63387c02a39b...