It doesn't include any proprietary software and the whole thing is an open design that other people are able to build (and have successfully done so in practice). The primary purpose is for cryptocurrency wallets but it works well for U2F, GPG, SSH and various other purposes too.
-
-
Replying to @DanielMicay @nitrokey and
There are definitely options beyond proprietary ones, including options with much different approaches than a traditional HSM storing the keys with / without encryption (ideally with a passphrase entered onto the device). I really like the approach pioneered for Bitcoin wallets.
1 reply 0 retweets 1 like -
Replying to @DanielMicay @nitrokey and
Since that lets you generate keys on the hardware wallet, back up the high entropy recovery seed as a phrase, verify you backed it up correctly and then if you need to recover on a new device you can enter it directly onto a new hardware wallet without exposing it to a computer.
1 reply 0 retweets 0 likes -
Replying to @DanielMicay @nitrokey and
The traditional approach is good if you have existing SSH and GPG keys that need to be moved onto an HSM. I'll definitely prefer the deterministic wallet approach for new keys though. It's not that bad to migrate to new SSH keys but GPG tends to make rotating keys very painful.
1 reply 0 retweets 0 likes -
Replying to @DanielMicay @nitrokey and
Signing keys for firmware usually can't be rotated at all since they're burned into fuses so that's another case where a more traditional HSM is the best option since existing keys need to be migrated. Android app signing keys were similar, but they've finally added key rotation.
1 reply 0 retweets 0 likes -
I really like the
@nitrokey - code has been audited by@cure53berlin so that is a huge plus in my book, and there's tons of eyes on the code as@linuxfoundation maintainers use them as well. Nothing against@Trezor - they are an incredible company and I use their devices for btc2 replies 0 retweets 0 likes -
Replying to @RobertSpigler @nitrokey and
I'm talking about the differences in the approach though, not implementations, i.e. recovery / backups, passphrase entry and deniability along with whether keys / passphrases need to be exposed to a general purpose computer as part of that.
1 reply 0 retweets 1 like -
Replying to @DanielMicay @RobertSpigler and
Traditional security keys store keys and having those encrypted with a passphrase entry requires exposing the passphrase to the attached computer. Similarly, there isn't a great story when it comes to recovery / backups. I'm not knocking it as an implementation of that model.
1 reply 0 retweets 1 like -
Replying to @DanielMicay @RobertSpigler and
It looks like a good option for importing an existing key that isn't easy to replace, which isn't something a Trezor can do since it's not a storage device for keys but rather a device for generating them from a stored high entropy seed and entered passphrase.
1 reply 0 retweets 0 likes -
Replying to @DanielMicay @RobertSpigler and
I'm only saying that I prefer a better approach to the traditional key generation, backup and HSM model for new keys. I need to have backups and I don't want to ever expose my keys or passphrases to a computer since that defeats a lot of the advantages of using an HSM.
1 reply 0 retweets 0 likes
Robert Spigler 🔑 Retweeted Robert Spigler 🔑
There are definitely pros and cons to each. IMO, backups break the promise between the device and servers (or the computer when logging in, etc) that the key is tied to that particular device.https://twitter.com/RobertSpigler/status/1058491267099828224 …
Robert Spigler 🔑 added,
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.