[Cryptography] Best internet crypto clock

Henry Baker hbaker1 at pipeline.com
Sat Oct 4 19:14:39 EDT 2014


At 12:50 PM 10/4/2014, Jerry Leichter wrote:
>On Oct 3, 2014, at 10:34 PM, Henry Baker <hbaker1 at pipeline.com> wrote:
>> No.  But I would like to see some simple, robust Internet crypto services, starting with a simple crypto clock with reasonable resolution that can't be hacked by anyone, not even the NSA.
>> 
>> To a first approximation, the Bitcoin blockchain is the only current candidate, although at a much coarser resolution, a hash of all of the Fortune 500 daily closing stock prices would also function.
>> 
>> If there are any other candidates -- e.g., NIST "beacons" with some less-corruptible authentication mechanism -- that have the same level of non-hackability, I'd be interested in finding out about them.
>There are two issues here:  The clock, and the original problem of establishing that some event occurred no later than a given time.
>
>The first isn't hard to solve, in the traditional way of producing trustworthy random number generators:  Simply have NIST, the NSA, the EFF, the Russian and Chinese governments - whoever is willing - implement beacons.  To produce a beacon you trust, choose any subset, combine the "random" numbers, and sign the result in the usual way.  The subset and the method of combination are all public and committed to; all the inputs are public.  Since the individual beacons can only be corrupted by entirely stopping them, or by producing predictable (to the attacker) values, unless someone corrupts *all* the sources, the combination is unpredictable.

Yes, one could do as you say, but _checking_ this calculation isn't going to be easy unless a large number of place on the Internet _store the appropriate sequences_.  You then have the problem of _checking that all (or most) of these sequences are the same_.

In the case of the Fortune 500 or the Dow Jones share prices, a large number of sources _already publish_ these numbers, so you only have to go check a sufficient number (for your purposes) of probes to these public databases to convince yourself that they are all consistent, and then perform your checking calculations on the published share prices.

Other sources might be sec.gov, which store all the submissions by public companies of their quarterly reports, changes in ownership, etc.  While the current sec.gov makes no attempt (that I'm aware of) to blockchain these submissions, it would be pretty easy to change sec.gov to require a "previous" hash for incorporation into any SEC report submission, and this would have the effect of partial ordering all the submissions in such a way that it would be essentially impossible for _anyone_ to change the ordering (including the SEC itself), without everyone else being about to notice that someone was trying to make a change.

---
It would be nice to have an in-the-clear/public Internet database with the following properties:

1.  The database is readonly, appendonly.

2.  Everyone sees the same database, and can "easily" ("without inordinate amount of effort") check this (somehow).

3.  Everyone can easily see _every element of this database_, and thus there is no possibility of tampering or censorship.

4.  Because everything is cross-hashed in various ways, it becomes impossible to delete any information in this blockchain.

5.  Because everything is cross-hashed & cross-coded in various ways, it becomes impossible to "redact" any information in this database.  I.e., you can't even follow the chain without having _every bit_ of every item in the portion of the chain you're trying to follow.

6.  If someone comes up with a piece of data that purports to come from this database, it should be easy to check this database that the data is indeed already there.

7.  Everyone -- in the sec.gov case "every public company" -- can submit an addition to this database.  Yes, there are issues about proper authentication of the submission to make sure that it is indeed from that public company, but this is garden-variety PKE.

sec.gov itself is a pretty good example where such a database makes sense.  Everything is supposed to be public; so now all we need is to make sure that it can never be tampered with--even by someone at the SEC.  If someone submits a report in error, the error can be explained, but will remain ever-after in this database.  The possibilities and harm from corruption are orders-of-magnitude more than the harm/embarrassment from repaired errors, so that such an incorruptible database is essential.

The same idea could be used in a wide variety of instances where there is a "server" and "people" to be served.  The order-of-arrival of the people served by the server is completely arbitrary, but once this serving order has occurred, it is completely nailed down into a linear order that can't later be spoofed.



More information about the cryptography mailing list