Excellent, and it's even free of charge. Following links from opentimestamps.org, I found https://stamp.io/ which claims to also be free of charge, and using both Bitcoin and Ethereum blockchains.
On Sunday, June 4, 2017 at 7:04:55 PM UTC+2, Jean-Philippe Ouellet wrote: > > On Sat, Jun 3, 2017 at 11:24 AM, Axel <[email protected] <javascript:>> > wrote: > > As Joanna has already noted, qubes-secpack is not advertised as solving > all > > problems related to distribution security, but "the best we can do" > > currently. > > > > I'd like to suggest a practical improvement of qubes-secpack that I > believe > > can protect against a (rather limited) class of threats including some > > forced private key hand-over and insider threats. > > > > The scheme: > > > > The idea is to publish hashes of git commits, and maybe also of detached > > signatures, to the bitcoin blockchain. This will serve as a reasonable > > secure proof that the information was created before a certain point in > > time. In addition to the proof of freshness, this locks the information > into > > a narrow time frame. > > > > Taking the canary as an example, the logic of the scheme would be as > > follows: > > > > Axioms: > > - BnBB: If X is before Y and Y is before Z, then X is before Z. > > - DB: If X depends on Y, then Y is before X. > > > > Assumptions: > > 1. <Timestamp A> is before <Proof of freshness> > > 2. <Canary> depends on <Proof of freshness> > > 3. <Signature> depends on <Canary> > > 4. <Blockchain transaction> depends on <Signature> > > 5. <Blockchain transaction> is before <Timestamp B> > > > > Argument: > > 6. <Proof of freshness> is before <Canary> [2, DB] > > 7. <Canary> is before <Signature> [3, DB] > > 8. <Signature> is before <Blockchain transaction> [4, DB] > > 9. <Timestamp A> is before <Canary> [1, 6, BnBB] > > 10. <Canary> is before <Blockchain transaction> [7, 8, BnBB] > > 11. <Canary> is before <Timestamp B> [10, 5, BnBB] > > 12. <Timestamp A> is before <Signature> [9, 7, BnBB] > > 13. <Signature> is before <Timestamp B> [8, 5, BnBB] > > 14. <Timestamp A> is before <Canary>, and <Canary> is before <Timestamp > B> > > [9, 11, Conjunction] > > 15. <Timestamp A> is before <Signature>, and <Signature> is before > > <Timestamp B> [12, 13, Conjunction] > > > > In other words, under these assumptions it is proven that the canary and > its > > signature was created in the time period between timestamps A and B. > > > > When publishing a statement to the blockchain, the statement should > include > > the hash of the latest git commit (and perhaps also hashes of detached > > signatures if git hashing is not trusted). The bitcoin transaction needs > > only to publish the hash of this statement. After it is published, the > > entire statement, its hash, and the identifier of the transaction that > > published it, should be added to qubes-secpack in a subsequent commit. > The > > purpose of this subsequent commit is only to provide discoverability, > and > > technically needs no signature. Further, the only security assumed to be > > provided by the publication of such a transaction, is to give reasonable > > assurance that the statement was produced before a certain point in > time. > > Especially, it does not matter who performs the publication or why. > > > > Suggestion: The instructions on how to use qubes-secpack, including the > > blockchain timestamping verification, should be part of qubes-secpack > and be > > signed. > > > > How this scheme mitigates some threats: > > > > Suppose the developers who sign commits and distributions are forced by > an > > outside actor to hand over their private keys. This actor could now for > > example attempt to sign digests of malicious images of Qubes OS and have > > them distributed, as well as falsify new canary statements on schedule. > So > > far everything seems lost. Now, suppose further that some indication of > this > > event comes to public knowledge, i.e. users begin to suspect the keys > can > > not be trusted after a certain point in time. With the current system, > i.e. > > without publishing to the blockchain, assumptions 4 and 5 above are not > > applicable, and we end up not being able to trust anything anymore. > However, > > by adding assumptions 4 and 5, i.e. continually publishing commits to > the > > blockchain, the signatures that were created before the adversarial > event > > are trustworthy despite a compromised private key, assuming both the > > signature and the blockchain transaction are verified. To clarify: If a > user > > trusts that a private key was compromised only after a certain > <Timestamp > > B>, then that user will still be able to trust the contents in > qubes-secpack > > verified by the corresponding <Signature>. > > > > Analogously, there may be several other scenarios in which this scheme > can > > help, e.g. in deprecating keys. > > > > Live example: > > > > So I went ahead and did it. > > > > -----Begin Statement----- > > Today is 2017-06-03 > > Last published git commit of qubes-secpack is > > 4b1d111457f793cd97524dce2ac98cc694220f88 > > ---End Statement----- > > > > SHA-256 hash of Statement is > > ec516a47d56b0fb6346404d8e40da1c20a6630d1f02635f9b402eb9b1b69865d > > > > Bitcoin transaction > > 840ea8d6a71ae5415bf0efb84fb25f03cd6a1b0fa2a511133383a3477fe18601 > includes as > > it's first output a script that ends with the hash of the Statement. See > > > https://www.blocktrail.com/BTC/tx/840ea8d6a71ae5415bf0efb84fb25f03cd6a1b0fa2a511133383a3477fe18601 > > > > > Although this particular publication was made using > > https://proofofexistence.com it is possible to do the same thing > manually > > for a lower fee. > > Peter Todd's https://opentimestamps.org/ seems like a good fit for this > purpose. > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/0e83b185-994e-40a4-be65-d8217ff2ecbf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
