Five pictures instead of a fingerprint: short authentication strings in practice

A short authentication string (SAS) is a small value, shown as words, numbers, emoji or pictures, that both devices derive from their key exchange; if the people holding the devices see the same thing, nobody sits in the middle of the connection. It replaces comparing long fingerprints, which almost nobody does carefully, with a check people will actually do.

This post explains what a SAS protects against, why pictures, and how Havenfold's joining ceremony uses five of them. It also says plainly what the check doesn't protect against. Havenfold is pre-alpha and has had no independent security audit; do not use it for real data.

The problem: who is on the other end?

When two devices set up an encrypted connection over a network, each needs to know it's talking to the other device and not to someone who has placed themselves in between. A classic answer is to compare key fingerprints: long strings of hexadecimal characters. In practice, people skim them or skip them.

A SAS turns that into a short, human-friendly check. Both devices derive the same short value from the key exchange. If an attacker were in the middle, each side would have a different exchange and, with overwhelming likelihood, a different value. The people compare the values; if they match, they confirm; if not, they stop.

This idea is not new. The ZRTP protocol for encrypted voice calls, published as IETF RFC 6189, has callers read a short authentication string to each other over the call. Messaging apps such as Matrix clients offer verification by comparing a set of emoji.

Why pictures?

Pictures are quick to compare side by side, don't depend on reading a language, and are easy to say out loud ("pepper, bicycle, cheese…"). For a family, where a grandparent and a child might be the ones comparing, that matters more than for an engineer.

How Havenfold's joining ceremony uses them

Havenfold's ceremony for joining a family is specified in RFC-0028 §5 (in Turkish). In outline:

• A QR code starts it. The family's phone shows a QR code containing a one-time invitation secret and a temporary key for meeting on the network. The phone accepts only a connection made with a key derived from that secret, so someone who hasn't seen the QR code can't connect. The QR code refreshes on screen with a countdown.
• Both phones derive a ceremony key. It comes from the two temporary keys, the invitation secret and a transcript that covers the handshake and both devices' certificates.
• Five pictures from the ceremony key. The pictures are derived from that ceremony key, from a fixed set of pictures. Because the key is bound to the handshake and both certificates, someone who saw the QR code and tried to sit in the middle can't make the pictures match on both sides.
• "Different" ends it. If either person says the pictures differ, the session closes.
• Nothing is shared before both confirm. The family's signed membership record is sent to the newcomer only after both sides confirm the pictures; the newcomer doesn't see it before.
• People sign. After the pictures match, the inviting parent's signed addition and the newcomer's signature go into the family's ledger.

The project's demo shows this with real output on a local test network: "Maya opened Alex's QR code; both phones showed the same 5 pictures: Pepper, Bicycle, Cheese, Bird, Crown". The pictures change from run to run.

Joining from far away

Sometimes a family member can't be in the same room. RFC-0028 allows a remote ceremony as an exception with extra locks: the invitation link is treated as sent over an untrusted channel, and the protection is that the five pictures are compared on a voice or video call. The remote code can't be refreshed and expires quickly, the new member's activation waits for a set period, and during that wait the family's parents are notified and any of them can cancel.

What the pictures don't protect against

• A trusted person in the room. The check proves the two phones talk to each other directly. It doesn't decide whether the person holding the other phone should be in the family. That's a human decision, which is why a parent's signature is required.
• Confirming without looking. If someone taps "same" without comparing, the check does nothing. The design can make comparing easy; it can't make people do it.
• A compromised phone. If one of the phones is already controlled by an attacker, what it displays can't be trusted.
• No audit yet. The ceremony is specified and tested, but nobody outside the project has audited it. Review is welcome.

Summary

• A short authentication string lets people confirm, at a glance, that two devices share the same key exchange and nobody is in the middle.
• It's an established idea: ZRTP (RFC 6189) uses it for calls, and messaging apps use emoji versions.
• Havenfold's ceremony shows five pictures derived from a key bound to the handshake and both certificates; "different" closes the session, and nothing is shared before both sides confirm.
• Remote joining is an exception with extra locks: pictures compared on a call, a waiting period, and parents able to cancel.
• The pictures don't protect against a trusted person, careless confirmation or a compromised phone; Havenfold is pre-alpha and unaudited.