Public key encryption is great in principle for keeping communications and secrets secure. Real world implementations of the technology, on the other hand, can be a little challenging.
It works well for single channel communications—when two parties need to communicate securely. They exchange public keys, and encrypt messages with the other person's public key. The recipient with the corresponding private key—and only this key—can decrypt the messages intended for them.
Real world scenarios, however, are rarely straightforward. Imagine the following scenarios:
The first scenario is straightforward—each recipient receives a different copy of the email encrypted with their public keys. Dig a little deeper and we start to uncover some practical challenges.
Large number of recipients, long emails and large attachments are computationally intensive. With copies and blind copies, each recipient in a secure mailing list receives an encrypted copy of every email. Complications and overheads add up rather quickly when you need to rely on public key encryption for multi-party communications via email.
Encrypted data is larger and takes up more space than unencrypted data. More processing power is required to encrypt (and decrypt) larger files with public key encryption. Repeating this for every recipient exponentially increases the storage, bandwidth and time required to send a single e-mail. The costs quickly adds up over the thousands of e-mails that we send, receive and read everyday.
The analogy I used previously for public key encryption was that of the padlock (public key) and key (private key). Encrypting every message and attachment with each recipient's public key for all recipients is like sending the same message to every recipient in a locked box, and each box is secured by a padlock and key unique to each recipient. This is cumbersome.
Secure e-mail communications in practice
In practice, we can simplify things somewhat.
Here's how—we encrypt each message only once for all recipients with a randomly generated symmetric key. We encrypt the symmetric key with each recipient's public key. The secure email is sent once to all recipients, with the encrypted message and a list of encrypted symmetric keys in the email. No changes are needed to email protocols. Message and list of recipients can be as long as they need to be without an exponential burden on compute, storage or time.
Instead of one strongbox (encrypted message) for each recipient, we only have one, secured by a chain (symmetric key) linked by everyone's padlocks (public keys). Instead of reinventing email, we adapt existing applications with plugins to support public key encryption. The public key encrypt secrets rather than the messages themselves. This is secret sharing. This is how most tools like PGP (Pretty Good Privacy) and Open PGP work.
Crypto joint accounts in practice
Every wallet is secured by a private key. Anyone with this private key can perform any transaction to this wallet. Hence the title of this article—there are no joint accounts for crypto wallets. Not a big deal until we start looking at issues such as trust and accountability—especially where large amounts of cryptocurrencies are involved.
Let's say I wanted to entrust the seed-phrase to a cryptocurrency wallet to a group of people, but I didn't want any single person to have access to this seed-phrase without first consulting the others.
Recommended by LinkedIn
There are twelve (or twenty-four) words in a typical seed-phrase. We can divide the seed-phrases equally amongst the people in the group.
Secret sharing allows us to create flexible and effective ways to limit and control access to secrets such as seed-phrases or private keys. In the above example, only 3 out of 4 shares are required to reveal the full seed-phrase. No single individual has knowledge of the full seed-phrase—until it is reconstructed.
With email, each message is encrypted with a different secret. On blockchains, every wallet's transaction is secured by the same private key. Once the seed-phrase has been reconstructed, secret sharing for a wallet's seed-phrase loses its purpose unless all participants are completely trustworthy.
Multisig and MPC wallets
Multisig (muliti-signature) and MPC (multi-party computation) wallets exist to provide features that resemble joint accounts and address some of these limitations.
Blockchains supporting multisig require transactions to be signed by a minimum (or fixed) number of authorised parties (each signing using their own private keys) before they can be confirmed. Multisig however, is not native to all blockchains. There is usually more transaction and gas fees to be paid because these transactions tend to take up more space and computation to complete.
MPC wallets are, on the other hand, are applications and not blockchain specific. They typically support a wide range of blockchains and cryptocurrencies. They still rely on secret sharing on some level, but unlike typical secret sharing, participants in an MPC wallet generally have no knowledge of their shares or the secrets (private keys) after they have been reconstructed. It requires trust in the developer that no one else does or can access these secrets either.
It all depends on use cases and degrees of risk
Each solution to the multi-part crypto problem presents its own unique advantages, disadvantages and complexities.
Secret sharing is great for keeping your cryptocurrencies (relatively) safe from $5 wrench attacks (more about this here: https://www.linkedin.com/pulse/keeping-private-keys-safe-raffi-ismail-8amfc/) or simple legacy planning.
MPC wallets are built around the concept of keeping reconstructed secrets (and even shares of secrets) obscured from everyone, while multisig takes the need to share secrets out of the equation.
There is no one-size fits all solution with cryptography, cryptocurrencies and security. It is only a matter of putting the right solutions together to reduce the likelihood of compromise with some measure of accountability and requiring minimum trust.
