Posts Tagged ‘ Namecoin ’

Web-of-Trust DNS

Originally published here, copied below (edits and references coming later):

Previously mentioned on my blog here:

WoT-DNS – Description


TL;DR: A system for deciding where domain names should go based on who you trust.

WoT-DNS is my proposal for a new P2P based DNS system.

This system decides where a domain name like reddit.wot should go based on your trust, as an invidividual; it does not care about the opinion of random strangers. You are the one who choose who’s trusted and who’s not, since it’s using WoT (web of trust). Also, domain names are intentionally NOT globally unique, since the only way to achieve that is with a centralized service or a first-come, first-serve system like Namecoin, and I dislike both those solutions. This means that if you would ask for a sitename like reddit.wot, you could get many results instead of going straight to one site. But whenever one site is trusted (for you) much more than the rest (like reddit’s official site would be), that’s where you’ll go.

Basic idea: Gather site registrations for a domain name from the network and from friends -> calculate your WoT metrics for each of the results -> pick the top site if one stands out at the top as most trusted -> let the application go to that site.


Every participant runs a WoT-DNS client. There are several ways to enable browsers and IM clients, etc, to use this system. One is to run a local proxy where only .wot domains are intercepted, and normal traffic are untouched. When connecting, it would start by asking the WoT-DNS network about who has registered their site with that domain name.

Every client has a unique asymmetric keypair, both regular users and servers have them. Servers additionally generate one unique keypair per registered domain. Registered .wot domains are identified by their key. Each registered domain has at least two addresses: The readable one, such as example-domain.wot, and one that contains it’s public key hash (like I2P, [the 52 base32 characters of the SHA256 hashed public key].key.wot, so “key.wot” are one of those domains you can’t register). That means you can always go directly to a particular site by entering it’s key hash.

A domain registration has to contain at least this: The domain name, the server’s public key, addresses (yes, more than one if you like, useful for load balancing and to additionally specify I2P/Tor addresses along with regular-internet IP addresses). Additionally, you can add all the data that ordinary DNS servers can hold for a domain. Also, it can hold a site name and a description of the site, which is useful for telling sites with the same domain name apart. All registrations are also timestamped. I would also like to see a trusted timestamping system built in, to ensure that nobody claims that their domain registrations are older than they are, and the point is to prevent phishing by faking a site’s age.

Domain registrations are stored in a distributed database. This means that every node keeps local copies of plenty of registrations. Updates will be continously added to the distributed database (such as when IP addresses change), and the old registrations are then replaced (but only if the keys and signature match). I suggest that we use some DHT system (“distributed hash table”) like Kademelia for the database, or something similiar that provides the features we need.

The Web of Trust part:

The keypairs make this possible. Since everybody has a unique key pair that consists of a public key and a secret one (using asymmetric cryptography, public key encryption), PGP makes it possible to create signatures of data that likely can’t be forged in our lifetimes. 2048 & 4096 bit keys using RSA are highly secure (while I prefer larger and safer 4096 bit keys, they’re unfortunately also about 5-6 times slower). Keypairs are both used by the site owners for signing their domain registrations, as well as by users that additionally sign them as a means to show that they trust that that site. You can also sign a site as untrusted.

WoT details: You have a list of trusted people and organizations, including their public keys. Organizations like Verisign (SSL certificate authority) could be predefined for the sake of newcomers, this will make it like SSL out of the box. If a site has been signed by a friend or by a trusted organization your client will detect that and calculate what level of trust (trust metric) that site gets based on it. Since there can be several sites for a domain name, the site with the highest trust metric are the site your client chooses to go to. If both Microsoft and a spammer registered microsoft.wot and only MS has a signature from Verisign, then Microsoft’s site will be more trusted so your client will prefer to go to Microsoft’s site if your client is set to trust Verisign.

If the site in the top don’t have a trust metric that’s high enough (not enough trusted signatures or less than around 30% higher trust than the runner-up) it triggers some an alert (some spam/scam detection should also be built in), then you won’t be sent to the top site right away – instead you get a list of the matching sites, ranked by the trust metrics.

So, how are trust metrics calculated? There are PLENTY of ways. One is to assign various levels of trust to your friends, and then simply take a look at how trusted a site is by the people in your web of trust, such as your friends friend. If it’s fully trusted by somebody you fully trust, then you fully trust the site. If it’s a bit trusted by somebody you trust a bit, it’s just a little bit trusted by you. And that’s just the short version!

Note that a signature of a domain from a user or organization as Verisign aren’t intended as a method to indicate how trustable the site owner is, it’s primarily a means of voting in this case (choosing who gets what domain name). The trust part is secondary, but necessary to make sure that scammers and spammers won’t be able to take over popular domain names to trick people.

So how do you get started? If you want to clear out Verisign and those from the predefined list because you don’t trust them, how do you add people you trust? Well, one way is to “bootstrap” using social networks. Let your client announce on Facebook, Twitter or Google+ that you now are using WoT-DNS with a message that contains the key. When your friends start using WoT-DNS, their clients will automatically find your key and connect to you (if they choose to connect to the same social network). Then you’ll have a list of your friends in your client, and can set the trust levels there. And we don’t need to limit it to social networks.

For site admins: While sites will have one keypair, it’s not the only one. Your client also have your personal (or corporate) keypair that your site’s key will be signed with. This “master keypair” for that site can be kept away from your servers, so you can keep it encrypted on a drive in a safe (obviously you can have multiple separate keypairs, so you don’t need that level of security for the rest). If the server is hacked and somebody get your site key, you can issue a revokation signature with your master key pair, which will tell everybody that the site’s old keys now are revoked.

Then you can restore the servers and generate a new site key, and all the old trust signatures can be “moved over”. This won’t be automatic, but everybody who has signed the site key will get notified about the replacement key pair so that they can sign it.


  • Vulnerable to targeted social engineering. A scammer could try to trick several close friends of some CEO to sign his site, in order to convince the CEO that his site is legitimate.
  • Trust metrics. How do we calculate them? How do we make them hard to “game”/mess with?
  • Evaluating trust. How do you know if your friend can judge if a site is legitimate? How do you yourself know if a site is legitimate?


  • Botnets/spammers that mass-sign phishing sites’ keys. This is only a problem if a significant part of YOUR Web of Trust (your friends) sign the site’s public key and it hasn’t been flagged yet by somebody like Microsoft or Google (they keep their own blacklists already for spam domains for use in Chrome and IE).
  • A bunch of strangers or Group X or Group Y signing the key for a site that’s in conflict with the one you want to go to from Group Z. This will NOT prevent you from getting to the site you want. Just don’t set your client to trust X or Y. But yes, this means that followers of different groups can end up on different sites for the same domain name. This is by design, as I can’t come up with any other solution that isn’t first come, first serve, and that would make domain names globally unique. So I’m allowing domain name conflicts and letting different people get to different sites for them. I do not see this as an issue.
  • Non-static URL:s. We can have those too, but you need to use the key hash domain names. A static URL could look like this: abcdef0123456789abcdef0123456789abcdef0123456789abcd.key.wot/news/global/reddit-is-awesome.php
  • Single point of failures/hacked Certificate Authorities. Remember that we are computing a site’s trust based on what ALL of the nodes that WE trust think of it. A single flag from somebody you trust could alert you about a malicious site. If Verisign were to be hacked, it could be a flag from StartSSL. Or from somebody else. Doesn’t matter. All it needs is one warning. But the scammer has to trick almost everybody you trust into trusting him.

Feedback and questions, please! Please contribute by giving me feature suggestions, or by pointing out possible problems, or by just telling me about any useful idea you might have. All feedback is welcome! If you don’t like my idea, tell me why!

[This is not finished yet, it’s a work in progress…]

A decentralized hash-chained discussion system

After thinking for a while about how I want a discussion system to work. Since I’ve seen numerous forums get abandoned, old archived discussions getting lost when servers crash, discussions jumping between various forums and chat rooms and blogs and more, etc, I came to the conclusion that I want a commenting system that is directly focused on the posts themselves, and which is decentralized and can easily reference external discussions, and where you don’t simply lose the history of old discussions because one server went down.

So with inspiration by Git and the Bitcoin blockchain, I’ve got an idea about a discussion system based on posts encoded in JSON (or a similar format, maybe XML), where each comment is signed by it’s author(s), references its author’s profile/ID (ideally in a verifiable manner, such as referencing a cryptographic public key), has topic tagging, which references to the comments it replies to with the hashes of the comments (so that anybody reading it can verify exactly what the author was responding to), and more.

The default use case I’m considering is the one that would work like mailing lists (email servers that relay messages sent to it to its subscribers, so you can discuss topics with a group of people by email). In this system the equivalent would be what I call a channel. A channel would be defined by an initial “channel definition post” that declares that a specific method of delivery (or several!) of the messages is to be used, what topics is allowed, moderation rules, where you can find an archive of messages, and other relevant details. You could then register with the server from your client (if registration would be required on the channel), send in your messages through the defined method (uploading to the server by default – serverless distribution methods would also be possible) and it would then relay it to all subscribers. On open lists where anybody can post directly, moderation posts could be used to declare that certain messages that went through are to be considered spam or breaks the rules, so that the subscribers’ software clients could delete or hide them automatically so that you don’t have to see them when you open your client to read the discussions on the channel. In a similar manner, moderation posts could also flag for rule updates and more in the channel.

Since we would be defining a standard format for how to encode the comments from scratch, we could also enable full semantic tagging from the start. Dates and events can be marked as such, just like addresses, phone numbers, even nicknames, and more. Disambiguation would be made far easier when you don’t have to wonder if you should write a long explanation or put details in paranthesis or omit it entirely hoping nobody will misunderstand you. Whenever you think a phrase or word or expression is unclear, you can just add a tag that shows what it means which would be hidden by default and that the readers can chose to display or not (and it would be possible to clarify that for example a word is used as a verb, or even make a link back to a previous or latter sentence in your post).

And since the whole discussions are defined simply by signed messages of a defined format that references each other by hashes, it suddenly becomes easy to let a discussion jump as a whole to other forums when the commenters agree that they want to continue it elsewhere. No longer do you have to simply cut-and-paste raw text if you want to import the discussion history, instead the posts can be reuploaded to the new place together and the whole history can be fetched by the subscribers’ client software when they want to see which posts is referenced or quoted, in a verifiable manner (the digital signatures allow you to verify the comments haven’t been modified).

This actually even enables the subscribers of two or more separate channels to crosstalk easily, since you can directly quote messages from the other channels / forums and at the same time include a reference to the “channel definition post” so that your client can see how to fetch the rest of the history of the discussion. So for example, in a channel about RC cars a quote could be made of a post in an electronics channel, allowing the RC folks to look up the rest of the discussion with just a few clicks, and to even join that channel to post questions which in turn reference the initial crosspost, further allowing the commenters on both channels to follow the discussions on each side. There’s even the possibility of having a shared discussion among several channels on multiple servers where all commenters only needs to reply to the discussion on their own channel, having it automatically synchronized among all the channels on all servers.

Author identities could be verified in several ways. Posts would as I mentioned be digitally signed (using public key cryptography such as ECDSA), and the public key would be included in the message. This public key could then be tied to for example a Twitter or Facebook account, or a GPG key, or a Namecoin profile (see, or whatever else you like. Your client would then (by default) verify that the public key used to sign the message can be found on the profile in question or is signed by it’s keypair. Combined with the previously mentioned address book software here on my blog, your client could automatically show which posts has been verified to be made by people in your address book, and the client could automatically verify Namecoin registered profiles through the signatures, etc. This way you can verify which posts have been made by the same person, and not just by different people with the same nickname. And since your profile also could have an index of all your previous public comments, your client could also trivially allow you to look up all public posts from people from all channels on all servers where they’ve participated in discussions.

(More updates coming later)

Universal P2P address book software using Namecoin

After having seen numerous social networks and blog hosts and personal website hosts go down over time and old accounts go abandoned, and after coming to the conclusion that the only method of long term addressing that seems secure and reliable has to be based on cryptographic public keys, I’ve thought up a type of address book software that would be independent of servers and yet could always stay up to date in sync, and work in a secure manner.

So lets introduce you to Namecoin. Some years ago a guy called Zooko, who is quite well known in the crypto community, minted the concept called Zooko’s triangle. The idea is that you could only have any two of three of globally unique nicknames, decentralization and rememberability. What he and most of the rest of the world at that point wasn’t yet aware of that you could achieve all three if only you can acheive a global concensus following the same set of rules. And the first system to achieve just that was Bitcoin, which uses a blockchain and proof-of-work to achieve a secure global consensus, used to establish ownership and transfers of tokens of value. And so a few years later Namecoin was born, in which anybody can register names of various types and assign data to them, and where each name only can be registered once, and where the entry owner (the first to register it) can use the same public key he used to register it in order to update it through digital signatures.

So what does that have to do with our address book software? Easy – in order to add your friends to your friend list you do NOT have to enter or remember or verify a long string of random characters (a public key) or trust a server to give you the correct key (GPG key servers, Facebook, blogs) while the username still can be unique. So when you want to add your friend all you need is his nickname, no different than what you’re used to when following somebody on Twitter, Tumbler, Facebook or Reddit or anywhere else. And you do not have to worry about any service shutting down, because the Namecoin blockchain is global and maintained by thousands of “miners” who adds more and more proof-of-work to the chain over time, for numerous reasons. So once you have registered your username, your friends can come back 20 years later and it will still be there, and you will still be able to update it.

So basically, the address book software would be a piece of software that holds a list of the Namecoin registered nicknames of your friends, and which on a regular basis fetches the latest data from the blockchain to look for updates from your friends. The file with this list of yours could also easily be synced between your devices, such as your laptop and phone, etc. This way you ALWAYS know which blog they’re currently using, their current email, which social media they use, etc, and can always contact them, and you won’t be affected by any servers going down. All the data wouldn’t have to be stored in the blockchain either, just an address to a place to fetch your full profile data, and the data there could be signed by the same key used to create the Namecoin registration so that the data can be authenticated (if the data is modified, the signature won’t validate).

(More updates coming later)

My ideas for DNS-P2P

First of all, see my previous post on dynamic DNS using DHT and asymmetric crypto keys. I am going to reuse ideas from there.

Basic idea: We want a way to have static and globally unique names for web sites and servers. We want to avoid centralization, so no single organization like ICANN will exist for it.
This Domain Naming System will ask peers instead of a single server for IP addresses, thus P2P in the name.

So here it goes:
Every site has a master key pair. This is important. This key should be large, maybe a 16 kb RSA key.
Every host (individual computer that acts as server on a domain) has a key pair of it’s own. The host’s public keys are signed by the master key for the domain.

All these public keys are stored in the peer network using DHT. The IP adressess and all the DNS data is also stored using DHT, and it’s signed.
To access a site, you ask for the public key by it’s checksum. Then you verifiy the DNS data that comes back by checking the signatures and time stamps.

The checksum based domain names would be in hexadecimal format, like this (but random instead): 0123456789abcdef0123456789abcdef.pkh.p2p
Pkh stands for “Public key hash”, and “hash” is another name for checksums. I would prefer something else, but I don’t know what would be better.

The readable domain names, like website.p2p, would be “mapped” to the hash based ones. That means that when you ask for website.p2p, you get the hash based domain name.
When you ask for the hash, you get the public master key, host keys, and the DNS data such as IP addresses.

The real issue that still has to be solved is how we can make the readable domain names globally unique and secure…
I guess we have to go for “majority-unique”, such that website-a.p2p will point to the same site for most users. We probably have to accept “subscriptions” or “moderation services” that will manage situations where several people want the same domain name, and they would be optional to use as well as decentralized.

I will write more about this in the future.

%d bloggers like this: