What if there’s a host called o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy on my network? Unlikely of course, but wouldn’t it better if those domains were under some special TLD, like o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy.pkarr to avoid namespace pollution?
Unfortunately, there is no way to do key revocation reliably without introducing centralization (ICANN) or rent (ENS), for fundamental reasons.
But if you introduced centralization or rent, you might as well get human readable names, but we already have these with ICANN and ENS, and frankly ICANN is better.
So, the philosophy of Pkarr and the only way it can be valuable, is if we work hard to make losing keys a very rare occasion, and when that happen once or twice in lifetime, one has to bootstrap again, like they do when they lose their old phone numbers.
I repeat, if that is not acceptable, then you are left with ICANN with extra steps, and might as well just use ICANN.
Wether or not the UX work for keeping keys safe is viable, is a question that can only be solved by trying.
One is «I no longer have any copy of the key». The other is «people I don’t want to also have a copy of the key».
For the second case, assuming you can distribute any updates at all, you could distribute a special value «compromised» that can not be updated to any other value. And yes, this means you still need to start with a fresh identity and bootstrap, but the old one cannot be abused for too long.
I understand the intent of your question in two ways. One about purposely causing a name collision when in possession of the private key, and the second about collisions themselves.
For the first way, I would assume the design must force different keys for designing internal and external networks. This is an excellent question and although I didn’t read all the documentation, I would suspect this concern deserves special attention.
That’s base32 with a length of 52, so 256 bits. (Ed25519 public keys are 256 bits) Two things about 2^256:
2^256 is about the number of atoms in the universe (~10^76). Having a collision is like finding the same atom twice after shuffling the universe.
At the Landauer limit, and assuming you’re just flipping bits, and using E=mc^2, it takes about 300,000 solar systems of energy to count to 2^256, making collisions and other computations infeasible in a physical sense. (This is just napkin math, I’m sure the actual useful value is much higher.)
There shouldn’t be a collision at 256 bits. It’s not just unlikely, but it’s essentially impossible in a very physical sense unless something very is broken with the cryptosystem.
What is very possible is for me to learn you are advertising a pkarr address o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy in some public place, then to add o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy.localdomain to the local resolver where DHCP returns local search option .localdomain, let’s say just for fun. Not attacking the cryptography, not blind guessing, abusing access to the local infrastructure in a formally allowed way. What will software do?
The problem with namespacing what is supposed to be sovereign keys under something like .pkarr is that you you are putting yourself under the mercy of ICANN, hoping they never claim that .pkarr, meanwhile if you use keys as TLDs, they can’t target all keys at once.
More importantly: Pkarr itself really doesn’t stop you from using <key>.pkarr go for it, it is just not encouraged. What is encouraged is to use the DHT directly and not depend on DNS servers, including doing so inside browsers (eventually).
So even if being a TLD is a deal breaker, software that insists on using DNS servers that understand .pkarr can do so, they however need to trust these servers because servers won’t respond with signatures as the actual library (and HTTP relays) would
The problem with namespacing what is supposed to be sovereign keys under something like .pkarr is that you you are putting yourself under the mercy of ICANN, hoping they never claim that .pkarr
There are a bunch of gnarly little issues with single-label names, to do with the resolver search path, multiple name service protocols, assumptions about syntax, assumptions about local vs global scope, … They mostly come up as edge cases but they are really annoying to deal with. They depend greatly on the protocol and application, so if a single-label name works in some contexts, that’s no guarantee it will work in others. If you want to be as compatible as possible with software that assumes domain names, then I would recommend avoiding single-label names.
The idea of .alt is to add some kind of name service protocol name under .alt, e.g., pkarr.alt, then the name service switch doesn’t have to guess what protocol to use to resolve a name, and users can unambiguously specify how names are resolved. It’s a generalization of the .onion special-use domain name that allows other alternative name services to occupy part of the namespace without having to rent a domain name, and without getting into an argument with ICANN.
Not sure if it’s coincidence, but my project “Rostra” featured on lobste.rs main page right now uses Pkarr under the hood (along with Iroh for p2p communication, which also supports Pkarr as discovery mechanism).
I’m very excited about both Pkarr and Iroh because they make building sovereign and/or p2p applications very accessible.
Things I’d love to see is adoption of Pkarr in Linux so Pkarr names could resolve automatically system-wide. I think I might push the NixOS support myself, though I’m not an expert on DNS, and also I’m wondering if https://github.com/pubky/pkdns could be added as some kind of a … side-dns to resolvd etc. just to not need to replace the defaults for people that just want to try it out, etc.
and also I’m wondering if https://github.com/pubky/pkdns could be added as some kind of a … side-dns to resolvd etc. just to not need to replace the defaults for people that just want to try it out, etc.
Depends on what you mean by “side-dns to resolved”, but you by definition would need to change some configuration for any DNS traffic to be sent somewhere else.
The minimal way to do similar things in reaolved involves DNS routing but that’s not applicable here since this system doesn’t contain everything within a common zone. Which seems a bit silly to me as it would’ve made integrating it with lots of systems significantly easier while not noticeably affecting the domain name length/readability.
As it is the simplest you can do is set it up on some unused loopback address and have the user switch their configured DNS stub resolved to it.
If you have more time you could then also implement an NSS module that would query this other server if the top zone is of the correct pattern. That way they wouldn’t need to change their actual DNS stub resolver settings, but it would only affect things going through NSS. (Which, to be fair, is most things.)
Which seems a bit silly to me as it would’ve made integrating it with lots of systems significantly easier
Yes, it did occur to me that putting Pkarr pubkey as a subdomain of some non-existent TLD, would make some stuff easier, but I think Pkarr wants to be uncompromisingly a TLD in itself, so oh well.
As it is the simplest you can do is set it up on some unused loopback address and have the user switch their configured DNS stub resolved to it.
I see, so just like systemd-resolved sits on 127.0.0.53, pkdns could sit on 127.0.0.54. Possibly /etc/resolve.conf could even point at both? I think the default behavior is that if a given nameserver can’t resolve, next one will be tried?
If you have more time you could then also implement an NSS module
I realize that NSS is there, and /etc/nsswitch.conf is checked even before dns is involved, but I don’t even know how a module like that works. That might be an interesting learning experience, and indeed might be optimal. All Pkarr names are fixed size and format, so it could work very effectively.
I use pkarr to publish the IP address of my home server every hour, under the theory that if my IPs ever change while I’m away from home, I can use pkarr to resolve them from anywhere (and thus maybe have some hope of reconnecting back to my home servers), including using the web demo app (though this was broken for months).
I’ve never really needed to use this system. For me, it’s mostly a solution in search of a problem. But it’s fun to play with.
I’ve never really needed to use this system. For me, it’s mostly a solution in search of a problem. But it’s fun to play with.
I don’t get it. You just pointed at a really cool usecase. :D
Now I want a NixOS module like that will start this daemon, generate per-host ID, and then I can CNAME it my normal DNS (mydesktop1.dpc.pw -> ssh.<pkarr-domain>) etc.
The main usecase are sovereign identities, bootstrap system, temporary domain names etc. DNS is nice, but most normal people don’t really know how to get one, and you can’t get a DNS name without human intervention. An application being able to create and publish some kind of identity/name “in th DHT” that anyone else can resolve and is really useful in a lot of scenarios.
E.g. if you are deploying a service online, wouldn’t it be nice if it got a default name and TLS without user needing to buy a DNS name and configure anything? Sure, the default name is just a bunch of base32 characters, but it would work, and through there the user could possibly access UI etc. to customize it. Lots of chicken and egg problems would be solvable.
I also just came across this, whilst browsing around the Iroh site.
I used to mirror my Git repos in IPFS, with each having an IPNS name to track the latest version; but IPNS always performed rather poorly in practice and I stopped bothering. Pkarr looks like an interesting alternative, which is simpler and more mainstream/supported (thanks to using Bittorrent’s DHT).
In fact, I recently decided to set this up again; but replacing IPNS with GNS (GNU Name System, part of GNUNet). I spent a while getting GNS up and running, and once that seemed to be working I thought I’d spend some time looking at the storage layer, to see whether I’d like to replace the IPFS part too.
That’s why I was browsing the Iroh site, and that’s why I discovered pkarr, which seems much simpler than GNS! (In fact, pkarr’s FAQ has an entry for “Why not GNU Name System?”, which says it looks too complicated for the author’s current needs!)
What if there’s a host called
o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyyon my network? Unlikely of course, but wouldn’t it better if those domains were under some special TLD, likeo4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy.pkarrto avoid namespace pollution?What happens when keys need to be revoked? That’s why blockchains (like Ethereum’s ENS) are useful for distributed domains.
Ignoring revocation is an architectural mistake that projects continue to make. Gracefully handing revocation is paramount.
If the industry solves revocation, I’m confident these solutions would be much easier to adopt.
“Don’t loose the key” isn’t the answer.
Author of Pkarr here:
Unfortunately, there is no way to do key revocation reliably without introducing centralization (ICANN) or rent (ENS), for fundamental reasons.
But if you introduced centralization or rent, you might as well get human readable names, but we already have these with ICANN and ENS, and frankly ICANN is better.
So, the philosophy of Pkarr and the only way it can be valuable, is if we work hard to make losing keys a very rare occasion, and when that happen once or twice in lifetime, one has to bootstrap again, like they do when they lose their old phone numbers.
I repeat, if that is not acceptable, then you are left with ICANN with extra steps, and might as well just use ICANN.
Wether or not the UX work for keeping keys safe is viable, is a question that can only be solved by trying.
I think «losing the keys» has two meanings here.
One is «I no longer have any copy of the key». The other is «people I don’t want to also have a copy of the key».
For the second case, assuming you can distribute any updates at all, you could distribute a special value «compromised» that can not be updated to any other value. And yes, this means you still need to start with a fresh identity and bootstrap, but the old one cannot be abused for too long.
I understand the intent of your question in two ways. One about purposely causing a name collision when in possession of the private key, and the second about collisions themselves.
For the first way, I would assume the design must force different keys for designing internal and external networks. This is an excellent question and although I didn’t read all the documentation, I would suspect this concern deserves special attention.
If it’s a question about collisions themselves:
That’s base32 with a length of 52, so 256 bits. (Ed25519 public keys are 256 bits) Two things about 2^256:
There shouldn’t be a collision at 256 bits. It’s not just unlikely, but it’s essentially impossible in a very physical sense unless something very is broken with the cryptosystem.
What is very possible is for me to learn you are advertising a pkarr address o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy in some public place, then to add o4dksfbqk85ogzdb5osziw6befigbuxmuxkuxq8434q89uj56uyy.localdomain to the local resolver where DHCP returns local search option
.localdomain, let’s say just for fun. Not attacking the cryptography, not blind guessing, abusing access to the local infrastructure in a formally allowed way. What will software do?The problem with namespacing what is supposed to be sovereign keys under something like
.pkarris that you you are putting yourself under the mercy of ICANN, hoping they never claim that.pkarr, meanwhile if you use keys as TLDs, they can’t target all keys at once.More importantly: Pkarr itself really doesn’t stop you from using
<key>.pkarrgo for it, it is just not encouraged. What is encouraged is to use the DHT directly and not depend on DNS servers, including doing so inside browsers (eventually).So even if being a TLD is a deal breaker, software that insists on using DNS servers that understand
.pkarrcan do so, they however need to trust these servers because servers won’t respond with signatures as the actual library (and HTTP relays) wouldThat’s what the .alt TLD is for.
There are a bunch of gnarly little issues with single-label names, to do with the resolver search path, multiple name service protocols, assumptions about syntax, assumptions about local vs global scope, … They mostly come up as edge cases but they are really annoying to deal with. They depend greatly on the protocol and application, so if a single-label name works in some contexts, that’s no guarantee it will work in others. If you want to be as compatible as possible with software that assumes domain names, then I would recommend avoiding single-label names.
The idea of .alt is to add some kind of name service protocol name under .alt, e.g., pkarr.alt, then the name service switch doesn’t have to guess what protocol to use to resolve a name, and users can unambiguously specify how names are resolved. It’s a generalization of the .onion special-use domain name that allows other alternative name services to occupy part of the namespace without having to rent a domain name, and without getting into an argument with ICANN.
Not sure if it’s coincidence, but my project “Rostra” featured on lobste.rs main page right now uses Pkarr under the hood (along with Iroh for p2p communication, which also supports Pkarr as discovery mechanism).
I’m very excited about both Pkarr and Iroh because they make building sovereign and/or p2p applications very accessible.
Things I’d love to see is adoption of Pkarr in Linux so Pkarr names could resolve automatically system-wide. I think I might push the NixOS support myself, though I’m not an expert on DNS, and also I’m wondering if https://github.com/pubky/pkdns could be added as some kind of a … side-dns to
resolvdetc. just to not need to replace the defaults for people that just want to try it out, etc.Not coincidence: I discovered Pkarr while reading about your project, and posted it.
Depends on what you mean by “side-dns to resolved”, but you by definition would need to change some configuration for any DNS traffic to be sent somewhere else.
The minimal way to do similar things in reaolved involves DNS routing but that’s not applicable here since this system doesn’t contain everything within a common zone. Which seems a bit silly to me as it would’ve made integrating it with lots of systems significantly easier while not noticeably affecting the domain name length/readability.
As it is the simplest you can do is set it up on some unused loopback address and have the user switch their configured DNS stub resolved to it.
If you have more time you could then also implement an NSS module that would query this other server if the top zone is of the correct pattern. That way they wouldn’t need to change their actual DNS stub resolver settings, but it would only affect things going through NSS. (Which, to be fair, is most things.)
Thanks, I really appreciate your thoughts.
Yes, it did occur to me that putting Pkarr pubkey as a subdomain of some non-existent TLD, would make some stuff easier, but I think Pkarr wants to be uncompromisingly a TLD in itself, so oh well.
I see, so just like
systemd-resolvedsits on127.0.0.53,pkdnscould sit on127.0.0.54. Possibly/etc/resolve.confcould even point at both? I think the default behavior is that if a givennameservercan’t resolve, next one will be tried?I realize that NSS is there, and
/etc/nsswitch.confis checked even before dns is involved, but I don’t even know how a module like that works. That might be an interesting learning experience, and indeed might be optimal. All Pkarr names are fixed size and format, so it could work very effectively.Thank a lot!
I use pkarr to publish the IP address of my home server every hour, under the theory that if my IPs ever change while I’m away from home, I can use pkarr to resolve them from anywhere (and thus maybe have some hope of reconnecting back to my home servers), including using the web demo app (though this was broken for months).
I’ve never really needed to use this system. For me, it’s mostly a solution in search of a problem. But it’s fun to play with.
I don’t get it. You just pointed at a really cool usecase. :D
Now I want a NixOS module like that will start this daemon, generate per-host ID, and then I can CNAME it my normal DNS (
mydesktop1.dpc.pw->ssh.<pkarr-domain>) etc.The main usecase are sovereign identities, bootstrap system, temporary domain names etc. DNS is nice, but most normal people don’t really know how to get one, and you can’t get a DNS name without human intervention. An application being able to create and publish some kind of identity/name “in th DHT” that anyone else can resolve and is really useful in a lot of scenarios.
E.g. if you are deploying a service online, wouldn’t it be nice if it got a default name and TLS without user needing to buy a DNS name and configure anything? Sure, the default name is just a bunch of base32 characters, but it would work, and through there the user could possibly access UI etc. to customize it. Lots of chicken and egg problems would be solvable.
I guess the question is whether it counts as a usecase, if the fixed-connection IP address is not going to change anyway.
There’s always the path to your very own number station (or cryptic reddit bot or…)!
I also just came across this, whilst browsing around the Iroh site.
I used to mirror my Git repos in IPFS, with each having an IPNS name to track the latest version; but IPNS always performed rather poorly in practice and I stopped bothering. Pkarr looks like an interesting alternative, which is simpler and more mainstream/supported (thanks to using Bittorrent’s DHT).
In fact, I recently decided to set this up again; but replacing IPNS with GNS (GNU Name System, part of GNUNet). I spent a while getting GNS up and running, and once that seemed to be working I thought I’d spend some time looking at the storage layer, to see whether I’d like to replace the IPFS part too.
That’s why I was browsing the Iroh site, and that’s why I discovered pkarr, which seems much simpler than GNS! (In fact, pkarr’s FAQ has an entry for “Why not GNU Name System?”, which says it looks too complicated for the author’s current needs!)