Do Nitrokey PRO2 and HSM2 support non standard key lenght for RSA? Quantum resistence

Nitrokeys
1

Hello,

Is it possible to generate inside HSM2 or at least import ready RSA keys of sizes like 3333, 4023, etc?

Is internal HSM2 firmware then capable of working with such keys? Say encrypt/decrypt, sign/verify, etc.

I am interested at least in compatibility with GPG-agent, though opensc-PKCS11 would be nice too.

2

Hi @sanyo!

  1. I do not think custom length would be any useful cryptographic side. I have not heard of any of that either.
  2. Nitrokey HSM2 supports only common lengths, see Nitrokey HSM2 facts sheet.
  3. I do not think any other software supports custom length, at least I am not aware of it.
3

According to:

https://blog.josefsson.org/2016/11/03/why-i-dont-use-2048-or-4096-rsa-key-sizes/

A significant burden would be if implementations didn’t allow selecting unusual key sizes. In my experience, enough common applications support uncommon key sizes, for example GnuPG, OpenSSL, OpenSSH, FireFox, and Chrome

There are rumors it might be harder to decrypt non standard key lengths because of a specific software customization and optimization can be needed. So I guess if the key length is floating, say changed semi automatically and randomly (say in a range of 4000+RND*96) daily or weekly it may be even harder.

Desktop OpenPGP GnuPG is known to work with non standard RSA key lengths, most likely OpenSSH can do it too.

But I guess OpenPGP JavaCard firmware shall support it in the first place to be usable.

4

Could you link any page with such information?

Good point about needing a custom implementation, but again, that would not be a problem for a skilled cryptographic algorithms programmer. Even worse, using custom lengths might introduce unintended side-effects, like secret data leakage, while the common key sizes execution paths seem to be audited and proven. For ECC leaking even 1 bit is catastrophic for the key strength - see this article: LadderLeak: Breaking ECDSA With Less Than One Bit Of Nonce Leakage.

1 Like
5

Already done earlier:
https://blog.josefsson.org/2016/11/03/why-i-dont-use-2048-or-4096-rsa-key-sizes/
just please try to search there by a sub-string.

Though I did not try to verify this by myself yet on my installation.

1 Like
6

According to:

1024-bit RSA requires 2051 qubits (1024 Ă— 2 + 3) and 160-bit ECC requires far more than 320 (it requires 160 Ă— 6 = 960). RSA can be broken with 2n + 3 qubits, whereas ECC can be broken with 6n .

It would take about 8K qubits to break RSA 40xx keys and about 3K qubits to break a ecc521.

RSA looks more strong in terms of a break by a quantum computer and it may be not convenient to permanently change amount of involved qubits it RSA key size floats often? Sorry if I am wrong about “involved qubits”, I hardly understand how it works and do not even have any imagination about how to reconfigure their breaking algorithms for different key sizes.

7

Please suggest, is following supported by HSM2 and PRO2?

The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
algorithms have the advantage of using the same key type as
“ssh-rsa” but use the safe SHA-2 hash algorithms. These have been
supported since OpenSSH 7.2 and are already used by default if the
client and server support them.

According to:
https://www.openssh.com/txt/release-8.2

Future deprecation notice

It is now possible[1] to perform chosen-prefix attacks against the
SHA-1 hash algorithm for less than USD$50K. For this reason, we will
be disabling the “ssh-rsa” public key signature algorithm that depends
on SHA-1 by default in a near-future release.

This algorithm is unfortunately still used widely despite the
existence of better alternatives, being the only remaining public key
signature algorithm specified by the original SSH RFCs.

8

If OpenSSH performs the hashing, Nitrokey would sign it (so called off-card hashing).

9

I have tried a software 16K RSA key, it generated fine, authentication worked too, but log contains a record like: debug1: Server accepts key: pkalg ssh-rsa blen 2071

Not sure after that, does it use true 16K RSA key size or a cut key to 2071 bits:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /download/rsa16k/test_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg ssh-rsa blen 2071

How can I verify actual key length is used?
Would for NK RSA 4096 key it work any different?