Amendment XLS: Quantum safe (single-use) "regular" key support

[ximinez]

Amendment XLS: Quantum safe (single-use) "regular" key support

  title: Quantum safe key rotation
  description: Add a new account root and transaction value to allow changing a Quantum Safe Key with every transaction
  author: Ed Hennis (@ximinez) (Inspired by Nik Bougalis (@nbougalis) and David Schwartz (@JoelKatz))
  category: Amendment  
  status: Idea
  created: 2025-12-11  

1. Abstract

Proposes an amendment that would enable a new field in both AccountRoot, and every transaction that would be similar to a RegularKey, but guarantees only a single use on ledger.

Quantum attacks may never materialize, but if they do, this feature would allow users of the XRPL to harden their accounts immediately upon the revelation of a viable attack, and to have them prepared ahead of time.

2. Assumptions

1. All potential quantum attacks require that a key be used before they can even hope to succeed. Specifically, an AccountID is not sufficient to obtain any key information.
2. Potential, practical key breaking attacks will take more time than it takes for a valid transaction to be validated, or at least broadcast to sufficient UNL validators that a replacement transaction using the same public key will not have any reasonable chance to be validated.

3. Goals

1. An account can define a Single Use Key on any transaction to update their account.
2. The Single Use Key can be used to sign a transaction exactly as the Master Key and Regular Key can do now.
3. However, the master key can not be disabled if only a Single Use Key is set.
4. A single use key can only be used once ever to sign a properly formed transaction. (If the transaction is malformed or otherwise can't be processed, the user is out of luck.) After that transaction, the key will be guaranteed removed or replaced at the protocol level.

This will allow a user to set up their keys such that after set up, the a public key or signature is never revealed until they send a transaction that changes it, while still allowing account recovery in case of user error. User error could include setting the wrong Single Use Key, or losing the more ephemeral Single Use Key secret key.

4. Usage

Usage for the typical user could consist of the following steps:

1. Create a regular key, and store that key's secret somewhere safe, but recoverable.
2. Create a single use key.
3. Send a SetRegularKey transaction that sets both the Regular Key and the Single Use Key, signed by the Master Key.
4. Send an AccountSet transaction that disables the Master Key, signed by the Master Key. This is the only place where a key needs to be reused. We could consider allowing the Single Use Key to sign such a transaction.
5. For every transaction sent from that point, sign with the Single Use Key, and set the SingleUseKey field to a newly generated key value.

If user ever needs to recover from a "bad" Single Use Key, they could:

1. Retrieve the secret for the Regular Key.
2. Create a new Regular Key, and store that key's secret.
3. Send a SetRegularKey transaction with both the new Regular Key and a new Single Use Key.
4. Resume as if nothing happened.

5. Outline of changes

1. Create a new feature. Proposed name: SingleUseKey. Alternate name: QuantumSafeKey.
2. Create a new SField of type ACCOUNT. Proposed name: SingleUseKey. Alternate name: QuantumSafeKey.
3. Add the new SingleUseKey to the commonFields defined in TxFormats.cpp as optional. This list holds fields that are available to all transactions, such as Flags, LastLedgerSequence, and Memos.
4. Modify the base Transactor class functionality to delete the signer's AccountRoot.SingleUseKey if the transaction is signed with the current SingleUseKey. This includes the case where the transaction only claims a fee due to a tec result (Transactor::reset).
5. Modify the base Transactor class functionality to set the signer's AccountRoot.SingleUseKey field to the field from the transaction if it is present and not empty. (An empty value should probably be considered malformed.) This includes the case where the transaction only claims a fee due to a tec result (Transactor::reset).
6. Optionally, modify transaction processing such that if the transaction properly signed by the QuantumSafeKey, and passes all the baseline requirements (properly formed, has a correct sequence or ticket, pays a correct fee, etc.) that the transaction will claim a fee and do the above steps even if the transaction otherwise would not claim a fee. (In code terms, this means the derived Transactor class returns a result that isn't tec or tesSUCCESS from either preclaim or doApply.)
   • Maybe create a new result code to indicate this situation. e.g. tecSINGLE_USE_KEY.

Note that steps 4 and 5 should be done at the same time as the sequence or ticket is consumed (consumeSeqProxy), and the fee is paid (payFee). If the transaction is delegated, then it must be signed by the delegate, and thus the delegate's SingleUseKey should be updated.

6. Potential issues

6.a. Multi-signing

Up to this point, I have intentionally avoided mentioning multi-signing, because of the extra complexity.

First, there is no intention to support anything like a "single use signers list".

Second, a Signer List can be used for recovery just as a Regular Key can.

Third, though, any signers that are activated on-ledger can define a Regular Key and use that in a multisignature. I think it makes sense to allow a Single Use Key in a multi signature as well. We will follow the same rules for the signer in a multisig as we do for the singer of the transaction. That will require adding an optional SingleUseKey field to the Signer and CounterpartySignature inner objects, too.

6.b. Tickets

Tickets allow transactions to execute out of order. Transactions signed with a chain of Single Use Keys effectively define their own order. Users using tickets will need to be cautious to ensure their ticket-based transactions and Single Use Keys are submitted and validated in an order that works. They may need to wait for each transaction to be validated before singing and submitting the next one.

If a transaction using a Ticket and signed with a Single Use Key that isn't yet valid is made public, it will not be able to be processed or claim a fee, and thus won't be broadcast, but it will be held by the submission node for a limited amount of time before being discarded. The risk is that if that submission node is public, an attacker could potentially subscribe to the proposed transactions stream, watch for such transactions, and if the quantum attack is fast enough, break their key, and sign a new transaction using that key, and submit it as soon as the key becomes valid. If their transaction succeeds in getting validated instead of the original, the attacker could cause all kinds of mischief, including draining an account's funds, and setting a new Regular Key or Signer List, and a new Single Use Key, potentially completely taking over the account. There is little or nothing that the XRPL can do to mitigate this risk, so the responsibility for that will land back on the user.

6.c. User error

We can't protect the user from themselves. If, for example, a user reuses an ephemeral key, there's nothing we can reasonably do to detect or prevent it.

We can detect if the user tries to set the Single Use Key to one of the existing keys - master, regular, signers(?), signers' regular(?), signer's ephemeral(?)... How deep do we go with that? Transactors don't load the signers list unless the transaction is multisigned. Should we start doing that if a Single Use Key is set? Or do we limit it to what is currently reasonable?