[RFC] Signing files with the namecoin blockchain

[domob]

phelix, just as a point that interests me: How do you communicate with namecoin / nmcontrol? Since you use presumably Python, maybe my Bitmessage code can help you (if you haven't yet written that yourself, it's not particularly hard). But I remember you posted about a JSON-RPC package once that allows to call RPC routines very easily - I couldn't use it because it handles wrong HTTP credentials miserably (for my application at least), but if you use nmcontrol exclusively without credentials, it won't matter.

[phelix]

phelix, just as a point that interests me: How do you communicate with namecoin / nmcontrol? Since you use presumably Python, maybe my Bitmessage code can help you (if you haven't yet written that yourself, it's not particularly hard).

So far I have been using pynamecoin* but always with the plan of switching to your code From what I've seen it should even be possible to use the file without modification. I will need some higher level functions (e.g. get_signer(name)) that might be useful for other purposes so hopefully we can agree on something useful for more people/projects.

* https://github.com/phelixbtc/ncsc/blob/ ... amecoin.py

[domob]

phelix, just as a point that interests me: How do you communicate with namecoin / nmcontrol? Since you use presumably Python, maybe my Bitmessage code can help you (if you haven't yet written that yourself, it's not particularly hard).

So far I have been using pynamecoin* but always with the plan of switching to your code From what I've seen it should even be possible to use the file without modification. I will need some higher level functions (e.g. get_signer(name)) that might be useful for other purposes so hopefully we can agree on something useful for more people/projects.

Great! Yes exactly, you should probably be able to use the namecoin.py module and implement the stuff you need based on executeRPC of it. I'm not sure whether the "signer" feature is useful for Bitmessage, though - I've been thinking about it only for NameID so far. Thus I have to implement it on my own in JavaScript anyway, but of course we first need a good specification. (For which you already opened a thread, I've seen.)

[phelix]

With the day job I simply can't find the time to work on this. Domob or anybody please go for it!

here is my latest idea about it:

The concept above with a master is pretty complicated. Maybe there is an easier option using a "lock in height".

Filename: setup_nfs#123456.exe
with 123456 being the "lock in height" in blocks (should be encoded as base 36 or so, maybe have reduced accurateness to save characters)

After the lock in height the entry will be frozen (by the retrieving client). If the value at that height can not be determined but only later entries are known or the current entry is known the entry is invalid. The only change possible after the lock in height is revocation by setting the value to "revoke".

This removes the danger of loosing the private keys because the only harm that can be done is to revoke the entry. The lock in height needs to be specified in the filename.


To make the whole thing successful it should be possible to retrieve information from a server without running the client / downloading the blockchain locally. Because entries can be frozen it would even be possible to retrieve information from the server that is self securing to by getting a block and a couple of following block headers.

[domob]

The concept above with a master is pretty complicated. Maybe there is an easier option using a "lock in height".

Filename: setup_nfs#123456.exe
with 123456 being the "lock in height" in blocks (should be encoded as base 36 or so, maybe have reduced accurateness to save characters)

After the lock in height the entry will be frozen (by the retrieving client). If the value at that height can not be determined but only later entries are known or the current entry is known the entry is invalid. The only change possible after the lock in height is revocation by setting the value to "revoke".

Not sure about this. What exactly is the threat scenario you want to prevent with the file signatures and the lock height? Isn't preventing against MITM-attacks and the like serving wrong files from a download page exactly what this file signing is for? I don't see how a lock height can help in this case if someone lost their signing keys, because the malicious server can just as well alter the file name to extend the time lock, couldn't it? If I wanted to download "namecoin-qt-3.72.tar.bz2" and I got "namecoin-qt-3.72#123456.tar.bz2", I wouldn't know whether this is the correct time lock or not. If the server gave me "namecoin-qt-3.72#666666.tar.bz2", I would just as well accept it.

Probably I don't get your point. I'd say that file validation is already a huge thing even if it doesn't prevent against lost private keys (after all, losing the keys screws a lot of existing systems). And if you wanted to guard against lost keys, why not look at a name's history and only use the first ever signature with a given public key? Wouldn't this solve the same problems as with a lock height, but without the problem associated by explicitly stating the height?

In general, I'm still interested in this. Since I'm busy for the next time, too, I don't mind if someone else wants to really take it up, though. If not, I hope that I can start on this during the next month or two. I'll probably go for a C++ backend based on libnmcrpc plus Gtk+ UI, for both signing and validation. But of course it should be easy to implement additional tools that use nmcontrol or whatever in addition, or host a web-based verification service (if you trust some server) or whatever.

[biolizard89]

Question: does the proposal at the beginning of this thread scale at all? Having a name for every file that someone wants to sign is probably going to use a lot more storage than d/ or id/. Why not just put a pubkey (or fingerprint) in id/, and distribute a signature file like is currently done? I think it's not the blockchain's job to store those signature files.

[phelix]

Question: does the proposal at the beginning of this thread scale at all? Having a name for every file that someone wants to sign is probably going to use a lot more storage than d/ or id/. Why not just put a pubkey (or fingerprint) in id/, and distribute a signature file like is currently done? I think it's not the blockchain's job to store those signature files.

Please note that ECDSA signatures are very small. Also there are only relatively few files around that are signed, probably a similar number as websites but a smaller number than there could be demand for IDs.

If I would have the time to do so I would implement this right away.