ACE-GF: A Generative Framework for Atomic Cryptographic Entities

1.1. Background and Motivation

Deterministic key management schemes, such as BIP-32 [BIP32] and BIP-39 [BIP39], have simplified key recovery by deriving keys from a single master seed. However, these schemes rely on the long-term persistent storage of that seed, which constitutes a single point of failure (SPOF). If the seed is compromised, all derived keys are irreversibly exposed.¶

This storage-centric design is ill-suited for Autonomous Digital Entities (ADEs), such as AI agents and IoT deployments, which require identity continuity without centralized trust anchors [DID-Core]. ACE-GF addresses these challenges by decoupling deterministic identity from long-term secret storage, ensuring that the identity root exists only ephemerally during the reconstruction process.¶

1.2. Core Contributions

ACE-GF introduces a generative framework for Atomic Cryptographic Entities (ACE) with the following properties:¶

• Seed-Storage-Free: The identity root (REV) exists only ephemerally in memory during active operations.¶

• Deterministic Reconstruction: The REV is reconstructed from a sealed artifact and authorization credentials.¶

• Context Isolation: Cryptographic keys are isolated across algorithms (e.g., Ed25519, ML-DSA) using explicit context encoding [RFC5869].¶

2.1. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Terminology

The following terms are used throughout this document:¶

ACE-GF

Atomic Cryptographic Entity Generative Framework. A cryptographic framework that enables deterministic reconstruction of digital identities from user-held credentials without requiring persistent storage of a master secret.¶

Credential

A user-provided secret input to ACE-GF, such as a passphrase, mnemonic, or other high-entropy material. Credentials are supplied at the time of identity reconstruction and are not persistently stored by the framework.¶

Identity

A stable cryptographic identity derived via ACE-GF. An identity may correspond to one or more public/private key pairs, addresses, or identifiers, depending on the application context in which ACE-GF is applied. An Identity in ACE-GF is defined by the ability to reconstruct the underlying Root Entropy Value (REV); loss of this ability renders the identity cryptographically unreachable.¶

Context

An explicit domain-separation parameter, as defined in the context of Key Derivation Functions [NIST-SP800-108], used by ACE-GF to ensure that derived material for different purposes, algorithms, or applications remains cryptographically isolated.¶

Rekeying

The process of updating the authorization metadata (Sealed Artifact) to associate new credentials with an existing identity while preserving the underlying identity semantics. Unlike traditional key rotation, ACE-GF rekeying does not modify the underlying Root Entropy Value (REV).¶

Profile

A specification that defines how ACE-GF is applied within a specific application domain. Profiles may impose additional constraints, parameters, or output formats, but do not modify the core ACE-GF construction defined in this document.¶

Wallet Application Profile

An application profile that applies ACE-GF to cryptocurrency wallet systems, including multi-algorithm key derivation and migration from legacy wallet formats. This profile is illustrative and does not constrain other applications of ACE-GF.¶

3.1. The Decoupled Identity Model

ACE-GF operates on the principle of Functional Decoupling. Unlike traditional deterministic systems that require the persistent storage of a master seed, ACE-GF separates the identity into two logically independent pipelines:¶

• Authorization Pipeline (The "Lock"): Manages the transformation between a user's volatile Credential and a persistent Sealed Artifact (SA). It controls access to the identity.¶

• Identity Pipeline (The "Key"): Performs deterministic derivation from the reconstructed Root Entropy Value (REV) to various cryptographic algorithms. It defines the substance of the identity.¶

3.2. Data Flow and Transformation

The following diagram illustrates how entropy flows from a raw state, through the authorization lock, and into algorithm-specific keys:¶

Authorization Pipeline            Identity Pipeline
----------------------            -----------------
[Credential] + [Salt]
      |
      v
  Argon2id (KDF1)
      |
      v
  K_seal (Symmetric)             Derivation Context (Ctx)
      |                               |
      |                               v
AEAD-Decrypt(SA, K_seal) ----> [  REV  ] ----> HKDF-Expand (KDF2)
                                      |
                                      v
                           [ Algorithm-Specific Keys ]

3.3. Atomic Entity Lifecycle and States

The lifecycle of an ACE is defined by the availability and reachability of the Root Entropy Value (REV).¶

3.4. Core Operations: Rekeying and Identity Unreachability

By decoupling authorization from identity, ACE-GF enables critical operations without changing underlying cryptographic identifiers (e.g., blockchain addresses):¶

• Stateless Rekeying: To change a password, the entity unseals the REV and re-seals it using a new Credential and new Salt. The REV remains invariant; thus, all derived public keys remain stable.¶

• Identity Unreachability: An identity becomes unreachable if the Sealed Artifact (SA) or required authorization inputs are lost or destroyed. Without these, the REV is mathematically lost, rendering the identity cryptographically unreachable without reliance on external revocation infrastructure.¶

3.5. Local Call Sequence

The following sequence describes the typical interaction between an application ("Caller") and an ACE-GF implementation:¶

Caller                         ACE-GF Implementation
  |                                     |
  |----- 1. generate_rev() ------------>| (Samples CSPRNG)
  |<------ [REV in RAM] ----------------|
  |                                     |
  |----- 2. seal_rev(REV, Cred) ------->| (Argon2id + AES-GCM-SIV)
  |<----- [Sealed Artifact (SA)] -------| (Store to disk)
  |                                     |
  |----- 3. zeroize_memory() ---------->| (Wipe RAM)
  |                                     |
  | ... later (identity usage) ...      |
  |                                     |
  |----- 4. unseal_rev(SA, Cred) ------>| (Reconstructs REV in RAM)
  |----- 5. derive_key(REV, Ctx) ------>| (HKDF-SHA256)
  |<----- [Derived Key Material] -------|
  |----- 6. zeroize_memory() ---------->| (Wipe RAM)

4.1. Identity Pipeline

The identity pipeline manages the transformation from the REV to application-specific keys. It utilizes a deterministic, one-way derivation function (HKDF) combined with explicit context strings. This ensures that compromise of a specific child key (e.g., an Ed25519 signing key) does not leak information about the REV or other sibling keys.¶

4.2. Authorization Pipeline

The authorization pipeline manages the secure "sealing" and "unsealing" of the REV. By utilizing Argon2id for memory-hard key stretching and AES-GCM-SIV for nonce-misuse resistant encryption, the framework ensures that the REV is only accessible when the correct Credential is provided.¶

5.1. KDF1: Credential Hashing (Argon2id)

To resist offline brute-force attacks, ACE-GF utilizes the Argon2id algorithm [RFC9106] for stretching user-provided credentials (Cred) into a symmetric sealing key (K_seal).¶

The specific mechanism by which auth_index is bound into the sealing key derivation is an implementation detail, provided that distinct values of auth_index result in cryptographically independent sealing keys.¶

• Algorithm Selection: Implementations MUST use the Argon2id variant (as opposed to Argon2i or Argon2d) to provide optimized protection against both side-channel attacks and GPU-based cracking.¶

• Parameter Negotiation: Implementations SHOULD support pre-defined Sealing Profiles that specify memory cost (M), time iterations (T), and parallelism (P).¶

• Salt: Each Sealed Artifact (SA) MUST include a 128-bit random salt sampled from a CSPRNG. For the purpose of binding the authorization epoch, the salt input to the Argon2id function MUST be a 20-byte sequence, constructed by concatenating the 16-byte random salt and the 4-byte Big-Endian representation of the auth_index.¶

• Credential Encoding: To ensure deterministic consistency across different platforms and programming languages, the Authorization Credential (Cred) MUST be encoded as a UTF-8 string [RFC3629] before being provided as the password input to the Argon2id function.¶

5.2. AEAD: Sealing Encryption (AES-GCM-SIV)

ACE-GF employs AES-GCM-SIV [RFC8452] for the authenticated encryption of the Root Entropy Value (REV).¶

AES-256-GCM-SIV is used exclusively for authorization sealing of the Root Entropy Value (REV). It is not part of the Derive operation and does not correspond to any AlgID value in the Context Identifier Registry.¶

• Misuse Resistance: AES-GCM-SIV is selected for its Synthetic Initialization Vector (SIV) properties. In the specific context of ACE-GF, given that the REV is a 256-bit high-entropy random value, using a fixed 96-bit all-zero nonce (N_fixed) is safe under the assumption that the plaintext (REV) is a uniformly random, high-entropy value and that the sealing key is not reused for arbitrary plaintexts. This usage constitutes a restricted, single-message sealing construction and MUST NOT be generalized beyond the specific case defined in this document. This assumption holds only for the sealing of a single, uniformly random REV per Sealed Artifact (SA) and MUST NOT be extended to sealing arbitrary data or multiple plaintexts under the same key.¶

• Security Assurance: The use of AES-GCM-SIV prevents confidentiality leaks even in cases of nonce reuse, eliminating the dependency on high-fidelity hardware Random Number Generators (RNG) during every sealing operation.¶

• Data Structure: The encryption process MUST produce a 256-bit ciphertext and a 128-bit authentication tag.¶

• Additional Authenticated Data (AAD): To ensure the integrity of the authorization metadata, the AEAD encryption MUST supply the first 10 bytes of the Sealed Artifact (SA) as Additional Authenticated Data. This AAD string consists of the Magic Number (4 bytes), Version (1 byte), ProfileID (1 byte), and the Authorization Index (4 bytes). All multi-byte fields MUST be encoded in Big-Endian (Network Byte Order).¶

• Authenticated Metadata Binding: Implementations MUST supply the Authorization Index (auth_index) as Additional Authenticated Data (AAD) to AES-256-GCM-SIV. This ensures that any modification of authorization metadata results in authentication failure during unsealing. Failure to bind auth_index via AAD constitutes a violation of this specification.¶

5.3. KDF2: Key Derivation (HKDF-SHA256)

For deriving algorithm-specific keys from the REV, ACE-GF utilizes HKDF [RFC5869].¶

• Core Logic: The standard Extract-then-Expand workflow is followed.¶

• Extract: Map the REV into a cryptographically strong Pseudorandom Key (PRK).¶

• Expand: Input the structured Context tuple (Ctx) as the 'info' parameter to generate target keys of specific lengths.¶

• Hash Function: SHA-256 MUST be used.¶

• Isolation Guarantee: By explicitly encoding AlgID, Domain, and Index into the 'info' string, HKDF ensures that the resulting child keys are computationally independent.¶

6.1. Root Entropy Value (REV) Generation

This operation generates the Root Entropy Value (REV), which serves as the atomic foundation of an ACE identity.¶

6.2. Sealing Process (Seal)

The Sealing process transforms a Root Entropy Value (REV) into a persistent Sealed Artifact (SA) using an Authorization Credential.¶

6.3. Unsealing Process (Unseal)

The Unsealing process reconstructs the Root Entropy Value (REV) from a provided Sealed Artifact (SA) and Authorization Credential.¶

6.4. Key Derivation Function (Derive)

The Derive operation deterministically produces algorithm-specific cryptographic key material from a reconstructed Root Entropy Value (REV).¶

7.1. Sealed Artifact (SA) Binary Format (Version 0x01)

This section defines the binary encoding of the Sealed Artifact (SA) for protocol version 0x01. The SA encapsulates the encrypted Root Entropy Value (REV) together with all metadata required for deterministic reconstruction.¶

All multi-byte integer fields MUST be encoded in Big-Endian (Network Byte Order). Implementations MUST reject any SA whose total length does not exactly match the expected length for the indicated Version.¶

7.2. Sealing Profiles

Sealing Profiles define the cost parameters for the Argon2id function. This allows ACE-GF to scale from resource-constrained mobile devices to high-security server environments.¶

Implementations MUST support at least the 'Standard' (0x02) profile. The 'Paranoid' profile is RECOMMENDED for high-value administrative identities.¶

7.3. Context Labels

To ensure computational independence between different cryptographic algorithms, the AlgID field in the Context Tuple MUST use the following initial registry. This ensures that a key derived for Ed25519 cannot be mistakenly used or mathematically linked to a Secp256k1 key.¶

Usage Domains describe the functional intent of derived key material and do not override algorithm-specific restrictions defined elsewhere in this document.¶

7.4. Context Tuple Encoding

The Context Tuple (Ctx) is a compact, fixed-length binary structure used as the info parameter for HKDF expansion. All fields are encoded in Big-Endian (Network Byte Order).¶

8.1. Sealed Artifact Persistence and Mobility

The Sealed Artifact (SA) is a persistent, encrypted authorization artifact, not a cryptographic root. Possession of an SA alone does not enable identity reconstruction without the corresponding Authorization Credential.¶

Because the SA contains no plaintext secret material and reveals no information about the Root Entropy Value (REV), it MAY be stored, replicated, and transported using untrusted storage mechanisms, including public cloud storage or distributed content-addressable systems.¶

Loss of all copies of the SA renders the identity cryptographically unreachable. Applications SHOULD treat the SA as durable authorization metadata and apply backup and redundancy strategies appropriate to their threat model.¶

8.2. Stateless Credential Rotation

ACE-GF supports stateless credential rotation, allowing an entity to update its Authorization Credential (e.g., changing a password or authorization factor) without altering the underlying Root Entropy Value (REV).¶

Because the REV is the sole source of all derived cryptographic keys, this process preserves identity continuity. No derived public keys, addresses, or identifiers need to be regenerated or re-announced.¶

The rotation process is performed as follows:¶

1. Unseal: Use the current Authorization Credential and the existing Sealed Artifact (SA) to reconstruct the REV in volatile memory.¶

2. Generate New Salt: Sample a new 128-bit random salt value.¶

3. Re-Seal: Perform the Sealing Process (as defined in Section 4.2) using the new Authorization Credential and the new salt, while maintaining the same REV.¶

4. Commit: Replace the previous SA with the newly generated SA.¶

This operation is stateless with respect to identity semantics. No persistent state other than the updated SA is required, and no protocol- visible identity attributes are modified.¶

8.3. Logical Revocation via Authorization Index

ACE-GF defines logical revocation as the ability to render a previously valid Sealed Artifact (SA) unusable without modifying the underlying Root Entropy Value (REV).¶

An ACE-GF Identity is defined by the ability to reconstruct the REV. Logical revocation invalidates specific authorization states while preserving the identity itself and all derived cryptographic identifiers.¶

8.4. Failure Modes and Recovery Considerations

Failure to reconstruct the REV may occur due to incorrect credentials, corrupted Sealed Artifacts, unsupported sealing profiles, or intentional revocation actions.¶

Implementations SHOULD treat all unsealing failures as indistinguishable from an external observability perspective and MUST NOT leak partial information about the REV or derived keys in failure scenarios.¶

Recovery is possible only if sufficient authorization material remains available. Loss of all authorization inputs results in permanent unreachability of the REV.¶

8.5. Storage and Ephemeral State Considerations

The Root Entropy Value (REV) is intended to exist only in volatile memory during active operations and MUST NOT be persistently stored.¶

The Sealed Artifact (SA) is the sole persistent representation required to reconstruct an ACE identity. It MAY be stored, transmitted, or backed up using conventional storage mechanisms, subject to application-specific security policies.¶

Implementations SHOULD ensure timely zeroization of all sensitive material, including the REV, sealing keys, and intermediate buffers, after use. Where available, hardware-backed isolation mechanisms such as Trusted Execution Environments (TEEs) are RECOMMENDED to reduce exposure risk during reconstruction and derivation operations.¶

8.6. Migration Considerations

Existing cryptographic identities MAY be migrated into the ACE-GF framework by treating a legacy high-entropy private key as a Root Entropy Value (REV) and sealing it using standard ACE-GF procedures.¶

Such migrations are OPTIONAL and profile-dependent. Implementations SHOULD document any deviations from native ACE-GF derivation semantics and SHOULD clearly distinguish between natively generated ACE-GF identities and migrated identities when relevant.¶

9.1. Entropy Requirements for Credentials

The security of the Sealed Artifact (SA) is directly proportional to the entropy of the Authorization Credential (Cred).¶

1. Minimum Entropy: Human-provided credentials SHOULD be long, randomly generated passphrases managed by password managers. Machine-generated credentials MUST provide at least 128 bits of entropy.¶

2. Entropy Stretching: While Argon2id provides significant resistance against brute-force, it cannot compensate for extremely weak secrets (e.g., short, common passwords).¶

3. Machine-Generated Credentials: For Autonomous Digital Entities (ADEs), credentials MUST be generated using a CSPRNG.¶

9.2. Protection of Volatile Memory and Memory Management

Since the Root Entropy Value (REV) serves as the atomic foundation for all derived identities, its exposure in volatile memory constitutes a single point of failure. An attacker capable of observing the memory space of an active ACE-GF implementation could compromise the entire identity hierarchy derived from that REV.¶

9.3. Resistance to Brute-Force Attacks

The use of Argon2id allows ACE-GF to scale its defense according to the threat model. The following table provides a theoretical analysis of attack costs across different Profiles:¶

9.4. Post-Quantum Transition and Hybrid Security

ACE-GF is designed with "Algorithm Agility" to survive the transition to Post-Quantum Cryptography (PQC).¶

1. Context-Isolated PQC: As defined in Section 5.3, the framework allows the derivation of PQC keys (e.g., ML-DSA) alongside classical keys (e.g., Ed25519) from the same REV.¶

2. Hybrid Derivation: For maximum security during the transition period, implementations MAY use a hybrid approach where a classical signature and a PQC signature are required to authorize a single action.¶

3. Future-Proofing REV: Because the REV is a high-entropy (256-bit) random value, it provides an effective 128-bit preimage security margin against generic quantum search attacks (e.g., Grover-style algorithms [Grover1996]), under standard complexity assumptions.¶

9.5. Note on AES-GCM-SIV and Fixed Nonce

The use of a fixed all-zero nonce (N_fixed) in Section 4.2.2 is safe specifically because the plaintext being encrypted (the REV) is guaranteed to be a unique, high-entropy 256-bit value for every Sealed Artifact. Therefore, the SIV (Synthetic Initialization Vector) derivation will inherently produce unique sub-keys for the underlying CTR mode, preventing the catastrophic key-stream reuse associated with standard AES-GCM.¶

10.1. ACE-GF Sealing Profile Registry

IANA is requested to create a new registry entitled "ACE-GF Sealing Profiles". This registry manages the parameter sets for the credential hashing function (Argon2id).¶

The registration policy for this registry is "Specification Required" as defined in [RFC8126].¶

Initial entries for this registry are as follows:¶

10.2. ACE-GF Context Identifier Registry

IANA is requested to create a new registry entitled "ACE-GF Context Identifiers". This registry manages the Algorithm Identifiers (AlgID) used in the key derivation context string.¶

The registration policy for this registry is "Expert Review" as defined in [RFC8126].¶

Initial entries for this registry are as follows:¶

10.3. ACE-GF Usage Domain Registry

IANA is requested to create a new registry entitled "ACE-GF Usage Domains". This registry manages the 8-bit Domain field.¶

11.1. Basic Protocol Test Vectors

11.2. Cross-Platform and Encoding Consistency

11.3. Multi-Algorithm and Post-Quantum Derivation

11.4. Application Profile Test Vectors (Informational)

{
"description": "ACE-GF Deterministic Identity Test Vectors V1.0",
"project_version": "2025.12.23",
"test_cases": [
{
"case_id": "TEST_CASE_001",
"name": "Initial_Generation_ASCII_Passphrase",
"description": "Generate a new ACE-GF identity using ASCII passphrase 'abc'. Establishes Identity #1.",
"command": "./acegf generate abc",
"input": {
"passphrase": "abc"
},
"expected_output": {
"mnemonic": "vintage crash medal recycle item pigeon error real join december image into toe bag coffee pyramid gorilla tank scrub drift pencil clap vacant unlock",
"solana": "5yFK8sUGK6Ng5TqENvnLhwHRPDzyTMzLLp5ViUyx2ppk",
"evm": "0x1aCDA9f78D27e433317de8b14F50bb333df5055e",
"bitcoin": "bc1pnjptwsfjpukkj4xcw20fm5ddjrfqqquahj34q4lkd6jemxnvs84s5wgs2u",
"cosmos": "cosmos1kzuju6s08kacthf45vd3raexjfuggrx2n9y6aq",
"polkadot": "16VnAyYpbPgnVzS2TEHeZK7LMegJ8dTDez68KUbrsS3D2thU",
"xidentity": "ZgjpfHPPDtpT0vHezh5inQW/ruBmDQTDuNMyrCWLzhw="
}
},
{
"case_id": "TEST_CASE_002",
"name": "View_Deterministic_Restore_ASCII",
"description": "Restore Identity #1 using the original mnemonic and passphrase 'abc'. Must deterministically match TEST_CASE_001.",
"command": "./acegf view abc [mnemonic]",
"input": {
"passphrase": "abc",
"mnemonic": "vintage crash medal recycle item pigeon error real join december image into toe bag coffee pyramid gorilla tank scrub drift pencil clap vacant unlock"
},
"expected_output_ref": "TEST_CASE_001"
},
{
"case_id": "TEST_CASE_003",
"name": "Rekey_ASCII_to_ASCII",
"description": "Rekey Identity #1 by changing passphrase from 'abc' to 'cde'.",
"command": "./acegf rekey abc cde [mnemonic]",
"input": {
"old_passphrase": "abc",
"new_passphrase": "cde",
"old_mnemonic": "vintage crash medal recycle item pigeon error real join december image into toe bag coffee pyramid gorilla tank scrub drift pencil clap vacant unlock"
},
"expected_output": {
"new_mnemonic": "stuff roast enable clown casual crazy swing sun spoil home derive ocean screen frog shoot devote memory fall chuckle float canvas blue sudden quick"
}
},
{
"case_id": "TEST_CASE_004",
"name": "View_After_Rekey_ASCII",
"description": "Restore Identity #1 using new mnemonic and new passphrase 'cde'. Addresses must match TEST_CASE_001.",
"command": "./acegf view cde [new_mnemonic]",
"input": {
"passphrase": "cde",
"mnemonic": "stuff roast enable clown casual crazy swing sun spoil home derive ocean screen frog shoot devote memory fall chuckle float canvas blue sudden quick"
},
"expected_output_ref": "TEST_CASE_001"
},
{
"case_id": "TEST_CASE_005",
"name": "Legacy_12_Word_Aceize",
"description": "Convert a legacy 12-word mnemonic into an ACE-GF identity using passphrase 'abc'.",
"command": "./acegf aceize abc [12-word mnemonic]",
"input": {
"passphrase": "abc",
"legacy_mnemonic": "figure pony hour transfer toilet blush easy sorry taste write swing neck"
},
"expected_output": {
"mnemonic": "language issue crash subject warm when step shadow two live fantasy cake crush key calm cabbage ready error sure idea dish rotate drama balance",
"solana": "p9vabuSUkrntQwDNiA7X2xaiaBkwFn2SxJdmAFdHgKd",
"evm": "0xe21AA588aEFA0AE391798A122f0994E9eD9406E5",
"bitcoin": "bc1pet90lyvvca05c4zhme6925zr2kgdwjj564nm8kqhf758gvgp9fvs6px5g7",
"cosmos": "cosmos1zvtxtz5vh500rh0k0n3laeh6z0t263yp8krl80",
"polkadot": "132SUNr7yrVqTMYYACtHQSz9RCR1Pkw126BkF5PGdW892LoV",
"xidentity": "DUZt+nGZE1ZpGJhW0MYdtibPQcEBKXMHYkZW5phnoTo="
}
},
{
"case_id": "TEST_CASE_006",
"name": "Unicode_Passphrase_Emoji",
"description": "Rekey identity using emoji passphrase. Tests UTF-8 and non-ASCII passphrase handling.",
"command": "./acegf rekey cde 🔥🔥 [mnemonic]",
"input": {
"old_passphrase": "cde",
"new_passphrase": "🔥🔥",
"old_mnemonic": "mushroom unusual extend belt torch sketch limb symbol invest fury dinner fly capital you love school logic banana mention wrist buffalo spike finger elite"
},
"expected_output": {
"new_mnemonic": "rabbit thing indoor flower brass blush distance sauce swear ramp guard decorate news girl belt kid embody spoil skate alone suit record park wisdom"
}
},
{
"case_id": "TEST_CASE_007",
"name": "Unicode_Passphrase_Chinese",
"description": "Rekey identity using Chinese UTF-8 passphrase '测试'.",
"command": "./acegf rekey 🔥🔥 测试 [mnemonic]",
"input": {
"old_passphrase": "🔥🔥",
"new_passphrase": "测试",
"old_mnemonic": "rabbit thing indoor flower brass blush distance sauce swear ramp guard decorate news girl belt kid embody spoil skate alone suit record park wisdom"
},
"expected_output": {
"new_mnemonic": "deliver truck spread mask fetch connect cute credit cigar garlic student forest decade exchange swap issue wage gauge eagle soup squirrel cash dog whale"
}
},
{
"case_id": "TEST_CASE_008",
"name": "View_After_Multi_Rekey_Unicode",
"description": "Restore identity after multiple rekey operations with Unicode passphrases. Addresses must remain invariant.",
"command": "./acegf view 测试 [mnemonic]",
"input": {
"passphrase": "测试",
"mnemonic": "deliver truck spread mask fetch connect cute credit cigar garlic student forest decade exchange swap issue wage gauge eagle soup squirrel cash dog whale"
},
"expected_output_ref": "TEST_CASE_005"
}
]
}

11.5. 10.5. Interoperability Verification Guidance

An implementation claiming conformance to this specification SHOULD verify interoperability as follows:¶

1. Using the test vectors in Sections 10.1 and 10.2, confirm that: - The reconstructed REV exactly matches the expected value. - The serialized Sealed Artifact (SA) fields match the specified binary layout and contents.¶

2. Using the vectors in Section 10.3, confirm that: - Derived key material for different algorithms and domains is deterministic and context-isolated. - Classical and post-quantum derivations can coexist under the same REV.¶

3. Implementations supporting the Cryptocurrency Wallet Application Profile SHOULD additionally verify conformance using the vectors defined in Section 10.4.¶

Successful verification across independent implementations indicates interoperability of the ACE-GF construction.¶

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.¶

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003.¶

[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010.¶

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017.¶

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.¶

[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: Nonce-Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, April 2018.¶

[RFC9106] Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications", RFC 9106, DOI 10.17487/RFC9106, September 2021.¶

[FIPS203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS PUB 203, August 2024.¶

[FIPS204] NIST, "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, August 2024.¶

[NIST-SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, October 2009.¶

12.2. Informative References

[BIP32] Wuille, P., "Hierarchical Deterministic Wallets", February 2012.¶

[BIP39] Palatinus, M., et al., "Mnemonic code for generating deterministic keys", 2013.¶

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017.¶

[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016.¶

[SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters", Version 2.0, January 2010.¶

[DID-Core] Drummond, R., et al., "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022.¶

[Grover1996] Grover, L., "A Fast Quantum Mechanical Algorithm for Database Search", 1996.¶

B.1. Note

• Note: The following pseudocode is provided for explanatory purposes only. It omits error handling, memory zeroization, and side-channel protections, and MUST NOT be used as a reference implementation. Conforming implementations MUST adhere to the normative requirements specified elsewhere in this document.¶

import struct
from cryptography.hazmat.primitives.ciphers.aead import AESGCMSIV
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes

# --------------------------------------------------------------------
# Pseudocode placeholder for Argon2id
# --------------------------------------------------------------------
def argon2id_kdf(password_bytes, salt_bytes, memory_mib, iterations, parallelism, out_len):
    """
    Pseudocode representation of Argon2id.
    Implementations MUST use RFC 9106–compliant Argon2id.
    """
    # This function is a placeholder.
    # A real implementation must call an Argon2id library.
    raise NotImplementedError("Argon2id KDF placeholder")


# --------------------------------------------------------------------
# ACE-GF: Seal REV
# --------------------------------------------------------------------
def ace_seal_rev(
    rev: bytes,
    credential: str,
    salt_16: bytes,
    auth_index: int,
    profile_id: int = 0x02,
):
    """
    Seal a 32-byte Root Entropy Value (REV) into a Sealed Artifact (SA).
    """

    assert len(rev) == 32
    assert len(salt_16) == 16

    # --- Extend salt with auth_index (Big-Endian) ---
    extended_salt = salt_16 + struct.pack(">I", auth_index)

# --- Select Argon2id parameters by profile ---
    if profile_id == 0x01:      # Mobile
        m, t, p = 64, 3, 1
    elif profile_id == 0x02:    # Standard
        m, t, p = 256, 4, 2
    elif profile_id == 0x03:    # Paranoid
        m, t, p = 1024, 8, 4
    else:
        raise ValueError("Unsupported Sealing Profile")

    # --- Derive sealing key using Argon2id ---
    k_seal = argon2id_kdf(
        password_bytes=credential.encode("utf-8"),
        salt_bytes=extended_salt,
        memory_mib=m,
        iterations=t,
        parallelism=p,
        out_len=32,  # 256-bit AES key
    )

    # --- Construct Additional Authenticated Data (AAD) ---
    # AAD = Magic || Version || ProfileID || auth_index
    aad = b"ACE\x00" + struct.pack(">BBI", 0x01, profile_id, auth_index)

    # --- Encrypt REV using AES-256-GCM-SIV ---
    nonce = b"\x00" * 12  # Fixed nonce (restricted single-message usage)
    aead = AESGCMSIV(k_seal)

    ciphertext = aead.encrypt(nonce, rev, aad)

    return ciphertext  # Ciphertext || Tag (library-defined layout)


# --------------------------------------------------------------------
# ACE-GF: Derive Algorithm-Specific Key Material
# --------------------------------------------------------------------
def ace_derive_key(
    rev: bytes,
    alg_id: int,
    domain: int,
    index: int,
    length: int,
):
    """
    Derive context-isolated key material from REV using HKDF-SHA256.
    """

    assert len(rev) == 32

    # --- Context Tuple encoding ---
    info = struct.pack(">HBI", alg_id, domain, index)

    # --- HKDF Extract + Expand ---
    hkdf = HKDF(
        algorithm=hashes.SHA256(),
        length=length,
        salt=b"\x00" * 32,
        info=info,
    )

    derived_key = hkdf.derive(rev)
    return derived_key

C.1. Autonomous Digital Entities (ADEs)

Autonomous Digital Entities such as AI agents may require a stable cryptographic identity that can be deterministically reconstructed across restarts without persistent secret storage.¶

In such deployments: - The Sealed Artifact (SA) may be stored in local or remote storage. - Authorization Credentials may be supplied at runtime by a controller or policy engine. - Derived keys may be used for signing, authentication, or secure communication between agents.¶

C.2. IoT and Embedded Devices

IoT devices often operate under memory and storage constraints and may lack secure persistent storage for long-lived secrets.¶

ACE-GF allows: - Off-device provisioning of Sealed Artifacts. - On-device reconstruction of identity only when required. - Integration with Secure Elements or TEEs where available.¶

C.3. Blockchain and Cryptographic Wallet Identities

Cryptographic wallets may use ACE-GF to derive multiple algorithm- specific keys (e.g., Ed25519, secp256k1, PQC) from a single REV.¶

Stateless rekeying allows credential updates without changing public addresses, while identity unreachability provides a recovery and lockout mechanism without reliance on external revocation infrastructure such as CRLs.¶

D.1. Trust Boundaries

ACE-GF assumes a clear separation between: - Authorization inputs (Credentials, salts, policy-controlled inputs) - Identity material (REV and derived keys) - Persistent storage (Sealed Artifacts)¶

The compromise of persistent storage alone does not reveal the REV or derived keys.¶

D.2. Authorization Boundary

Authorization Credentials are assumed to be protected by the application or deployment environment. Weak credentials reduce the effective security of the Sealing Process but do not compromise the cryptographic soundness of the framework.¶

D.3. Execution Environment Assumptions

During unsealing and derivation, the execution environment is assumed to provide basic process isolation. Where stronger guarantees are required, hardware-backed isolation (e.g., TEEs) is RECOMMENDED.¶

D.4. Non-Goals

ACE-GF does not attempt to: - Protect against fully compromised execution environments. - Provide anonymity or unlinkability guarantees. - Replace application-level access control or policy enforcement.¶