Serialization Format for Portable Encrypted Messages
An encrypted message is only portable if the recipient can work out how to decrypt it from the message itself. This defines a self-describing container so an encrypted message can be stored or forwarded and still be opened later.
Summary
- Why
- Two parties who want to exchange encrypted messages need a way to derive matching keys and format the result without first agreeing on a shared protocol identifier.
- What
- BRC-78 is a serialization format for encrypted peer-to-peer messages that combines BRC-42 key derivation and BRC-43 invoice numbers into one portable, self-describing byte layout.
- How
- A sender picks a random 256-bit key ID, builds a BRC-43 invoice number from it with security level 2 and protocol ID "message encryption", derives child keys via BRC-42, computes an ECDH shared secret, encrypts with AES-256-GCM (IV prepended), and serializes version, sender ID, recipient ID, key ID and ciphertext into
What this lets you do
- Encrypt a message for a specific recipient's identity key without agreeing on a shared protocol first
- Derive one-time encryption keys per message using a random key ID
- Decrypt a received message by deriving the matching private key from the sender's public key
- Package sender ID, recipient ID, key ID and ciphertext into one portable byte format
- Send encrypted messages peer-to-peer without a pre-shared protocol identifier
Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.
Reference for an AI
Everything an assistant needs to answer questions about BRC-78 accurately, including what it depends on.
The specification
Abstract
This document describes a protocol for a portable message encryption and description scheme. It follows the BRC-42 key derivation and BRC-43 invoice number standards to protect the confidentiality of message content, without requiring the added complexity of agreeing on a specific BRC-43 protocol for the parties to use.
Motivation
Message encryption is a fundamental requirement as it ensures the privacy and confidentiality of the content transmitted between parties. The current standards like Electrum ECIES don't provide a comprehensive solution for message encryption by integrating with BRC-42 and BRC-43. This document aims to enhance security by developing a protocol for message encryption and decryption, utilising the BRC-43 invoice numbers. The protocol facilitaes a way to exchange encrypted data in a general way.
Specification
The protocol employs the BRC-2 encryption process and makes use of the BRC-42 key derivation and BRC-43 invoice numbering scheme.
The encryption procedure follows these steps:
- The sender employs BRC-43 with security level
2, protocol IDmessage encryption, and a randomly generated 256-bit key ID to compute the invoice number to facilitate BRC-42 key derivation. We specify the key ID is in base64 format when added to the invoice number. - The sender derives their own child private key and the child public key of the recipient using BRC-42 key derivation.
- The sender then computes an ECDH shared secret between the two child keys which is used in symmetric encryption with AES-256-GCM.
- With a random initialization vector, the message is encrypted and the vector is prepended to the ciphertext.
For decryption:
- The recipient computes their own private key and the public key of the sender using BRC-42 key derivation.
- The recipient computes the same Shared Secret and uses it along with the received initialization vector to decrypt the ciphertext.
Serialization format
The serialized data for transmission includes a version number, the identity key of the sender, the identity key of the recipient, and the AES-256-GCM ciphertext (with the initialization vector prepended). Note that anyone is not permitted for encrypted data:
| Field | Field Length | Description |
|---|---|---|
| Version | 4 bytes | Defines the version of the standard used. Currently 0x42421033. |
| Sender ID | 33 bytes | Identity key of the sender (encryptor) |
| Recipient ID | 33 bytes | Identity key of the recipient (decryptor) |
| Key ID | 32 bytes | The specific key ID used for the signature |
| Ciphertext | Variable | The encrypted message data (AES-256-GCM with IV prepended) |
This standard serialization format contributes towards a standardized way of securely transmitting and decrypting encrypted messages.
Hex Examples
10334242 # version
032e5bd6b837cfb30208bbb1d571db9ddf2fb1a7b59fb4ed2a31af632699f770a1 # Sender
02e5e1a150745253aff65cdbcef722873110d89c396223e3d8715f018e72f7d4f8 # Recipient
46a897fa6c3b4e1269284f28fb46827dc3a6a88d424f7570aca296e587612c52 # key ID
7511245c12f83e8e5ad5bd2e536ce33e06cdb76bfb80022830e0976db7866a6607cede3f9b5c95011a0cb04b0816c9c3586f106be31effc73dd8e24d1eca818bc3cdf0f9d330e2696786d375ea8c8bc38ac7f67eb2436eb4daf5c7739047d9d341cdd8eaa10d7f577122726b2ab08ffa8ca88fb2ad2c69f04edcf877a1712c2999f8a85cf94e5ae94a13862d00ec4ffd71782b7ab8b98f8844d0e011cf3843dbb3f763087e3d94693d24d57a9d389aa466bd3779adbe862ba146bbec8ac59991d56a5f2fe282720b42ce058838f0fd577d39a2e2309b4ac765f3cd64b38ed8296bd044641b814000a840fa8c0577d89ff74578c75b4b7883180bf3f994fba623 # ciphertext