Beersy
BRC-78

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.

Ty Everettchanged 26 Mar 20242 min read
versionsender idrecipient idkey id0

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 into one portable, self-describing byte layout.
How
A sender picks a random 256-bit , builds a BRC-43 invoice number from it with 2 and "message encryption", derives child keys via BRC-42, computes an 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 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 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:

  1. The sender employs BRC-43 with 2, message encryption, and a randomly generated 256-bit 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.
  2. The sender derives their own child private key and the child public key of the recipient using BRC-42 key derivation.
  3. The sender then computes an shared secret between the two child keys which is used in symmetric encryption with AES-256-GCM.
  4. With a random initialization vector, the message is encrypted and the vector is prepended to the ciphertext.

For decryption:

  1. The recipient computes their own private key and the public key of the sender using BRC-42 key derivation.
  2. 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 of the sender, the identity key of the recipient, and the AES-256-GCM ciphertext (with the initialization vector prepended). that anyone is not permitted for encrypted data:

FieldField LengthDescription
Version4 bytesDefines the version of the standard used. Currently 0x42421033.
Sender ID33 bytesIdentity key of the sender (encryptor)
Recipient ID33 bytesIdentity key of the recipient (decryptor)
Key ID32 bytesThe specific key ID used for the signature
CiphertextVariableThe 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
Was this helpful?

Search Beersy

Search standards by number, title, author or topic