<div dir="auto"><div style="padding:0px 16px;background-color:rgb(4,10,47)" dir="auto">Hi!<br><div style="font-size:12.8px;height:90px">As the Baochip-x1 has the hardware to do a lot of cryptographic functions like <span style="font-size:large">active zeroisation, </span><span style="font-size:large">Ed25519 signed boot, </span><span style="font-size:large">Glitch sensors, security mesh, PV sensor, ECC-protected RAM,</span><span style="font-size:large">Algorithm-agnostic engine etc I think that these could be added to standards.  </span></div><div style="font-size:12.8px;height:90px" dir="auto"><span style="font-size:large">.</span></div><div style="font-size:12.8px;height:90px" dir="auto">I suggest:</div><div style="font-size:12.8px;width:363.429px;padding:8px 0px 0px"><div><div dir="ltr"># Authenticated Ephemeral ECDH Session Protocol and Cipher Profile Encoding<br>## Abstract<br><br>This document specifies a **binary authenticated ephemeral ECDH handshake** (InitMessage and ResponseMessage), **HKDF-SHA256** key derivation with fixed UTF-8 labels, and a **compact binary encoding** for **named cipher profiles** (ECDHE curve, ordered AEAD layers, Shamir threshold metadata). The handshake provides **forward secrecy** for session keys: long-term keys authenticate ephemeral keys; ECDH uses ephemeral key pairs only. The format is intended for submission to the OpenPGP working group as an extension compatible in spirit with [RFC 9580](<a href="https://www.rfc-editor.org/rfc/rfc9580" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9580</a>) algorithm and notation registries, without reusing OpenPGP packet syntax for the handshake octets themselves.<br><br>---<br><br>## 1. Introduction<br><br>OpenPGP ([RFC 9580](<a href="https://www.rfc-editor.org/rfc/rfc9580" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9580</a>)) specifies message formats, public-key encryption, signatures, and AEAD payloads. It does **not** define a standalone **ephemeral-ephemeral ECDH** session establishment with **mutual** authentication of ephemeral keys via **long-term** Brainpool signing keys. This document fills that gap for toolchains that require **forward secrecy** at the session layer while binding identity to existing long-term OpenPGP-compatible key material (fingerprint binding).<br><br>**Cipher profiles** name a policy: **ECDHE curve**, **ordered list of symmetric AEAD layers** (encrypt order; decrypt reverse), and **Shamir (k, n)** metadata for long-term key handling. Profiles serialise to a **deterministic octet string** for storage and negotiation.<br><br>This specification is written for **interoperability** among independent implementations that adopt the same octet layouts and labels.<br><br>---<br><br>## 2. Terminology<br><br>The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** are to be interpreted as described in BCP 14 ([RFC 2119](<a href="https://www.rfc-editor.org/rfc/rfc2119" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc2119</a>)) ([RFC 8174](<a href="https://www.rfc-editor.org/rfc/rfc8174" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc8174</a>)) when, and only when, they appear in all capitals, as shown here.<br><br>**Initiator:** The party that sends `InitMessage`.  <br>**Responder:** The party that sends `ResponseMessage`.  <br>**Long-term fingerprint:** SHA-256 digest (32 octets) over the uncompressed SEC1 encoding of the long-term **verifying** public key, represented on the wire as 64 ASCII hexadecimal digits.<br><br>---<br><br>## 3. Conventions<br><br>- All multi-octet integers are **big-endian** unless stated otherwise.  <br>- **Curve public keys** are **uncompressed SEC1** points ([SEC 1](<a href="https://www.secg.org/sec1-v2.pdf%29" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.secg.org/sec1-v2.pdf)</a>).  <br>- **ECDSA** signatures on the wire are **DER**-encoded ([RFC 5480](<a href="https://www.rfc-editor.org/rfc/rfc5480%29-style" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc5480)-style</a> ECDSA-Sig-Value).  <br>- **HKDF** follows [RFC 5869](<a href="https://www.rfc-editor.org/rfc/rfc5869" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc5869</a>) with **HMAC-SHA256**.<br><br>---<br><br>## 4. Protocol and encodings<br><br>### 4.1 Protocol version<br><br>Implementations MUST support protocol version byte `0x01` for both `InitMessage` and `ResponseMessage`. Parsers MUST reject other version values unless a later specification defines them.<br><br>### 4.2 Curve identifiers (`curve_id`)<br><br>| `curve_id` | Curve | SEC1 uncompressed length (octets) |<br>|------------|--------|-----------------------------------|<br>| `0x01` | brainpoolP256r1 [RFC 5639](<a href="https://www.rfc-editor.org/rfc/rfc5639" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc5639</a>) | 65 |<br>| `0x02` | brainpoolP384r1 | 97 |<br>| `0x03` | brainpoolP512r1 | 129 |<br><br>Senders MUST set `curve_id` to one of these values. Receivers MUST verify that the ephemeral public key length field matches this table for the received `curve_id`.<br><br>### 4.3 InitMessage (normative layout)<br><br>Serialisation order (concatenation):<br><br>| Field | Size | Description |<br>|-------|------|-------------|<br>| `version` | 1 | MUST be `0x01`. |<br>| `curve_id` | 1 | As in Section 4.2. |<br>| `epk_len` | 1 | Length of initiator ephemeral public key; MUST equal SEC1 length for `curve_id`. |<br>| `epk` | `epk_len` | Uncompressed SEC1 initiator ephemeral public key. |<br>| `fp_len` | 1 | Length of fingerprint field; MUST be `64` when fingerprint is hex-encoded SHA-256. |<br>| `fingerprint` | `fp_len` | 64 ASCII hex digits (`0-9`, `a-f` preferred; parsers MUST accept `A-F`). |<br>| `sig_len` | 2 | Big-endian; length of DER signature. |<br>| `signature` | `sig_len` | ECDSA-SHA256 over initiator **preimage** (Section 4.5). |<br><br>The total serialised size MUST NOT exceed **512** octets.<br><br>### 4.4 ResponseMessage (normative layout)<br><br>Fields 1–8 are identical in structure to InitMessage for `version`, `curve_id`, responder `epk_len`, responder `epk`, `fp_len`, responder long-term `fingerprint`, and `sig_len` / `signature` for the **responder** preimage. Additional fields:<br><br>| Field | Size | Description |<br>|-------|------|-------------|<br>| (same as Init through responder signature) | | |<br>| `iepk_len` | 1 | MUST equal initiator ephemeral length for `curve_id`. |<br>| `initiator_epk_copy` | `iepk_len` | **Copy** of initiator ephemeral public key from InitMessage. |<br>| `sig_len_r` | 2 | Big-endian; length of responder DER signature. |<br>| `signature_r` | `sig_len_r` | ECDSA-SHA256 over responder **preimage** (Section 4.5). |<br><br>The initiator MUST compare `initiator_epk_copy` to its own sent ephemeral key using a **constant-time** equality check.<br><br>### 4.5 Signature preimages (ECDSA-SHA256)<br><br>Hash input is **raw concatenation** (no length prefixes except where lengths are fixed by `curve_id`):<br><br>- **Initiator preimage:** `version || curve_id || initiator_ephemeral_sec1_uncompressed`  <br>- **Responder preimage:** `version || curve_id || responder_ephemeral_sec1 || initiator_ephemeral_sec1`<br><br>The hash function is **SHA-256**; ECDSA is Brainpool with the long-term signing key associated with the fingerprint.<br><br>### 4.6 ECDH shared secret and HKDF<br><br>1. **ECDH** is performed on the agreed curve; the shared secret is the **x**-coordinate of the resulting point, packed to a fixed width per curve; **interoperating peers MUST use identical packing** (see Appendix A for conformance vectors).  <br>2. **HKDF-Extract** salt: lexicographic ordering of the two ephemeral public key byte strings: if `epk_initiator <= epk_responder` (lexicographic octet compare), salt = `epk_initiator || epk_responder`; else salt = `epk_responder || epk_initiator`. If the salt is empty in a helper, implementations MUST use 32 zero octets as HMAC key per [RFC 5869](<a href="https://www.rfc-editor.org/rfc/rfc5869" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc5869</a>) empty-salt handling where applicable.  <br>3. **HKDF-Expand** with **SHA-256**; output length **32** octets per derived key unless a profile specifies otherwise.<br><br>**HKDF `info` labels (UTF-8, exact octets):**<br><br>| Label (exact) | Derived key role |<br>|---------------|------------------|<br>| `openpgp-ephemeral-session/payload-i2r/v1` | Payload AEAD, initiator to responder |<br>| `openpgp-ephemeral-session/payload-r2i/v1` | Payload AEAD, responder to initiator |<br>| `openpgp-ephemeral-session/gdss-mask/v1` | Optional GDSS masking stream |<br>| `openpgp-ephemeral-session/gdss-sync/v1` | Optional GDSS sync |<br>| `openpgp-ephemeral-session/gdss-timing/v1` | Optional GDSS timing |<br>| `openpgp-ephemeral-session/mac/v1` | Optional HMAC key |<br><br>Implementations MUST NOT reuse labels for distinct key roles. Changing any label octet breaks interoperability.<br><br>### 4.7 Cipher profile compact encoding<br><br>A **cipher profile** serialises as:<br><br>| Field | Size | Description |<br>|-------|------|-------------|<br>| `name_len` | 1 | Length of `name`; MUST be ≤ 64. |<br>| `name` | `name_len` | UTF-8 profile identifier (e.g. `standard`, `conservative-shamir`). |<br>| `desc_len` | 1 | Length of description; MUST be ≤ 128. |<br>| `description` | `desc_len` | UTF-8 human-readable text. |<br>| `curve_id` | 1 | Same as Section 4.2 (ECDHE curve for session). |<br>| `layer_count` | 1 | Number of AEAD layers; MUST be 1–4. |<br>| `layer_id` × `layer_count` | each 1 | Symmetric layer type (see below). |<br>| `shamir_k` | 1 | Shamir threshold **k** (1–255). |<br>| `shamir_n` | 1 | Shamir total **n** (1–255); MUST satisfy `k ≤ n`. |<br><br>**Layer type IDs (`layer_id`):**<br><br>| `layer_id` | Algorithm |<br>|------------|-----------|<br>| `0x01` | AES-256-GCM |<br>| `0x02` | ChaCha20-Poly1305 [RFC 8439](<a href="https://www.rfc-editor.org/rfc/rfc8439" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc8439</a>) |<br>| `0x03` | Twofish-256 (EtM construction as in implementation) |<br>| `0x04` | Serpent-256 (EtM construction as in implementation) |<br><br>**Encryption order:** layers are applied **in array order** (first layer = innermost plaintext); **decryption** applies **reverse** order. **Authentication** MUST be verified at each layer; failure MUST abort decryption.<br><br>---<br><br>## 5. Security Considerations<br><br>**Threat model:** The handshake aims for **confidentiality** and **integrity** of session keys against passive and active network attackers, under the assumption that long-term signing keys remain uncompromised during the handshake. **Forward secrecy** holds for past sessions if ephemeral private keys are destroyed after use.<br><br>**Limitations:**<br><br>- This document does **not** specify transport binding to TLS or OpenPGP; bindings are application-defined.  <br>- **Side-channel** resistance of ECDH and ECDSA depends on the cryptographic library and hardware.  <br>- **Downgrade** of `curve_id` or profile MUST be prevented by policy at a higher layer if multiple options are offered.  <br>- **GDSS** optional keys are product-specific; implementations MAY omit derivation of those labels.<br><br>**Guidance:** Implementations SHOULD use constant-time comparison for `initiator_epk_copy`. Implementations MUST zeroise ephemeral private keys after ECDH.<br><br>---<br><br>## 6. IANA Considerations<br><br>This document requests IANA to create or extend registries under the **OpenPGP** umbrella (exact registry names subject to IESG and IANA review):<br><br>| Registry | Request |<br>|----------|---------|<br>| **Ephemeral ECDH extension `curve_id`** (or sub-registry of Experimental / Private Use) | Reserve `0x01`–`0x03` as in Section 4.2; future values via IETF Review or Specification Required. |<br>| **Cipher profile `layer_id`** | Reserve `0x01`–`0x04` as in Section 4.7. |<br>| **HKDF info labels** | Register the six UTF-8 strings in Section 4.6 as **well-known** `info` labels for this protocol (reference: this document). |<br>| **Notation names** (optional OpenPGP binding) | Register `<a href="mailto:openpgp-cipher-profile@ietf.org" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">openpgp-cipher-profile@ietf.org</a>` (example) for embedding profile fingerprints in signature notations if WG desires OpenPGP message binding. |<br><br>Until IANA assigns numbers, private experimentation MAY use implementation-defined prefixes with **no** guarantee of global uniqueness.<br><br>---<br><br>## 7. References<br><br>### 7.1 Normative References<br><br>| ID | Reference |<br>|----|-----------|<br>| RFC2119 | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |<br>| RFC5639 | Lochter, M. and Merkle, J., "Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation", RFC 5639, March 2010. |<br>| RFC5869 | Krawczyk, H. and Eronen, P., "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010. |<br>| RFC8174 | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. |<br>| RFC8439 | Nir, Y. and Langley, A., "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, June 2018. |<br>| SEC1 | SECG, "Elliptic Curve Cryptography", SEC 1, Version 2.0. |<br><br>### 7.2 Informative References<br><br>| ID | Reference |<br>|----|-----------|<br>| RFC9580 | Wussler, S., et al., "OpenPGP", RFC 9580, July 2024. |<br><br>---<br><br>## Appendix A. Interoperability test anchors<br><br>Implementations MUST demonstrate interoperability using **fixed test vectors** (to be published in a future revision of this document or a companion **Implementation Techniques** note). Until those vectors are published, conformance tests SHOULD cover:<br><br>- Handshake serialisation round-trip for `InitMessage` and `ResponseMessage` per Sections 4.3–4.4.  <br>- HKDF label distinctness (no two roles share the same `info` string).  <br>- Brainpool ECDH and ECDSA with [RFC 5639](<a href="https://www.rfc-editor.org/rfc/rfc5639" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc5639</a>) test vectors where applicable.  <br>- Side-channel review of comparison and scalar paths (implementation-dependent).<br><br><br><br># Shamir Secret Sharing for OpenPGP-Adjacent Key Material: Share Format and Field Arithmetic<br>## Abstract<br><br>This document specifies **Shamir’s Secret Sharing** over **GF(256)** for secrets of **16 to 64 octets**, including **share index** and **share value** layout, **K-of-N** metadata, a **textual armour** format (**OPENPGP SHAMIR SHARE**), and **HKDF** labelling for post-recovery key derivation. It is intended for interoperability with hardware tokens and host tools that split or recover OpenPGP-relevant signing material. The format complements [RFC 9580](<a href="https://www.rfc-editor.org/rfc/rfc9580" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9580</a>) OpenPGP messages by defining a **container** for shares that MAY be transported inside experimental packets or as standalone files.<br><br>---<br><br>## 1. Introduction<br><br>Shamir’s method (1979) splits a secret into **N** shares such that any **K** shares suffice for reconstruction. This document **normatively** defines the **field**, **byte-wise sharing** construction, **wire formats**, and **armour** using **GF(256)** arithmetic compatible with the **AES** field (see `vsss_rs::Gf256` or equivalent **bit-identical** implementation).<br><br>OpenPGP ([RFC 9580](<a href="https://www.rfc-editor.org/rfc/rfc9580" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9580</a>)) does not define threshold splits of long-term private key material. This specification provides a **concrete** format implementors can adopt pending WG adoption of OpenPGP-native packet types.<br><br>---<br><br>## 2. Terminology<br><br>The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** are to be interpreted as described in BCP 14 ([RFC 2119](<a href="https://www.rfc-editor.org/rfc/rfc2119" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc2119</a>)) ([RFC 8174](<a href="https://www.rfc-editor.org/rfc/rfc8174" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc8174</a>)) when, and only when, they appear in all capitals.<br><br>**K:** Threshold number of shares required to reconstruct.  <br>**N:** Total number of shares generated.  <br>**Share index:** Non-zero octet in `1..=255` identifying the polynomial evaluation point.<br><br>---<br><br>## 3. Conventions<br><br>- **Field:** GF(256) with the **same** reduction polynomial as the AES block field; implementations MUST produce **bit-identical** results to a **reference** `vsss_rs::Gf256` (or equivalent) definition across all split and recover operations.  <br>- **Secret length:** `L` octets where **16 ≤ L ≤ 64**. All shares for one split MUST use the same `L`.  <br>- **Threshold:** Integers **K** and **N** MUST satisfy **1 ≤ K ≤ N ≤ 255**.<br><br>---<br><br>## 4. Mathematical construction (normative)<br><br>For each byte position **j** in `0..L` independently:<br><br>1. Let **s[j]** be the secret byte at position **j** (treated as an element of GF(256)).  <br>2. Construct a polynomial **P** of degree **K − 1** with coefficients in GF(256): the constant term is **s[j]**; coefficients **1..K−1** MUST be sampled uniformly at random using a cryptographically secure RNG.  <br>3. For share index **i** (1 ≤ **i** ≤ **N**), the share byte at position **j** is **P(i)** evaluated in GF(256) with **i** mapped to the field element **i**.<br><br>**Recovery:** Given **K** distinct shares with indices **i_1…i_K** and matching value vectors, the secret byte **s[j]** is **P(0)** computed via Lagrange interpolation in GF(256).<br><br>Implementations MUST reject duplicate share indices during recovery. Implementations MUST NOT infer **K** solely from the number of shares without explicit parameter matching.<br><br>---<br><br>## 5. Binary share payload (normative minimum)<br><br>A **share value** in memory or binary transport is:<br><br>| Field | Size (octets) | Description |<br>|-------|----------------|-------------|<br>| `index` | 1 | Share index **i**, MUST be in `1..=255`. |<br>| `value` | `L` | **16 ≤ L ≤ 64**; polynomial evaluation bytes aligned with Section 4. |<br><br>The tuple `(index, value)` together with known **K**, **N**, and secret length **L** are REQUIRED for recovery.<br><br>---<br><br>## 6. OPENPGP SHAMIR SHARE armour (normative text format)<br><br>Armour is **ASCII** and MUST use the following structure:<br><br>1. Line: `-----BEGIN OPENPGP SHAMIR SHARE-----`  <br>2. Line: `Version: 1`  <br>3. Line: `Profile: ` + UTF-8 profile name (policy label).  <br>4. Line: `Threshold: ` + decimal **K**.  <br>5. Line: `Total: ` + decimal **N**.  <br>6. Line: `Index: ` + decimal share index **i**.  <br>7. Line: `Fingerprint: ` + hexadecimal fingerprint of associated long-term key (implementation-defined encoding).  <br>8. Line: `Created: ` + RFC 3339 timestamp.  <br>9. Empty line.  <br>10. Base64 ([RFC 4648](<a href="https://www.rfc-editor.org/rfc/rfc4648" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc4648</a>)) body encoding **only** the **`value`** octets (not the index).  <br>11. Line: `-----END OPENPGP SHAMIR SHARE-----`<br><br>Parsers MUST verify Base64 and length constraints. The **index** in the header MUST match the share; implementations MUST treat mismatch as fatal.<br><br>**Note:** The index appears in the header; the **value** is Base64-only. Implementations MAY alternatively encode `index || value` in Base64 in a future version—**Version: 1** as specified ties index to header fields.<br><br>---<br><br>## 7. HKDF after recovery<br><br>When expanding recovered material into operational keys, implementations **MUST** use [RFC 5869](<a href="https://www.rfc-editor.org/rfc/rfc5869" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc5869</a>) with **SHA-512** and `info` exactly:<br><br>`openpgp-shamir/vault-recovery/v1` (UTF-8 octets)<br><br>This label MUST NOT be reused for unrelated derivations.<br><br>---<br><br>## 8. Mapping to OpenPGP (informative operations)<br><br>Implementations MAY:<br><br>- Wrap armour in a **MIME** part or **file** attachment.  <br>- Place a **notation** on a signature: e.g. name `shamir-share-digest@openpgp.example` with a SHA-256 digest of the armour body (policy-specific).  <br>- Encapsulate binary payloads in **Private/Experimental** OpenPGP packets ([RFC 9580](<a href="https://www.rfc-editor.org/rfc/rfc9580" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9580</a>) private packet conventions) once IANA assigns packet tags (Section 10).<br><br>This document **does not** require OpenPGP implementations to parse shares inside literal data packets; it defines the **share format** independent of OpenPGP framing.<br><br>---<br><br>## 9. Security Considerations<br><br>**Threat model:** Shares protect against single-point loss of the full secret only if **K** shares are required and **custody** is separated. An attacker with **K** shares reconstructs the secret.<br><br>**Limitations:**<br><br>- **GF(256)** Shamir is **not** post-quantum for the share reconstruction math; long-term risk is the same class as symmetric key recovery.  <br>- **RNG** quality for polynomial coefficients MUST be CSPRNG-backed.  <br>- **Armour** is **not encrypted**; implementations SHOULD encrypt shares at rest (e.g. OpenPGP-encrypted file) when distributed.  <br>- **Fingerprint** binding does not prevent substitution unless the fingerprint is verified out-of-band.<br><br>**Guidance:** Implementations MUST zeroise recovered secrets after use. Implementations SHOULD use **constant-time** comparison where comparing share metadata to secrets.<br><br>---<br><br>## 10. IANA Considerations<br><br>This document requests:<br><br>| Item | Action |<br>|------|--------|<br>| **OpenPGP Packet Tag** | Assign an **Experimental** or **Private** packet tag for **OPENPGP-SHAMIR-SHARE** binary blob (optional encapsulation of Sections 5–6), or reserve from private-use range per [RFC 9580](<a href="https://www.rfc-editor.org/rfc/rfc9580" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9580</a>) IANA procedures. |<br>| **Notation name** | Register `<a href="mailto:openpgp-shamir-share-v1@ietf.org" style="text-decoration-line:none;color:rgb(168,199,250)" rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">openpgp-shamir-share-v1@ietf.org</a>` (example) for signature notations pointing to external share custody. |<br>| **HKDF info registry** | Register `openpgp-shamir/vault-recovery/v1` as a well-known `info` label for Shamir recovery KDF. |<br>| **Media type** (optional) | `application/vnd.openpgp.shamir-share` for armour files. |<br><br>Exact numbers are **TBD** pending IESG and IANA review.<br><br>---<br><br>## 11. References<br><br>### 11.1 Normative References<br><br>| ID | Reference |<br>|----|-----------|<br>| RFC2119 | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119. |<br>| RFC4648 | Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648. |<br>| RFC5869 | Krawczyk, H. and Eronen, P., "HKDF", RFC 5869. |<br>| RFC8174 | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174. |<br>| SHAMIR79 | Shamir, A., "How to share a secret", Communications of the ACM, 1979. |<br><br>### 11.2 Informative References<br><br>| ID | Reference |<br>|----|-----------|<br>| RFC9580 | "OpenPGP", RFC 9580. |<br><br>---<br><br>## Appendix A. Interoperability test anchors<br><br>Implementations MUST validate split/recover using **published test vectors** (to be added in a future revision). Conformance tests SHOULD include:<br><br>- Round-trip split and recover for fixed K, N, L.  <br>- Rejection of duplicate `index` values.  <br>- Boundary checks for L in {16, 64}.  <br>- **Fuzz** and timing-hardening (implementation-dependent).<br><br>---<br><br>## Document history<br><br>| Version | Notes |<br>|---------|--------|<br>| 00 | Initial proposal: GF(256) Shamir, binary share payload, OPENPGP SHAMIR SHARE armour Version 1. |</div></div></div><div style="font-size:12.8px;height:16px"></div></div><div style="font-size:12.8px;padding:0px 16px;background-color:rgb(4,10,47)" dir="auto"><div style="height:184px">The baochips specs can be found here: <a href="https://www.baochip.com/" target="_blank" rel="noreferrer">https://www.baochip.com/</a>   Or here: <a href="https://github.com/Supermagnum/Baochip-1x-firmware">https://github.com/Supermagnum/Baochip-1x-firmware</a></div><div style="height:184px" dir="auto"><br></div><div style="height:184px" dir="auto"><br></div><div style="height:184px" dir="auto"><br></div><div style="width:363.429px;padding:8px 0px 0px"><div><br></div></div></div></div>