pgp – Terence Eden’s Blog

An NFT without a Blockchain. No gas fees. No Eth. No gatekeepers

@edent — Sat, 18 Dec 2021 12:34:38 +0000

This is a small proof-of-concept. It relies on PGP - but you could use Keybase, GPG, or any other hard-to-use encryption program.

Background

Suppose you want to support an artist and give them money. That's easy. Most artists take PayPal, bank transfer, or cash. But how can you prove that you've paid an artist for a specific piece of work? That is, in essence, all an NFT is - the seller signing a statement that the buyer has sent them money related to a thing.

Whether that claim can be meaningfully sold on to someone else is outside the scope of this discussion.

The artist's signature

Most cryptographic schemes let a user digitally sign a file. Essentially, all this says is "this string of bits was seen by this user". It cannot say whether the signer was the person who originally created the file.

Here's an example.

-----BEGIN PGP SIGNED MESSAGE-----
I, Terence Eden, created "monkey.jpg" with a SHA512 hash of
123a887f3d5e7f246077eee40d0c073fa5ecad85d5b9bd130a87eb07408…
This token was created at 2021-12-25T01:02:03.5Z
-----BEGIN PGP SIGNATURE-----
Version: 1.2.3

456aae68585c9b176e06792396a08ad9ab92e335940e33c79ab69053a55e4f19…
-----END PGP SIGNATURE-----

Hey presto! Now the seller has a token - the above file - which offers strong proof that they were in possession of that exact monkey.jpg file.

(In reality, this would be a formal schema - JSON, ASN.1, XML, whatever - with lots of metadata. But for these examples, let's keep it simple and human readable.)

The transaction

The sale can go via any medium. Cash in hand, PayPal, bank transfer, or even unregulated cryptocurrency. The problem with Blockchain is that you cannot guard against off-chain transactions. There's nothing to stop me buying an NFT for 100ETH and the seller immediately returning that to me in cash.

Here's how a buyer can create their own "receipt" saying that they purchased the above token:

-----BEGIN PGP SIGNED MESSAGE-----
I, Luke Skywalker, have purchased "monkey.jpg" with a SHA512 hash of
123a887f3d5e7f246077eee40d0c073fa5ecad85d5b9bd130a87eb07408…
And signed with
456aae68585c9b176e06792396a08ad9ab92e335940e33c79ab69053a55e4f19…
For 100ETH
This payment was sent at 2021-12-26T02:03:04.5Z
-----BEGIN PGP SIGNATURE-----
Version: 1.2.3

798a42cec24ff0cc40a9270a645f115c137625e1868563044adb139a1d0a3050…
-----END PGP SIGNATURE-----

The seller can verify the transaction once they have received the money:

-----BEGIN PGP SIGNED MESSAGE-----
I, Terence Eden, have sold "monkey.jpg" with a SHA512 hash of
123a5887f3d5e7f246077eee40d0c073fa5ecad85d5b9bd130a87eb07408…
And signed with
456aae68585c9b176e06792396a08ad9ab92e335940e33c79ab69053a55e4f19…
For 100ETH
To Luke Skywalker
With transaction signature
789a42cec24ff0cc40a9270a645f115c137625e1868563044adb139a1d0a3050…
This receipt was generated at 2021-12-27T02:03:04.5Z
-----BEGIN PGP SIGNATURE-----
Version: 1.2.3

000a7324409938862ff8006291b5471aef8c7ba4732a60e6823e77284d42cf17…
-----END PGP SIGNATURE-----

Ta-da! The buyer now has a chain of cryptographically signed, Non-Fungible Tokens, which shows that an artist claims to have created a file and claims to have received funds from the buyer.

Sure, you can pad it out with a bit more back-and-forth, adding promises to sell, more thorough metadata. You could even use a publicly agreed-on Merkle Tree to add a bit more "trust".

And that's how you mint an NFT with none of the baggage and none of the fees. Easy!

Problems

But there are a few drawbacks with this.

Without a published chain of transactions, there is no guarantee that the artist hasn't sold the same item multiple times.

Without a verified on-chain transaction, there is a risk that either the buyer or the seller may be lying about the transaction price.

Because there are no third-parties involved, there is no opportunity for escrow or complaint resolution.

To be clear - all of these problems are also present in "traditional" NFTs. Buyers have no idea of the provenance of the piece, there's nothing stopping multiple sales of visually identical artworks, scams are rife and smart-contracts are buggy.

But if you want to create an Non-Fungible Token - there's no reason to pay inflated "gas" fees. You don't need any centralised brokers or platforms. You can own your own ledger and be completely decentralised for free.

Web3 should be about you being in control - not endlessly paying micro-transactions to hundreds of gatekeepers.

Update

Siyuan Ma has built a Proof of Concept Chainless NFT

PGP Sign Your Twitter Messages

@edent — Thu, 14 May 2020 11:01:25 +0000

I'm not sure if I'm the first person to do this - but I'm going to claim credit anyway!

You can verify by pasting the alt text into keybase.io/verify - or by using your favourite command line tool.

Back in 2017, I wondered if Twitter's alt text could be (ab)used to store message metadata like a PGP signature. Sadly, the limit was 420 characters per image.

At some point in the last few months, Twitter quietly upped the alt text limit to 1,000 characters per image.

So, if you pgp --sign some text, you can paste the result into the alt text field on Twitter. If I had time, I'd create a Twitter client to do this for you automagically.

I pointed out in 2015 that Twitter Direct Messages were long enough for PGP encrypted messages.

Nowadays, Tweets can contain 280 characters in their body + 4,000 characters of image metadata - that should be more than long enough for a PGP encrypted Tweet.

Of course, due to the "baroque" nature of PGP, there's a fair chance I've messed this up some how!

(NB - alt text is really important for visually impaired users. Please don't needlessly clutter their timeline with garbage.)

Things For Which Cryptographic Signing Would Be Useful

@edent — Sun, 27 May 2018 14:26:30 +0000

Every time someone mentions BlockChain, I have to down my drink. Those are the rules.

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:

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?

PGP Encrypt Twitter DMs with Keybase

@edent — Fri, 04 Sep 2015 10:51:25 +0000

This is a quick tutorial on how to encrypt your Twitter messages using PGP with the help of Keybase.io.

I read an article yesterday which seemed to imply that Twitter was mangling PGP encrypted messages (albeit unintentionally).

There is a minor bug in Twitter's web interface - but PGP seems to work perfectly in apps. So, I want to demonstrate how it can be done successfully.

I've written this article with a non-technical audience in mind - feel free to point out any areas where I can make my explanations more simple.

Get My Public Key

Suppose you want to send me a message - but you are worried about the contents being seen by someone else. If you encrypt the message to me, only I will be able to read it. In order to encrypt, you need to know my Public Key. This is a digital lock which only I can open.

The website Keybase.io contains a list of people's public keys. You can visit Keybase.io/edent to see mine.

Encrypt The Message

Keybase gives you the option of encrypting a message to me. Just type what you want to send and hit the "Encrypt" button.

Hey presto! A big blob of text which can only be decrypted by me.

Send The Message

It's as simple as copying the entire block of encrypted text and pasting it into a Twitter Direct Message.

Ok! Stop! There is a minor problem here. In order for PGP encrypted messages to work, it is important that they are not altered in any way. A rogue space, or missed character, will render the message completed undecipherable.

Some Twitter clients will "helpfully" remove line breaks. A proper PGP message should look like this:

Not like this:

The Twitter website preserve newlines when you send a message - make sure that your app also does so.

A Word About Message Length

Twitter touts DMs as being "unlimited" - in reality, there's a limit of 10,000 characters. PGP is a relatively efficient way of encrypting text so, depending on your message, you can fit around 9,000 plain text characters into a 10,000 character encrypted message.

In addition, you may only send up to 1,000 Direct Messages per day.

So, no DMing Harry Potter length novels!

Decrypting

Ok, this is where it gets a bit more technical.

It should be fairly easy to decrypt a message that you have been sent - but it will depend on your Twitter client.

When copying from a browser, it is possible that newlines will not be preserved - this may cause your decryption app to think that the message is corrupted.

This is a bug with Twitter's web and mobile-web sites. I've reported it to them. I think they should be encoding \n as to facilitate copying and pasting.

I've found that copying from apps (on Android) preserves all the line breaks and keeps the formatting intact.

On Android, I use OpenKeyChain. I copy the message from my Twitter client and OpenKeyChain can decrypt directly from my phone's clipboard.

You can also use Keybase to host your private key and decrypt messages in the browser. This is at your own risk.

That's really all there is to it. I've successfully exchanged encrypted messages with several people. The only problems have occurred when trying to copy the message from the Twitter web interface - when using apps everything has been fine.

Obviously, this isn't a fully automated solution (yet!) it would be great if Keybase allowed users to send encrypted DMs directly from its site - or if apps could start offering this natively.

Colin Mahns has written an excellent tutorial for how to integrate OTR (a different encryption protocol) into messaging apps which can work with Twitter.

But, for now, if you want to encrypt a message to me, you can successfully do so using nothing other than a web-browser and a Twitter account.

Have fun!

Update! It's possible to send encrypted DMs directly from a website or the command line.

Using Twitter Web Intents it's possible to send a Direct Message. If your message starts D edent it will be converted into a DM to me.

So, if we URL Encode the message we want to send:

https://twitter.com/intent/tweet?text=D%20edent%20testing

We can pre-populate the compose window with the DM.

It looks like the message is too long - but the "Tweet" button works and it will be sent to the user:

Hopefully Twitter will one day make it slightly easier - but for now, at least it works!

Don't Use Bit.ly To Advertise Your PGP Key

@edent — Wed, 25 Mar 2015 11:45:14 +0000

I had dinner with the outgoing editor of The Guardian the other night. Clever chap, sure he'll go far in life.

The Guardian is very hot on security. Many of their writers have PGP keys which they publicly advertise. In theory, that's great (complaints about PGP notwithstanding) - but the reality shows just how tricky it is to act in a security conscious manner.

Have a look at Alan's Twitter profile.

In the bio, we see a link - http://bit.ly/1g4S9WR which points to http://static.guim.co.uk/ni/1393869928289/Public-Key.asc.

Let's take a look at a few reasons why this is sub-optimal.

Control

Who controls bit.ly? Not Alan. Not the Guardian. How easy would it be for a rogue employee to subtly redirect that URL elsewhere?

Gone are the days of Libya exercising its control on the .ly space (you did know that's what .ly stood for, right?) But that doesn't mean you should trust a third party with directing people to sensitive information!

Bit.ly isn't accessible over HTTPS. A sufficiently determined attacker can see who is accessing the page - and possibly redirect the URL to a different site.

Information Leakage

Most bit.ly links allow you to append a "+" to the URL to see a page of statistics. I've written about this several times.

Off we go to http://bit.ly/1g4S9WR+

We can see when a cluster of people have visited the URL and what country they're in. Is this leaking the identity of a journalistic source? Not directly - but it could help narrow down the target.

Homographic Disambiguation

Bit.ly allows you to create your own custom URLs. Useful for pulling pranks - and extremely useful for redirecting people.

So, if someone hacked the Twitter account and replaced http://bit.ly/1g4S9WR with http://bit.ly/Ig4S9WR - how long would it be before someone noticed? The latter example uses an upper-case i rather than the numeral 1 - and points to my PGP key.

Final Destination

But, let's assume that no-one has monkeyed with the shortlink. We end up at http://static.guim.co.uk/ni/1393869928289/Public-Key.asc.

What is "guim.co.uk"? I guess it's a server used by the GUardian to serve IMages - but it doesn't quite carry the same trust as seeing the public key on TheGuardian.com

guim also suffers from security issues. It's not served over HTTPS - which means that it's possible to see who is accessing the page and, crucially, a man-in-the-middle could alter its contents.

Putting it all together

By exploiting one or all of these weaknesses, a malicious attacker could create quite a convincing forgery.

If a random Bit.ly link took you to GUlM.CO.UK (a lower case L) and served you a PGP key for alan@guardian-email.co.uk (not the real address) - would you be convinced that it was a legitimate key for the correct user?

Fixing It

This is a pretty simple fix.

Use a direct link...
...to a trustworth site...
...served over HTTPS...
...
That's it!

Security is, sadly, too hard for most people. I wrote about how freedom fighters in South Africa were unable to maintain security due to human weaknesses - nothing much has changed in the intervening years.

I've shared these tips directly with The Guardian's security people, and they are in the process of changing to a more robust system.

I've been reading "Think Like A Freak" by the authors of Freakonomics. In it, the authors ask us to start thinking more like maverick economists. It's a fine way to increase your cognative ability and get a fresh perspective on the world.

I'd like to ask you to think like a hacker. Find every weakness in the chain and work to eliminate it.