Is LocalCryptos Decentralized?
10 mins
One of the major differences between LocalCryptos and other peer-to-peer trading platforms is that LocalCryptos is secured by decentralized technology.
LocalCryptos is decentralized in the way that matters most — we don't see your private keys, we don't have access to your coins, we can't read your messages without consent, and we don't have the power to withdraw from escrow accounts. Additionally, all trades are peer-to-peer and transfers are made off-platform using external payment services, which means LocalCryptos isn't trusted with either crypto or dollars.
But like everything you interact with online, LocalCryptos is not a completely decentralized system. It's made up of a mixture of centralized and decentralized components to strike a balance between strong security and usability. The platform is centralized in the same way that end‐to‐end encrypted applications such as Signal, Telegram, Wickr, Viber and WhatsApp each rely on centralized servers to deliver code, transport and store encrypted payloads, and perform housekeeping tasks that would be infeasible or unnecessary to execute in a self-custodial or end-to-encrypted manner.
Unlike most websites on the internet, many important operations are performed inside your browser rather than by our servers. Nevertheless, we do have servers that are responsible for certain tasks — however we try to keep their role as limited as feasibly possible with available technology.
We made the choice to avoid a fully decentralized system to be able to adhere to our important design constraints. That means, primarily, making the product available to everyone, regardless of their knowledge and experience with cryptography and cryptocurrency.
As a quick summary, the following components of LocalCryptos can be summed up as either decentralized or centralized:
- Wallets: Decentralized — The private keys to your wallet are generated by your device and can never be seen by our servers. Your LocalCryptos web wallet is a self-custodial wallet.
- Escrow: Decentralized — P2P transactions are secured using a non-custodial escrow service that is powered by blockchain technology. LocalCryptos doesn't have the power to withdraw from an escrow account.
- User messages: End-to-end encrypted — Messages between users are end-to-end encrypted. LocalCryptos can't read your message history without permission.
- Payments: Off-platform — In peer-to-peer transactions, payments are made using external financial services outside the marketplace's environment.
- Reputation: Centralized — Users' reputation, such as feedback scores and volume, is maintained in a centralized database operated by LocalCryptos.
- Offers: Centralized — Public offers are posted by users to a directory maintained by LocalCryptos, and our servers make searching and sorting fast and easy.
- Trade metadata: Centralized — Although trade messages and transfers involve cryptography and self-custodial wallets, various metadata properties are not encrypted. For example, amounts, currency codes, and public addresses, are stored in a centralized database.
- Notifications: Centralized — Email notifications, SMS messages, and so on, are delivered to you by servers maintained by LocalCryptos. In order for this to work, we need to store some personal information just as any other website would. You can read how we use and handle your information in our Privacy Policy.
Cryptography inside your browser
LocalCryptos is built using the relatively modern Web Cryptography API , which has made it possible to perform cryptographic operations, such as encryption and decryption, from within a web application. As of 2022, Web Cryptography is supported by the latest version of all major desktop and mobile web browsers.
LocalCryptos is among only a few well-known web applications that has taken full advantage of the new Web Cryptography API to build a new category of website backed by cryptography. Other examples include WhatsApp Web, the end-to-end encrypted messaging service, and Skiff, an encrypted collaborative document editor.
Cryptography is used by the LocalCryptos web app in various ways to secure information, and to enable end‐to‐end encrypted messaging. Our goal has always been to allow users to retain complete control over the most important aspects of their account, while only revealing a minimal metadata to LocalCryptos servers.
Each of the techniques used by LocalCryptos were inspired by renowned systems such as the Off‐the‐Record Messaging protocol, Open Whisper System's Signal Protocol, and Blockchain.info's encrypted web wallet. These systems are already in widespread use and have been reviewed by prominent cryptographers and developers.
How account passwords work
You can log in to your account with a username and password. However, while the log‐in process might look and feel like an ordinary website's, it actually involves complex cryptography under the hood. The password you have is actually a cryptographic passphrase, and it never leaves your device.
The password selected by you when you first created an account was transformed into a cryptographic key using a key-stretching process known as PBKDF2. Then, your "master key" — which essentially unlocks your account — was encrypted using that newly stretched passphrase.
When you log in, your passphrase goes through the same key-stretching process as it did when you signed up, and then it's used to attempt to decrypt your "master key". It's the ownership of the master key that allows you to decrypt other keys, such as the private keys to your wallet or the keys that are used to encrypt messages with other users.
The reason why everything important is encrypted with this "master key", rather than encrypting everything with your passphrase directly, is so that it's possible to later change your password. Changing your password simply involves re-encrypting the master key with a new passphrase (rather than the alternative which would be to re-encrypt everything).
In more detail
Creating an account
When a user creates a LocalCryptos account, a cryptographic key is generated on the device of the user, known as a "master key". This "master key" is later used to derive other keys — such as a key for encrypting other private keys used to store cryptocurrency, or a key for signing information.
When creating an account, the first step is to generate a securely random 32-byte "master key" (AccountKeyMaster) using the Web Cryptography API.
Once the AccountKeyMaster is created, two more keys can be derived from it:
AccountKeyIdentityPrivate is the function of SHA256(AccountKeyMaster, "identity"). This will be used for digitally signing messages using elliptic curve cryptography.AccountKeyEnc is the function of SHA256(AccountKeyMaster, "enc"). This key will be used to encrypt other keys using AES symmetric encryption.
The AccountKeyMaster key must be encrypted using the user-inputted password. However, the password alone will not suffice: it must be first transformed into a secure key suitable for encryption using the key derivation function PBKDF2. This process, known as "key stretching", adds complex computational work to make password cracking very difficult. Passphrase is stretched using PBKDF2 using at least 100,000 iterations with the salt PassphraseSalt to create SecretKey.
Once SecretKey is derived, AccountKeyMaster is encrypted using it with AES-256-CBC. The initialization vector (16 random bytes) is kept as SecretIv.
Before the sign up process can be completed, LocalCryptos requires a unique message to be signed to prove that you know the private key. The browser needs to obtain the unique message needed to be signed from the LocalCryptos API. This is known as an ephemeral registration “token” and it contains:
TokenId — A unique identifier to the registration token.TokenNonce — The message needed to be signed with the new key pair you are about to create.
Once obtained, a digital signature of the registration token is created using the AccountKeyIdentityPrivate key. TokenSignature is an ECDSA signature of the Keccak-256 hash of TokenNonce.
The non-sensitive information is then submitted to the API and a new LocalCryptos account is created. (Everything marked "secret" below is not uploaded.)
Passphrase (secret) — User-inputted plain password.SecretKey (secret) — A more secure 32-byte key derived from stretching Passphrase using PBKDF2 with the salt PassphraseSalt using at least 100,000 iterations.AccountKeyMaster (secret) — A randomly generated 32-byte account master key. This is the seed to everything in your account; it's crucial to keep this secure.AccountKeyIdentityPrivate (secret) — A key that is the SHA-256 hash of the concatenation of AccountKeyMaster and "identity". Used for signing and authentication.AccountKeyEnc (secret) — A key that is the SHA-256 hash of the concatenation of AccountKeyMaster and "enc". Used for encryption.AccountKeyIdentityPublic — Using the secp256k1 curve, an ECDSA public key that corresponds to AccountKeyIdentityPrivate. Uniqueness is enforced here; no two users can have the same AccountKeyIdentityPublic.PassphraseSalt — The random 16-byte salt used for the PBKDF2 process.PassphrasePBKDF2Iterations — The number of PBKDF2 iterations to use to stretch the Passphrase to more secure key material. A higher number results in a slower key stretching process, weakening brute-force attempts.SecretIv — The randomly generated 16-byte initialization vector used to encrypt AccountKeyMaster.SecretCiphertext — The ciphertext of AccountKeyMaster encrypted to SecretKey using AES-256-CBC.TokenSignature — A digital signature of the Keccak-256 hash of TokenNonce by AccountKeyIdentityPrivate, to verify ownership of AccountKeyIdentityPublic.- Any other account information (e.g. username and e-mail address).
Logging into an account
Logging into an account requires two-factor authentication. E‐mail is the default two‐factor authentication method and there is optional support for time-synchronized OTP (e.g. apps like Google Authenticator). SMS is not supported as a two-factor method because SMS is not safe.
Two-factor authentication is necessary to protect the encrypted version of AccountKeyMaster (i.e. SecretCiphertext and SecretIv). Although the decryption process has been slowed by the key stretching process, passwords are still theoretically susceptible to brute‐force attacks (especially dictionary‐based attacks on extremely weak passwords). Hiding the key behind a two‐factor method virtually eliminates the hypothetical attack vector of another user obtaining your passphrase by brute-force.
The two-factor authentication process is executed by the API, meaning that there is a small element of trust here. If the database were to be hacked, an attacker could get all the encrypted private keys. Still, these passwords are salted and stretched so rainbow-table attacks aren't possible and other brute-force attacks are very hard. In this hypothetical hack scenario, it would be difficult for the hacker to obtain passwords except those that are very weak (e.g. "password", or a re-used password from a separate compromised database).
This is the log-in process for two-factor authentication by e-mail:
- The user enters their username and password.
- The username is delivered to the API in a request for the associated encrypted private key. The password is ignored for now.
- An e‐mail is sent to the e‐mail address associated with the username, containing a secure link to progress the login request to the next stage.
- Once the link in the e-mail is clicked, the original log-in window receives
SecretCiphertext, SecretIv, PassphraseSalt, and PassphrasePBKDF2Iterations. - The user‐entered password is salted and stretched as required to derive
SecretKey. The stretching process must be exactly the same as the process used when signing up. - If the
SecretKey can be used to calculate AccountKeyMaster correctly and hence AccountKeyIdentityPublic, then the login attempt was successful. If not, the user is prompted to try another password and step 5 is repeated. - A nonce provided by the API is signed by
AccountKeyIdentityPrivate to prove ownership of the key pair, and a new session is issued. AccountKeyMaster is stored in the browser's storage for the duration of the session.
Changing your password
Changing an account password involves re-encrypting AccountKeyMaster with a new SecretKey. The AccountKeyMaster key can never be changed, hence neither can the identity key or account encryption key be changed.
Known caveats
There are some known limitations of our implementation to keep in mind.
- Brute-force attacks — Brute‐force attacks are very difficult because of the key stretching process, but the threat shouldn't be ignored. No matter how large the warnings are, some users are still going to use weak or reused passwords. As further protection, two-factor authentication is mandatory before the log-in process.
- Two-factor confusion — The fact that second-factor authentication comes before attempting the password is opposite to nearly every other website out there. This inevitably causes some confusion to users.
- Lost passwords — If you lose your password, there is no way for staff to manually recover access to an account. It's the same as losing the private key to a cryptocurrency wallet. There is nothing we can do to allow you to regain access to an account without the password. Consequently, if you had any cryptocurrency stored in the web wallet attached to your account, we cannot recover it. This is why LocalCryptos strongly recommends to back up your wallet.
- No recovery from break-ins — Changing the account password after a break‐in has essentially no effect; the account is forever compromised as the master key cannot change. If an account is stolen, the victim must make a new account and start over.
Author
Michael is the co-founder and technical lead of LocalCryptos, the largest non-custodial peer-to-peer digital currency marketplace. Peer-to-peer traders use LocalCryptos to buy and sell crypto using non-custodial wallets and a secure decentralized escrow system.
Australia
