I took a look and decided that I don't want to generate the quantum-proof key pairs on a networked machine. It looks like there is an offline path available in principle, but it seems like the key generation functionality is currently a bit entangled with the Nostr event signing functionality.

It would be nice if the key generation could be done airgapped, the unsigned Nostr event then transported to a networked device, and the event then be signed as usual (e.g. with nak or a browser extension).

I was facing a somewhat similar situation with Inkan and started using the following de-networked version of Tails for key pair generation. As a word of caution, this is just a working proof of concept and it has not been audited or anything like that, but it may be useful as a model:

https://gitlab.com/inkan_dev/inkan-offline-live

This is interesting. I think I may want to combine this with the Inkan key rotation / replacement system, which incidentally also records identity-defining declarations on-chain and provides similar OTS timestamping for all of a user's regular Nostr events.

I guess that, for quantum-proof key pairs to get associated with an Inkan identity, it's enough if the current signer key pair signs the quantum pubkeys. Through delegation, the quantum keys will then be automatically attributed to the master key that secures the Inkan identity, and can then be interpreted as a continuation of that master key.

Let me take a closer look at this, it seems to be a nice fit for getting Inkan identities prepared for a potential post-quantum scenario.

Thanks, that's good to hear. I was most likely going to see it anyway.

I'm assuming it's a bad movie? I was bored out of my mind by Oppenheimer.

observers are sceptical ...

"I understand, but you run into the same issue the moment your master key is compromised."

If you pay attention to the handling of the master key, it's quite unlikely that it will get compromised. You can create it on an airgapped system and then store multiple encrypted copies on, for example, 5 (or more) USB drives. You can store these USB drives in different secure locations, like a bank deposit box, a personal safe, or somewhere in your basement. You don't have to keep the master key close at hand since you will most likely never have to access it again after its creation (replacement of signing keys can be done using intermediary keys in the delegation chain, so you don't need to access the master key to perform signing key rotations).


"... intepertation complexity/demands."

The "interpretation complexity" can mostly be automated away. The Inkan client represents a prototype for how to do this. For the most part, the complexity has to be dealt with by the developer, not the end user. There is some residual complexity that the end user has to handle, mostly relating to the key creation and key replacement ceremonies. Basically, end users must learn to set aside 30 minutes to focus on the steps for key creation and replacement, and to use an airgapped device for that. This will feel like a huge bother and annoyance to people who are not used to it and where there is not yet social proof for the practice. But it is in itself easier to get used to than, say, driving a car, doing long division, or going to the gym.

When people complain about "complexity", one should distinguish "This looks like a headache to implement" from "This will be a headache to use". The first may be true to some extent, but it just reflects developer laziness ("I don't want to have to code this" is not really a convincing argument against a perfectly feasible protocol, and lots of commercially successful software implements far more complex methods). The headache-to-use point isn't actually true and it's being conflated with "I'm currently not accustomed to this and why should I be doing it when noone else is?" Again, I think the main challenge here is to get social proof for the practice and, and once that's been done, people will be less prone to confuse "I'm not currently used to this" with "This is difficult to use."


"... a president or something ..."

Nah, this feels like saying that only the clergy needs to learn how to read, what use could a peasant have for such skills. And this is much easier than reading.


"1: don't believe there will be one scheme that manages universal addoption. ... i deem 1 to be self-explanatory"

This isn't self-explanatory at all, in fact I think it's probably false. The reason it currently *feels* self-explanatory is, I think, again that there is not yet social proof for the practice. It's a bit like saying in the late 1970s that, at some point, there will be a personal computer in every home.


"... all (rigid formal) defenses like this that you implement turn against you and benefit the attacker the moment an attacker succeeds in penetrating them. If the running assumption is 'this master key is truth/my guiding star the moment there is appearent chaos', and that assumption is invalid, you just increased the problem."

I think it's preferable to put up better defenses rather than worse ones, especially if it's easy to do so. I wouldn't say that the master key is a "guiding star." But having a master key that you can expect with some confidence to keep over the long term may incentivize some people to invest more seriously in building online personas with large followings (e.g. 1 million followers) that attach to that key. The key will make these followers portable across the internet. Of course, there is still a risk of loss either due to compromise of the offline master key, or due to flaws in the implementation or in the underlying cryptographic algorithms. But this risk will be smaller than it is with the available alternatives, and that differential may persuade people that investing in an online persona is worth their time.


"If all you can do is extend what is ultimately the same problem ..."

It's not an extension of the same problem. The difference is that you can reasonably have *far* greater confidence in the integrity of a key that has never touched a networked computer. With proper precautions, you can have a very high degree of confidence that the device you used for key creation could not connect to the internet, and that the key you created has therefore not been leaked. You cannot, as a matter of principle, have any comparable amount of confidence that keys which sit "hot" on an internet-connected device have not been leaked. In other words, "ensuring that device X is properly airgapped and cannot connect to the internet" is a very different type of problem than "ensuring that key X, which sits hot on my laptop in a browser extension, doesn't get compromised." You have a great deal of control over the former, and relatively little control over the latter.


"... don't let me discourage you"

Can't be discouraged as long as the underlying math holds up. As long as there's asymmetric public key cryptography + blockchain timestamping, this type of permanent decentralized identity is far too intriguing as something that should be added to the internet's infrastructure. It sort of refocuses thinking about the internet, which is currently still conceptualized as a collection of "websites" on which users rent space and identity from platforms, to a collection of user identities that avail themselves at their own discretion of the communication infrastructure that the internet furnishes to them.

Strongly agree, with one important nuance / correction on this part:

"Same thing with the key stuff...do we have "house rotation" for the moment your house burns down?"

I need to point out here that a fully functioning key rotation / replacement scheme for Nostr currently exists. This is not an unsolved problem. It's fully implemented at Inkan and you can use it today. I've been using it for months.

The fact that people aren't looking at it or trying it out doesn't mean it doesn't exist. It exists and it works. See below.

Key rotation has been implemented through Inkan.

You can use it today if you like. See below.

Here is a blockchain-anchored identity that handles key rotation cleanly:

Apologies for the delay in responding, I'm still digesting this. I may not be technical enough to provide in-depth technical commentary on your device, but I'd definitely be interested in trying it out and getting a closer understanding of it when there's opportunity. As you know, I'm interested in offering an online identity that is secured by 100% airgapped credentials but can nonetheless be used for easy everyday authentication, and a signing device obviously fits into that picture.

As for Inkan, it's actually not EIP-712. There are three "inner" declarations that get signed ("Key X delegates signing authority to key Y", "Key X revokes it from key Y" and "Key X permanently invalidates itself"). Each declaration is signed with a plain secp256k1/ECDSA signature over a hash of the declaration, just a standard signed-message scheme the contract checks with ecrecover. Getting such a declaration recorded on-chain then takes a further normal Ethereum transaction that hands the signed declaration to the contract and pays the gas. So the identity signature and the on-chain-submission signature are distinct layers. There's also a sponsored payment mode, which adds an EIP-7702 transaction on top.

It still seems that the relevant signatures can maybe be handled by your device or something close to it. If you're interested in the details of what Inkan is signing, you could just download the source code of the Inkan Management Utiltiy here: https://www.inkan.cc/settings/inkan-management-utility. If you point your AI at the code, it can explain to you in detail what is getting signed and how.

That does sound pretty comfortable overall. I've never been beyond I think the sixth station, maybe I'll try this year.

You picked a hot day. How was the temperature?