At EthSign, data privacy is one of our top priorities. Not only does selling user data have nothing to do with our business model, one of the major tenets of Web 3 is for users to have control over how their data is used and anything contrary is a betrayal of the entire space. In this article, let’s take a closer technical look at how EthSign honors those principles and handles user secrets.

Zero-Knowledge Encryption

ZK is one of the hottest topics in blockchain but it is important to note that when people mention ZK, they are usually referring to zero-knowledge proofs. We don’t currently utilize zero-knowledge proofs in our products but we do extensively utilize something of similar principle — zero-knowledge encryption.

Zero-knowledge encryption refers to the practice that prevents anyone aside from the sender and intended recipients from decrypting encrypted data, not even the service provider middleman. This is also known as end-to-end encryption (E2EE), which is a standard practice across major communication platforms such as Google Messages RCS, Signal, and Proton Mail. They all have different implementations of the same concept with varying degrees of transparency and user-friendliness. We wanted to maximize both while embracing the Web 3 ecosystem, therefore we came up with our own solution.

EthSign Keychain

Our newly launched EthSign Keychain is a MetaMask Snap that serves as a general-purpose password manager for all supported browsers, much like 1Password, LastPass, and BitWarden. Keychain gives users the option to synchronize their password records via our hosted service on AWS, the decentralized Arweave network, or offline manually through an exported JSON file. Going with either of the first two options means sensitive user data inevitably persists temporarily on our servers or permanently within the public domain for everyone to see, both of which require a reliable encryption solution.

EthSign Keychain utilizes symmetrical end-to-end encryption to safeguard user secrets. First, Keychain requests a deterministic entropy value derived from your secret recovery phrase via MetaMask. The entropy is salted to be Snap-specific and no other Snap can obtain the same entropy. Then, the user can optionally add a second layer of security by setting a password that further modifies the entropy value. We use the resulting entropy value as the symmetric AES-256-GCM encryption key to encrypt all username and password records.

Once encrypted, those records are bulletproof and safe to be uploaded anywhere. You can be rest assured that unless someone breaks AES-256 encryption or compromises your secret recovery phrase, it is impossible for anyone other than you to decrypt those records.

EthSign Password Manager

One of the biggest roadblocks to adoption facing the entire Web 3 industry is the lack of user-friendliness. The onboarding process is tedious with mutiple downloads and requires some level of understanding of cryptography. To be fair, this is the direct result of building a system entirely on cryptography and mathematics. It’s incredibly secure but near impossible for your average grandma to use.

Since we never want to see any user data in plaintext, we strongly recommend our users encrypt their data when using EthSign. Because we want this done in a decentralized and non-custodial fashion, we mandate users generate their own passwords. This presents a problem because we humans suck at memorizing things yet due to the multi-chain nature of EthSign, we cannot exclusively use Keychain to store passwords as it is only available as a MetaMask plugin and does not support other wallets yet. In this particular use case, we also wanted password-sharing capabilities so PDF contract recipients don’t need to know the password at all to decrypt and sign. To address all of the above, we developed EthSign Password Manager, a feature exclusive to the EthSign web app.

EthSign Password Manager uses asymmetric end-to-end encryption to achieve secure password storage and sharing. To give credit where credit is due, we took a lot of inspiration from Web3MQ and XMTP so you will notice the workflow is similar. Random bytes are first locally generated as the decryption private key. A random message is then locally generated and signed by the user. The digital signature is then hashed to 256 bits and used as the ECIES private key*. A public encryption key is then derived, signed, and sent to EthSign to enable password sharing capabilities. The random message is also sent to EthSign so users can regenerate their ECIES private key when they switch devices. Possession of the random message alone does not compromise the security of this system and EthSign keeps a copy of this random message to prevent users from losing access to their encrypted data forever.

*For incompatible wallets, a master password is used in place of a digital signature.

When sensitive data needs to be shared, it is encrypted to the recipient’s public encryption key which is stored with EthSign. When encrypted data needs to be decrypted, the user retrieves the random message from EthSign, signs it, and derives the private key locally to decrypt. Just like the encryption system used in Keychain, it is impossible for anyone other than you to decrypt data intended for you.

A Cryptographic Awakening

The slow but steady adoption of blockchain technology has started a subtle paradigm shift in the way we think about our data and identity. Building applications on blockchain-oriented systems means we must process data in a way so that secrets are not compromised when stored in public or available for anyone other than the intended recipient. The cryptographic-centric approach has quietly rippled into the Web 2 world in the form of Passkeys, which is a custodial wallet controlled by your service provider (Apple, Google, etc.) that replaces usernames and password pairs as your identity.

However, there is still a major difference between utilizing cryptography and being truly Web 3. What makes this even trickier is the constant need to optimize UX in a system based on something fundamentally user-unfriendly. It is a fine line between decentralization, security, and convenience, and EthSign will continue to walk this line with great care.