Choice of curves on the Storage 2

Nitrokeys
#1

I’ve been waiting for the Storage 2 for a few weeks now and planned to buy it the day it is released. I’m not sure anymore as I’ve seen that the Storage 2 only supports NIST and Brainpool and these two curves are both reputed unsafe.

On https://safecurves.cr.yp.to/, it is said that both are unsafe. On GnuPG - What’s new in 2.1 it is said that many people think both have a doubtful origin.

Why didn’t you include Bernstein’s Curve 25519 which is GnuPG’s future default: “ed25519/cert,sign+cv25519/encr”?

#2

I would agree with you, however I am hoping they know what they are doing.

But yeah, regardless of if those curves are safe in gnu privacy guard or not or in nitrokey-app, I would still highly recommend someday adding Curve25519.

Even if its a Nitrokey-Storage 3 option. Seriously, it would be awesome to have that curve… or one as secure. :slight_smile:

#3

Please be careful. At safecurves.cr.yp.to curves are primarily evaluated with focus on complexity and implementation considerations. There “unsafe” means that the implementation needs to be performed carefully and may be more complex and error-prone than for other curves. “Unsafe” is different from “insecure”.

If you don’t trust NIST curves, Brainpool is for you. I’m not aware of profound critic on Brainpool curves.

Because Curve 25519 isn’t supported by the smart card chip we are using. Also Curve 25519 has the disadvantage that it is hard to protect against side channel attacks when being implemented in embedded devices. From this perspective, NIST or Brainpool may be more secure.

Note that our Nitrokey Start does support Curve 25519, perhaps this is an option for you.

#4

Thank you very much for your detailed answer @jan.

what makes it suitable for the Nitrokey Start then?

#5

I didn’t mean that it is a show stopper to prevent the implementation of Curve 25519. I’m just saying that Curve 25519 isn’t perfect and that the devil is in detail.

#6

The implementer of Curve25519 says the exact opposite:
https://lists.gnupg.org/pipermail/gnupg-users/2018-June/060741.html

#7

This is interesting, so is brainpool better than curve25519?

Just wondering, and if so, which one is the best of the brainpool curves?

I will though say, safecurves hasn’t been updated for a while, so you could be correct about curve25519’s weakness.

What do you mean by side channel attacks by the way? Like a cold boot you mean?

#8

A question/proposal to escape the “Curve vs Nitrokey-problem” :
Wouldn’t it be a reasonable approach to generate a Curve22519-Masterkey externally (only signing-capability) to have a “secure” identity even after the era of RSA4096 ends?
To use this master-key on the Nitrokey you generate RSA4096 subkeys for the daily routine and import it onto the Nitrokey.
When their time is over, you are able keep your Curve22519-Identity and just replace the subkeys?
Greetings,
niklas

#9

You don’t need the signing capability for your master key, you need the Certify one. The Sign capability can be given to a dedicated sub-key that you would put on the token.

Pay attention that some people say that RSA might be more secure than elliptic curves in the context of quantum computers: https://crypto.stackexchange.com/questions/60392/choice-of-ecc-curve-on-usb-token

The Nitrokey might take quite some time (several seconds) to work with such large keys. You need to experiment to know if that is acceptable to you or not.

yes. Changing subkeys is easy.

#10

With Nitrokey Pro and Nitrokey Storage operations with RSA-4096 should take less than a second.

#11

On my system with Nitrokey Pro and RSA4096

comio@gentoobox /tmp $ ls -al testfile.txt 
-rw-r--r-- 1 comio users 5091 12 lug 16.19 testfile.txt
comio@gentoobox /tmp $ time gpg -a -r a@b.c --encrypt testfile.txt

real	0m0,102s
user	0m0,024s
sys	0m0,045s
comio@gentoobox /tmp $ time gpg -a --decrypt testfile.txt.asc  > testfile.txt.decrypt
gpg: encrypted with 4096-bit RSA key, ID 0xD6B1D10FE58271F8, created 2017-08-01
      "A B (comio) <a@b.c>"

real	0m3,612s
user	0m0,046s
sys	0m0,023s
comio@gentoobox /tmp $ diff -u testfile.txt testfile.txt.decrypt
1 Like
#12

Please note, that it is basically only the NK Start which is very slow with RSA-4096 (usually said to be about 8 seconds per operation). All other devices should be reasonable fast.

#13

off-topic: @nitroalex we should make some benchmarks sometime (e.g. with Graphene).