I may forgotten something, but I didn’t find how I can use ECDH with Nitrokey Start, and it seems that ECDH is not present in the OpenPgp smart card application specification v2.
Regarding RSA, could I suggest changing a little bit the sentence in order to highlight that it’s only a PKCS#1 RSA deciphering that is supported by the card ?
Indeed I thought that the card will be able to provide me with the full result of a RSA deciphering, but correct me if I’m wrong, but it’s not the case.
I believe ECDH is mentioned in the context of encryption, which could be done with the GnuPG. I believe you are right, and ECC is not handled by OpenPGP Card older than 3.x, however Nitrokey Start has chosen elements supported from the OpenPGP Card 3.x and most of the OpenPGP Card 2.x (e.g. private DOs are not supported).
Thank you for the suggestion! Will forward it.
What do you mean by full result?
Many thanks for your answer. I found how to use ECDH with Nitrokey Start in the OpenPGPCard Specification v3.4.1 page 68.
So I will try it.
Regarding the full buffer, I meant the 2048 or 4096 bits without any format.
If we consider the OpenPGPCard Specification v3.4.1 page 67, I thought i will receive the 2048 bits and I will have to check that StartByte, Block Type, etc were there, and not receive the Data field only (L bytes). In the former case I will be able to create for instance my own CSR for this key. Since we don’t have the full deciphering buffer, we are not able to create our own CSR for decryption key.
Indeed, the “encryption/decryption key” is more a key agreement key.
Hmm, when I read the fact sheet for the NK Start, it states, that the RSA 4096 will take at least 8 sec. Have you been patient while you created that RSA key ?
Just to avoid any misunderstanding I haven’t created the RSA key with the Nitrokey Start. The device is not able to do it, if I have correctly understood. So I have created the RSA keys offline and store the private keys in the NitrokeyStart afterward.
But I have been patient for RSA deciphering which takes roughly 8 seconds. when I checked that my keys was correctly managed by the Nitrokey Start.
And I will have to wait each time, I would have to decipher a symmetric key protected by this RSA 4096 bits.
Consequently I plan to test how Nitrokey Start will behave with ECDH since I need to understand which algorithm is embedded in the key. According to the OpenPGPCard specifications
With its own private key and the given public key the card calculates a shared secret in
compliance with the Elliptic Curve Key Agreement Scheme from Diffie-Hellman.
so I assume that we will receive the value before any KeyDerivationFunction but I need to clarify this.
But before checking this, I would like to verify if I’m able to cope with this 8s processing time with Strongswan usage.
so when you look at https://www.nitrokey.com/files/doc/Nitrokey_Start_factsheet.pdf it states that it could generate/handle 4096 Bit RSA Keys - not only for en/decryption. But it will take the 8 sec and that will be the problem with strongswan: it will timeout earlier. I already looked through strongswan configuration and have not found a Key/value pair to setup the default timeout - it might be charon.retransmit_timeout , but I am not sure. I am not an expert on strongswan.
I just wanted to understand, if you can’t create a 4096bit RSA key on NKStart…
Don’t get me wrong, I have no problem with your question and I am not an expert too
I agree with RSA keys for Sign or Auth, but i moved directly to ECC for this, and was a little bit misleaded by the Encipher/Decipher notion and this is why I use RSA rather than ECC.
Bearing in mind your experience, and since I have another Nitrokey Start, I will check with a NitrokeyStart with 3 ECC keys.
I just wanted to correct, that generating RSA4096 on device is not possible with the latest firmware but importing and using is, with signing taking as much as 8 seconds. RSA2048 generation takes about 1 minute to complete (signing 1.2 s). Generating and handling ECC keys is much much faster (ECC signing is one of the fastest on the market, about 0.2 s).
thanks for clarification - so the datasheets needs to be updated or a better clarification as already mentioned. And yes, 4096 also takes long on the other NK’s ( and I don’t want to blame the NK’s, I think it is more a balanced matter between HW costs and usage )
Since NSA, also ECC are a bit in bad shape - was there not a roumor that some of them are not save ?
cc @nitroalex@jan : Could you update the performance details for the Nitrokey Start?
Speed for RSA is indeed troubling. However I think the transition to ECC should be done sooner or later. AFAIK ECC is not only faster, but also safer (to implement too) than RSA. I think here about this article.
According to this NIST document: Recommendation for Key Management (page 54, table 2) you need P384 ECC key for equivalent of RSA7680 strength, which should be faster to execute (I do not know whether this key size is handled by the Nitrokey Start though).
Do you refer to NIST curves? I think there was one about presumably intentionally weakened design, but until proved it will stay to be just a rumor. We need to operate on facts.
Some of the possible problems with the curves implementations were identified in the Daniel J. Bernstein and Tanja Lange. SafeCurves: choosing safe curves for elliptic-curve cryptography. https://safecurves.cr.yp.to.
One can of course use the Curve25x/Ed25x ECC curves, which are claimed to be better and selected NIST independently, which Nitrokey Start supports AFAIR.
ECC and RSA are not based on the same concept. RSA is based on factorization and if I remember well ECC on modular logarithm. It is considered that factorization is a polynomial time complexity. But modular logarithm is quasi polynomial time complexity. And the difference resides in the quasi. This is why you have the same security with shorter length key.
I tried to generate ECC keys longer than 256 bits, but failed each time, so I doubt that Nitrokey Start is able to manage P384 ECC keys.
Curves are not equivalent, and a lot of controls should be considered. For instance with the Cofactor : to make it simple the number of points you can generate with the curve, and obviously the order of your generator.
If you are curious, study this easy Curve
E : y2 = x3 + 2 with n = 7. so x,y in [0,6]
Regarding the ECDH computation, I need to dig a little bit more.
I tried this command :
Since I was not able to manage the ECDH computation wtih the NitrokeyStart I opened a dedicated topic to not pollute this one dealing with documentation. DECIPHER with ECDH Key.
when I checked that my keys was correctly managed by the Nitrokey Start.