2 ms·

As the archiver I first have to publish (once) the public part (key) of a Bitcoin address I own. To archive something I keep a copy (file) of it (it may be an

As the archiver I first have to publish (once) the public part (key) of a Bitcoin address I own. To archive something I keep a copy (file) of it (it may be an archive storing many files), calculate some digest (let's say SHA512) of the file, then immediately publish the file on my archive-webserver, and its size (amount of octets) and digest an the existing and active blockchain (in this case: Bitcoin). As a courtesy I can let the source know that I archived. At publishing time everyone can check that I (and no one else) archived the exact material published by the source. If I distorted the published material I cannot deny it, thanks to the timestamped digest stored in the blockchain. Later everyone can be quite sure of the publication date and integrity of the archive, once again thanks to the timestamped digest. Doesn't this method cover all needs? Is releasing another key necessary, which one and why?

vidarh 7y ago
I think this illustrates that there are many reasons to do this: 1. Your suggested approach handles provenance for data you yourself arranges to "open up" in the future. 2. Additionally people may want to ensure the longevity of the data - this is "easily" done by simply archiving all referenced archives multiple places. 3. Some people wants to ensure important data eventually will get released, but don't dare / can release it now and/or worry that they will be prevented from releasing it in the future (be that for a nefarious reason, or simply because you might die of natural causes before you get a chance). The last case is what I meant by a "time locked" system. Being able to archive something now even though you're not prepared to publish it now in a way that doesn't require you to take complicated steps to guarantee that "someone" is trusted to release the right keys would be powerful. What you suggest also have value, it just covers a different set of use cases.
- natmaka 7y ago
  Case 3 is indeed a non trivial one. 1/ put all those important to-be-published-later data in an archive 2/ obtain the archive SHA512 hash 3/ cypher the archive, using a symmetric-key algorithm and a a random key 4/ use secret sharing, with the key being the secret, with the adequate amount of redundancy (this is the most tricky part). https://en.wikipedia.org/wiki/Secret_sharing https://en.wikipedia.org/wiki/Secret_sharing 5/ give each part of the secret to some notary, and pay him to have it delivered to each member of a group of tech-savvy friends of yours. Chose unrelated notaries installed in different countries 6/ give the cyphered archive along with detailed instructions to each member of the group, in order for him to be able to rebuild the secret and then decrypt the archive. If they will have to act this way more than 10 years after receiving the instructions give them full "image systems" (a real machine!) storing all required software, ready to run 7/ publish the SHA512 hash (on archive.org?), sealed-signed by you, along with some explanation "At date X I, John Smith, created the archive whose digest is...". You may also publish the cyphered archive (this is not very useful and raises the risk) 8/ pray. The symmetrical cypher has to resist attacks during the timelapse, enough groupmembers have to survive long enough, image systems must be usable when time comes...

vidarh 7y ago

I think this illustrates that there are many reasons to do this: 1. Your suggested approach handles provenance for data you yourself arranges to "open up" in the future. 2. Additionally people may want to ensure the longevity of the data - this is "easily" done by simply archiving all referenced archives multiple places. 3. Some people wants to ensure important data eventually will get released, but don't dare / can release it now and/or worry that they will be prevented from releasing it in the future (be that for a nefarious reason, or simply because you might die of natural causes before you get a chance). The last case is what I meant by a "time locked" system. Being able to archive something now even though you're not prepared to publish it now in a way that doesn't require you to take complicated steps to guarantee that "someone" is trusted to release the right keys would be powerful. What you suggest also have value, it just covers a different set of use cases.

natmaka 7y ago
Case 3 is indeed a non trivial one. 1/ put all those important to-be-published-later data in an archive 2/ obtain the archive SHA512 hash 3/ cypher the archive, using a symmetric-key algorithm and a a random key 4/ use secret sharing, with the key being the secret, with the adequate amount of redundancy (this is the most tricky part). https://en.wikipedia.org/wiki/Secret_sharing https://en.wikipedia.org/wiki/Secret_sharing 5/ give each part of the secret to some notary, and pay him to have it delivered to each member of a group of tech-savvy friends of yours. Chose unrelated notaries installed in different countries 6/ give the cyphered archive along with detailed instructions to each member of the group, in order for him to be able to rebuild the secret and then decrypt the archive. If they will have to act this way more than 10 years after receiving the instructions give them full "image systems" (a real machine!) storing all required software, ready to run 7/ publish the SHA512 hash (on archive.org?), sealed-signed by you, along with some explanation "At date X I, John Smith, created the archive whose digest is...". You may also publish the cyphered archive (this is not very useful and raises the risk) 8/ pray. The symmetrical cypher has to resist attacks during the timelapse, enough groupmembers have to survive long enough, image systems must be usable when time comes...