onion like domain with ed25519 about kadnode HOT 9 CLOSED

Interesting to know. I will take a look.

from kadnode.

It would be nice to swtich to ED25519, but it seems the implementation in mbedtls is not complete (enough). I do not find an entry here: https://github.com/Mbed-TLS/mbedtls/blob/development/library/ecp.c#L404

from kadnode.

oh, that's sad. Thank you for the answer!
I'm also interested in your opinion about if the idea of having interoperable domains between tor onion and KadNode makes any sense to you.
Thus if the KadNode is not installed a user still can open a link but just by using a Tor browser.
Also the onion domains are shorter because they are Base32 encoded. Why the KadNode uses hex?

Initially my goal was to create a Dynamic DNS server that doesn't needs for a manual registration step.
And idea was to generate an onion domain. To update a DNS record just send a signed request with privkey. See https://github.com/yurt-page/dyndns-onion

Then I came to idea to also use DHT i.e. the same as KadNode :) And the KadNode is perfect!
But the main difference is that I want to anybody who even doesn't have a kadnode installed to be able to open such sites. So now I think to setup a KadNode on my jkl.mn server and make it as NS for all subdomains.
But the resolution via DHT would be long. So still think to just implement a simple DNS record update with a plain GET request. So that the DHT lookup in KadNode network will be performed only if the DNS record wasn't found in my database.
If my jkl.mn DNS server will be blocked or disappears users still can install the KadNode to get to a site. Basically I hope that ICAN can just make the .p2p domains as a special TLD similarly to .onion and .bit https://tools.ietf.org/id/draft-grothoff-iesg-special-use-p2p-names-01.html. But unlike those domains in fact such DNS queries won't be blocked by a DNS but instead be resolved by any recursive DNS including a top root. But this is something for a future. Now I hope that it would be sufficient to just have a subdomains.

While doing a research I also found GNUnet Name System which is also DHT based but it looks so complicated so that I'll just leave it alone.

The KadNode seems so small so that may be included into OpenWrt by default. Like imagine that any OpenWrt device already have some domain out of the box. That would be cool.

from kadnode.

Hi @stokito

if we can have some interoperability between TOR and KadNode addresses, then that would be nice.
Anyway, the addresses that KadNode use are already in Base32. In the source code it says base32hex, which is confusing, I will fix that. :-)

While doing a research I also found GNUnet Name System which is also DHT based but it looks so complicated so that I'll just leave it alone.

You are not the only one who has this impression.

Is there anything specific that need to be done? I do not have the full understanding of your idea yet.

from kadnode.

Thank you

from kadnode.

Sorry for rising the old topic. I just want let you know that openwrt has usign utility and internally it has the ed25519.

We can generate a key pair:

usign -G -s onion.key -p onion.pub

Then the onion.pub will look like:
RWSNGBSrjIP7GAZN409X3/x2vi+4e2BpScIQcarK8bP/yyEesp7h0DxH

First digits are fingerprint of the key.

So basically it's possible to generate the ed25519 domain even without the OpenSSL on a router.
Except of a domain generation and TLS verification does the mbedtls is used for anything else? SHA1? It looks like the KadNode can have own code just for the DHT client.
I saw that you extracted dhtd from KadNode and it doesn't have any TLS dependencies.

For me this is a good news because I can write a simple DDNS client in shell that will use the usign to sign an IP and then use uclient-fetch to update domain's A record.

Yeah, and we can also use a Dropbear to generate an ed25519 key pair. But no signing there.

from kadnode.

hi,

yes, I think using ed25519.c in KadNode might be possible. But it is hard to find time to integrade it.

I saw that you extracted dhtd from KadNode and it doesn't have any TLS dependencies.

For me this is a good news because I can write a simple DDNS client in shell that will use the usign to sign an IP and then >use uclient-fetch to update domain's A record.

Yes, that is the plan. Let users use the DHT from the command line. But development is in phases. I do not have an ETA for when it is usable.

from kadnode.

Thank you, I will also back to this in a month or two. Just learned about the usign.

from kadnode.

I have fixed a few issues in DHTd. It might need polishing, but otherwise it should be usable.

from kadnode.