6 ms·

There used to be - probably still are - cameras that would digitally sign all their images. Used in crime scenes? Maybe we will end up seeing wider adoption of

There used to be - probably still are - cameras that would digitally sign all their images. Used in crime scenes? Maybe we will end up seeing wider adoption of this, despite the privacy implications. Hackers attention then will focus (once again) on the certificate supply chain and crypto hardware.

aorloff 3mo ago
I imagine in this age of blockchains you could embed into a media file a signature that proved it was no older than the timestamp of when it occurred, the digital equivalent of a hostage-proof-of-life photo with a recent newspaper But I don't know of a cryptographic mechanism to ensure that a digital image is not more recent than a particular time
- catlikesshrimp 3mo ago
  Interesting, There aren't any newspapers left in my country, neither printed nor not printed. The closest you can find is the weekly advertising booklet here and there. Which is irrelevant now because a computer can either stich new content to an old picture, or entirely producing a custom picture. That would be a use case for a block chain. But I still don't understand how you are securing the integrity of the validity of the certificate stating the authenticity of the media. I only understand you are stamping media with a "at least as old as [timestamp]
  - 3eb7988a1663 3mo ago
    If you want to prove that "happened at or after this timestamp" you can use a randomness beacon. NIST[0] and others publish a random number every N minutes. Embed that (or a combination) of those seeds to prove that you observed this value. This does not work for the harder problem of proving an event happened before a timestamp. [0] https://csrc.nist.gov/projects/interoperable-randomness-beacons https://csrc.nist.gov/projects/interoperable-randomness-beac...
    - aorloff 3mo ago
      Thanks - this is the perfect example of how to do this
    - Dwedit 3mo ago
      Seems like this idea solves a different problem than signed timestamps. You have access to not only the current random numbers, but also any random number from the past (as long as someone somewhere wrote it down). I just don't quite get what this could solve if you can either use a current number or an old number. Just not a future number because they're not around yet. Embedding a public random number also doesn't resist tampering, unlike signed timestamps.
  - appaj 3mo ago
    Which country no longer has newspapers?
- __del__ 3mo ago
  wouldn't that be a hash of the image signed by a trusted entity and stored on a chain? maybe i'm overlooking why this doesn't work
- deleted 3mo ago
  [deleted]
- gcr 3mo ago
  Publish hash(image) on the blockchain at a verifiable time, then publish the image itself. The image contains the previous block’s hash. Wouldn’t this establish both a lower bound and an upper bound on the time the image could have been produced?
  - bigiain 3mo ago
    You don't need a blockchain for that. You just need some reliable-enough way to publish hash(image) with a timestamp - some way that it's infeasible enough as to be considered impossible for thepublisher to change the hash or the date. Back when I was on Twitter and following a lot of infosec accounts, it was quite common to see tweets that were just a hash. Sometimes they'd have an explanation "Zero click RCE in Android 10 - {hash}" In the past I've used gmail for this internally - email a hash of something critical (logs, configurations, decision docs, etc) to a dedicated gmail account - relying on the in feasibility of "faking" the date/time once it's onb Google's servers. The important thing here would be to make sure those hashes are published somewhere where its technically infeasible for the police to change it after the fact, so not on a platform the police run or p-aid for (or that is run or paid for by an organization that the police can request or coerce the operators to make changes).
    - XorNot 3mo ago
      You literally just need several oracles which sign hashes at the time they receive them and record that fact. As a community service you need them to have enough scale that no individual hash or source can be tampered with without being likely to become known as unreliable to everyone else as well ala certificate transparency records. (You could probably just bootstrap let's encrypt for this - issuing a certificate you use to sign a bunch of data would stamp several minimums on the order anything could have happened).
- dspillett 3mo ago
  > But I don't know of a cryptographic mechanism to ensure that a digital image is not more recent than a particular time Many (most?) blockchain mechanisms include a timestamp in each transaction on the chain, so while multiple records from the same owner prove little (the timestamps could be faked over a given period of time) the interaction with the wider network and the chain would give some confidence that the record happened between within a small amount of time. The other possibility, that doesn't require a chain with many independent active participants, is to have things signed by an external trusted authority. Submit a hash of the content and appropriate metadata to them, and have them sign it with a signing timestamp. I've considered abusing ACME certificates for document signing like that: the hash of content (or some signature based upon it) becomes the subdomain to sign¹ and you get a certificate that even after expiry is evidence that the CA saw that value at the signing timestamp. Note of the signing will also be in the public certificate transparency log. This wouldn't, on its own, prove anything about the authenticity of the content, that could have been doctored before signing, but it does prove that the content+metadata existed at that time (so might be more useful in copyright claim type cases, or agreed contract situations where all parties have signed the content and the signatures are included in the metadata, than for proving authenticity). ---------------- [1] based64²-ed with non-alphanumeric characters removed and truncated³ to fit or split, so acodha3sf7whsrhtqestkabtx0b4bbhyveee0ajnrpqcuxrjjvmhsujgcex.domain.tld or acodha3sf7whsrhtqestkabtx0b4bbhyveee0ajnrpqcuxrjjvmhsujgcex.w5jmmkpmyfgshx2jecsfordpnq.domain.tld [2] names not being case-sensitive drops some of the entropy, if that is a concern use a 32-bits-per-character encoding instead and have names twice as long
  - aorloff 3mo ago
    I suppose you could put a hash of the content into a TXT record
    - dspillett 3mo ago
      There isn't a way to externally sign/validate a TXT record, that I know of. A TXT record may be used in the signing process if using DNS verification, but you are getting a certificate for the name overall so using an A record to hold the hash you are looking to certify does the trick, then if you want to use HTTP-01 for verification rather than an extra DNS record you can.
ChrisMarshallNY 3mo ago
I worked for a company that made these. We sold expensive software to the FBI. Took about six months for someone to crack the hash.
- deepserket 3mo ago
  What about a system that saves in some way the hash in a Blockchain, and if you, eg, XOR the hash of the video with the hash of the previous block you will "certainly" know that the video was created between the previous block and the block where the hash is saved in. That's a starting point.
  - ChrisMarshallNY 3mo ago
    Might have a point. This was before blockchain. I suspect that the cops wouldn’t like the chain public, though.
    - Terr_ 3mo ago
      Like when people discuss voting, I believe a blockchain [0] is a terrible pitfall compared to a classic distributed database system of predefined nodes run by different organizations. For example, imagine a couple hundred predefined nodes run by different states, federal agencies, etc. An attacker altering the ledger would still require compromising an unreasonably large number of independent groups at once, and even then the rest would be able to clearly see that some unusual and suspicious event occurred. By limiting membership a bunch of problems simply vanish, like long-clearing times, wasting hardware on mining, vulnerability to foreign botnets, etc. [0] A blockchain is distinguished by its core requirement, from which a cascade complexity flows: Uncontrolled node membership. Don't be fooled by people pitching "private blockchain", its a contradiction in terms designed to rehabilitate hype, like "multi-sample Theranos test" or a bicycle as "Segway passively stabilized inline wheel model."
      - girvo 3mo ago
        You just described IBM's whole Hyperledger Fabric thingy. I worked with it once upon a time, with the biggest insurance companies in my country where they plus a regulator all ran nodes.

aorloff 3mo ago

I imagine in this age of blockchains you could embed into a media file a signature that proved it was no older than the timestamp of when it occurred, the digital equivalent of a hostage-proof-of-life photo with a recent newspaper But I don't know of a cryptographic mechanism to ensure that a digital image is not more recent than a particular time

catlikesshrimp 3mo ago
Interesting, There aren't any newspapers left in my country, neither printed nor not printed. The closest you can find is the weekly advertising booklet here and there. Which is irrelevant now because a computer can either stich new content to an old picture, or entirely producing a custom picture. That would be a use case for a block chain. But I still don't understand how you are securing the integrity of the validity of the certificate stating the authenticity of the media. I only understand you are stamping media with a "at least as old as [timestamp]
- 3eb7988a1663 3mo ago
  If you want to prove that "happened at or after this timestamp" you can use a randomness beacon. NIST[0] and others publish a random number every N minutes. Embed that (or a combination) of those seeds to prove that you observed this value. This does not work for the harder problem of proving an event happened before a timestamp. [0] https://csrc.nist.gov/projects/interoperable-randomness-beacons https://csrc.nist.gov/projects/interoperable-randomness-beac...
  - aorloff 3mo ago
    Thanks - this is the perfect example of how to do this
  - Dwedit 3mo ago
    Seems like this idea solves a different problem than signed timestamps. You have access to not only the current random numbers, but also any random number from the past (as long as someone somewhere wrote it down). I just don't quite get what this could solve if you can either use a current number or an old number. Just not a future number because they're not around yet. Embedding a public random number also doesn't resist tampering, unlike signed timestamps.
- appaj 3mo ago
  Which country no longer has newspapers?
__del__ 3mo ago
wouldn't that be a hash of the image signed by a trusted entity and stored on a chain? maybe i'm overlooking why this doesn't work
deleted 3mo ago
[deleted]
gcr 3mo ago
Publish hash(image) on the blockchain at a verifiable time, then publish the image itself. The image contains the previous block’s hash. Wouldn’t this establish both a lower bound and an upper bound on the time the image could have been produced?
- bigiain 3mo ago
  You don't need a blockchain for that. You just need some reliable-enough way to publish hash(image) with a timestamp - some way that it's infeasible enough as to be considered impossible for thepublisher to change the hash or the date. Back when I was on Twitter and following a lot of infosec accounts, it was quite common to see tweets that were just a hash. Sometimes they'd have an explanation "Zero click RCE in Android 10 - {hash}" In the past I've used gmail for this internally - email a hash of something critical (logs, configurations, decision docs, etc) to a dedicated gmail account - relying on the in feasibility of "faking" the date/time once it's onb Google's servers. The important thing here would be to make sure those hashes are published somewhere where its technically infeasible for the police to change it after the fact, so not on a platform the police run or p-aid for (or that is run or paid for by an organization that the police can request or coerce the operators to make changes).
  - XorNot 3mo ago
    You literally just need several oracles which sign hashes at the time they receive them and record that fact. As a community service you need them to have enough scale that no individual hash or source can be tampered with without being likely to become known as unreliable to everyone else as well ala certificate transparency records. (You could probably just bootstrap let's encrypt for this - issuing a certificate you use to sign a bunch of data would stamp several minimums on the order anything could have happened).
dspillett 3mo ago
> But I don't know of a cryptographic mechanism to ensure that a digital image is not more recent than a particular time Many (most?) blockchain mechanisms include a timestamp in each transaction on the chain, so while multiple records from the same owner prove little (the timestamps could be faked over a given period of time) the interaction with the wider network and the chain would give some confidence that the record happened between within a small amount of time. The other possibility, that doesn't require a chain with many independent active participants, is to have things signed by an external trusted authority. Submit a hash of the content and appropriate metadata to them, and have them sign it with a signing timestamp. I've considered abusing ACME certificates for document signing like that: the hash of content (or some signature based upon it) becomes the subdomain to sign¹ and you get a certificate that even after expiry is evidence that the CA saw that value at the signing timestamp. Note of the signing will also be in the public certificate transparency log. This wouldn't, on its own, prove anything about the authenticity of the content, that could have been doctored before signing, but it does prove that the content+metadata existed at that time (so might be more useful in copyright claim type cases, or agreed contract situations where all parties have signed the content and the signatures are included in the metadata, than for proving authenticity). ---------------- [1] based64²-ed with non-alphanumeric characters removed and truncated³ to fit or split, so acodha3sf7whsrhtqestkabtx0b4bbhyveee0ajnrpqcuxrjjvmhsujgcex.domain.tld or acodha3sf7whsrhtqestkabtx0b4bbhyveee0ajnrpqcuxrjjvmhsujgcex.w5jmmkpmyfgshx2jecsfordpnq.domain.tld [2] names not being case-sensitive drops some of the entropy, if that is a concern use a 32-bits-per-character encoding instead and have names twice as long
- aorloff 3mo ago
  I suppose you could put a hash of the content into a TXT record
  - dspillett 3mo ago
    There isn't a way to externally sign/validate a TXT record, that I know of. A TXT record may be used in the signing process if using DNS verification, but you are getting a certificate for the name overall so using an A record to hold the hash you are looking to certify does the trick, then if you want to use HTTP-01 for verification rather than an extra DNS record you can.

ChrisMarshallNY 3mo ago

I worked for a company that made these. We sold expensive software to the FBI. Took about six months for someone to crack the hash.

deepserket 3mo ago
What about a system that saves in some way the hash in a Blockchain, and if you, eg, XOR the hash of the video with the hash of the previous block you will "certainly" know that the video was created between the previous block and the block where the hash is saved in. That's a starting point.
- ChrisMarshallNY 3mo ago
  Might have a point. This was before blockchain. I suspect that the cops wouldn’t like the chain public, though.
  - Terr_ 3mo ago
    Like when people discuss voting, I believe a blockchain [0] is a terrible pitfall compared to a classic distributed database system of predefined nodes run by different organizations. For example, imagine a couple hundred predefined nodes run by different states, federal agencies, etc. An attacker altering the ledger would still require compromising an unreasonably large number of independent groups at once, and even then the rest would be able to clearly see that some unusual and suspicious event occurred. By limiting membership a bunch of problems simply vanish, like long-clearing times, wasting hardware on mining, vulnerability to foreign botnets, etc. [0] A blockchain is distinguished by its core requirement, from which a cascade complexity flows: Uncontrolled node membership. Don't be fooled by people pitching "private blockchain", its a contradiction in terms designed to rehabilitate hype, like "multi-sample Theranos test" or a bicycle as "Segway passively stabilized inline wheel model."
    - girvo 3mo ago
      You just described IBM's whole Hyperledger Fabric thingy. I worked with it once upon a time, with the biggest insurance companies in my country where they plus a regulator all ran nodes.