[RFC] Signing files with the namecoin blockchain

[moa]

domob:

Sounds good, but maybe we could also use the more generic "hash/" I suggested. I think I read already that the "Holy Grail" guys discussed about putting hashes into the blockchain (supposedly for a similar feature but not to verify files but some OT datastructures or so), and then it may make sense to have some kind of "generic" namespace and specification for how to do this to verify "things". What do you think?

The proposed OpenTransactions method is to store the hash of a credentials file http://opentransactions.org/forum/index ... sg40#msg40. The credentials file contains a number of public keys that the identity wants posted (wherever) for authentication. So yes, it is actually the hash of a file, just quite an important file. It also is just the first documented such special case of the method, i.e. using a hash as the name part of the {name:value} pair, that you guys are discussing here so don't see why it needs it's own "ot/" namespace.

Therefore, I think you should use for namespace "hash/" or simply "h/" since it could become a general method for storing any type of hash in the blockchain, with many different fields in the value for a broad range of applications. To keep it consistent with "d/" (domain) and "id/" (identification) for instance.

I see what you are trying to do by standardising the method to use for creating the hash of general files and it may have some merit. But there is no way of enforcing it so anybody can store whatever type of hash they like into the namespace you choose to use, at best you are standardising a special use case for storing hashes in the blockchain, at worst you are creating a vector for mischief.

[domob]

What about the length of the name? I think 20 characters of base58 should be enough, do you guys agree? A Bitcoin address is about 30 characters long but in this case a collision would be harmless.

I have no idea, but yes, I suppose that should be enough. 58^20 = 10^35.something, which seems plenty of room. Even for a birthday attack, you would have to generate 10^17 hashes which seems unrealistic (in particular I don't see what such an attack would buy you even if you tried). So I'm fine with 20 characters.

note: fileopenedasbinary - this can make a difference for text files on windows I think

Yes. I think we should do what existing tools to calculate hashes of files do (e. g. the "shaXYZsum" utilities on GNU/Linux). I can't guarantee for that, but I presume this is exactly hashing the binary representation.

Sounds good, but maybe we could also use the more generic "hash/" I suggested. I think I read already that the "Holy Grail" guys discussed about putting hashes into the blockchain (supposedly for a similar feature but not to verify files but some OT datastructures or so), and then it may make sense to have some kind of "generic" namespace and specification for how to do this to verify "things". What do you think?

I think they should use ot/ . hash/ is too general imho Would like to hear more opinions on this.

I'm fine with both versions in general. But I still believe it could make sense to use a generic "hash" or "h" namespace for this (wider) use-case (see also moa's post). I still also think that it makes sense to somehow "standardise" how the signatures and possible fields for hashes could look like. Of course no-one is forced to use that specification for her specific application, but having a worked out specification ready to use makes sense to me.

Regarding implementation: Phelix mentioned interest in working on it yesterday - are you still interested? If so, I'll leave it to you and try my hands on Pidgin-OTR integration as next project. (The OTR guys seemed to be interested in the general idea, although they don't want to include it into the "stock" OTR plugin - but am willing to adapt it so it can work when the user installs a "namecoin" plugin alongside.) I can work on a Gtk / GNU/Linux desktop integration UI when the "core" is done.

Yup, I would like to do it but would be glad about help on the Linux side.

Sounds great, then good luck! Let me know if I can help you on the GNU/Linux side, I'll test it out as soon as something is available and fix GNU/Linux specific issues should there be ones. I'll also work on a UI here as soon as the basic functionality is there.

Oh, and as mentioned already, should you decide to set up a website for the project and like one of my proposed names, just let me know which one and I'll send it/them over to you.

[phelix]

Namespace
I am aware that anybody can write anything to any name they like... luckily that does not hurt much in this case.

My point for not using hash/ or h/ is that there probably are plenty of ways and purposes to use a hash. Why do you want to throw all these into one namespace? The use case at hand is very specific (verify a file) so why not give it it's own namespace?

Also the name here is not really a hash but only part of a hash - for other applications where collisions are fatal you probably would want to use a full hash.

It does not have to be file/ - now that I think about it that might even be quite misleading.

[domob]

Then I suppose we first need to find a good way for this "protocol" (not the implementation but the general scheme which would allow for competing implementations), so that we can name the namespace after it.

[phelix]

A couple of days ago I created a simple yet working prototype and verified my first file . There are two slightly bothersome issues. I have been pondering on them for a while now and am open for ideas.

signee updates
Unfortunately the client sends names to a new address on name_update. As the signature is currently bound to the address that held the signee name at the height of creating the signature entry the verification will break after a name_update on the signees. This can be solved by using the historic address that held the signee name at the time of signature entry creation. As an alternative I intend to make it possible via an option in the signature entry to use an address or pubkey published in the signee value.

signature entry expiry prevention
There is another issue that can easily be fixed by using historic name_ops but takes more effort to fix without using it. It is obvious a signature name can be hijacked by someone else should it expire. This means it can be abused for spam, maybe even tricking people into visiting bad sites. IMHO hijacking of signature entries should be prevented. Again this can be done by using historic data, this time for the signature entries (e.g. freeze at first expiry, possibly name can be unfrozen by sending it back to the address that held it at expiry / value needs to be signed by the very first registration address).

The only idea that I could come up with that does not depend on historic data is to include an address in the filename. The value would then always have to be signed (signature attached at the end of the json string).

setup_tbd#NDtPuyg3adscr6HCE1GUiSsKPtA8ewKgz3.exe (not so nice , no go for starting the project imho).


So, at least for now it looks like file verification will depend on historic name ops.

[domob]

Great to hear you have some stuff working already!

Unfortunately the client sends names to a new address on name_update. As the signature is currently bound to the address that held the signee name at the height of creating the signature entry the verification will break after a name_update on the signees. This can be solved by using the historic address that held the signee name at the time of signature entry creation. As an alternative I intend to make it possible via an option in the signature entry to use an address or pubkey published in the signee value.

This is off-topic, but I wondered about a similar thing myself for NameID. What about a "general purpose" specification to include "signature keys" (most likely namecoin addresses) in name values, which are allowed to sign on behalf of the name for all kinds of applications (file verification and login being the ones I have in mind so far)? In the simplest case, it would be enough to have a "signer" or "authorized" or whatever field in the name which contains an array of or just a single namecoin address. For the future, it could even be extended to allow signing with GPG keys or so if that should ever be desired.

As you mention, this would prevent problems with name_update changing the address. But it would also allow me to keep my name's "master key" in protected storage while having a throw-away signer address in my working wallet in order to use NameID. Thus I can use the signing feature day-to-day without worrying about losing my name's private key.

[moa]

signee updates
Unfortunately the client sends names to a new address on name_update. As the signature is currently bound to the address that held the signee name at the height of creating the signature entry the verification will break after a name_update on the signees. This can be solved by using the historic address that held the signee name at the time of signature entry creation. As an alternative I intend to make it possible via an option in the signature entry to use an address or pubkey published in the signee value.

I'm not sure if you have said this or not but it is not clear so I'll say it anyway ... a name_update can also be used to send to any nmc address (this is how unexpired names are transferred), so can you just send it to the signee address, i.e. back to itself, or if this is not permitted then send it to tmp address and then back to nmc_signee_address?

Code: Select all

name_update d/name <JSON-VALUE> nmc_signee_address

[phelix]

Great to hear you have some stuff working already!

Unfortunately the client sends names to a new address on name_update. As the signature is currently bound to the address that held the signee name at the height of creating the signature entry the verification will break after a name_update on the signees. This can be solved by using the historic address that held the signee name at the time of signature entry creation. As an alternative I intend to make it possible via an option in the signature entry to use an address or pubkey published in the signee value.

This is off-topic, but I wondered about a similar thing myself for NameID. What about a "general purpose" specification to include "signature keys" (most likely namecoin addresses) in name values, which are allowed to sign on behalf of the name for all kinds of applications (file verification and login being the ones I have in mind so far)? In the simplest case, it would be enough to have a "signer" or "authorized" or whatever field in the name which contains an array of or just a single namecoin address. For the future, it could even be extended to allow signing with GPG keys or so if that should ever be desired.

As you mention, this would prevent problems with name_update changing the address. But it would also allow me to keep my name's "master key" in protected storage while having a throw-away signer address in my working wallet in order to use NameID. Thus I can use the signing feature day-to-day without worrying about losing my name's private key.

+1 to general spec

What about "pp" - "per procurationem" http://en.wikipedia.org/wiki/Procuration ?

signee updates
Unfortunately the client sends names to a new address on name_update. As the signature is currently bound to the address that held the signee name at the height of creating the signature entry the verification will break after a name_update on the signees. This can be solved by using the historic address that held the signee name at the time of signature entry creation. As an alternative I intend to make it possible via an option in the signature entry to use an address or pubkey published in the signee value.

I'm not sure if you have said this or not but it is not clear so I'll say it anyway ... a name_update can also be used to send to any nmc address (this is how unexpired names are transferred), so can you just send it to the signee address, i.e. back to itself, or if this is not permitted then send it to tmp address and then back to nmc_signee_address?

Code: Select all

name_update d/name <JSON-VALUE> nmc_signee_address

Ahh yes, I had thought of it but did not write about it. Actually I had expected the default behavior to be exactly that, always send the name-coin to the same address. I guess Namecoin does what it does for privacy reasons...

Anyway, it works even directly, just tested. What about this: Look for a "signee"/"auth"/"pp" entry, if there is none test the current address.

With a solution for the signee addresses we could also do this:

setup_tbd#mywebsite.exe
setup_tbd#id#phelix.exe

These I can imagine to be embraced. It is somewhat like signing a letter and have your name printed below your signature.

[domob]

Anyway, it works even directly, just tested. What about this: Look for a "signee"/"auth"/"pp" entry, if there is none test the current address.

I agree to this. This is exactly what I had imagined - default to the name's address as is currently done with NameID and presumably also your proof-of-concept code, but allow to specify signee addresses.

With a solution for the signee addresses we could also do this:

setup_tbd#mywebsite.exe
setup_tbd#id#phelix.exe

These I can imagine to be embraced. It is somewhat like signing a letter and have your name printed below your signature.

Sorry, but I personally still don't like changing the file name. What would that give you? If I download "setup_tbd.exe" and verify it, I get a list of names that have signed it anyway. Furthermore, since the filename is part of the file's hash, wouldn't this prevent multiple people from signing a file? (At least it doesn't make sense to me to explicitely put the signing name into the filename but then afterwards have again also signatures of names not being id/phelix or d/mywebsite on it.)

[phelix]

Anyway, it works even directly, just tested. What about this: Look for a "signee"/"auth"/"pp" entry, if there is none test the current address.

I agree to this. This is exactly what I had imagined - default to the name's address as is currently done with NameID and presumably also your proof-of-concept code, but allow to specify signee addresses.

Good. Some native english speaker please share your opinion on the field name for the list of Namecoin addresses that can sign for a name on behold of the address actually holding the name. What about "owner"?

Also see the normal way to include an address here: http://dot-bit.org/Namespace:Identity

Code: Select all

$ namecoind name_show id/khal
{
   "namecoin" :
   {
     "owner" : "N15D34JVMDnD8vu82M5hCfn3nJWq3DSDdd",
     "default" : "N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq",
     "donation": "N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"
   }
}

?

With a solution for the signee addresses we could also do this:

setup_tbd#mywebsite.exe
setup_tbd#id#phelix.exe

These I can imagine to be embraced. It is somewhat like signing a letter and have your name printed below your signature.

Sorry, but I personally still don't like changing the file name.

I had hoped to trick you into it

What would that give you? If I download "setup_tbd.exe" and verify it, I get a list of names that have signed it anyway. Furthermore, since the filename is part of the file's hash, wouldn't this prevent multiple people from signing a file? (At least it doesn't make sense to me to explicitely put the signing name into the filename but then afterwards have again also signatures of names not being id/phelix or d/mywebsite on it.)

It is very different this time, let me elaborate:

It would be nice to have a protection against the signature entry being hijacked in case of accidental expiry. This could be done by including an address M into the filename. The file would still be hashed like before and the name for the signature entry would still be just namespacetbd/hash.
But to the end of the value data there would be added a signature from address M that would sign the first part of the value data. Address M could thus function as a master address to the value data. All value data would have to be signed by M.
In case of expiry the worst thing a hijacker could do then would be to block the entry or set the value to previously published data (one could even include block height in the signed value to restrict this to the most recent data).

Adding an address to the filename is rather ugly. Therefore I suggest using a name instead as a compromise. I call it a master name.

Limitations of the master name in filename approach:
* Should both the master name and signature entry expire hijackers can still screw around (The advantage of the master address would be that it of course never expires).
* The master name holder needs to maintain a proper address either via always using
"name_update id/phelix <value> previousaddress"
when updating (as moa suggested) or by including "signee"/"pp"/"auth"/"owner" in the value.