End-to-End Not-Encrypted

Let’s play a quick round of word association. I say “end-to-end.”
You say …?

If you’re a cryptographer, I bet you say “encryption.” And with good reason: end-to-end encryption is a basic best practice and fundamental building block of secure communication.

TL;DR

Let’s apply strong authentication to our communication, even when unencrypted.

The phrase, “end-to-end encryption,” emphasizes the sender encrypting a message. In practice the sender is likely to both sign and encrypt messages, to prevent both spoofing attacks and evesdropping. Should we instead say “end-to-end cryptography”? Nah. It doesn’t have the same ring to it, even if it is more literally accurate.

In end-to-end encryption, the sender Alice encrypts a message to Carol, before delivering via a third-party (we’ll call Bob). Encryption gives Alice a cryptographically strong guarantee that Bob can’t decrypt and read the message.

Lately, I’ve been thinking about benefits associated with end-to-end encryption, only (…wait for it…) without any encryption.

End-to-End Authentication

To illustrate what I mean, say Alice is sending a file without any concern for keeping the contents secret. But Alice is concerned that recipients receive the file unaltered. Perhaps Alice is not simply sending, but distributing it widely, i.e. to anyone in the world.

What Alice wants is that anyone with a copy of the file is able to authenticate it, regardless of how they received it.

Authentication is the process of verifying the truthfulness of a fact claimed true by another entity.

I like the term end-to-end authentication to describe this idea, that anyone with a copy of a file is able to verify it. It has quite a lot in common with end-to-end encryption, and some interesting differences:

End-to-End Encryption End-to-End Authentication
Origin: author author or third-party authority
Cryptography (origin): encryption (and signing) signing
Destination: specific recipient(s) arbitrary recipients
Cryptography (destination): decryption (and verifying) verifying

As with end-to-end encryption, the sender takes steps to preserve the integrity of the message before sending. And, the recipient takes steps to verify after receiving. Unlike end-to-end encryption (which implies a single sender encrypts), their may be many authorities attesting a single message. And anyone with a copy of the message can verify it (not only specific recipients).

A Use in Software Development

One application for end-to-end authentication is the need to verify the integrity of software releases.

Most software includes dependencies, meaning software written by other people. How can we trust that dependencies are reliable? Each time we include a dependency, we’re trusting the original author, and also whatever channel(s) we used to fetch that code. By the time we kick off our own build process, do we really know we can trust all the software we’re including?

I’m working on a tool, called hancock, to address this using the principles of end-to-end authentication. If you’re a developer, I hope you’ll give it try and start signing your own libraries with this tool. Please reach out if you’d like to learn more.

Read more in this blog, or see hancock source code for documentation, including how to install and use.