[HN Gopher] QR Date - signed timestamps inside for verifying dates
___________________________________________________________________
QR Date - signed timestamps inside for verifying dates
Author : JNRowe
Score : 92 points
Date : 2022-03-05 09:48 UTC (13 hours ago)
(HTM) web link (qrdate.org)
(TXT) w3m dump (qrdate.org)
| fbn79 wrote:
| You could create a QR based on the last block of BITCOIN
| blockchain. These way you do not rely on a private key and onyone
| can check and trust it.
| jeroenhd wrote:
| But what would that solve? The blocks on the blockchain are
| public, so anyone can fake a timestamp by grabbing an old block
| and generating a QR code.
|
| The point of this website is that the server signs the
| timestamp. It's more than just a QR code with a time and date,
| it has some actual verification code.
| itake wrote:
| you wouldn't need to use their website and the service would
| be completely decentralized.
|
| the website has the exact same problem that you pointed out
| for the blockchain: you can screen capture a QR code and re-
| use it later.
| ricardobeat wrote:
| No, you can't. It's one of the main features, explained
| right there in the page.
| itake wrote:
| > It does not work against the past (taking snapshots of
| the code and using them later)
|
| Right on the page, it says this.
|
| Maybe I am not understanding your point. Both the website
| and the blockchain strategy make it impossible for you to
| record video content and claim it happened in the future,
| but neither of them defend against recording after the
| timestamp happened.
|
| The blockchain strategy does not require a centralized
| service, while the QR code requires the website to be up
| forever.
| miunau wrote:
| You can always use the published public key to verify the
| signature.
|
| There's also a way to generate the codes offline using a
| certificate chain and a fingerprint
| (https://github.com/qrdate/qrdate#static-qr-date-v1-spec)
| which does not require a website, just a key store. It
| needs more specifying to be viable for real world use but
| it should be possible. Help is very welcome.
| IanCal wrote:
| The server verifying just adds a security hole - the makers
| of this site can fake a qr code for any time & date.
|
| Using info from the the block is safer as you don't need to
| trust the host of the system.
|
| The point (like showing a newspaper) is to prove the image /
| video was taken _no earlier than_ that time.
| neilv wrote:
| Good point. And the people who decide what the newspaper
| front page will display for a given day are constrained to
| some degree by newsworthy events on that day.
|
| That thought does does cast an additional possible funny
| interpretation on a photo I took of the adjacent street
| newspaper vending boxes of the two major Boston papers one
| day. The Boston Globe main headline was of a serious major
| news event. The Boston Globe above the fold was mostly
| filled with a photo of some political or sports figure, and
| a lowbrow muckraking headline about them. A funny (highly
| implausible) theory is that the Herald editor/publisher had
| needed to determine the front page for a paper issue, days
| or more into the future, such as for faking proof-of-life
| on/after a date, and then had to run that front page. :)
| innocenat wrote:
| And you can take screenshot today and use it tomorrow, too.
| oauea wrote:
| > But what would that solve?
|
| Nothing, which is amusing irony.
| tgsovlerkhgsel wrote:
| You can always "hold up an old newspaper". Nothing prevents
| you from storing and reusing an old signature.
|
| It always only proves that it wasn't taken _before_ a certain
| date.
|
| You can then _also_ prove "not after" by timestamping the
| picture (having it signed by a RFC3161 timestamping authority
| or putting a hash on the blockchain).
| avnigo wrote:
| That reminds me something like the OpenTimestamps project:
|
| https://opentimestamps.org/
| amelius wrote:
| Have these stamps already been tested in a court of law?
| rosndo wrote:
| This question doesn't make any sense, there's nothing to
| "test".
|
| An irrefutable cryptographic timestamp is just that,
| irrefutable.
|
| Sometimes courts make mistakes, but you can't expect any
| useful precedent over something like this.
| ohyeshedid wrote:
| > An irrefutable cryptographic timestamp is just that,
| irrefutable.
|
| In math, sure, but he specifically asked about a court of
| law. Irrefutable in math doesn't mean admissible in
| court. Then there's the 1, 6, 12, or however many random
| people that decide the case; they likely need the math
| explained to them, and two sides get turns convincing
| them the other is wrong.
| rosndo wrote:
| So uh, it's like _literally everything else_ in court?
| What's the point here? This feels like such a strange
| line of thinking.
|
| > Irrefutable in math doesn't mean admissible in court
|
| What is that even supposed to mean? Why would (relevant)
| _math_ not be admissible in court? Do you even know what
| these words mean?
|
| If cryptographic timestamps are relevant and not against
| the rules of evidence, _obviously_ they are admissible.
| amelius wrote:
| Most of cryptography can in theory always be brute-forced
| or simply guessed. There is no absolute guarantee, though
| you can get very very close. And there are other ways
| around it, such as keys getting leaked.
|
| Also, because of lack of expertise courts may simply not
| want to deal with this kind of proof and thus not
| acknowledge it.
| rosndo wrote:
| > Also, because of lack of expertise courts may simply
| not want to deal with this kind of proof and thus not
| acknowledge it.
|
| Courts lack expertise on almost every subject, I don't
| think this logic can actually hold up.
| amelius wrote:
| Perhaps, but the other points I brought up might.
| rosndo wrote:
| No, not really. Opentimestamps addresses all of them.
|
| Opentimestamps cannot be bruteforced, and there are no
| keys that could leak.
|
| Bruteforcing would require for you to permanently take
| over the entire bitcoin network.
| miunau wrote:
| I believe at that point it's up to the lawyers to argue.
| It's up to persons with people skills to convince other
| people that something is not fake, using tools like these
| as assistance, not as clinchers.
| miunau wrote:
| This is certainly a possible implementation and good if you
| would want to base it on the chain, doable via a minimal node.
| It would not work offline though, which would make it harder to
| use in frontline reporting, so I think the spec itself should
| not specify such a requirement.
| 3np wrote:
| Qrdate involves server-side signing and does not work offline
| either?
|
| If the signature involves a hash of a bitcoin block we don't
| have to trust the site owner to not sign future timestamps.
| miunau wrote:
| There's two proposed ways specified. The web way (called
| "Dynamic") and a fingerprint-based implementation that can
| work offline ("Static"), for example in approved apps for
| some organisations:
| https://github.com/qrdate/qrdate#static-qr-date-v1-spec
|
| It is still a concept as there's no implementation of it
| besides the tests in the repo, so it would require further
| refining for production apps. For example with specifying
| key exchange formats, which we are looking at right now.
| Anyone with expertise in this field wanting to contribute
| is welcome!
| can16358p wrote:
| Remimds me of Vitalik Buterin holding a paper with a new
| block's hash and posting his photo when there were rumors about
| him being dead a few years ago.
| [deleted]
| thamer wrote:
| I hadn't heard of this, this is a pretty cool way to provide
| this proof.
|
| Back story:
| https://www.coindesk.com/markets/2017/06/26/proof-of-life-
| vi...
|
| The block in question (open "Click to see more" and look for
| the "Hash" field): https://etherscan.io/block/3930000
| edent wrote:
| I don't get the problem this solves.
|
| As it says, I can use a code from today and add it to a video
| from yesterday.
|
| I don't know who controls the private key, so how can I trust
| that they won't sign tomorrow's timestamp today?
|
| If someone scans the code, and visits the website, their IP and
| UA will be logged. Which is a good way to track who has viewed
| your video.
| miunau wrote:
| Hi,
|
| These are all valid concerns.
|
| Programatically superimposed usage of the code is problematic
| for all the same problems as with EXIF manipulation, so the
| thinking is to recommend using a physical prop (smartphone or
| paper) that makes it harder to fake the code in later. When
| combined with rapid distribution (to a news agency, live feed,
| Telegram or such), there's a period of time where I think it's
| unfeasible that someone would had tampered with it to future-
| date an older image.
|
| It is possible to superimpose the code of course, as I noted:
|
| "For example, when uploading photos through a messenger
| service, the service can sign the photos upon upload date and
| superimpose the QR Date onto it. Any further uploads to date
| the photo again would have to either crop the code out or
| otherwise mangle it so much that it would raise suspicion.
|
| For videos, the QR Date can be superimposed as either moving
| around in the frame, switch places, or other motion to make it
| harder to superimpose another code later."
|
| However these would only be indicative, not definite proof, and
| would need to be combined with other efforts- mainly
| deduplication, to find doubles.
|
| For key storage and logging, I don't think it's my job to try
| to convince people to trust me with a private key (or logs) for
| the purposes of introducing this idea. Frankly I do not want
| the responsibility. If it ends up being useful, I would be
| happy to donate the domain to a reputable NGO or journalistic
| organisation for proper storage of the private key on a
| hardware device, contracts on how it and logs are handled, etc.
| In the meanwhile, if you want to trust the site, it's up to you
| just like with any CA.
|
| I don't think a single online centralised authority would be a
| good idea in any case- it's why I'm trying to also consider
| situations where it can be used offline and by many
| organisations that each have their own requirements for trust.
| jka wrote:
| A practical idea. I wonder whether a more consensus-based
| alternative to this could use some aspects of the current-
| highest-block from a blockchain to incorporate proof of a
| previously-unknowable, globally-verifiable value.
| gsich wrote:
| No matter what you use, you can backdate everything.
| StevenWaterman wrote:
| The typical solution to this is to create the message,
| publish its hash immediately, then publish the message itself
| at a later date.
| 00117 wrote:
| Why is this true?
| jka wrote:
| Unless you're hoarding some material that emits a verifiable,
| secure random information into the future while itself being
| depleted in the process?
| amelius wrote:
| And this could make it more useful too. You could prove that an
| event happened before a certain timepoint (not after it).
|
| Some notary services allow you to inject documents or hashes
| into cryptocurrency blockchains which prove that the submitted
| documents existed before a timepoint.
| lucb1e wrote:
| > You could prove that an event happened before a certain
| timepoint (not after it).
|
| Not with what GP proposes.
|
| If I understand their proposal correctly, it is to _include_
| a value from "the current-highest-block from a blockchain to
| incorporate proof of a previously-unknowable, globally-
| verifiable value." You can always include historic values
| trivially.
|
| It is much more involved to actually do a transaction on that
| chain, which could indeed be used to prove existence _before_
| a certain time. But yes, your alternative proposal would work
| for that, if you assume the chain cannot be controlled by any
| individual /partisan party.
| miunau wrote:
| Some sort of a web of trust based on fingerprinting has been
| discussed, but it's an abstract idea still. Currently I don't
| think a blockchain would bring any added advantage- in my mind
| there is no need for unobserved codes that are older than a few
| hours unless someone emerges from a jungle or similar place
| with zero internet coverage to distribute the photography. The
| whole idea is that outside observation needs to happen rapidly
| for social proof to emerge, based on which journalistic
| organisations could make editorial decisions.
| msoad wrote:
| I agree that you don't need a blockchain for this but
| consensus systems can be nice. A system that others can run
| this system and somehow verify with your keys as well as
| their own, or anyone running this and offering the API. So
| scanning that QR code will send me to the website of whoever
| generated it but will also show other instances's approval
| there.
| miunau wrote:
| Yes, it's a good idea. It has some security and privacy
| considerations of its own which are outside of my area of
| expertise, and I believe it could be implemented on top of
| the existing spec.
| kmfrk wrote:
| Very clever!
|
| The news article headlines get cut off pretty quickly to the
| effect of "Putin [says something]", but I guess it's not overly
| important as long as the headlines differ in wording.
| miunau wrote:
| Thanks! I thought about using <marquee> for some flair, but
| concluded it's best to leave it as simple as possible for now.
| :) The headline is there to try to provide some familiarity to
| the idea and it's not required for implementation.
| kmfrk wrote:
| Yeah, a marquee probably introduces the potential for blur,
| which can obscure the photo/video and also create false
| positive suspicions of manipulation if it looks blurry in the
| finished capture.
| kazinator wrote:
| > _but if you include a timestamp that was signed by a trusted
| third party within your photo, in a reasonably non-fakeable way,
| it is then provable beyond a reasonable doubt that you indeed are
| capturing the near-present._
|
| This smells like complete bullshit to me. You can incorporate a
| QR code like this into any image whatsoever.
|
| To prove "beyond a reasonable doubt" that an image was taken at a
| certain date, or not before a certain date, you need a trusted
| witness who saw it being taken, who signs the entire image.
| miunau wrote:
| Yes, the observer (preferably multiple) is an integral part of
| the process. The second signing is an interesting idea, though
| I'm not sure if it would prove more veracity over, say, a
| newsroom verifying the code.
| kazinator wrote:
| "verifying the code" means absolutely nothing. Any code
| you're verifying is from the past, and could be edited into
| any image from any time in the past.
|
| All you know is that neither the image nor the code came from
| the future, which is self-evident.
|
| I suspect the idea here is to rely on it being difficult to
| forge a printed version of the QR code that is shot together
| with the scene. For that purpose, a newspaper is better; it
| is more complex. I mean, someone could take a picture in,
| say, the year 2032, using a new QR code (printed on paper and
| everything), and then carefully edit an old QR 2022 QR code
| into that image. It's a very regular, high contrast, simple
| image.
|
| In the era of deep fakes, I can't believe someone would think
| any of this is "beyond the shadow of a doubt".
| miunau wrote:
| A newspaper might not be available; often pictures with a
| blank piece of paper with the date written are used. QR
| Date relies on the signature in the QR code, not just the
| date, which makes it harder to fake within a reasonable
| amount of time. The proof is based on the public key being
| from a trusted authority, and the speed of dissemination.
|
| I don't think anyone has said "beyond the shadow of a
| doubt" besides you. Reasonable doubt is a different thing.
| If you wanted more veracity, you could always keep on
| taking more pictures around the subject with more codes, or
| just keep holding the generator within frame for video.
| megapatch wrote:
| It is a modern version of displaying the current first page of a
| newspaper to prove something has not happened earlier than the
| displayed reference.
| amelius wrote:
| That's probably why QRDate has a news headline in the footer of
| the opening screen.
| IYasha wrote:
| Yup, I'd love the old way better. As long as it's human-
| readable. I hate barcodes in a way because they require tools
| to read. And circumstances vary a lot!
| crtasm wrote:
| I like what the Qubes developers have done with a short
| script adding current headlines and bitcoin block hash to
| their warrant canaries:
|
| https://github.com/QubesOS/qubes-
| secpack/blob/master/canarie...
| systemz wrote:
| From UX side, nice addition would be displaying time in local
| time zone from browser and/or additional list to select
| timezone/country on page with scanned QR code
| miunau wrote:
| Thanks for the feedback, on the front page it was a
| consideration to keep it UTC to not accidentally dox anyone
| using it on-stream. I like the idea for having a selectable
| timezone on the verification page.
| jwilk wrote:
| The date is off by 2000 years.
___________________________________________________________________
(page generated 2022-03-05 23:01 UTC)