Let's briefly step back into history.

The Enigma machine represented the most powerful form of convenient cryptography available in the early 20th century. There were only two practical ways to crack its encryption.

1. Capture a codebook with the encryption keys printed in it⁰.
2. Literally invent the computer¹.

The basis of Enigma is conceptually simple. You want to write a character. You follow a complex sequence of instructions and get the resulting encrypted character. You want to write the next character, so you follow the same instructions for the first which then changes the sequence of instructions for the next character. And so on. Every character you type changes the algorithm for the next character. Fiendish!

You could encrypt an Enigma message by hand. But it would be tiresome, error-prone, and take ages. So a machine was invented to do the hard work. A series of cogs and wheels and wires and lights.

One of the weaknesses of Enigma is that it used symmetric encryption. The password used to scramble the message was the same as the one used to descramble it. Each day the codes changed, so they were printed in a handy codebook which was distributed to each operator. If someone captured the codebook, they could decrypt all sent and received messages.

Decades after the war, asymmetric cryptography was invented². The magic of asymmetric encryption is that it allows you to have one password to scramble the message and a totally different one to unscramble it. This completely obliterates the risk of your codebooks being discovered; you can have a "public key" for encryption. Anyone with that key can encrypt a message, but not decrypt it. You have a private key for decryption which you guard with your life.

Asymmetric encryption powers the modern world. It is made possible by high-speed computer chips which can precisely perform mind-boggling calculations in microseconds.

Let us slip into an alternate timeline. The mathematics behind asymmetric encryption are conceptually simple - even if they are exceedingly difficult to execute without a computer. If the mathematicians of the day had made the necessary intellectual breakthroughs, could public-key encryption have worked in WW2?

I'm going to work through the following problem to prove that it was just about possible³.

0. Could a public / private keypair have been calculated in the 1930s?
1. Is it possible to use paper-and-pencil to encrypt a message using a very short public key?
2. Would it have been possible to build a machine to encrypt using longer public keys?
3. What key length would have prevented the private key being cracked by brute-force?

Let's take a look at the last question first.

Why brute force?

The original machines used to crack Enigma used brute-force; trying every possible combination until they discovered the right one. That's not strictly true - a large part of cryptanalysis was understanding the statistics behind the encryption algorithm, the likely content of messages, and common phrases that they contained.

Modern encryption algorithms are resistant to most of those statistical attacks. So the only feasible method of cracking a private key is by trying each combination sequentially.

Let's suppose there's a very short private key - for example just 4 bits long. There are 2⁴ possible combinations; 16 in total. It seems reasonable to suppose that, if the message can be easily decrypted by the intended recipient, it could easily be cracked by someone able to try 16 different key combinations.

For every bit of length added to the key, the number of combinations doubles. 2⁴=16. 2⁵=32. 2⁶=64. Once you get the 2³², you're at 4 billion combinations⁴. Trying one combination per second would take over 120 years to complete.

Of course, manually using a 32 bit key might be too complex for the technology of the day. So a shorter key might be easier to use while still retaining sufficient strength. How difficult is it to manually encipher and decipher messages with short keys?

Let's go back to question 0.

Generating a Keypair

How do we generate an asymmetric keypair? Remember, no computers allowed⁵!

What is a keypair?

Briefly and incorrectly put, keys are based on prime factors.

Multiply these two prime numbers: 29 and 113.

You can easily do that on paper or on a pocket calculator. It is trivial. But suppose I asked you to reverse the equation? Find out which two prime numbers are multiplied to give the number 40,133. That's much harder. For larger numbers, it is even harder than you think.

Calculating a keypair

Mathematically, it is relatively simple. You need to know the following concepts:

• What is a prime number? (A number divisible by nothing other than itself and 1. For example, 13.)
• What is a coprime? (Another number with no common factors to the first⁶. For example, the number 13 has a coprime of 9.)
• What is a modular inverse? (When the Prime is multiplied by Coprime, then divided by the modular inverse, the remainder is 1.)

You can follow along with this Python example, but the steps are simple enough to do by hand using sufficiently small numbers.

Here's the algorithm:

• Pick two prime numbers, 𝒑 and 𝒒
• Multiply them to get 𝒏
• Calculate (𝒑-1) × (𝒒-1) to get ϕ(𝒏)
• Pick a coprime of ϕ(𝒏) to get 𝒆
  • Any coprime can be randomly selected, although there are some choices which are bad.
• Calculate 𝒅 where 𝒅 × 𝒆 = 1 (mod ϕ(𝒏))
• The private key consists of 𝒏 and 𝒅
• The public key consists of 𝒏 and 𝒆

Let's do that with two small prime numbers 17 and 61. They are sufficiently small to be calculated by hand⁷.

• 𝒏 = 17 × 61 = 1037
• ϕ(𝒏) = 16 × 60 = 960
• 𝒆 = 77 (Chosen randomly)
• 𝒅 = 773 (Calculated using the Extended Euclidean Algorithm, which was first described in 1740)

Here's how calculating 𝒅 works. This isn't intended to be a complete explanation of how the algorithm works, but it is sufficient to show that generating keypairs would have been well within the grasp of mathematicians of the 1930s. Feel free to skip to the next section.

From Step 4, we have: 1 = 15 × 960 + (−187) × 77

We are interested in the coefficient of 77, which is −187. This means −187 × 77 ≡ 1 (mod 960)

We need a positive value for d, we add ϕ(𝒏) to −187.

𝒅 = −187 + 960 = 773

Let's Encrypt!

We have a plaintext message (𝒎), we calculate the encrypted version (𝒄) with the formula 𝒄 = 𝒎^𝒆 % 𝒏

Let's suppose our message starts "HELLO". We'll give every letter a number. Our message starts with H - the eighth number of the alphabet.

8⁷⁷ % 1037 = 638

You can do that today on any pocket calculator. But could a competent mathematician calculate that by hand?

Exponentials get very large very quickly. There are some shortcuts, like Modular Exponentiation, but it is a fairly manual process. Doable, but not pleasant.

With enough time, you could manually encrypt a message like HELLO from 8 5 12 12 15 to 638 768 388 388 835.

Let's Decrypt!

We have an encrypted version (𝒄), we calculate the plaintext message (𝒎) using the formula 𝒎 = 𝒄^𝒅 % 𝒏

638⁷⁷³ % 1037 = 8

Again, piece of cake today, but an almost insurmountable a manual grind for a pencil and paper computer.

The Land of Big Numbers

In the toy example above, we turned 8 5 12 12 15 into 638 768 388 388 835. That's a very bad way of encrypting text. Working on individual letters allows for fairly trivial attacks in the form of frequency analysis. You might not know what prime numbers were used, but you know what the most common letter in English is and which letters often come in pairs.

Let's pretend that a binary code like ASCII had been invented by the 1930s, giving each letter its own number⁸. So the text translates to 1001000 1000101 1001100 1001100 1001111 7 bits is sufficient to store 128 characters, which is good enough for text, numbers, and punctuation.

Smooshing those bits together gives 10010001000101100110010011001001111, which is 19,473,311,311 in decimal.

But here we hit a snag! And rather an important one. Our message 𝒎 must be less than the key 𝒏 otherwise the maths doesn't work. So each "chunk" that is encrypted must be less than, in this case, 1037. In binary, 1037 is an 11 bit number - 10000001101 so let's chop the long binary string into groups of ten bit numbers⁹.

1001000100 0101100110 0100110010 01111 which, in decimal is 580 358 306 15.

How easy is it to calculate 580⁷⁷ % 1037?

Well, 580⁷⁷ is this 213 digit number:

608072697981095702436950488113933187346914897948969284857902654293722732546509642998889930612690327222151182305275310987597838669368524800000000000000000000000000000000000000000000000000000000000000000000000000000

Erk!

But, using Modular Exponents as mentioned above, it is just about doable to calculate it modulo 1037, to give the answer of 287.

Manual decryption

The reverse starts with 287⁷⁷³ - which is a 1,900 digit monster:

8764076814703289747574882682976372218202744117677541506077211396661935894880088329104690573410169261407987339892509470735016770231680618285939631509696980819464283401576517028048058993738338212389624747625283501942530083096110122657663164247353946331224458655354563571410933387843518380823303070498533169970946532897148031815166130665099650412982697122333628263892989475993249398481489331587762699843745762158170438822856768199827373555952739238985122598013870248178442111493156638843557234189706340583484083198539928533412908164601212156510176835050241254357263891198022046581958723118373933025616238122851775785374806117735760339884871872459839891658484324244684568308566814363900160248669794871064158507228968139134265889106231940693454825286506694141354013548608249280312471711991110620182847512187270642477617113287609180070026599666866308043914633111575444534093596344978016090107810671208184558268833063049379828413374691670084694302906835473338305746126263384285289946318656379558672414106052389234651640556324925755102419977400705380530065200979454412655589210213499344464257545650144053951331232875248144510526902329651434948453811412299881757959472385612984529276884875992403776906120156323972516615974836750108651889727547635267691073017967972912857552981641062535868781437285961802657794299581952590634427029261618023579258415033039194531248890027241354305598494848058858007937053616885726584609180601099791624229397351704959975692231801353195625613188074479028803108341519961929058549691769420863241680253570449204941176209229012471375228095132443055306202854239923235089133210534407289759826457721708012298751583195590595588629155245907825766955419953439709562536473174022072079161000252263007473231270835574140865544015688184196904473193955950050289022786886850214941882872222159427413174019940977015728353647777297220099220515546638682392602897440872932518693189627668062600415788447

There is no sensible way for a human to calculate that without mechanical or algorithmic assistance.

So our 1939 cryptographers are ready to pack up and go home, right?

Wrong! Remember, the plaintext message 𝒎 = 𝒄^𝒅 % 𝒏

For this operation, that's 287⁷⁷³ % 1037

Let's turn 𝒅 into binary - decimal 773 is 1100000101 - we can now use the "square-and-multiply" algorithm to calculate the plaintext.

Again, you don't need to read this table and can skip to the next section - this is just to show that the calculations are possible (if somewhat convoluted).

Yeeeesh! Tedious, but absolutely doable by hand. As long as you don't make mistakes and don't fall asleep.

Could this be made easier? Perhaps - but let's consider whether this effort would be worth it.

The Benefits of Symmetric Encryption

As discussed earlier, Enigma's password let you encrypt and decrypt using the same password. That means if the password leaks, you have lost the secrecy of both your outgoing and incoming messages.

The key advantage of symmetric encryption is that it is much easier to use. You set today's secret, then you can send and receive with ease. You do not need to manage two separate codes.

Let's imagine that there is a theoretical machine which can mechanically or electronically code and decode messages. You have the public key for sending messages back to base - but what about if you want to receive a message?

You will need a private key. A key which has to be protected in exactly the same way as Enigma's codebooks. If your private key is captured, all the messages previously sent to you can be decrypted.

OK, perhaps the solution is to give every machine its own unique keypair? Well, to quote the sages, now you have two problems.

First is the complexity of managing all the public keys. You have to remember which one to use when sending information.

Secondly, it means that you cannot broadcast a general message to all recipients. If HQ wants to send a message, they need to encrypt it separately for each receiver and also broadcast it separately. That also means the receivers have to know which message is intended for them¹⁰. Similarly, if a single user wants to send an encrypted message to all nearby units, they need to know who they are and separately encrypt messages to them¹¹.

Simplicity is the main factor in making usable security as I've written about before. Regardless of whether a machine could have done the calculations, key management is a tough problem.

A brief look into key exchange

Diffie-Hellman key exchange is a cryptographic technique which allows two or more parties to use an insecure channel to exchange enough information to create a unique public/private keypair for themselves. As with all the other maths talked about, it is conceptually simple - but rather difficult to do by hand.

Given the limitations of the speed of 1930s technology, it might be easier just to broadcast in plaintext "Hello! I'm station 123 and my public key is ..." That would be a simple way of distributing your keys but has two disadvantages:

• The enemy can flood you with encrypted messages. You have no way to verify that they come from a legitimate source.
• There's no way to verify who the public key is from.

I'm not going to get into cryptographic signature verification because this blog post is already too long!

Would a machine have helped?

This, alas, is approaching the limits of my ignorance. I know it is possible to build a Difference Engine out of Lego. Similarly, in the late 1930s it was possible to build a mechanical calculator which was small, lightweight, and accurate.

There were massive analogue computers on battleships, able to solve "20-plus variable calculus problems in real-time". At around 1,400Kg these weren't as portable as the typewriter sized Enigma - but do go some way to showing it might have been possible to design a mechanical computer for these equations.

So it is possible?

The mathematics behind public key cryptography are simple and, in my estimation, could easily have been understood by people nearly a century ago.

The various algorithms for simplifying the necessary calculations were neither obscure nor difficult to implement.

With smaller keys, it is possible to hand-calculate encryption and decryption

But, could it work in practice? If you had suitably trained battlefield mathematicians, it would be just about feasible to encrypt a message for transmission and decrypt something you've received. You wouldn't want to do it while under fire or for any long messages or while using large prime numbers. But, technically it is possible to hand-calculate the encryption and decryption of public key cryptography!

Let's look through the steps again.

• Generate a public / private keypair.
  • Yes! Tedious for larger primes, but well within the abilities of skilled mathematicians.
• Converting a plaintext message to binary.
  • Yes! Baudot codes were well known, as were things like Morse code.
• Splitting a binary message into smaller chunks.
  • Yes! A trivial exercise on paper, but might be difficult mechanically.
• Encrypting a chunk.
  • Possible but difficult - especially with larger keys.
• Decrypting a chunk.
  • Possible but difficult - especially with larger keys.
• Creating a machine to do the difficult work.
  • A very cautious maybe. Large battlefield mechanical-computers existed and were precise. Given the effort that went on in Bletchley Park, I don't doubt something could have been created.
  • However, given the complexity of the calculations, I don't think a portable machine would have been possible.
• Key management.
  • A nightmare, as always.

Aside from the conceptual leaps required and the lack of computational power, the major problem with successfully deploying public key cryptography in 1939 is… usability!

The usability of security systems is often hidden from us. Managing a complex key infrastructure is a problem which still plagues the security industry. Despite decades of advances, we still regularly read stories about "secure" microchips getting hacked for their keys - I imagine it would be trivial to extract them from a mechanical computer.

Could public-key cryptography have been used in 1939? Possibly, but the complexity of mechanical computation would have made it impractical.

If you happen across a time machine with access to the mid-20th century, please pop back and let me know if I am right.

Conceptually, they're relatively straightforward.

You send me a normal HTTP request. For example, you want to POST something to https://example.com/data

You send me these headers:

POST /data
Host: example.com
Date: Sat, 24 Feb 2024 14:43:48 GMT
Accept-Encoding: gzip
Digest: SHA-256=aaC57TDzM0Wq+50We2TkCsdMDvdqON92edg7KI+Hk8M=
Content-Type: application/activity+json
Signature: keyId="https://your_website.biz/publicKey",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="JGQ53kEoIiMWRp9By9jajVGCOCu4n7XBeiA1uY5xLcnAxL2Y1GIgU/...=="
Connection: Keep-Alive
Content-Length: 751

In order to verify the contents of the message, I need to do three things:

1. Check the SHA-256 hash of the message matches the content of the "Digest" header.
2. Check the timestamp is somewhat fresh.
3. Check the signature matches.

The first is simple: base64_encode( hash( "sha256", $request_body, true ) ).

The second is a matter of opinion. I might be happy to receive messages from the distant past or far in the future. For the sake of a little clock drift, let's allow 60 seconds either way.

The third gets complicated.

First, I need to get the public key published at keyId="https://your_website.biz/publicKey".

Next, I need to know which algorithm is being used to sign the headers: algorithm="rsa-sha256"

Then, I need to know which headers - and in what order - are being signed: headers="(request-target) host date digest content-type"

So I create a string using the received details which matches those headers in that specific order:

(request-target) POST /data
Host: example.com
Date: Sat, 24 Feb 2024 14:43:48 GMT
Digest: SHA-256=aaC57TDzM0Wq+50We2TkCsdMDvdqON92edg7KI+Hk8M=
Content-Type: application/activity+json

I can verify if the signature - signature="JGQ53kEoIiMWRp9By9jajVGCOCu4n7XBeiA1uY5xLcnAxL2Y1GIgU/...==" matches by:

openssl_verify(
    $headersString, 
    $signature, 
    $publicKey, 
    $algorithm
);

If that's TRUE then all is well.

But can you spot the implicit problem?

How do I get your server's public key?

I just GET https://your_website.biz/publicKey - but if your server uses something like Authorised Fetch then I have to sign my request to you.

Which means your server will need to validate my signature by obtaining my public key. Which it will get by signing a request and sending it to me. Which, before I return my public key, I will need to validate your signature by obtaining your public key. Which I will get by signing a request... and so on.

This deadlock loop is documented. The usual way around it is either for the sending server to use an instance-specific signature which can be retrieved by an unsigned request, or to allow any unsigned request to access a user's public key.

I get why things happen this way - I just wish it were easier to implement!

And... I think I've done it!

I'll warn you now, this is a deeply stupid way to solve the problem.

Here's a screencast of the demo in action:

Type the password and the page decrypts!!!!!

This abuses some interesting CSS features.

First, you can display the <style> element on the page.

<style>
   style {
      display: block;
   }
</style>

Secondly, you can make the CSS editable by the user with contenteditable

<style contenteditable="true">...</style>

As soon as a user types into the CSS, it is applied to the page. No need for JS.

So if a user types in a password...?

Let's step back a bit. How can we encrypt text using CSS? I know... WEBFONTS!

A WOFF2 webfont is a Brotli compressed file. If I've read the spec correctly (LOL!) removing a chunk of a small file should render the file too damaged to read.

It's possible to convert the WOFF2 into Base64 and use it in the CSS:

@font-face {
   font-family:'encrypt_sans';
   src:url('data:application/font-woff2;charset=utf-8;base64,d09GMg...') format('woff2');
}

Cut a chunk out of the middle of that font, and use that missing piece as the password. Foolproof!

But - I hear you say - how to encrypt text using a font? Well, that's easy!

That cleverclogs Eli Grey has a font which encrypts text. It's magical. Well, OK, it's ROT13. Obviously, any substitution cipher can probably be broken using frequency analysis.

Of course, it is possible to use font ligatures to obfuscate the text even more. See Bullshit Sans as an example

So, there you have it. A way to sort of encrypt a statically served HTML file without using JavaScript.

Demo and Source

• Demo
• Source

Possible Improvements

This was a demo hastily put together while hungover one weekend. There's lots of room for improvement.

The UI abuses CSS to hide some of the boilerplate involved. It could be made to look nicer.

There's no way to generate an "encrypted" font. Ideally someone (not me!) would take a plaintext and generate a scrambled and ligatured font to automagically do this.

It is inaccessible to screen readers. The font doesn't change the underlying text.

Brotli compressed WOFF2 files might be recoverable even after substantial damage.

This is really really stupid.

It all comes down to user needs. What pain point are you removing? Uber made taxis mildly less irritating, for example. But the UK already has a fairly mature mobile money market, so what does Signal add? Here are a few obvious questions I asked them:

• The UK already has faster payments in all major banks. I can send and receive money instantly from app or Web. Will Signal be as fast as that?
• The UK has a problem with authorised push payment fraud. Banks can recover funds which have been sent as a result of phishing / fraud. How can someone reverse a payment on Signal if it was fraudulent?
• The UK also has receiver verification. If I try to send to an account and it doesn't match the name I'm sending to, my bank will warn me. How does Signal stop impersonation?
• There's no cost to sending payments on most mainstream banks. How much does Signal charge?
• Most banks let the user block receiving payments from specific accounts. Can Signal stop harassers sending unwanted money?

Those were the questions I immediately thought of with my "product" hat on. I'm sure you can think of more.

The responses were... not well thought through. I'll respond to each one.

A: MobileCoin is as fast (or faster in some cases) than a bank payment in the UK with greater privacy. As far as settling back to Fiat, if that's what you're asking about, the velocity of that depends on on-ramp and off-ramp integrations which will come over time (but it looks like there's no reason MobileCoin can't help developers deliver payments at the same speed as banks).

I've yet to see a settled crypto transaction which is as fast as a UK bank transfer. We'll come back to "privacy" later. In terms of getting real money out of the system, the answer seems to be "variable" - which doesn't sound like a great customer experience.

Payments on MobileCoin cannot be reversed at the protocol level. If you want escrow and reversibility, you should use a wallet or payment service that supports those primitives. We believe that developers will build such services on top of the foundation of the MobileCoin protocol.

So, no. If you get scammed, tough. Neither a bank, nor a regulator, nor a court can reverse a dodgy transaction. Where's the user need for that?

Signal relies on phone numbers for identities. Other apps that integrate MobileCoin may have a higher threshold for identification.

So, again, if someone pretends to be your mate and cons you out of money, there's no independent verification. I bet users just love sending money and not knowing who it is going to.

Fees are set by the foundation (which has a stated goal of keeping transaction fees to around $.04 when the network isn't congested). Currently fees are higher as they need to be adjusted by a foundation vote.

That's pretty high! People in the UK literally use their banking apps to message each other - sending penny payments to get someone's attention. What is the user getting for this proposed transaction fee?

Signal doesn't allow people you haven't keypaired with to send you funds. If you have accepted a message request from someone, they can send you money.

If you can't block people - even after accepting them - that's a vector for harassment, or worse. Your psycho-ex can bombard you with micropayments. Your dodgy mate can offload his illegitimate gains into your account. It sounds like a nightmare.

So, I ask again, what is the use-case for this feature? It isn't faster, it costs more, it is in a volatile cryptocurrency, it has no fraud protection, and it facilitates abuse.

The one thing it has going for it is that it is "anonymous".

Except, of course, it isn't anonymous in any real sense. You need the user's phone number - which means law enforcement can track their activity. While the ledger may be anonymous, if you send a unique amount of money, and it gets received instantly, it's going to be pretty easy to work out who is at either end of the transaction.

Perhaps there is a huge untapped desire to send expensive pseudonymous payments. Perhaps people want to pay for stuff using a speculative instrument. Perhaps everything I thought I knew about people is wrong.

Or, perhaps this is another pump-and-dump cryptoscam?

I wonder who was "investing" in those coins before the big announcement? Nothing to see here...

Terence Eden is on Mastodon

@edent

Hello! This Tweet has been signed with my PGP Key. pic.x.com/ed4rcldlvw

---

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.)

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:

-----BEGIN PGP MESSAGE-----
Version: Keybase OpenPGP v2.0.43
Comment: https://keybase.io/crypto

wcFMAz8xGBvPCGIHAQ//aaPuyglRhwo0hzeVuyDC8pgIGyS7f5oyp99wMRsIh8G0
i6kuo9+dPVNJ+gGLC2B5eMuoYE0Bjv/2YfBkxaJ6HTacniUEgD9x7OxNnQY2PCyi

Not like this:

-----BEGIN PGP MESSAGE----- Version: Keybase OpenPGP v2.0.43 Comment: https://keybase.io/crypto  wcFMAz8xGBvPCGIHAQ//aaPuyglRhwo0hzeVuyDC8pgIGyS7f5oyp99wMRsIh8G0 i6kuo9+dPVNJ+gGLC2B5eMuoYE0Bjv/2YfBkxaJ6HTacniUEgD9x7OxNnQY2PCyi

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 <br/> 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!

This is a case study focusing on the usability of encryption systems as used by political dissidents in Apartheid era South Africa.

Background - South Africa

Between 1948 and 1994, the nation of South Africa was ruled by an ethnically white minority. They set in place a system of government – known as Apartheid - which suppressed, brutalised and discriminated against other races.

The African National Congress (ANC) was formed in the early 20th Century² with the explicit aim of bringing "all Africans together as one people to defend their rights and freedoms." In 1960, it was outlawed by the ruling National Party³ and was subsequently branded a terrorist organisation by many nations⁴.

Activists working for and on behalf of the ANC were placed under intense scrutiny by the National Party and its allies. In order to safeguard their communications, the ANC needed to develop, deploy and successfully use digital encryption.

The primary source of this information comes from the ANC's monthly journal "Mayibuye". In 1995 they published a series of articles on their encryption efforts, collated in a single article: "Talking To Vula"⁵

Lines of Communication

With the ANC's leadership under extreme surveillance by a technologically superior aggressor, communications between the leadership and members were subject to interception and disruption.

Poor communications had determined the shape of our struggle. It was because our fighters and cadres could not communicate with their leaders and between themselves that the underground never developed and People's War never became a reality. "Talking To Vula"

The ANC's typical method of encrypting communications in the late 1970s was by the manual use of One Time Pads (OTPs).

While OTPs represent a theoretically uncrackable encryption, they have two fundamental flaws :

• It is difficult to distribute an OTP; it wasn't until the late 1970s that key-exchange over a public channel was solved using the Diffie-Hellman Key Exchange⁶.
• OTPs often suffer from unrecoverable errors introduced by flaws common in manual transcriptions⁷.

Activists had to manually encipher messages - a tedious and error prone process - and then manually transcribe and decipher the messages they received.

The lack of digital communications required that messages be physically distributed. This increased the latency of communication to the speed of international postal services.

It was always the same pattern: comrades would go back home feeling enthusiastic and begin by sending a series of messages. They soon came to realise that it was a futile activity as it took so much effort to say so very little and the responses, as few and far between as they were, contained little encouragement and advice.

"Talking To Vula"

These activists were fighting to free their country from the yoke of a repressive and racist government. Yet they found the long-winded process of protecting their communications just too hard.

Security is usability.

Operation Vula

The growth of the Personal Computer industry in the 1980s made digital computing increasingly affordable. The ANC's technical committee began to research digital encryption and communication over the telephone network using modems. This was known as "Operation Vula"⁸.

Modern cryptographic science frowns on the sort of self-created encryption algorithms used by Operation Vula; such algorithms often contain subtle weaknesses of which their creators are unaware^{9 10}. However, developing bespoke encryption systems was a common occurrence in the 1980s – mostly due to the United States Government forbidding the export of encryption software¹¹. This meant that strong, audited encryption was not widely available to the public.

The introduction of computer-based encrypting revolutionised the revolutionaries so that with little effort it was suddenly possible to communicate over vast distances with (apparently) total security. Messages could be long and complex, and the latency of response times were reduced.

This home-made encryption flourished for several years before it came crashing down¹².

It failed not because of technological weakness - but because of human weakness.

Usability

Maintaining secrecy is hard. Attaching computers to modems and loading secret codes is still a lot easier than the mind-numbing process of hand powered encryption; but it is an extra burden.

Individuals were careless. They knew that organising against the government could result in torture or death. Despite that, it was hard to act with 100% vigilance.

The details of Vula that the regime released to the press revealed that indeed a number of important documents had fallen into their hands. It became clearer by the day that the comrades in Durban had violated all the rules of security that we had so assiduously tried to impress upon them. Data files of confidential information were kept "in clear" on disk and keywords and key books must have been easily obtainable. The minutes of an entire underground conference were quoted by police as evidence of the plot to overthrow the government.

"Talking To Vula"

These communications were not between "hacktivists" doing it for "teh lulz", lovers exchanging sexts or business people protecting their Intellectual Property. It was between freedom fighters working against a sadistic and murderous government. Failing to maintain security would not just end with their families being tortured - it could mean the disruption of an entire political movement.

And yet that threat still was not enough to keep people acting in a security-conscious manner. "Talking to Vula" concludes with the lessons the ANC learned from running their encryption programme:

Without first-class communications you cannot carry out a successful underground operation. "Talking To Vula"

"First class" does not just refer to the technology powering the system, but also the usability of the security.

Barriers

We know that commonly used encryption programs often have fundamental flaws (such as the recent POODLE¹³ and HeartBleed¹⁴ vulnerabilities), that state-based agencies have deliberately weakened encryption standards¹⁵ and that there are theoretical attacks on cryptography using quantum computing¹⁶.

Let us assume for now that via some combination of Vernam ciphers¹⁷ and Perfect Forward Secrecy¹⁸ it is possible to create an encryption scheme which, if used correctly, can withstand sustained attack from determined adversaries. The correct use of encryption relies on, at a minimum, the following behaviours :

• Users understanding why encryption is necessary.
• A provably secure way for users to generate encryption keys.
• Securely storing the encryption keys.
• Exchanging keys.
• Validating that the keys are trusted by the recipient.
• Correct enciphering of messages.
• Correct deciphering of messages.
• Validating the provenance of messages.
• Securely storing or destroying messages.
• Updating behaviours and technologies in the light of emergent threats.

If any of these behaviours are weak, the entire encryption scheme becomes vulnerable.

The Challenge

Is it possible to create a system that simultaneously satisfies the conditions of desirability (the understanding of its necessity) and usability (the inability to use incorrectly)?

Modern systems like GPG and Keybase.io have improved on the usability of older encryption systems – but they still require the user to act in an almost perfect manner.

A recent high profile case illustrates that, despite the improvement of these systems, intelligent and committed users still make basic mistakes :

David Miranda was carrying password for secret files on piece of paper

A journalist’s partner who was detained carrying thousands of British intelligence documents through Heathrow airport was also holding the password to an encrypted file written on a piece of paper, the government has disclosed.

Daily Telegraph. 2013-08-30

This careless attitude was present 23 years earlier, during Vula :

[Ghebuza's] assistant was in the habit of moving around with Ghebuza's program and "key" disks as well as his data files. This was against all the rules though we had always suspected that some of the comrades were less than meticulous about observing them.

"Talking To Vula"

Users will seemingly do almost anything to bypass security in the name of convenience^{19 20}. From writing down passwords^{21 22} to pointing a webcam at a VPN token²³, these behaviours completely negate any of the protection provided.

Users are left with, at best, a placebo security measure.

A comprehensive encryption programme has to account for the fallibility of human nature.

Ubiquity & Transparency

Usability of encryption relies on two essential factors: Ubiquity and Transparency.

Until the release of the Firesheep software²⁴ it was assumed that websites only had to protect the login portion of their services with HTTPS. Firesheep showed how every interaction with the site could leak login information to an observer.

The only way to guarantee the security of users was to ensure that every single interaction with the site was secured. Ubiquitous security became a necessity.

Similarly, it used to be common that in order to securely access a site like Facebook or Twitter, a user had to remember to enter the URL with the "https://" protocol, or they had to manually set an option to enable security.

By having the website insist on using HTTPS and enforcing it for all users at all times, they removed the need for the user to have to constantly check their security settings. This mode of operation means that encryption technology does not get in the way of the user's normal use of the site. Users do not have to undertake manual actions to enable encryption.

An excellent example of this can be found in my research into British Police websites²⁵. Several forces run online crime reporting tools, enabling victims to send in details electronically.

Despite the obvious legal and moral need to protect such sensitive information, I discovered that 18 of the forces did not provide any website security. Six of the sites had encryption available but did not force visitors to use it. This meant that users of the site would have to manually manipulate the URL to select a secure method of communication.

Conclusions

Even minor transgressions in the correct use of security can offer an adversary the opportunity to penetrate a user's defences. Users have to continually protect themselves against an unending onslaught of criminals and state-backed hostiles.

"Remember we only have to be lucky once. You will have to be lucky always."

Anonymous IRA Spokesman²⁶ referring to the 1984 Brighton hotel bombing.

In order to make encryption practical and to extend the benefits of secure communication to as many people as possible, we have to find ways of making users as "lucky" as possible.

The challenge for future security systems is to protect users from their own fallibility whilst being as unobtrusive as possible.

It was immediately banned by the British Government. Although the Internet wasn't around to facilitate its distribution, it was trivial to obtain copies imported from Australia. As a boy, I remember seeing the publicity about it on the news and being very upset that my parents had a copy!

In light of the recent revelations by Edward Snowden and Julian Assange, I would have thought that the book would be enjoying somewhat of a reassurance.

It is not.

The physical book is long out of print and is available second hand on Amazon.

There's a scanned and OCR'd copy of the eBook available on OpenLibrary. If you are to venture to the "deep web" (i.e. the 2nd page of Google results) you'll find plenty of ersatz eBook copies floating around.

So, what does a book about the security state in the 1950s, 60, and 70s have to do with the world today?

Here are some choice quotes which I found interesting.

Metadata and Warrants

Each major [post] sorting office and [telephone] exchange in the country had a Special Investigations Unit Room, under the control of [Major Albert] Denman, to place taps and intercept mail.

...

In fact, Denman was very particular about warrants. He was prepared to install a tap or intercept an address without a warrant only on the strict understanding that one was obtained as soon as possible. MI5 were, however, allowed to request a form of letter check without a warrant. We could record everything on an envelope, such as its origin and destination and the date it was sent, as long as we did not actually open it. Denman, like everyone in the Post Office who knew of the activity, was terrified in case the Post Office role in telephone and mail intercepts was discovered.

Spycatcher - page 45-46

Here we have a excellent argument about why metadata is important. Traffic analysis about which parties are communicating and can be used to build up a detailed picture of a target - even without a warrant and probable cause.

We also see that the security service has always been lax about the need to obtain warrants before intercepting communications.

Finally - I wonder if ISPs today are similarly terrified about their role in PRISM? With seemingly every major ISP, social network, and telecoms company now in the hands of the intelligence services, it seems the more things change the more they stay the same...

Listening In

I had spent a lot of time researching ways in which innocuous objects, like ashtrays or ornaments, could be modified to respond to sound waves when radiated with microwaves of a certain frequency. If a system could be perfected, it promised enormous advantages. The object itself would carry no transmitter or receiver, so detection would be virtually impossible. By 1956 we had successfully developed prototypes, and decided to attempt an operation against the Russian Embassy in London.

Spycatcher - page 67

While we sit here and worry whether our phones can be used to eavesdrop on us, or wonder if an empty crisp packet can do the same - the reality is that for over 60 years MI5 has had the ability to listen in to our conversations at will.

Storing Data

In 1959, a new discovery was made which resuscitated VENONA again. GCHQ discovered that the Swedish Signals Intelligence Service had taken and stored a considerable amount of new wartime traffic, including some GRU radio messages sent to and from London during the early years of the war. GCHQ persuaded the Swedes to relinquish their neutrality, and pass the material over for analysis.

Spycatcher - page 186

While it is natural that wartime signals should be stored, I think it's interesting that going back over ancient data with new knowledge has been a staple of spying for years. While we may think our PGP encryption is secure now - any future attacks will render its protection useless.

Of course, storing data is somewhat pointless when the sheer volume of it means it overwhelms the capacity to analyse it.

A joint MI6/CIA team had tunneled under the Russian sector of Berlin in February 1955, and placed taps on the central communications of the Soviet Military Command.

The actual electrical taps were done by Post Office personnel. Both the CIA and MI6 were reeling under the sheer volume of material being gathered from the Tunnel.

So much raw intelligence was flowing out from the East that it was literally swamping the resources available to transcribe and analyze it. MI6 had a special transcription center set up in Earl's Court, but they were still transcribing material seven years later when they discovered that George Blake had betrayed the Tunnel to the Russians from the outset.

Spycatcher - page 47

And, even if cracked and analysed - someone has to actually make use of the material!

I was shown into a room in Northumberland Avenue which contained all the Dragon material, stacked up in dozens and dozens of dusty volumes. Incredibly, neither MI5 nor MI6 had bothered to process any of this material for its own use.

Spycatcher - page 116

With Friends Like These...

The Germans are appalled to discover gambling spying taking place against them. Merkel is furious!

For nearly three years, between 1960 and 1963, MI5 and GCHQ read the French high grade cipher coming in and out of the French Embassy in London. Every move made by the French during our abortive attempt to enter the Common Market was monitored. The intelligence was avidly devoured by the Foreign Office, and verbatim copies of De Gaulle's cables were regularly passed to the Foreign Secretary in his red box.

Spycatcher - page 111

Yeah. We spied on friend and foe alike - and they spied on us.

Analysis

I made a series of analyses of Soviet strength in 1945, based on the VENONA material. Although we broke only a small fraction of the traffic, GCHQ were able to statistically assess the total number of spies active in Britain at between 150 and 300. (The statistical analysis was conducted using methodology devised by one of the top cryptographers, I.J. Good.)

Spycatcher - page 344

Again, we see that decryption isn't necessarily needed in order to analyse data. Encrypting your email isn't enough - traffic analysis can give an excellent idea of how many people you are in communication with and the volumes of material you are exchanging.

And, in the end

There's no doubt that Spycatcher is still a highly significant book. What may have seemed somewhat dry and irrelevant when first published, has now become frighteningly prophetic. It is vital that the book is republished and that all students of security - computer or otherwise - read it and learn its lessons.

For anyone with an interest in the development of the security state - and the evolution of computerised espionage, Spycatcher is a must.

Much as today, it was The Guardian newspaper who were on the forefront of helping to reveal those who seek to spy on us.

I'll leave the last words to the judgement of the Law Lords who decided whether Spycatcher should be banned.

'In a free society,' Lord Geoff said, 'there is a continuing public interest that the workings of government should be open to scrutiny and criticism.'

Lord Keith of Kinkeld said the Government's claim that anyone receiving confidential information from a Crown servant in any circumstances is bound by an obligation of confidence was 'untenable and impracticable, in addition to being unsupported by any authority'.

Lord Griffiths, chairman of the Security Commission, said: 'The balance in this case comes down firmly in favour of the public interest in freedom of speech and a free press.' But he said that a member or former member of the security services could publicly disclose his concerns only as a last resort.

Attorney General v Guardian Newspapers Ltd (No 2) [1988] UKHL 6 (13 October 1988)

You can buy used copies of Spycatcher on Amazon.

The article is a good 15,000 words and will take you some time to read. It is a fascinating account of how an ersatz encryption technology was developed by enthusiastic amateurs using acoustic couplers, DTMF, tape recorders, and early mobile phones.

I'm going to ignore the technical aspects - which are wonderful to read - and talk about the human aspect.

Security is usability.

The story starts with the problems faced by the ANC before they adopted computerised encryption. Activists had to manually encipher messages - a tedious and error prone process - and then manually transcribe and decipher the messages they received.

A huge effort for very little gain. Add the article puts it:

It was always the same pattern: comrades would go back home feeling enthusiastic and begin by sending a series of messages. They soon came to realise that it was a futile activity as it took so much effort to say so very little and the responses, as few and far between as they were, contained little encouragement and advice.

To be clear, these political activists were fighting to free their country from the yoke of a repressive and racist government. They were some of the most committed people imaginable, fighting for the most noble of causes - as were their leaders - yet they found the long winded process of protecting their communications just too hard.

The article goes on to describe how the introduction of computer based encrypting revolutionised the revolution. With very little effort, it was suddenly possible to communicate over vast distances with total security. Messages could be long and complex. Replies could take hours rather than days or weeks.

The political opposition flourished in such an environment. It also, no doubt, provided a much needed psychological boost to those involved in the struggle. Lifting the weight of fear by knowing that their seditious conversations were impenetrable to the enemy.

This home made encryption flourished for several years before it came crashing down.

It failed not because the technology was weak - but because people are weak.

Maintaining secrecy is hard. Attaching computers to modems and loading secret disks is still a lot easier than the mind numbing process of hand powered encryption - but it is an extra burden.

Individuals were careless. Despite knowing that the government was violently racist and that organising against it could result in your torture or death, it is hard to be 100% vigilant.

The details of Vula that the regime released to the press revealed that indeed a number of important documents had fallen into their hands. It became clearer by the day that the comrades in Durban had violated all the rules of security that we had so assiduously tried to impress upon them. Data files of confidential information were kept `in clear` on disk and keywords and key books must have been easily obtainable. The minutes of an entire underground conference were quoted by police as evidence of the plot to overthrow the government.

Remember, these communications weren't between file-sharers doing it for "teh lulz" or business people protecting their IP. It was between freedom fighters working against a sadistic and murderous government. Failing to maintain security wouldn't just end with your family being tortured - it could mean the disruption of an entire political movement. That's pretty serious motivation.

And yet that threat still wasn't enough to keep people acting in a security conscious manner.

The piece concludes with the lessons the ANC learned from running their encryption programme:

Without first-class communications you cannot carry out a successful underground operation.

First class doesn't just mean usability of the system - but also the usability of the security. We can create "perfect" encryption (NSA backdoors not withstanding) - but can we make a system easy enough the people want to use it correctly and don't want to abuse it by, say, writing down passwords?

I've tried setting up PGP more times than I care to remember. Each time the process has been a frightening and confusing mess. Using it has required using plugins, remembering arcane commands, and trusting that I've not somehow screwed up.

Just like a hotel room safe that's too complicated to easily understand, the current usability of encryption software encourages us to hide our valuables in the sock drawer and hope the housekeeping staff don't go snooping.

The tour guides of Bletchley Park are full of fascinating stories. They can tell you how all the primitive computers work, about the history of each building, they know all the curious little facts which make visiting the park an absolute joy.

There's one story in particular that I never tire of hearing.

By 1945, Turing's computers were able to decrypt Enigma transmission within 48 hours - it was thoroughly broken. After the war, the British had captured thousands of working Enigma machines. What on Earth could they do with them? The answer was simple. Sell them to our Allies as "The Uncrackable Enigma!"

And, indeed, they did. The British Government sold cryptographic devices to their allies even though the British knew that the cryptography was fatally compromised.

I presume that for the next few years, the British Government were able to spy on the world. Listening in on all the high level discussions they could.

In 2007, the security expert Bruce Schneier asked "Did NSA Put a Secret Backdoor in New Encryption Standard?"

Cryptography experts were worried that the American National Security Agency were promoting a new encryption standard which was potentially crackable by the US Government.

The US Government had taken a leaf out of the UK's book, so it seemed, and had encouraged the world to use insecure cryptography.

This has been going on for decades.

"[Blog posts are] a tale told by an idiot, full of sound and fury, signifying nothing."

Today Ofcom published the responses it had for its consultation on plans for the BBC to encrypt its HD broadcasts.

The blogosphere went nuts! DRM? Not on our watch.  Boing Boing mobilised its army of commentators, the BBC published two blog posts which quickly filled up with comments, Facebook statuses were updated and all these links were retweeted until our fingers were worn to their nubs.

No doubt Ofcom has collapsed under the weight of public opinion. How can the BBC possibly hope to get away with their fiendish plans with such a backlash?

90 People

Ninety.  Less than one hundred.  Smaller than the viewing figures for BBC Three.  That's how many people could be arsed to type a few dozen words to Ofcom, spell check them, then hit send.

More people signed a petition asking for a Yorkshire sign to be erected on the M1 than responded to this consultation.  Now, maybe my finger is off the pulse, but I haven't seen major blogs crying foul over Yorkshire's lack of signage.

On The Plus Side

You can read my response on their site.  Like all the others I've read, it's against the proposals.  I haven't read every response, but the twenty or so that I downloaded were all against the plans.

I know that there's typically low turn out to consultations of this kind.  Organisations know that for every person who bothered to complain, there's more waiting in the wings quietly seething.

But only 90 people?  I realise that the power of retweeting helped free Iran from a stolen election, but sometimes you actually have to do something.  You don't even need to get off your computer.  Find an email address, write a few sentences and let those in charge know how you feel.

This will help get you started.

• List of government consultation websites
• Public Consultations in your area
• Ofcom Consultations