Last Notes
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
Thanks, that's good to hear. I was most likely going to see it anyway.
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.
I'm assuming it's a bad movie? I was bored out of my mind by Oppenheimer.
observers are sceptical ...
Not sure if I'll still be in Tokyo then, but if I am I'll definitely go.
Yes, it should be easy to add on actually. I might just do it as an exercise and initially charge 0.00 and see if I can find any takers at that price.
For Bitcoin, I'd be nervous to keep keys that hold larger amounts on a device with WIFI capabilities. On the other hand, for keys holding smaller amounts for everyday use, this seems very appropriate and convenient, including the choice between QR and local network.
For Nostr, I'd again be nervous about holding my identity-securing key on a device with WIFI. But for my everyday signing key, a device that can do NIP-46 remote signing over WIFI seems ideal. As we had already discussed, this is complementary to the separation between identity key and signing key that I've implemented with Inkan.
Part of the reason I'm curious about all of this is that airgapped signing of certain transactions is part of the core idea of Inkan. The transactions that need to be signed in an airgapped environment are delegations and revocations of signing authority between key pairs, and these then need to be recorded on Ethereum.
I made the "Inkan Management Utility" (https://www.inkan.cc/settings/inkan-management-utility) to perform this airgapped signing. It's a working prototype / proof of concept at this point, certainly not an audited product. It's meant to be run on an airgapped Linux system (as I mentioned I use a de-networked version of Tails), but I'm sort of curious whether these types of key delegation transactions could ultimately also be signed on a bespoke signing device of the kind you're making.
npubs that are part of Inkan identities are recorded on Ethereum when the identity is created.
The recording of an identity currently costs about $0.80 - $1.20 in gas fees. Users can make a request for sponsored payment of the gas fees at https://www.inkan.cc.
I guess it's not a sure-fire way to distinguish npubs that have real persons behind them from those that don't, but it's definitely a signal.
That does sound pretty comfortable overall. I've never been beyond I think the sixth station, maybe I'll try this year.
"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.
#nevent1q…r4gy
#nevent1q…zyrs
Key rotation has been implemented through Inkan.
You can use it today if you like. See below.
#nevent1q…r4gy
#nevent1q…zyrs
Here is a blockchain-anchored identity that handles key rotation cleanly:
#nevent1q…r4gy
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.
It's much more crowded than it used to be. The hill country is full of cars now, it feels a little bit like L.A.
You picked a hot day. How was the temperature?
I usually walked around shirtless all about Austin, with several T-shirts in my backpack in case I wanted to go to one of their refrigerator movie theaters.
One of the beneficial contributions Nostr is making to the world is that it forces people to learn key pairs. That's precisely one of the reasons you want people to use Nostr, so that they have to learn them.
If you're in downtown Austin right now, you could stop by at Pete's Dueling Piano Bar. Can be fun for a Saturday night.
Well it looks like you found me sir. And your npub seems to have been active before I wrote the note above, although that's precisely the sort of timing question that I'd prefer to be able to verify with OTS timestamps (if you were an Inkan user your notes would have these).
Now the thing is that the pricing seems really quite steep for what appears to be AI-directed audit, so probably not. But it's still interesting of you to offer this service.
Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
The prototype is here:
https://www.inkan.cc
https://image.nostr.build/e1f639c89bcc211bbff5a335a913b5982245e273cadfa51e4bf0df2e60eee83a.jpg
Let me know any questions.
I guess I could offer the Inkan relay.
I originally set it up for testing, but if anyone would like to just use it just in a regular way and is a very well-mannered person, please feel free to request access at https://www.inkan.cc.
One neat feature is that the events you post automatically get OTS timestamps. You can retrieve these timestamps and keep them as proof of when you created your events.
It's free. What I get in return is a chance to practice running a relay, and to practice content moderation on you.
https://www.nytimes.com/1977/10/19/archives/harassment-alleged-over-code-research-computer-scientists-say-us.html
I looked at the site overall. I can't really comment on the hardware tooling since I don't know much about that topic, but the amount of detail that's included plus the effort to not over-promise make it seem conscientious and to some extent trustworthy. I guess "trustworthy" may not be the best word because there's an emphasis on auditability, verification, and disclosure, so in a way you're not asking for people's trust, which seems like the right posture.
The combination of secure boot + source code for the firmware + reproducible builds is maybe enough to make the device auditable, at least to the extent to which that's possible at all? Not an expert, but I guess the residual trust is that these things are actually implemented correctly and as promised at the hardware level?
One thing that wasn't completely clear to me from a quick look is what *types* of things can be signed by the device. It seems like it's "Bitcoin transactions" and "Nostr events", and I guess any type of event? Can anything else be signed?
I'm interested in technologies that keep the signer key safe and make signing convenient. I haven't focused on that part, but it's complementary to Inkan.
Let me take a look at what you build. If you have a favorite description of it somewhere, feel free to point me to it.
I think this is all really important to the advancement of the protocol.
Yes, I thought about that. It would be cleaner though if I can just tell people to contact me directly at my regular npub. Also using another key for DMs doesn't necessarily address the issue of being able to promise some degree of privacy to the people who contact you.
It's one thing to use DMs with people you're already acquainted with. It's another thing to go out and solicit the general Nostr user base to send you DMs. After all, the persons you're soliciting might then have an expectation that the info they send you is kept private, and I'm wondering if Nostr DMs are mature enough to justify that expectation.
Maybe the solution is just to tell people that they can DM you, but attach a disclaimer that I don't actually fully know how well DMs currently guarantee privacy.
Just something I thought about recently, and your post reminded me of it.
This is a problem I was facing recently, i.e. asking other Nostr users to get in touch with me privately.
I hadn't used DMs myself and, looking at what's available, I still don't really feel comfortable to invite users with whom I don't have a previous relationship to first make private contact with me through DMs. So I ended up just posting an email address for other users to contact me.
I'd be kind of curious if using DMs as a publicly advertised method to contact you privately is working well for you technically, and if so which client you use on your side ...
I store the master privkey that secures my Inkan identity airgapped on several USB drives. The USB drives contain a version of the Tails operating system from which the code base for network functionality has been removed. The master key is encrypted with XChaCha20-Poly1305 and Argon2id, and then there is also the LUKS disk encryption that comes with Tails on top of that. The USB drives are kept in secure locations. Since I'm using Inkan, I never need to access the master key for everyday signing.
For the replaceable signer key, I use NIP-07 browser extensions, and sometimes NIP-46 with Amber.
We're talking about (i) Bitcoin for OTS timestamping of Nostr events, and (ii) Ethereum for recording declarations of delegation and revocation of signing authority.
Onboarding is indeed the hard part. Not much success so far, including within the Nostr community (which is a bit disappointing).
If you're feeling avant-gardish, there is a "Create a Toy Identity" button on the landing page at https://www.inkan.cc. It's very quick and the instructions at the end of the process include an option to send me the toy identity creation transaction (which does not include any privkeys or secrets) for sponsored payment of the Ethereum gas fees. These one-time gas fees typically run between $0.80 - $1.20 or so, and I'm happy to cover these for people who'd like to try it out.
Also, feel free to ask any questions -- always happy to chat about this.
明日と明後日、東京のWebX2026に参加する予定です。
参加される方、ブースを出される方がいれば、ぜひ声をかけてください。
Yes, pretty much.
You get a "master" key that stays offline in cold storage and never does any day-to-day signing. That's your real identity, and that's what your followers attach to. You also get a separate signing key that you actually post with.
When the master key is first created, it signs a statement delegating signing authority to the signing key. That statement is recorded on a blockchain. After that, any notes signed by the signing key get attributed to the master key by the Inkan client.
If the signing key ever leaks or gets lost, the master key can sign another statement (also recorded on-chain) that revokes the old signing key and re-delegates to a new one. Your identity, i.e. the master key, and the followers attached to it never change. The only thing that changes is the signing key underneath.
It's actually even a bit more powerful than that, since you can create *chains* of delegations from the master key down to the signing key. That means you don't even need the master key for revocations, an intermediary key in the chain can handle them. So after creating it and signing the initial delegation on an airgapped system, you can basically keep the master key in a safe deposit box or buried in your cellar and most likely never touch it again.
For a more detailed explanation, see below.
#nevent1q…4pj3
Hmm, looks like I have to look up Cayley trees and Bethe lattices. See if I can figure out what is going on.
I suspect it's the same with senior developers. I'd recommend competing at the senior level.
That sounds ambitious if it's meant to be a step in the direction of making deepseek 4 run on your laptop. I've sometimes made ambitious claims myself, so I take care to never be entirely dismissive. Proof is in the pudding I guess.
I'd much prefer that, it would be great if it turned out like that.
Oh, our darling weirdo / mad prophet. I guess my concern is who will own the physical infrastructure. I gather it's expensive. A high degree of decentralization of control over that would be desirable. As a sort of political / society building project.
My main worry about AI is who will own the means of production.
It's not a bad time to revive that good old Marxian phrase.
Inkan separates your identity from your signing key.
If the signing key is leaked or lost, revoke it. Switch to a new one. Same identity. Same followers. New signing key.
The prototype is here:
https://www.inkan.cc
https://image.nostr.build/9ad72700d44765da63fa5e9b550ef801cc3f913ec1770bc726183736691632a4.jpg
Let me know any questions.
Not leaking anything "beyond proof" raises the question what's included in the "proof." You're right I should ask a chat bot about this, and that's precisely what I'll do.
I need to read up on the fundamentals of zero knowledge proofs. There are lots of online articles that try illustrate with "easy" examples what they are, but the explanations are often barely coherent. There are definitions like "a method by which one party can prove to another party that a statement is true, without revealing any information apart from the fact that this specific statement is true." But then if you look at the examples, it seems like there is tons of additional information being revealed to the other party. It feels like what they mean is "a method by which one party can prove to another party that a statement is true without revealing *certain specified* other kinds of information that one wants to keep secret to the other party." That's of course fine for what it is, but then they probably shouldn't be called "zero knowledge" but instead "limited knowledge" proofs or something like that. But I need to read up on them before I say too many ill-informed things.
Well, the original post wasn't meant to be quite as conclusive as you make it out to be. I was just trying to figure out what's going on.
It seemed useless if it's traceable. Then you told me that it's not traceable. So that then made me wonder what use cases there are for an ID that you can present in such a way that it's not possible for anyone to determine the identity of the owner.
You can't cryptographically confirm that you are providing the service to the actual owner of the ID, but maybe you can confirm that you are providing the service to a device where the ID is installed? I.e. maybe you can confirm something like
"I'm providing this service to a device that has an ID installed for someone for which the EU attests that they are over 18."
And it's assumed that the owner of the ID is in possession of that device, and that assumption then justifies the idea that you are providing the service to the owner.
If that's the picture, the EU will have to ensure that the ID for a person can only be installed on devices that the EU has confirmed are controlled by that person. It's a device-bound ID, and it can piggy-back on the mechanisms we currently have for binding devices to their owners.
I certainly can't trust it right now without knowing a lot more about it. In this case, I'm also interested in the conceptual question whether it's in principle possible to build something that allows you to prove that you're over 18 without revealing further info about you, and which is useful in practice. I'm having a hard time getting my mind around it.
It's a peculiar feature of this system that there is no way for anyone to ever identify the person who provided the proof that they are over 18.
Presumably you are doing the age verification to provide some service to someone. If you can't ever identify the person who provided the proof that they are over 18, how can you ever confirm that you are providing that service to them and not to someone else?
With regular IDs like a passport, you can always (if you kept a record of the ID) track down the person to whom the ID belongs and investigate whether the service was really provided to them.
If the tokens can't be tracked back to a particular person by anyone (including the EU itself), what prevents someone from using someone else's token?
Suppose your relay has an 18-and-over policy and I want to request access to it for my pubkey. I'm 17 and my friend is 19, so I ask my friend to send to you
(i) the pubkey for which I'm requesting access and
(ii) a token proving that the EU attests to the fact that the person who produced the token is over 18 (which my friend can produce)
It seems like you'd be giving the pubkey access to the relay based on this info, since the person who sent you the pubkey could prove that they were over 18. And I can then start posting notes to your relay with my pubkey, even though I'm only 17.
And nobody could ever prove that my friend participated in this deceptive arrangement, given that the token that was provided cannot be tracked back to my friend. The token could have come from anyone over 18.
You can see I'm still struggling with this conceptually ...
Ah, but actually there's a further wrinkle to it:
Suppose I send such a proof to the tobacco store. If the tobacco store later shares that proof with the EU, will the EU be able to determine that the person who sent the proof to the tobacco store was me?
So the idea is that there will be a proof showing that the EU attests to the fact that I'm over 18?
And this proof will provably be generated "locally" on my device without in any way phoning back to the EU?
And I can then send this proof to anyone and they will be convinced by it?
If that's what it does, it would be quite useful. Not sure though if I'm understanding it correctly.
Are these tokens issued without giving the EU the ability to know where they will be used?
So if I want to buy a cigarette, does the app issue a token proving that I'm over 18 without giving the EU the ability to determine at what tobacco store I'm using it?
I'm scrolling through the Q&As on the website you linked to, and am not yet seeing the answer.
Based on the article it seems like, even with a carefully designed protocol, the role of credential issuers will be a problem.
I gather that verifiers need to trust issuers. In practice, this likely results in there being only a few widely trusted issuers, most likely large institutions like governments.
The article then suggests that issuers will be able to track where and how the credential is being used. I read that to mean no anonymity at all vis-a-vis the issuer.
The very possibility of such tracking by the issuer seems like a fatal flaw. Unless there is a way of proving to everyone that such tracking is not occurring, one would need to rely on mere assurances to that effect, and that seems unacceptable.
Not sure if I'm putting all the pieces together correctly, but that's my current understanding.
So these attempts by governments to introduce online age verification requirements, are these going to use zero knowledge proofs?
Are they trying to sell this by floating the idea that you can prove your age while still remaining "anonymous" in some sense or another?
From what I'm reading, it seems that zk proofs won't really work to achieve this in any truly meaningful way. See for example this for a critique:
https://brave.com/blog/zkp-age-verification-limits/
Does anybody have any insights into what's going on here?