Secret Harbour: Encrypted Multisig Transactions for Safe

Introducing Secret Harbour: the next evolution in Safe Research’s decentralized transaction queue including end-to-end encryption, ensuring that transaction details stay secret until they end up onchain.

Harbour introduced a permissionless and decentralized Safe transaction queue, allowing the collection of Safe smart account signatures for multisig operations. By default, it uses Gnosis Chain as a credibly neutral data availability layer for teams to exchange verified transaction signatures. Because Harbour is designed as a public queue, this also means that transaction details are there for everyone to see. This is not always desirable, as transaction details may contain sensitive information (such as a treasury strategy) that can lead to material losses if made public. Secret Harbour, the next evolution in our decentralized transaction queue, adds end-to-end encryption (E2EE) between the signers, ensuring that sensitive transaction details remain secret during the long (and sometimes too long) process of collecting signatures.

Sharing Secrets

As discussed in our previous post about encryption in Web3, we have access to encryption primitives that allow parties to share secret information even over public channels.

Key Generation

Harbour uses Sign-in with Ethereum (SIWE) to derive deterministic session keys used for encryption. By using a SIWE signature you ensure that:

• The key derivation mechanism is portable across Ethereum wallets, meaning that you are not locked in to a specific wallet implementation

• Session keys are deterministic, meaning that you take them with your wallet and don’t have to worry about preserving browser sessions or backups

• Wallets can implement additional domain checks in order to prevent malicious websites from phishing your session credentials

Signing in to Harbour

For example, if a malicious dapp were to try to fish your Secret Harbour session credentials, MetaMask would show the following warning:

Wallet warning of a potential phishing attempt

💡There is notable downside: Encryption keys are materialized in the Harbour web interface instead of a hardware wallet. But risks are limited: Executed transactions are already public on the blockchain, and Secret Harbour supports key rotation for future transactions.

Onchain Key Server

In order for E2EE to work, the signers need to securely exchange the generated session keys. Secret Harbour acts as a trustless key server, allowing any account to register their session encryption keys onchain. A signer’s session key registration is authenticated onchain, which is important to ensure that you are encrypting the Safe transaction to the correct recipient public encryption key, in order to prevent malicious actors man-in-the-middle (MITM) attacking secure communication between the signers.

Key registration for multiple signers

Safe Harbour supports authenticating encryption key registrations by either having the signer execute a transaction to Safe Harbour directly (in which case the msg.sender encryption key will be registered), or by signing an ERC-712 message (in which case, the encryption key registration can be permissionlessly relayed for improved user experience).

Encryption key registration authentication

This is an improvement over some more traditional mechanisms for exchanging keys, such as the Linux Kernel PGP keyring repository or Root Certificate Authorities, which are either permissioned or require proving complicated chains of trust.

Transaction Proposals

Secret Harbour uses envelope encryption in order to encrypt Safe transactions for multiple recipients, using only the public keys registered on Secret Harbour, and without requiring any additional secret key exchange beforehand:

1. A random data encryption key (DEK) is generated per transaction

2. The Safe transaction proposer requests the registered key encryption keys (KEKs) for the signers from the Secret Harbour contract

3. The DEK is used to symmetrically encrypt the transaction, and the KEKs are used to asymmetrically encrypt the DEK for each signer

4. The encrypted transaction, and encrypted DEK per signer are submitted onchain to Secret Harbour

Re resulting “encryption blob” that gets stored onchain contains a fully encrypted Safe transaction that can only read by the intended recipients. Here is an example of an actual encrypted Safe transaction on Secret Harbour that can only be decripted by one of the three listed recipients: the three owners of the Safe.

Encrypted Safe transaction with three recipients

💡Storing encrypted data onchain is considered an anti-pattern: the encrypted data will be available forever onchain, and as computers get more powerful and new algorithms are found, the encryption may eventually be broken. However, This is not a problem for Secret Harbour, as the transaction details only need to remain secret until the fully signed transaction is submitted onchain.

How to Try Out the Encrypted Queue

The encryption used by Secret Harbour is not particularly fancy or novel, which is a really good thing in cryptography! The result: a fully E2EE transaction queue, all without sacrificing the user experience. Safe multisig signers can seamlessly share their sensitive transaction details among each other with confidence, over a public, decentralized, and fault-tolerant channel. Head over to the official Harbour web interface and try out the new encrypted queue feature, and get some peace of mind that your transactions are kept secret until executed!

About Safe Research

Safe Research is the applied R&D arm of Safe, dedicated to advancing the self custody stack. Our work is grounded in the cypherpunk principles of security, censorship resistance, and privacy, and we focus on building trustless, user centric infrastructure for smart accounts and wallets.

• Discuss encrypted transaction queues in our forum

• Learn more about Safe Research

• Read our manifesto

Let’s make Ethereum’s original cypherpunk vision real, one commit at a time.