A keystore is a mechanism for storing private keys. It is a JSON file that encrypts a private key and is the standard for interchanging keys between devices as until a user provides their password, their key is safe.
The secure storage and exchange of keys is a vital component of the user experience as people are expected to hold their own keys. It allows users to control access to individual keys and their use by applications.
In Ethereum, Web3 Secret Storage (commonly referred to as "keystores") fulfills these requirements, however it is not perfectly suitable for these purposes moving forward. Specifically the problems with the existing standard are:
The use of Keccak256. Web3 Secret Stores use Keccak for their checksum. BLS signatures, keys (ERC-2333), and key-storage are inter-chain standards, the establishment and proliferation of which hinges on them being neutral to all chains, something which Keccak is not.
A lack of abstraction. Web3 Secret Stores are a result of an iterative design process whereby functionality was added and modified as needed without considering how abstractions could simplify the notion of different properties.
The process of decrypting the secret held within a keystore can be broken down into 3 sub-processes: obtaining the decryption key, verifying the password and decrypting the secret. Each process has its own functions which can be selected from as well as parameters required for the function all of which are specified within the keystore file itself.
The password is a string of arbitrary unicode characters. The password is first converted to its NFKD representation, then the control codes (specified below) are stripped from the password and finally it is UTF-8 encoded.
The C0, C1, and Delete control codes are not valid characters in the password and should therefore be stripped from the password. C0 are the control codes between 0x00 - 0x1F (inclusive) and C1 codes lie between 0x80 and 0x9F (inclusive). Delete, commonly known as "backspace", is the UTF-8 character 7F which must also be stripped. Note that space (Sp UTF-8 0x20) is a valid character in passwords despite it being a pseudo-control character.
This standard makes use of the notion of a module which serves to represent, in an abstract sense, the different Β cryptographic constructions and corresponding parameters for each component of the keystore. The idea being that components can be swapped out without affecting the rest of the specification should the need arise.
A module is comprised of a function, which defines which cryptographic construct is being used, params, the parameters required by the function, and message the primary input to the function.
The decryption key is an intermediate key which is used both to verify the user-supplied password is correct, as well as for the final secret decryption. This key is simply derived from the password, the function, and the params specified by thekdf module as per the keystore file.
| KDF | "function" | "params" | "message" | Definition |
|---|---|---|---|---|
| PBKDF2-SHA-256 | "pbkdf2" |
| RFC 2898 | |
| scrypt | "scrypt" |
| RFC 7914 |
The password verification step verifies that the password is correct with respect to the checksum.message, cipher.message, and kdf. This is done by appending the cipher.message to the 2nd 16 bytes of the decryption key, obtaining its SHA256 hash and verifying whether it matches the checksum.message.
decryption_key, the octet string obtained from decryption key processcipher_message, the octet string obtained from keystore file from crypto.cipher.messagechecksum_message, the octet string obtained from keystore file from crypto.checksum.messagevalid_password, aΒ boolean value indicating whether the password is valida[0:3] returns a slice of a including octets 0, 1, 2a | b is the concatenation of a with b| Hash | "function" | "params" | "message" | Definition |
|---|---|---|---|---|
| SHA-256 | "sha256" | RFC 6234 |
The cipher.function encrypts the secret using the decryption key, thus to decrypt it, the decryption key along with the cipher.function and cipher.params must be used. If the decryption_key is longer than the key size required by the cipher, it is truncated to the correct number of bits. In the case of aes-128-ctr, only the first 16 bytes of the decryption_key are used as the AES key.
| Cipher | "function" | "params" | "message" | Definition |
|---|---|---|---|---|
| AES-128 Counter Mode | "aes-128-ctr" |
| RFC 3686 |
This field is an optional field to help explain the purpose and identify a particular keystores in a user-friendly manner. While this field can, and should, be used to help distinguish keystores from one-another, the description is not necessarily unique.
The pubkey is the public key associated with the private key secured within the keystore. It is stored here to improve user experience and security which is achieved by not requiring users to enter their password just to obtain their public keys. This field is required if the secret being stored within the keystore is a private key. The encoding of the pubkey is specified in the in the appropriate signature standard (eg. ERC-2333), but can be seen as a byte-string in the abstract and should be directly compatible with the appropriate signature library.
The path indicates where in the key-tree a key originates from. It is a string defined by ERC-2334, if no path is known or the path is not relevant, the empty string, "" indicates this. The path can specify an arbitrary depth within the tree and the deepest node within the tree indicates the depth of the key stored within this file.
The uuid provided in the keystore is a randomly generated UUID as specified by RFC 4122. It is used as a 128-bit proxy for referring to a particular set of keys or account.
The version is set to 4.
The keystore, at its core, is constructed with modules which allow for the configuration of the cryptographic constructions used password hashing, password verification and secret decryption. Each module is composed of: function, params, and message which corresponds with which construction is to be used, what the configuration for the construction is, and what the input is.
None.
The rationale behind the design of this specification is largely the same as that behind the Ethereum Web3 Secret Storage Definition except for the lack of support for Keccak (explained in motivation above) and the notion of modules.
Modules provide a very useful level of abstraction which allow the Key-Derivation-Function, Checksum, and Cipher to be thought of as instances of the same thing allowing for their substitution with minimal effort.
The version is set to 4 to prevent collisions with the existing Ethereum keystore standard.
This specification is not backwards compatible with the Ethereum Web3 Secret Storage Definition due to the lack of Keccak256 checksums as explained above. While this format is capable of supporting Keccak checksums via the Checksum module, it would defeat the purpose of this standard to include it as this standard could no longer be considered neutral with respect to other projects in the industry.
Password "π±π’π°π±πππ°π°π΄π¬π―π‘π"
Encoded Password: 0x7465737470617373776f7264f09f9491
Secret 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Password "π±π’π°π±πππ°π°π΄π¬π―π‘π"
Encoded Password: 0x7465737470617373776f7264f09f9491
Secret 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
None.
Copyright and related rights waived via CC0.