In the article it's written that the yubikey is tamper proof.
This is not the case. They report their product as tamper evident but not tamper proof.
Yubico with new 4096-bit keys and gpg-agent for ssh authentication
21–30 of 51 posts
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#22I'm surprised that more folks haven't just gone to 8,192-bit keys, out of an abundance of caution.
I think the general consensus was not extending RSA key size, but using elliptic curves instead? (But NIST and Brainpool curves aren't completely trustworthy and Curve25519 is not yet standardized for OpenPGP, so we're practically stuck with RSA at the moment)
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#23Earlier quoted context omitted.
Yubico have a product specifically for that use case: https://www.yubico.com/products/yubihsm/
My mistake, it doesn't appear to support that functionality. I'll have to look into it further.
There is also the non-insignificant issue of the $500 price tag. Wouldn't bat an eyelid if this was for professional/corporate use, but $500 out of my own pocket for my personal home server is a bit steep.
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#24Is there any way to store an ssh server key in it, or an https server's key? Basically turning this into a mini-HSM ?
You might want to look at the Nitrokey HSM. I'm using one for a project and I was blown away by the feature set for the cost (as compared with the SafeNet devices I originally looked at). Its signing throughput is too slow to run a website with any significant new connection volume, but for personal applications it could be made to work. As just an HSM I think they're a phenomenal value.
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#25Earlier quoted context omitted.
For usage with mobile applications, where NFC is typically available but USB Host is not, I would imagine.
On Android, you typically have USB host (at least on any phone that someone interested in this tech would buy). On iOS it's moot since NFC is gimped and can't be used by apps.
Most people don't carry the necessary cable around with them, though. NFC doesn't require any additional hardware.
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...
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#26> Encrypting by default is a good idea.
I suspect the author intended to say Signing by default is a good idea.
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#27Looked at these last year but opted for smartcard and secure pinpad reader instead.
Can you provide links to what you chose instead?
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#28Is there any way to store an ssh server key in it, or an https server's key? Basically turning this into a mini-HSM ?
Sure! There are a lot of ways you can do this. One is to use PIV mode, which exposes a PKCS#11 interface that can be used by OpenSSL. Yubico has some nice docs on using a Yubikey as an HSM to store CA keys: https://developers.yubico.com/yubico-piv-tool/Certificate_Au...
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).
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#29for folks interested in more on yubikeys and gpg I also would suggest these two blog posts
http://viccuad.me/blog/secure-yourself-part-1-airgapped-comp...
http://blog.josefsson.org/2014/06/23/offline-gnupg-master-ke...
Re: Yubico with new 4096-bit keys and gpg-agent for ssh authentication
#30Earlier quoted context omitted.
4,096 is already an abundance of caution. You might as well say people should go to 32,768 just to be sure. Then somebody else would come along and say, "why not 65,536?"
Indeed. Mostly, it's just a question of whether or not the software will support a key of such size. Typically, I would recommend that, unless you've a good reason to use a smaller key (like support concerns), one should use the biggest key one possibly can use at the time the key is generated. Though, if one is doing key rotation as one should be, one can always adjust up as needed as time goes on.
Not really, especially in the context of RSA keys, because:
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.