satoshilabs · andrewkozlik · May 4, 2026 · May 7, 2026
diff --git a/README.md b/README.md
@@ -23,12 +23,13 @@ Each SLIP should provide a concise technical specification of the feature and a
 | SLIP-0018                 | reserved (CoSi)                                                       | Standard      | Draft    |
 | [SLIP-0019](slip-0019.md) | Proof of Ownership                                                    | Standard      | Accepted |
 | [SLIP-0020](slip-0020.md) | Proof of User Confirmation                                            | Standard      | Draft    |
-| [SLIP-0021](slip-0021.md) | Hierarchical derivation of symmetric keys                             | Standard      | Final    |
+| [SLIP-0021](slip-0021.md) | Hierarchical derivation of secret keys                                | Standard      | Final    |
 | [SLIP-0022](slip-0022.md) | FIDO2 Credential ID format for HD wallets                             | Standard      | Final    |
 | [SLIP-0023](slip-0023.md) | Cardano HD master node derivation from a master seed                  | Standard      | Final    |
 | [SLIP-0024](slip-0024.md) | Trezor payment request format                                         | Standard      | Draft    |
 | [SLIP-0025](slip-0025.md) | Key derivation for CoinJoin accounts                                  | Standard      | Draft    |
 | SLIP-0026                 | reserved (CoSi)                                                       | Standard      | Draft    |
+| [SLIP-0027](slip-0027.md) | Variable-length secrets for cryptographic schemes                     | Standard      | Draft    |
 | [SLIP-0032](slip-0032.md) | Extended serialization format for BIP-32 wallets                      | Standard      | Draft    |
 | [SLIP-0039](slip-0039.md) | Shamir's Secret-Sharing for Mnemonic Codes                            | Standard      | Final    |
 | [SLIP-0044](slip-0044.md) | Registered coin types for BIP-0044                                    | Standard      | Active   |

diff --git a/slip-0019.md b/slip-0019.md
@@ -36,7 +36,7 @@ proofOfOwnership = proofBody || proofSignature
 
 ### Ownership identifier
 
-Let *k* be a secret *ownership identification key* derived from the wallet's master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of symmetric keys as:
+Let *k* be a secret *ownership identification key* derived from the wallet's master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of secret keys as:
 
 ```
 k = Key(m/"SLIP-0019"/"Ownership identification key")

diff --git a/slip-0021.md b/slip-0021.md
@@ -1,8 +1,8 @@
-# SLIP-0021 : Hierarchical derivation of symmetric keys
+# SLIP-0021 : Hierarchical derivation of secret keys
 
 ```
 Number:  SLIP-0021
-Title:   Hierarchical derivation of symmetric keys
+Title:   Hierarchical derivation of secret keys
 Type:    Standard
 Status:  Final
 Authors: Andrew R. Kozlik <andrew.kozlik@satoshilabs.com>
@@ -13,21 +13,21 @@ Created: 2019-06-25
 
 ## Abstract
 
-This document describes a method of deriving a hierarchy of symmetric keys from a master secret, such as the recovery seed used in cryptocurrency wallets.
+This document describes a method of deriving a hierarchy of secret keys from a master secret, such as the recovery seed used in cryptocurrency wallets.
 
 ## Motivation
 
-The [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) specifications define how to derive a hierarchy of private/public key pairs from a master seed for the elliptic curves secp256k1, NIST P-256 and ed25519. However, there does not exist any similar specification for the derivation of keys for symmetric-key algorithms, which are needed for example in password encryption or encryption of Bitcoin metadata. [SLIP-0011](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) deals with this problem by first using BIP-0032 to derive a secp256k1 private key and then deriving the symmetric key from this private key. However, BIP-0032 was not designed to be used in this way and it also implies that an implementation of SLIP-0011 requires secp256k1 arithmetic, which should not be needed for symmetric key derivation. The purpose of this specification is to lay down a common framework for the deterministic derivation of a hierarchy of symmetric keys from a master seed.
+The [BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) specifications define how to derive a hierarchy of private/public key pairs from a master seed for the elliptic curves secp256k1, NIST P-256 and ed25519. These derivations are tied to elliptic-curve arithmetic and produce keys whose use is constrained to those curves. Many applications instead require raw secret key material that is not bound to a specific algebraic structure, for example, keys for symmetric-key algorithms used in password encryption or encryption of Bitcoin metadata, or seeds for other cryptographic schemes. [SLIP-0011](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) addresses part of this need by first using BIP-0032 to derive a secp256k1 private key and then deriving a symmetric key from it, but BIP-0032 was not designed to be used in this way, and an implementation of SLIP-0011 requires secp256k1 arithmetic that should not be needed for raw key derivation. The purpose of this specification is to lay down a common framework for the deterministic derivation of a hierarchy of secret keys from a master seed.
 
 ## Master node generation
 
-We adapt the master node generation from BIP-0032 and SLIP-0010. To achieve proper domain separation from the secp256k1, NIST P-256 and ed25519 key hierarchies, we use the string “Symmetric key seed” instead of the curve name. Let *S* be the master secret, such as that defined in [SLIP-0039](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) or the binary seed defined in [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). Then the master node *m* is derived as follows:
+We adapt the master node generation from BIP-0032 and SLIP-0010. To achieve proper domain separation from the secp256k1, NIST P-256 and ed25519 key hierarchies, we use the string “Symmetric key seed” instead of the curve name. Despite its name, the derived nodes are not restricted to use with symmetric-key algorithms. Let *S* be the master secret, such as that defined in [SLIP-0039](https://github.com/satoshilabs/slips/blob/master/slip-0039.md) or the binary seed defined in [BIP-0039](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). Then the master node *m* is derived as follows:
 
 ```
 m = HMAC-SHA512(key = b"Symmetric key seed", msg = S)
 ```
 
-The master node is used to derive child nodes, each of which can in turn be used to derive lower-level child nodes of their own and so on. Each node is associated with a 256-bit symmetric key. The master node is thus the root of a key tree.
+The master node is used to derive child nodes, each of which can in turn be used to derive lower-level child nodes of their own and so on. Each node is associated with a 256-bit secret key. The master node is thus the root of a key tree.
 
 ## Child node derivation
 
@@ -68,7 +68,7 @@ This standard is designed in accordance with [NIST SP 800-108](https://doi.org/1
 
 ### Key length
 
-Each node is associated with a 256-bit symmetric key. This key length is considered sufficiently secure for a number of years to come, see [keylength.com](https://www.keylength.com/en/compare/). It is also compatible with all major symmetric-key algorithms in use today, such as AES-256, ChaCha20Poly1305 or HMAC. The key derivation functions specified in NIST SP 800-108 allow for the derivation of variable length keys. Nevertheless, since such a feature appears to be of little use, a fixed key length was chosen to keep the implementation of this SLIP as simple as possible.
+Each node is associated with a 256-bit secret key. This key length is considered sufficiently secure for a number of years to come, see [keylength.com](https://www.keylength.com/en/compare/). It is also compatible with all major symmetric-key algorithms in use today, such as AES-256, ChaCha20Poly1305 or HMAC, and matches the seed length accepted by many other cryptographic schemes. The key derivation functions specified in NIST SP 800-108 allow for the derivation of variable length keys. Nevertheless, since such a feature appears to be of little use, a fixed key length was chosen to keep the implementation of this SLIP as simple as possible.
 
 ### Key separation
 

diff --git a/slip-0022.md b/slip-0022.md
@@ -93,7 +93,7 @@ a5                                   # map(5)
 
 The CBOR encoded credential data is encrypted using Chacha20Poly1305 as defined in [RFC 8439](https://tools.ietf.org/html/rfc8439). In case of FIDO2 the SHA-256 hash of the rpId is used as the AAD input to the cipher. In case of U2F the application parameter (SHA-256 hash of the UTF-8 encoding of the application identity) is used as the AAD input to the cipher.
 
-The encryption key *k* is the same for all credential IDs of the same version which are generated by an authenticator with a given master secret. The key is derived from the master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of symmetric keys as:
+The encryption key *k* is the same for all credential IDs of the same version which are generated by an authenticator with a given master secret. The key is derived from the master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of secret keys as:
 
 ```
 k = Key(m/"SLIP-0022"/version/"Encryption key")
@@ -113,7 +113,7 @@ where *version* is the first four bytes of the credential ID interpreted as a 32
 
 ## Derivation of hmac-secret CredRandom
 
-The CredRandom value used in the hmac-secret extension is derived from the master secret and the credential ID using the SLIP-0021 method for hierarchical derivation of symmetric keys as:
+The CredRandom value used in the hmac-secret extension is derived from the master secret and the credential ID using the SLIP-0021 method for hierarchical derivation of secret keys as:
 
 ```
 CredRandom = Key(m/"SLIP-0022"/version/"hmac-secret"/credentialId)
@@ -195,4 +195,4 @@ The rationale behind using the authentication tag for the SLIP-0010 key path is
 * [IANA-COSE-REG](https://www.iana.org/assignments/cose/cose.xhtml): IANA CBOR Object Signing and Encryption (COSE) Registries.
 * [RFC 7049](https://tools.ietf.org/html/rfc7049): Concise Binary Object Representation (CBOR)
 * [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md): Universal private key derivation from master private key
-* [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md): Hierarchical derivation of symmetric keys
+* [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md): Hierarchical derivation of secret keys
diff --git a/slip-0024.md b/slip-0024.md
@@ -201,7 +201,7 @@ In order to simplify the communication protocol with the wallet, it is more conv
 
 The address authentication code defined in this section should only be issued for addresses that are fully controlled by the wallet, i.e. only for non-multisig addresses.
 
-Let *k* be a secret *address authentication key* derived from the wallet's master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of symmetric keys as:
+Let *k* be a secret *address authentication key* derived from the wallet's master secret using the [SLIP-0021](https://github.com/satoshilabs/slips/blob/master/slip-0021.md) method for hierarchical derivation of secret keys as:
 
 ```
 k = Key(m/"SLIP-0024"/"Address MAC key")