Data Encryption and Decryption
Ty Everett (ty@projectbabbage.com)
Abstract
We devise a method for applications to request the encryption and decryption of data. Specifically, we define a mechanism for data encryption within the BRC-42 key derivation system, utilizing the BRC-43 protocol and key ID scheme. During encryption, the sender derives their own child private key and the child public key of the recipient using the BRC-42 process, then computes an ECDH shared secret between the child keys which is used in symmetric encryption with AES-256-GCM. The initialization vector, together with the ciphertext, are sent to the recipient. During decryption, the recipient computes their own private key and the public key of the sender, and uses ECDH to compute the same shared secret. The key is then used together with the provided initialization vector to decrypt the ciphertext. When no counterparty exists, we stipulate substitution for the sender's own public key in the child key derivation process.
Motivation
The Bitcoin ecosystem has demonstrated a clear desire for wallets to support data encryption between parties1. This capability facilitates secure exchange of information, improves user privacy, and enables novel applications that require direct and secure communication between users. The unique economic incentives of micropayment-based applications, particularly those facilitated by Bitcoin wallets, make user privacy paramount, and have led to the adoption of end-to-end encryption by many applications2. While several encryption systems have been developed and integrated into various platforms, there is currently no standard methodology that supports both single-party and multi-party encryption, protocol-level permissions management, and leverages BRC-42 key derivation. The BRC-2 standard aims to fill this gap and provide a secure and standardized framework for encryption and decryption within the Bitcoin ecosystem.
Specification
We start with the same constructs defined in BRC-43: users with clients, protocols and applications. We stipulate the use of BRC-43 invoice numbers in the context of BRC-42 key derivation, and we build on top of the permissions architecture defined by BRC-43.
When an application sends a message to a client requesting that data be encrypted, the message comprises:
The data to encrypt
We stipulate the following process for encryption:
The message sender begins by computing the BRC-43 invoice number based on the security level, protocol ID, and key ID
The message sender uses BRC-42 key derivation with the computed invoice number to derive a child public key for the recipient
The message sender uses BRC-42 key derivation with the computed invoice number to derive their own child private key
The message sender computes the ECDH shared secret between the two derived child keys
The resulting elliptic curve point's X and Y values are hashed with SHA256 to create an AES-256-GCM symmetric encryption key
The resulting 256-bit value is used in conjunction with a randomly-generated 256-bit initialization vector to encrypt the message with AES-256-GCM
The initialization vector is prepended to the ciphertext, and the combined value is returned by the client to the application over the abstract BRC-1 communications substrate.
We stipulate the following process for message decryption:
The recipient somehow comes to know the ciphertext (prepended with the initialization vector), the counterparty, the security level, protocol ID, and key ID. The mechanism for conveying this information to the recipient is beyond the scope of this specification.
The recipient begins by computing the BRC-43 invoice number based on the security level, protocol ID, and key ID
The recipient uses BRC-42 key derivation with the computed invoice number, their own private key and the public key of the sender, to compute the sender's child public key
The recipient uses the same process to compute his own child private key
The recipient computes a shared secret between the two child keys, using the hash of the X and Y values as an AES-256-GCM symmetric key
The recipient then uses the symmetric key to decrypt the ciphertext with the provided initialization vector
We build upon the abstract messaging layer first described in BRC-1. Specifically, we define five new BRC-1 messages to facilitate requests and responses for encryption and decryption, and error handling. For each of the messages, we stipulate that there exists some out-of-band mechanism for the parties to communicate which of the messages are being exchanged, removing the need for a message type field. Finally, specifically for the request messages, we stipulate that the message comprises a header and a payload, with the payload containing the data (ciphertext or plaintext), and the header containing the other information. For the response messages, no message header is defined and the payload simply contains the specified data.
Encryption Request
The encryption request is a message sent by the BRC-43 application to the client. It contains a header with the following information:
| Field | Description |
|---|---|
| The BRC-43 security level and protocol ID represented as an array. For example, |
| The BRC-43 key ID |
| The BRC-43 counterparty, or |
The message payload comprises the data to encrypt.
Encryption Response
The response message comprises a payload containing the encrypted ciphertext, prepended with the 32-byte initialization vector.
Decryption Request
The decryption request is a message sent by the application to the client. It contains a header with the following information:
| Field | Description |
|---|---|
| The BRC-43 security level and protocol ID represented as an array. For example, |
| The BRC-43 key ID |
| The BRC-43 counterparty, or |
The message payload comprises the data to decrypt, prepended with the 32-byte initialization vector.
Decryption Response
The response message comprises a payload containing the decrypted plaintext.
Cryptography Error
If the client is unable to fulfill the encryption or decryption requests for any reason, we specify that it should respond with a JSON-formatted Cryptography Error. The fields for the object are specified as follows:
| Field | Description |
|---|---|
| This should always be a string comprising |
| A machine-readable error code. Extensions to this standard can define specific error codes and standardize additional fields. Codes are strings, for example |
| All errors must have a human-readable |
One example of a Cryptography Error is given below:
Test Vectors
For compatibility with this encryption scheme, we stipulate the following:
A user who has the following identity private key...
...which implies the followign identity public key for that user...
...should be able to use security level 0, the BRC2 Test protocolID with keyID 42 and the following counterparty...
...to decrypt the message with the following base64 ciphertext (with prepended initialization vector)...
... and receive the following plaintext:
Implementations
This encryption capability is incorporated into the Babbage SDK
References
2: BaeMail
Last updated