4096-bit key generation on OEM reset takes unadvertised 15 minutes with Librem Keys/Nitrokey Pro (instead of 2 minutes with 2048-bit RSA keys and 3 for 3072))

[MrChromebox]

ugh, not sure how I missed testing #906, but 4096-bit key length breaks the OEM reset with Librem Keys. Ends up hanging on GPG key generation, with the dongle returning 'card busy' forever. Setting the key length back to 2048 resolves the issue. What's the best way to guard or override this?

[tlaurion]

@MrChromebox Should work but takes 15 minutes to generate keys? 5 minutes per subkey.

[tlaurion]

@MrChromebox : This warning about resetting GPG key under 2 minutes is misleading though

[MrChromebox]

@tlaurion how does something like that not get mentioned in the PR? going from 2 mins to 15 mins is a massive change, one which would cause most users (and devs) to think something had broken.

As a 15-min keygen time isn't ideal for Purism boards, I'm thinking that a patch to default to 4096, but to allow boards to override via board config would be ideal -- same way we do now for BOARD_NAME / CONFIG_BOARD_NAME

Any objection to that approach?

[tlaurion]

@MrChromebox : No objection, other then not being sure what is the point of having that added security inside of the key if not taken advantage of at the moment of generating the keys (which you do only once). I think users would have nothing against it if they were warned about it. (I received 0 complain as of now for the past year).

The idea here is to secure data at rest for longest possible time against traditional computing attacks.
While:
For RSA-2048, current computers would take around 300 trillion years to discover RSA keys using a brute force attack.

Nothing happened, really, in the news sphere, but:
When protecting against attacks by traditional computers, systems can achieve great security by extending the key-length of the algorithm. An organization could switch to RSA 4096, for example. With quantum computers, however, that approach will not work. Even though RSA 4096 uses a key that is twice as long, the difference in time for a quantum computer to break RSA 4096 vs. RSA 2048 is negligible.

SRC

[kylerankin]

I support the idea of this being optional/configurable if the default is to be changed both to account for customers and companies who have different threat models. In our case the key is aimed only to protect secrets during shipping. We advise people to change keys upon receipt and I believe many of our customers would interpret a 15 minute key generation like @MrChromebox did: as the system freezing/failing, and they would contact our support team for help.

Our average customer does not have NSA-with-a-quantum-computer in their threat model, or if they do, the reasonable among them would still not expect RSA 2048 to be cracked within a day or two during shipment interdiction (and if they did, we could accommodate them during our anti-interdiction process to generate a larger key). We suggest they change the keys upon receipt (which any customer with NSA-with-a-quantum-computer in their threat model would do as good practice anyway) and at that point the customer with that threat model could opt to use a stronger key. For everyone else who doesn't have that extreme threat model a 15 min wait might risk discouraging them from doing a key change.

[tlaurion]

#831 (comment)

So yes, it seems that the default should set to something, and that something should be configurable.
My insight would be to prompt the user ("Use default of $KeySize bits? Y/n") and then validate for valid input prior of going forward.

[techge]

At Nitrokey we are using 3072-bit keys and this is reasonable fast imho.

[tlaurion]

@kylerankin @MrChromebox @techge : I would agree that following upstream decision should be the default. (default keysize to 3072, asking Y/n defaulting to Y, and outputting correct waiting time corresponding to user selection if n is chosen. Users choose defaults.)

As reported #831 (comment), the latest GPG versions defaults to 3072 keysize, where the LTS version that was pinned into gpg2 module doesn't. I would suggest simply making the user/oem aware of the selected keysize output so that keygen waiting time is known prior of key generation. (expectation management).

Once again, keygen is not happening everyday... and should not happen everyday.
OEM should scope that prep time and parallelize other needed tasks in fulfillment without choosing to reduce security in transit because he wants to save 12 minutes per paired to USB Security dongle + platform (my opinion).

Otherwise, we are here, once again guys, choosing 3 different security options (2048: Librems, 3072: Nitropad, 4096: PrivacyBeast) without users knowing nor understanding the difference (which is basically cost optimization for OEM, nothing else, let's be frank). On a psychology basis, the point here is just to not create false expectation. As said at other place, not a single customer complained of having had to wait one time 15 minutes for added security/confidentiality/privacy for his whole, later on data at rest/signing/encrypting experience with its USB Security dongle and all applicable use cases from the added benefit.

My point is that if user/OEM fulfillment guy pairing USB Security dongle to platform (to protect it in transit and then for data at rest, right?), he a priori knows that 15/7/2 waiting minutes are needed prior of doing next steps of fulfillment) which is actually a false problem and another choice of lesser security for more convenience.
I would understand if that step was repeating everyday for the end user. But in most if not all cases, that should happen only once, and if that time is a problem, then that problem should be fixed with #771 (generating keys under Heads, backup the private key under encrypted storage, then do keytocard) not here.

@techge @MrChromebox @kylerankin :

• 4096 bits RSA subkey generation takes 5 minutes each for a total wait time of ~15 minutes (maximum)
• 2048 bits RSA keypair generation is taking a whole 2 minutes ( so ~ 45 seconds per subkey generation)
• @techge what are the waiting time for 3072 keypair and subkey generation?

[MrChromebox]

Once again, keygen is not happening everyday... and should not happen everyday.

but it does, both in the production workflow of preparing devices from shipping, and in testing.

My point is that if user/OEM fulfillment guy pairing USB Security dongle to platform (to protect it in transit and then for data at rest, right?), he a priori knows that 15/7/2 waiting minutes are needed prior of doing next steps of fulfillment) which is actually a false problem and another choice of lesser security for more convenience.

it's not a false problem at all -- all security decisions are tradeoffs. it's a question of what threat model is attempting to be mitigated by a given measure/set of measures, and are the measures sufficient.

So the real question is, what is the threat model, does is a 3072 or 4096-bit key provide a quantifiable security benefit against that model that justifies the 'inconvenience'

[tlaurion]

it's not a false problem at all -- all security decisions are tradeoffs. it's a question of what threat model is attempting to be mitigated by a given measure/set of measures, and are the measures sufficient.

@MrChromebox Agree. There won't be consensus, obviously. It seems, from having reread linked issues, that the use case that is proned here is mostly to have /boot detached signature + HOTP sealing for transit tampering detection, where having the user using the generated keypair afterward in OS, using public exported public key doesn't seem to be really taken into consideration, where all litterature and even default under GPG in newer versions are putting 3072+ keysize being the default. Why push a public key of 2048 online for people wanting to use USB Security dongle enforced encryption...

So the code/board configs need to define defaults under boards and offer GUI to be able to choose from preconfigured options in code to switch between those, limiting input error and not complexifying different use cases/different threat models. So everyone will be happy, being able to test key generation of 2 minutes when needed, and have 4096 keys when wanting to use the Security Dongle for signing/encrypting and disclosing public key online. (preferably, generated inside of heads and exported with keytocard with offline encrypted backup anyway so that loosing the USB Security dongle is not an unrecoverable nightmare with key transition being required and such.)

[MrChromebox]

@tlaurion I'll implement and push a PR, and then can adjust as needed

[jans23]

@techge what are the waiting time for 3072 keypair and subkey generation?

Roughly, 1-3 minutes.

[tlaurion]

@jans23 so it is 9 minutes total (3 minutes each subkey?) or 3 minutes total keygen session (1 minute per subkey?)
Sorry, I just want numbers given by each defender of the default value to be changed.