I recently downloaded a file. The website said the file should have a SHA-256 hash of: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb

So I ran sha256 filename on my machine. And then lazily compared the hashes. By which I mean "Yeah the first few characters match, as do the last few. It's probably fine."

Stupid lazy humans.

It's pretty easy to demonstrate that you can take a string, generate a hash, and then create a different string which has a hash with the same first character as the original.

This toy example starts with a string "a" and then creates a different string "b". It then pads the "b" string with spaces until the first characters of both hashes match:

$s1 = "a";
$h1 = hash("sha256", $s1);
$first = substr($h1, 0, 1);
echo $first . "\n";

$s2 = "b";

for ($x=0; $x<100; $x++) {
   $s2 .= " ";
   $h2 = hash("sha256", $s2);
   if ( $first == substr($h2,0,1) ) { 
      echo "{$s2}.{$h2}\n";
   }
}

Assuming SHA-256 is randomly distributed, and there are 16 possible values for each character, this should produce ~6.25 matching hashes.

And, indeed it does! Four hashes appear which all have the same first character.

What about generating a "collision" of the first and last characters? 16x16 = 256. So that should be doable on modest hardware.

$s1 = "a";
$h1 = hash("sha256", $s1);
$first = substr($h1, 0, 1);
$last  = substr($h1, -1); 
echo "{$first}-{$last}\n";

$s2 = "b";

for ($x=0; $x<2000; $x++) {
   $s2 .= " ";
   $h2 = hash("sha256", $s2);
   if ( $first == substr($h2,0,1) && $last == substr($h2, -1) ) { 
      echo "{$s2}.{$h2}\n";
   }
}

That spits out a bunch of strings where the first and last characters of the hash matches the first and last of the original hash.

Of course, from there it gets exponentially harder. If you want to match 2 characters at each end, you'll need around 65,536 attempts. As it happens, it takes 74,653 attempts before a "collision" of the first two and last two characters are found.

Of course, padding with spaces makes the string significantly longer. So you could pad with incrementing Unicode characters. Depending on the contents of the message, you could fill it with invisible characters which wouldn't be seen by an ordinary user.

Is this a practical way to generate full-length hashes? No, obviously not. It goes some way to show just how difficult it is to force even a partial collision.

There is a brilliant explanation of this problem space on David Buchanan's blog.

This is a quick example to show how to verify these signatures using PHP. I don't claim that it covers every use-case, and it is no-doubt missing some weird edge cases. But it successfully verifies messages sent by multiple Fediverse servers.

Let's step through it with an example of a message sent from Mastodon to my server.

Headers

The HTTP request starts with these headers:

User-Agent:  http.rb/5.1.1 (Mastodon/4.3.0-nightly.2024-02-23; +https://mastodon.social/)
Host:  example.com
Date:  Sun, 25 Feb 2024 10:48:22 GMT
Accept-Encoding:  gzip
Digest:  SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=
Content-Type:  application/activity+json
Signature:  keyId="https://mastodon.social/users/Edent#main-key",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="
Connection:  Keep-Alive
Content-Length:  2857

Some of those you may be familiar with, some not. The first thing we'll do is a sanity check; was this message sent recently? Because clocks drift in and out of synchronisation, we'll check if the message was within ±30 seconds.

$headers = getallheaders();
if ( !isset( $headers["Date"] ) ) { return null; }  //  No date set
$dateHeader = $headers["Date"];
$headerDatetime  = DateTime::createFromFormat('D, d M Y H:i:s T', $dateHeader);
$currentDatetime = new DateTime();

// Calculate the time difference in seconds
$timeDifference = abs( $currentDatetime->getTimestamp() - $headerDatetime->getTimestamp() );
return ( $timeDifference < 30 );

That was easy! On to the next bit.

Digest

A message posted to the server usually has a body. In this case it is a long string of JSON data. To ensure the message hasn't been altered in transit, one of the headers is:

Digest:  SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=

That says, if you do a SHA-256 hash of the JSON you received, and convert that hash to Base64, it should match the digest in the header.

$digestString = $headers["Digest"];
//  Usually in the form `SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=`
//  The Base64 encoding may have multiple `=` at the end. So split this at the first `=`
$digestData = explode( "=", $digestString, 2 );
$digestAlgorithm = $digestData[0];
$digestHash = $digestData[1];

//  There might be many different hashing algorithms
//  TODO: Find a way to transform these automatically
if ( "SHA-256" == $digestAlgorithm ) {
    $digestAlgorithm = "sha256";
} else if ( "SHA-512" == $digestAlgorithm ) {
    $digestAlgorithm = "sha512";
}

$json = file_get_contents( "php://input" );

//  Manually calculate the digest based on the data sent
$digestCalculated = base64_encode( hash( $digestAlgorithm, $json, true ) );

return ( $digestCalculated == $digestHash );

But, of course, if someone has manipulated the JSON, they may also have manipulated the digest. So it is time to look at the signature.

The Signature

Let's take a look at the signature header:

Signature:
  keyId="https://mastodon.social/users/Edent#main-key",
  algorithm="rsa-sha256",
  headers="(request-target) host date digest content-type",
  signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="

This contains 4 pieces of information.

1. keyID - a link to the user's public key.
2. algorithm - the algorithm used by this signature.
3. headers - the headers which make up the string to be signed.
4. signature - the signature string.

Let's split them up so they can be used:

//  Examine the signature
$signatureHeader = $headers["Signature"];

// Extract key information from the Signature header
$signatureParts = [];
//  Converts 'a=b,c=d e f' into ["a"=>"b", "c"=>"d e f"]
               // word="text"
preg_match_all('/(\w+)="([^"]+)"/', $signatureHeader, $matches);
foreach ($matches[1] as $index => $key) {
    $signatureParts[$key] = $matches[2][$index];
}

Let's tackle each part in order.

Get the user's public key

You might think you can just get https://mastodon.social/users/Edent#main-key - but you would be wrong.

Firstly, you need to tell the key server that you want the JSON representation of the URl - otherwise you'll end up with HTML.

$publicKeyURL = $signatureParts["keyId"];
$context   = stream_context_create(
    [ "http" => [ "header" => "Accept: application/activity+json" ] ] 
);
$userJSON  = file_get_contents( $publicKeyURL, false, $context );

That gets you the JSON representation of the user. On Mastodon, the key can be found at:

I don't know how to automatically find the key, so I've hard-coded its location.

$userData  = json_decode( $userJSON, true );
$publicKey = $userData["publicKey"]["publicKeyPem"];

Get the algorithm

This is rather straightforward. It's just the text in the signature header:

$algorithm = $signatureParts["algorithm"];

Reconstruct the signing header

Let's take a look at the third piece of the puzzle:

headers="(request-target) host date digest content-type"

This says "The signature is based on the following parts in order". So we only care about the headers which make up the request, the host, the date, the digest, and the content type. Other servers may require different parts of the headers.

Again, let's tackle them in order.

(request-target)

This means the method of the request and the target it was sent to. In our example, this is a POST sent to the path /inbox.

host

This is the HTTP host the message was sent to. This should be retrieved from the server, not taken from the sent headers.

date digest content-type

These are the values from the headers which were sent with the request.

Putting it all together

Annoyingly, the HTTP headers are written in Title-Case whereas the headers in the Signature are in lower-case. So some conversion is necessary:

//  Manually reconstruct the header string
$signatureHeaders = explode(" ", $signatureParts["headers"] );
$signatureString = "";
foreach ($signatureHeaders as $signatureHeader) {
    if ( "(request-target)" == $signatureHeader ) {
        $method = strtolower( $_SERVER["REQUEST_METHOD"] );
        $target = strtolower( $_SERVER["REQUEST_URI"] );
        $signatureString .= "(request-target): {$method} {$target}\n";
    } else if ( "host" == $signatureHeader ) {
        $host = strtolower( $_SERVER["HTTP_HOST"] );    
        $signatureString .= "host: {$host}\n";
    } else {
        //  In the HTTP header, the keys use Title Case
        $signatureString .= "{$signatureHeader}: " . $headers[ ucwords( $signatureHeader, "-" ) ] . "\n";
    }
}

//  Remove trailing newline
$signatureString = trim( $signatureString );

This results in a string like this:

(request-target): post /inbox
host: example.com
date: Sun, 25 Feb 2024 10:48:22 GMT
digest: SHA-256=Hqu/6MR2imi8DTzbNp5PNEAFSyk0poN7+x5F+Z4vZMg=
content-type: application/activity+json

Get the signature

The signature that we are sent is in Base64.

signature="P07V5I2zflR8FRsDMHshHmhgOwSkjWevujEbOyKMwjycrdVXjTD0ACiLuc5lTqDEXZ/...4eg=="

It needs to be decoded before we can use it.

$signature = base64_decode( $signatureParts["signature"] );

Verify the signature

We're nearly there! Luckily, we don't have to do any crazy cryptography by hand. We use PHP's openssl_verify():

//  Finally! Calculate whether the signature is valid
$verified = openssl_verify(
    $signatureString, 
    $signature, 
    $publicKey, 
    $algorithm
);

That takes the reconstructed string based on the headers, the signature which was sent, the public key we retrieved, and the algorithm.

If it all matches, it will return true. If not... time for some debugging!

But what about...?

This is not a complete solution. My code almost certainly contains bugs, unforeseen edge-cases, memory leaks, black holes, and poisonous frogs. This is intended to step you through the practical process of verifying an HTTP Message Signature.

Then you should get a properly tested and validated library and use that instead.

I'm going to talk through a proposed user experience, and then discuss how it would work in practice.

Let us imagine a future digital currency ₢. It might be fiat, it might be crypto, doesn't really matter.

• Alice loads up a smartcard with ₢100 and locks it.
• Alice gives Bob the smartcard.
• Bob uses offline verification to see that the smartcard contains ₢100 of unspent currency.
• Bob unlocks the smartcard and transfers the ₢100 to his own wallet.

Sketching out how it works.

The key thing here is that Bob doesn't need to connect to the Internet - or do a live check with any 3rd party - in order to verify that the card has cash. How would that work?

It is - sadly and unavoidably - an escrow system. If you want to avoid the "double-spend" problem without going online, then you need intermediary to vouch that the funds are locked.

Let us imagine a physical token. For example, a Smartcard with an embedded microchip. The microchip has a unique ID and is able to perform certain cryptographic functions. It is able to sign data with its own private key - for example, it may have embedded a subkey of its manufacturer.

When Alice loads a card, this is what happens.

• Alice sends a challenge, signed with her private key, to the Smartcard.
• Smartcard sends Alice a response to the challenge, and its unique ID, signed with its private key.
• Alice tells the Escrow provider that she is in possession of a specific Smartcard by sending her signed challenge and the Smartcard's signed response.
• The Escrow provider checks a public ledger to see if this specific Smartcard is in use.
• If the card is not in use, the Escrow sends a challenge, signed with its private key, to the Smartcard.
• Smartcard sends the Escrow provider a response signed with its private key.
• Escrow provider tells Alice that it is convinced that she is in possession of that Smartcard.
• Alice sends ₢100 to the Escrow provider.
• Escrow sends the Smartcard a cryptographically signed digital certificate saying that Escrow is in possession of ₢100 and will release it to the bearer of the Smartcard.
  • The certificate could be time-limited?
• Smartcard validates the certificate and securely stores it for later retrieval.

Effectively, this Smartcard is now digitally engraved with the words "I promise to pay the bearer on demand". Anyone who proves that they are in possession of that specific Smartcard, can redeem the stored value from the Escrow provider.

Here's how it works.

• Bob asks Alice for ₢100.
• Alice hands Bob a Smartcard.
• Bob asks the Smartcard for the amount it has stored.
• Smartcard responds with a figure which is cryptographically signed with the private keys of the Smartcard and the Escrow provider.
• Bob has previously stored the public keys of all major Escrow providers.
• Bob validates offline the Escrow's signed statement against the Escrow's public key.
  • Alternatively, Bob may have the Smartcard vendor's public keys available for validation.
• Once satisfied the card contains the correct amount, he takes the card.

How does Bob redeem the stored value? Well, firstly, he doesn't have to! The smartcard is fungible. He can hand it over to someone else as payment.

But, if Bob wants to "cash in" the card and transfer the ₢100 to his own wallet, he will need an Internet connection

• Bob sends a challenge, signed with her private key, to the Smartcard.
• Smartcard sends Bob a response to the challenge, and its unique ID, signed with its private key.
• Bob tells the Escrow provider that he is in possession of a specific Smartcard by sending his signed challenge and the Smartcard's signed response.
• The Escrow provider checks a public ledger to see if this specific Smartcard is in use.
• If the card is not in use, the Escrow sends a challenge, signed with its private key, to the Smartcard.
• Smartcard sends the Escrow provider a response signed with its private key.
• Escrow provider tells Bob that it is convinced that he is in possession of that Smartcard.
• Bob tells the Escrow provider he wants to cash out and sends them the details of his wallet.
• Escrow provider sends an instruction to the smart card to "self-destruct" and remove the signed amount.
• Smartcard deletes the stored amount and sends a signed transaction back to the Escrow.
• Escrow transfers the money to Bob's wallet.

All this is... complicated. And relies on smartcards which have close-to-unbreakable storage for their private keys. And has a lot on baked-in assumptions about humans want to transfer money. But it is something. At the moment, all cryptocurrencies demand a permanent Internet connection if you want to use them. I think offline transactions are useful.

Notably, it doesn't require a blockchain or any cryptocurrency. It makes use of cryptography, sure. But you don't need inefficient, permanently-online, slow databases to make this work.

1. There exists a class of numbers which are illegal in some jurisdictions. For example, a number may be copyrighted content, a decryption key, or other text considered illegal.
2. There exists a class of algorithms which will take any arbitrary data and produce a fixed length text from it. This process is known as "hashing". These algorithms are deterministic - that is, entering the same data will always produce the same hash.

Let's take the MD5 hashing algorithm. Feed it any data and it will produce hash with a fixed length of 128 bits. Using an 8 bit alphabet, that's 16 human-readable characters.

Suppose you live in a country with Lèse-majesté - laws which make it treasonous to insult or threaten the monarch.

There exists a seemingly innocent piece of data - an image, an MP3, a text file - which when fed to MD5 produces these 128 bits:

01001001 00100000 01101000 01100001 
01110100 01100101 00100000 01110100 
01101000 01100101 00100000 01110001 
01110101 01100101 01100101 01101110 

Decoded into ASCII, that spells I hate the queen.

128 bits is probably too short to be illegal in all but the most repressive of regimes. It would be hard, if not impossible, to squeeze terrorist plans into that little space.

But it is just enough space to store an encryption key for copyrighted material.

Therefore, it is possible that there exists a file which - by pure coincidence - happens to have an MD5 hash which is illegal.

Because MD5 is a relatively weak algorithm, it is possible to create deliberate hash "collisions". That is, take some data and manipulate it until it has the same MD5 as a different piece of data.

Someone could, theoretically, deliberately create a file which looks unremarkable when viewed, but is illegal when hashed.

The SHA-1 hashing algorithm produces 160 bits - 20 ASCII characters. It is somewhat cheap and easy to produce a file with a specific SHA-1 hash.

The SHA-512 hashing algorithm, as its name suggests, produces a 512 bit hash. That's enough space for 64 ASCII characters. Is that long enough to contain text which is blatantly illegal? Almost certainly. But modern hashing algorithms are designed to be resistant to collision attacks. So much so that it seems like theoretical quantum computers will be needed to crack them. The chances of any file having an illegal hash is infinitesimally small.

Nevertheless, it intrigues me that there may be a form of hash-steganography. How would you detect whether the hash of a file was problematic?

Suppose you have a super-secure password for a Really Important Thing.

Th15IsMyP4s5w0rd!123

You can remember this - because you're awesome. But it might be a good idea to share the password with someone else, just in case. Of course, if you share it with one person, they'll be able to use it. No good! So you split the password into several overlapping pieces and give each one to a different trusted friend.

 T____s____s____d____ 

 ____Is___4s___r____3 

 Th____MyP4____r____3 

 __15_______5w0__!12_ 

And so on and so forth. As you can see, no one person has the entire password. All the participants need to get together in order to reconstruct the whole things.

(This is a massive simplification. The real SSS is so mind-boggling complex that your brain will melt before you understand even half of it. At a minimum, you need to be able to understand maths like this:

before you can even make a start.)

You can make it so that a simple majority of secret-holders are mathematically guaranteed to be able to reconstruct the password. So you could split it between 10 friends, safe in the knowledge that your security is impenetrable until at least 6 of them betray you.

"Murder on the Orient Express" is one of Agatha Christie's most beloved murder mysteries. It's 88 years old which, so I'm told, is beyond the statute of limitation for spoilers.

In the book, American businessman Samuel Ratchett is murdered while travelling on the Orient Express train. But which passenger murderised him?

All of them. They all did it. Individually they all had motive, so they ganged up and each stabbed him.

I'm sure none of your friends would do the same.

If you used SSS to split your Cryptocurrency password between a dozen trusted friends, I'm sure the promise of untold riches wouldn't be enough to tempt half of them. Would it?

Of course, you don't tell the secret-keepers who their fellows are. But social graphs are fairly easy to navigate. And not all of your friends have perfect security. A few hacks here, a gentle inquiry there, a bribe or two, and a threatening word in the right ear - suddenly you find yourself drugged, in the dark, and being stabbed. Metaphorically.

There are no simple technological solutions to complex social problems.

There is no fancy mathematics which can fix this. If you split a secret in such a way that it can be reconstructed for a sanctioned purpose, then it can be reconstructed for an unsanctioned purpose.

SSS is a technologically excellent scheme - but it requires strong social bonds to operate effectively.

How can you, as a publisher, prove that you wrote a scheduled Tweet at a specific time?

Here's one method.

1. Write a Tweet which contains a timestamp - "This is my message 2020-08-17"
2. Generate a hash of the message - SHA256: BAE149775399E3AEBC9DEF9D4D4468C9217593B58B76655F479C9CEE4FF73CBA
3. Post the hash to Twitter.
4. Schedule your message as a reply to the hash.

Here's an example - check the dates:

Terence Eden is on Mastodon

@edent

My reply to this message will have a SHA256 hash of:
04CBC2CCD67A7C4F932FCBD21E8A5C366D4E18D1AC2EDC6782FDC873AE1E2859

---

Terence Eden is on Mastodon

@edent

Replying to @edentThe previous Tweet in this thread contains the SHA256 hash of *this* Tweet. This message was written on 2020-08-17.

---

Is this useful?

Probably not very useful. Here's a couple of ideas.

Post your prediction for something, without influencing it. For example, the results of an election.

A sort of Dead Man's Switch - a message to be sent when you're not available.

It isn't foolproof.

It's really easy to screw up a hash. My first couple of experiments didn't work because of errant whitespaces.

Modern hashes like SHA256 are probably resistant to collisions in Twitter's limited message space.

And, of course, a person can post two hashes - for contradictory messages - and only publish replies one of them.

As the recipient of some data, I want to verify that it hasn't been tampered with.

and

As the recipient of some data, I want to verify who originally published it.

Here's why I think this is important. We are in an era of fake news. A screenshot can be easily altered. A webpage is trivial to edit. But data should be provably true.

Recently, a prominent person's private Twitter messages were leaked. It was presented as a series of JSON files ostensibly directly from the API. But, of course, there was no way to prove the data-dump didn't contain misinformation.

If I call https://api.example.com/?id=123 myself, then I can be reasonably sure that the data has come from the server unaltered.

But what if someone emails me a JSON file? Or someone re-hosts an XML dump? Or a hacker claims to have uncovered proof of...?

As data-journalism gathers pace, it's vital to be able to see whether data is authentic.

Suppose you see a news site claiming that your favourite sports star endorses the opposing team. They have an image of a tweet. But you wouldn't trust an image of a website (I hope) without a checking a live link. Right?

But in the data world, we get no such assurances.

Here's data from a Tweet I've just faked:

{
  "created_at": "Wed Oct 10 20:19:24 +0000 2018",
  "id": 105011862119892123,
  "text": "Terence Eden is now officially the King of Australia",
  "user": {
    "id": 6253282,
    "id_str": "6253282",
    "name": "Australian Government",
    "screen_name": "AusGovOfficia1",

I've just made that up. But you've got no way to prove that it did not come from Twitter. Perhaps it was a real Tweet which was subsequently deleted?

Where this matters

Do you rely on data for your job? If someone gives you a scrap of data claiming to be from a website, how can you prove it is authentic?

Perhaps a Police API tells you what the crime rate is, or a betting API tells you what the odds are, or a news API tells you who was convicted of a crime. Or a source leaks information from a social network. How can you prove that the data is authentic and unaltered? Or someone else could present false data as coming from a trusted source. Or a trusted source could publish fake data and later claim they didn't.

Here's the end result that I want.

• Given a piece of data,
• Prove that where it came from and,
• Prove that it hasn't been altered.

How to do it

This is where I get stumped. I can clearly see the need for this. Disinformation is an attack on civilisation. But I can't see how to do it in a seamless and easy to understand way.

There have been lots of proposals for how to do this.

I think it boils down to three distinct design choices.

1. Keep the signature and the message separate.
2. Include the signature in the message.
3. Only sign part of the message.

Separation of Powers

The first is conceptually easiest.

• The API call example.com/?id=123 returns some JSON containing the data requested.
• The API call example.com/?id=123&signed=true returns the signature only.

It relies on a few assumptions. Mostly that a GET operation is Immutable in terms of what it returns. That is, the data returned from a query is always the same.

It reduces complexity for the server and client. If the client doesn't care about verification, the server doesn't have to calculate it.

It might be complicated to store the information. You would need to keep response.json and response.signed.json as separate files.

It might be fragile. If a single bit or byte of the data is altered - say tabs get converted to spaces - then the signature could become invalid.

If you want someone to verify an API response, they need two separate files and need to load them in the right order into any verification system. Again, not an impossible task, but might make things more complicated than necessary.

Inclusivity

Does the set of all sets include itself? This isn't just a philosophical problem. If a signature is included in a response, does the signing process have to take account of the signature?

The usual way around this is to encode the result first. So, imagine your API response was BASE64 encoded and then signed. It might look like this:

{
   "response": "data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D...",
   "signature": "0f60066673e0de...."
}

That keeps the document and signature together, but does have some disadvantages. It loses the human-readable nature of the response. It also means that your code has to BASE64 decode the response before interpreting it. Both of those are annoying for debuggers - but not critical issues.

Partial

What if we only sign the critical parts of the response, rather than all the metadata? This is perhaps the easiest to implement, but has some drawbacks.

{
  "created_at": "Wed Oct 10 20:19:24 +0000 2018",
  "id": 105011862119892123,
  "text": "Terence Eden is now officially the King of Australia",
  "text-sig": "0f60066673e0de....",
  ...

That is, only sign the text. Or perhaps text + ID. Or any useful subset of the API response. It's simple to parse for humans and computers. But the metadata might be a crucial part of the information we want to verify. Knowing the date something was published, for example, could be as important as the content itself.

Put it all on the blockchain!!!!!

No.

Well... OK. Maybe this is a use for a Merkle Tree or similar. If every API response has an ID, then a cryptographic hash could be appended to a public ledger. But that has all the disadvantages of the previous schemes without any real benefit.

Security is hard

The problem with all of the above approaches is that the API provider needs to safely and securely manage cryptographic keys. That's expensive and complicated. If an attacker got access to the keys, they could issue fake statements.

But, the good news is that the tech tech is here and it works. JOSE is a suite of specifications - including JSON Web Tokens - which are well used across the Internet. Mostly for signing OAuth logins.

So, can we use it?

Will anyone care?

I suppose this is the crucial question. Right now I can easily fake a screenshot and the majority of people won't even look to see if the information is true - no matter how incredible the claim is.

But we need to build a better foundation for the future. One where information brokers can say "I have proof that this exact data came from this specific website at this precise time."

We have to believe that truth and trust are important.

You see, most uses of Distributed Ledger are really just a way to get people interested in cryptographic signing. There's lots of money and attention flowing to projects which have no need to publish to an energy-inefficient global database. They would be better suited to public-key cryptography.

Let me give you an example, then we'll dive in to some details.

Recently, I needed to prove that I went to University. How did I do it? I rang up the alumni department, paid for a copy of my transcript, they posted it to me printed on high quality paper, I scanned it and emailed it to the person who wanted it. I've no idea if anyone checked if it was legitimate.

This is fragile nonsense!

In an Internet-connected world, sending forgeable bits of paper around is just daft. All the university need to do was publish something like this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I confirm that Terence Eden studied at Example University 1998-2002 
earning a 2.1 in Advanced Drinking
-----BEGIN PGP SIGNATURE-----

wsFcBAEBCAAQBQJbCnsECRAADQX2QFV8YgAA6swQAHTZ2jtR2x5bK1oX+shZK0SM
1EXIWvBN0ECzeFsY86AtL4bd9qTKwpjgWPsPN4NSh7Rpg2xvgLTKIdFWSsMsWTrw
QPtKiaFbYa/1Cah8uBV6rSJOodKXRGveni9vojpjT1fUZ0APhzhLbki6mvfwMquq
IWQwqgEAp4odp8Yv98sIXvSKlc/f7Y4XDYmCyapPaoNDOpzXsROSuQIqaLqrTrjf
D/U+fTQrKSx9LqsW7KLgb3dfBPXVOjBmFdCn+iNJjVMF1GLNk0fjWsUu3oy4vvrX
9SCoM5TzCxBRdGZpVmrvOSr0hg5Rmx7VRXfVhUj4/kfaM2s0NWxGr0rBMzRYsl1o
OLDplZqhYxcHI3XivfFTAwZY7UZvCPnNJCQCFDtpFnRgdpq97Lynj2cF6u9gU/gL
Kb3cTeut2uHtMJAG7DN3tpQMLWDrbX96eXDB64zD73gfOyXrbjivSStSlCC8VrmU
njkc3393qiYW9AF9zKtYo8x/9n0/WhO6kSW0Mt/V6LdIhqFVqHyWZqh6vRAtfNIf
W80OR/dKtXSBYZgmg72/pgZBNeBne9lL+Nd4I/MlVzmC96fI+jkoeXO0cZanXWRm
2JoW+7R8I8de4PS9fjTMl8fVgEAsWFXjMUas0fJu4POxQDoSIaSEGxYJvTc01lGS
tzdqLOC6zBKeS6ndUFdH
=kSYS
-----END PGP SIGNATURE-----

Now, perhaps it needs to be cross-signed with a Trusted Timestamp Server or possibly incorporating my signing key as well - but the basics are there. Either stick that up on a website, or email it to anyone who wants to check my qualifications.

No Merkle-Trees or paying vastly inflated transaction fees. Just a document which has been signed by the issuer and can be validated as legitimate. Why do you need anything else? Public key signature systems are quick, simple, and cheap. Pick any three!

The best part is... this technology is already in use! If you have a modern passport, it contains an RFID chip which holds data about you. These biometric data are cryptographically signed. It uses a PKI solution to ensure no one has tampered with the information.

Potential Uses

Feel free to add more in the comments section.

• Qualifications
  • Example University confirms that I have this qualification.
• Work history / employment references
  • Big Corp verifies that I was employed from these dates in this position.
• Customer verification
  • Energy Company confirms I am a current customer.
• Nuclear Launch Codes
  • This order is legitimate and has been cross-signed by at least 3 members of the of the command chain.
• Medicine Licencing
  • This drug is approved by this regulator in this territory.
• Legislation
  • This amendment to that law was published by this legislature.
• Prison sentences
  • This Judge issued this sentence on that person.
• Food
  • The farm that provided this food has been certified as an organic farm by this inspector.
• Statements
  • This document was written by that author and published by that organisation.
• Prescriptions
  • This doctor from that surgery prescribes these drugs to that patient.
• Credit History
  • This mortgage has been provided to that person and they have paid off 10% of it.

Downsides

This is a technological solution to the human problem of trust.

Firstly, there's no guarantee that people will actually verify the message - as this XKCD Cartoon puts so succinctly.

Secondly, there's no guarantee that people will actually have the software to verify the message - US Border Patrol are still unable to verify e-Passports.

Thirdly, there's no guarantee that keys won't be stolen or broken in the future. One (small) advantage of a Distributed Ledger is that you can verify when a claim was published. Assuming a malicious party hasn't found yet another weakness in the technology.

Fourthly, a claim once issued is hard to revoke. If my university discovers I cheated in an exam, of if a company mistakenly says I am their customer - how do you issue a notice of revocation? If a corrupt employee is bribed to make a fake claim about me, it could be impossible to backtrack. Again, this problem isn't solved by putting claims on a BlockChain.

Finally, there's no guarantee that people will understand what verification means.

Just because I present you evidence that "Terence Eden" has a qualification, that doesn't mean that I am Terence Eden. Or even the same Terence Eden mentioned.

Just because the label on a box of baby-milk claims that the supply chain has been verified, it does not mean that the contents are unadulterated with plastic.

Which leads us back to the start. We can make verifiable claims - but will anyone care? In a world where a scrawled ink signature is seen as the ultimate proof of truth and easily debunked forgeries are treated as genuine news how do we convince people to care about verification?