News for hackers. Stuff that matters.
Re:The Internet Archive is waging war on misinformation by vidarh on Thursday September 19, 2019 @05:16AM (#21014578)
The problem would be how you guarantee the release of the keys at a time in the future.

If it was possible to create a "time-locked" blockchain vault would be interesting.

I can't see any way of doing that which wouldn't boil down to taking bets on the speed of advances in computing, though. But that might be good enough if the goal is just to ensure it takes "long enough" rather than guarantee a specific amount of time has passed.

Re:The Internet Archive is waging war on misinformation by natmaka on Thursday September 19, 2019 @10:36AM (#21016579)
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?

Re:The Internet Archive is waging war on misinformation by vidarh on Friday September 20, 2019 @08:36AM (#21025981)
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.

Re:The Internet Archive is waging war on misinformation by natmaka on Monday September 23, 2019 @09:27AM (#21048699)
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

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...