An NFC PGP SmartCard for Android

This was the main reason I picked up the yubikey, but I simply could not get GPG to recognize the yubikey to import my keys. I'm sure I simply missed some important step, but I couldn't figure it out with either GPG for windows or GPG in a linux VM.

I wish there more smart card devices available for use with PGP that were as widely purchasable as the yubikey.

doesnt seem to work for ed25519 keys :(

As far as I know the blocker is that ed25519 is not in the openpgp standard. If that's wrong, please provide source.

That's the big blocker - but, without wishing to be too mean to NXP (sorry Joppe!), the A700x MX51 microcontroller used in the YubiKey Neo is pretty old. Really, most crypto chips are at their core: they almost always just make them out of old ones with new bits glued on to (reasonably) try to reduce (high) NIST/etc certification costs. (Seriously, it's still carting a hardware DES implementation around.)

I believe it has a 2048-bit multiplier with a particular (patented?) form of blinding to protect against side-channel attacks. That's used for RSA; it can't do 3072/4096 bit RSA keys without tricks as it stands unfortunately.

The existing NXP ECC implementation is also not in JCOP's applets by default, I think? From what I saw, it (ab)uses the RSA multiplier. That can go up to 320 bit curves in theory without running out of scratch space, and is a generic implementation of prime fields over GF(p), so you'd think it'd be able to do some operations on Curve25519 fine in principle.

And it can, but in my testing it did what I thought it'd do, and leaked side-channels when used with the NIST curves and djb's curves, because the blinding on the RSA multiplier was simply not designed to cope with the regular structure of the special prime fields that most elliptic curves use. And the performance of random prime fields (like Brainpool) in software is awful, so no-one else wants to use those.

You've also got the problem that the existing implementation there can only do ECDSA (not the EdDSA used by Ed25519) and doesn't have SHA-512 around, too.

A pure software implementation that avoids using the RSA multiplier would be much safer, and I think in principle would be able to do the other CFRG favourite, Ed448-Goldilocks, as well. That is what some HSM vendors are doing. It'd be a very tight fit on the NXP A700x, however. I'll leave that to NXP, if they want to.

I myself want an open crypto chip, not one that still needs blobs in 2015. And I've seen a few movements in that direction.

Even if the Yubikey supported larger RSA keys (3072 or 4096-bit), you might not want to use them. Decryption is quite slow with a 4096-bit key on a smartcard (for example, it takes ~5 seconds to decrypt with a 4096-bit key using a g10code smartcard), which seriously hampers usability. Increasing RSA key size also has diminishing security returns [0], so in an ideal world you'd be using ECC instead, to get a strong 256-bit security level with good performance. Unfortunately, both the OpenPGP smartcard spec and smartcard hardware need to be updated to add support for ECC (and who knows how long that might take).

It's worth noting that, while many people refer to the NIST guidelines that say that RSA 2048-bit keys are acceptable until 2030, NSA's Suite B doesn't include RSA at all and only recommends ECC. The problem is that the state of the art in open source cryptography software and hardware has not caught up to NSA in the 10 years since Suite B was published.

If you really want to use your Yubikey, a reasonable compromise might be to generate a 4096-bit RSA master key (stored offline), and put 2048-bit subkeys on your Yubikey, which you would want to rotate periodically. This gives you the benefits of a strong key for establishing your identity in the Web of Trust and the better performance characteristics of 2048-bit keys on smartcards. The downside is a higher upfront setup cost, and periodic maintenance cost on both your part and on the part of the people you communicate with, since you will want to rotate your subkeys and they will need to refresh their copy of your key whenever you do that.

Given what we know from the Snowden documents, spy agencies seem to attack endpoint security often and don't seem to be able to crack commonly used encryption schemes, including RSA (although they can almost certainly factor 1024-bit keys, given current estimates for the costs of such an operation). Therefore, the improved endpoint security afforded by using a GPG smartcard might make using a smaller key size a worthwhile tradeoff.

On the other hand, GPG does not provide forward secrecy, so while it's important to rotate keys and delete old messages as much as possible as part of OPSEC for your local machine, if NSA is capturing your GPG messages from the wire for later decryption, you'd probably want to prefer using the strongest keys possible. This is an area where increased StartTLS deployment (especially with forward secure ciphersuites) can help.

Finally, it's important to note that when you argue in favor of 4096-bit keys over 2048-bits keys, you are saying "I believe my adversary can factor a 2048-bit RSA key, but not a 4096-bit RSA key". If your adversary can factor a 2048-bit RSA key, and they really want to read the email that's been encrypted with your 4096-bit key, I would argue there are a lot of options available to them, such as:

1. MITM a software update for your mail client or operating system. It depends on the specifics of your system, but many systems today use 2048-bit (or weaker) keys for authenticating software updates.

2. MITM any website you visit (most CA's have 2048-bit roots, so it doesn't even matter if all the sites you visit have 4096-bit keys) and use a browser exploit to deliver some malware that exfiltrates your email when you decrypt it.

[0]: https://www.yubico.com/2015/02/comparing-asymmetric-encrypti...