The NEO chip only supports 1024 and 2048 bit keys. There is a OpenPGP card ECC draft (at least), so we should be able to move forward.

Ideally the app should reject larger keys when you send them - I just spent half an hour working out why my 4096 bit keys were causing errors :p

Something in the readme would be a great help as well.

Damn here I was thinking it supported 4096 bit keys.

@jas4711 to confirm: is the 2048-bit limitation still present in the NEOs currently on sale on the website? If so, presumably this limit also applies to subkeys generated on-card as well as those 'uploaded' to it?

Scanning a Yubico Neo, of 1 month old, wtih NFC TagInfo by NXP said it is either a P5CD041 or P5CD081 chip wich both support 4096 bits maximum key length for calculation within RAM. It would be good to know if it's actually the case or not.

Yes, 2048-bit is the limit, and it applies to both on-board generated keys and imported keys.

The NFC TagInfo by NXP app is confused, I don't recognize any of those chip numbers. We are using a NXP chip. The 2048 limit is in the NXP chip, and not something we can do anything about easily.

/Simon

If this really is a hardware limitation, then surely you can start using different hardware that raises the limit. Do you have plans to do that in the future?

Currently I'm only allowed to disclose that we have plans to send YubiKeys to other galaxies in the future.

This is a seriously frustrating, 2Kb keys only provide 112 bits of security and the ECC curves supported by GPG are widely believed to be compromised (Bruce Schneier and D. J. Bernstein believe that the NSA chose constants that give them a speedup).

GPG doesn't support PFS and the NSA stores all encrypted emails until they can be decrypted. The time estimates for these algorithms are based on Moore's law, without regard to quantum crypto or other mathematical discoveries. Quantum computing will also see exponential rates of improvement once it gets worked out and DWAVE has teased the ability to perform factorization. As the saying goes, the attacks only get worse.

Security engineers should target the 1% who really need the protection offered by encryption: political dissidents living under oppressive regimes. Encryption standards should aim to protect people for the rest of their lives and if NXP offers chips that support 4Kb keys, you should switch.

+100 for ECC EDcurves

if NXP offers chips that support 4Kb keys, you should switch

+1 to this and everything else @indolering said.

FYI: In case you missed it, the newer Yubikey 4 supports 4096 bit keys.

@jonathancross Does that mean that yk4 uses unpublished applet version?

@nmikhailov, I see @jas4711 says above that the issue is hardware rather than software. The Yubikey 4 is new hardware, so perhaps that explains it? Do we know for a fact if the applet only supports 2048?

@jonathancross Well 2048 is still hardcoded in https://github.com/Yubico/ykneo-openpgp/blob/master/applet/src/openpgpcard/PGPKey.java#L25 so it is unclear for me how it can support 4096bit keys.

Just to try to answer some questions in this thread:

1. The NEO hardware is not capable of key sizes beyond 2048, thus this applet does not implement anything larger.
2. The YK4 hardware is capable of RSA 4096, which is exposed through its OpenPGP card functionality. The YK4 uses a different hardware platform from the NEO, and it does not run this applet.

Thanks @dainnilsson.

it does not run this applet.

Which applet does it run then?

The YK4 page links to all the standard OpenPGP documentation and suggests that this applet is used.

What are my benefits when using the OTP+U2F+CCID configuration?
...applets loaded on your device, such as the OpenPGP applet.

And links to a page about this applet.

Can the applet be modified on YK4?

@jonathancross
Technically it's not running any applet, as the YK4 does not have a JavaCard environment. It's running a proprietary implementation of the OpenPGP card specification. Linking to the blog post on OpenPGP for the NEO might not be accurate, but mainly the information there applies to the YK4 as well, and the page does quite clearly state that the source code is for the applet running on the NEO. @SueHeim - This might be something you'd want to look over for accuracy?

@fuzzyroddis
For security reasons, the code running on a YK4 cannot be modified.

@dainnilsson cool, could the applet on the NEO be modified?

@fuzzyroddis - Only if you have one of the earlier development versions of the YubiKey NEO, current devices are locked down.

@dainnilsson thanks!

It's running a proprietary implementation of the OpenPGP...

@dainnilsson - Am I correct that the OpenPGP implementation (used now and going forward) is no longer Open Source then? How can it be reviewed for security? This seems especially important considering the bug discovered last year by @josecastillo.

The implementation is not open source, that is correct. We have both internal and external review of our code to ensure that it is secure. It's important to remember that open source code is no guarantee that bugs/vulnerabilities will be detected as the bug you've linked to demonstrates quite well. The bug was inherited from the upstream project which ykneo-openpgp is based on, and was NOT detected by any audit of the source code. It was interaction with the device itself which lead to it's discovery.

We're all for open source, and we try to open source as much of our code as possible when and where it makes sense, but in this case it was determined not to be so. One reason is that on the YubiKey NEO, each applet runs in its own sandbox, isolated from the rest of the system and can be audited/reasoned about on its own. This is not the case on the YubiKey 4, where each part of the system interacts with several others. Another reason that ykneo-openpgp was implemented as an open source project (aside from being able to leverage an existing project) was that it was useful for others, as it can run on a variety of devices. Again, this is not the case for the implementation running on the YubiKey 4.

The implementation is not open source

I find this very disappointing.

We have both internal and external review of our code to ensure that it is secure.

It would be better if we didn't have to trust you.

but in this case it was determined not to be so

I don't follow your reasoning, especially the architectural argument. The second point, about reuse by others, makes some sense for some projects but doesn't seem relevant to security. As evidenced by this thread, you have a knowledgeable community that's willing to dig into YK code. For security-related projects like YK, I think that's the main decision point - will people look at the code and report issues if they find them.

Especially with users like the Linux Foundation and the open source projects they manage, this may be a deal breaker. Unfortunately, I feel obliged to bring this to the attention of those decision makers.

Update: Konstantin, the main LF sysadmin, is advising core kernel devs not to get YK4s and is looking for alternatives.

Everyone that does not have shit for brains knows that security through obscurity doesn't work hence people should be asking themselves why they don't want security concerned actors to properly verify the security properties of their software ( suddenly ).

In any case just boycott their devices and products, don't file any bug reports, then it should not take to long for someone to exploit the dumb asses that buy and use their allegedly "secure" closed source product.

I'm now locking this conversation as it has derailed from the original issue. I've tried to answer questions about our products for clarification. If you want a device that runs the code in this repository, the YubiKey NEO is still available. We will as always continue to evaluate the landscape, and it is possible that some parts of the YK4 firmware will be made open source in the future, but I can make no promises here. Further hostility against the company or our users will not be tolerated in this forum, and will be met with bans.