-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Brave Wallet Seed Wiki
Brave Wallet is a native Brave Browser implementation of an Ethereum (or any EVM compatible chain) and Filecoin remote client. Please note this is different than the old Brave Ethereum wallet based on a fork of MetaMask (wiki can be found here). The native implementation requires less processes to run and may even be extended to support other protocols in the future (e.g. Doge, Solana, etc.).
These protocols adopt the BIP-32 (HD-Wallet) specification and maintains its own implementation of a Keyring Controller. HD-Wallet uses the bitcoin-core implementations of secp256k1
, ripemd160
, base58
, and BLS12-381
. The remaining cryptographic wallet functionality is provided by BorringSSL which is used in Chromium in place of OpenSSL (BorringSSL is maintained by Google).
As in the old MetaMask extension, we adopt BIP-39 mnemonic keywords based on a high entropy seed of 256bits. Mnemonic phrases are encrypted at rest using the AEAD suite AES-256-GCM-SIV with a randomized 96-bit nonce, and an encryption key derived by a user passphrase fed into a key derivation function. Mnemonics are generated using a Brave maintained hard fork of libwally-core.
Protocols
- Using
crypto::RandBytes
(a BoringSSL source of strong entropy) we derive a 128bit-256bit seed (currently it is configured at 128bits). - Create a salt with the string 'mnemonic'
- Using PBKDF2 + HMAC-SHA512 with 2048 iterations, take the seed from step 2 and the mnemonic from step 1, derive our 512bit seed.
- Used the 512bit seed to construct the HD-Wallet using BIP32.
- User chooses a strong passphrase. Passwords must be at least 7 characters and contain at least one number and special character, though we STRONGLY RECOMMEND much longer passphrases.
- Derive a 256-bit salt using
crypto::RandBytes
- Derive 256-bit symmetric key using PBKDF2+HMAC-SHA256 with the passphrase + salt as input. We use 100,000 iterations.
- Derive a 12-byte (96-bit) initialization vector using
crypto::RandBytes
- Encrypt the Mnemonic under AES-256-GCM-SIV mode with the mnemonic, key, and IV as input.
- User provides the password that they used to unlock MM and CW
- We will fetch the data stored in
chrome.storage.local
to get salt, iv and encrypted data - Derived encryption key using PBKDF2 + HMAC-SHA256 with password from step1, salt from step 2 and 10000 iterations
- Then we decrypt the encrypted data using key from step 3 with mod AES-GCM along with iv from step 2
- When we get the decrypted mnemonic, we will do auto import for user
- User provides the password that they used to unlock CW which has 24 words mnemonic
- We will fetch the data stored in
chrome.storage.local
to get salt, iv, encrypted data and also argon2 params and salt for argon2 - Derived new password using argon2 with password from step1 along with argon2 params and argon2 salt
- Derived encryption key using PBKDF2 + HMAC-SHA256 with password from step3, salt from step 2 and 10000 iterations
- Then we decrypt the encrypted data using key from step 3 with mod AES-GCM along with iv from step 2
- When we get the decrypted mnemonic, we will do auto import for user
An address is an identifier that refers to an actor in the Filecoin state. An address may also be encoded to a string, this encoding includes a checksum and network prefix. Filecoin spec
network | protocol | payload | checksum |
---|---|---|---|
'f' or 't' | 1 byte | n bytes | 4 bytes |
Network:
- 't' means test/calibration or localhost node network.
- 'f' means Mainnet
Procotol:
- value 1: addresses represent
secp256k1
public encryption keys. The payload field contains theBlake2b
160 hash of the uncompressed public key (65 bytes). - value 3: addresses represent
BLS
public encryption keys.
Payload:
- The payload field contains 48 byte
BLS
PubKey public key. All payloads except the payload of the ID protocol arebase32
encoded using the lowercase alphabet when seralized to their human readable format.
Checksum:
- Filecoin checksums are calculated over the address protocol and payload using
blake2b-4
. Checksums arebase32
encoded and only added to an address when encoding to a string. Addresses following the ID Protocol do not have a checksum.
- Filecoin adopt the BIP-32 (HD-Wallet) specification and maintains its own implementation of a Keyring Controller. It uses the bitcoin-core implementations of
secp256k1
, and bls-signatures forBLS12-381
. - Derivation paths adopt SLIP-0044. Importing accounts for Mainnet uses
m/44'/461'/0'/0/${i}
derivation paths, and, accordingly, am/44'/1'/0'/0/${i}
is used for test networks