[Cryptography] Review request: BIP39-native Shamir backup over GF(2053)

[Renato Schiavinato Lopez]

Hello,

I would like to *request review* of a draft applied-cryptography design:

*Schiavinato Sharing: BIP39-Native Threshold Backup over GF(2053) with Full
Manual Fallback*
https://github.com/GRIFORTIS/schiavinato-sharing

The goal is long-horizon cold-storage backup for existing BIP39 mnemonics
to maximize sovereignty. The construction instantiates standard Shamir
sharing directly over GF(2053), the smallest prime field containing the
2048 BIP39 word indices. The protected value for each word position is the
1-indexed BIP39 word index itself; there is no KDF, compression step,
custom share alphabet, or seed transform between the sharing arithmetic and
the recovered BIP39 mnemonic.

The intended use is human-first and software-assisted. Software should
normally handle arithmetic and guide setup/recovery. However, if the
original software stack is unavailable or untrusted, *recovery remains
specified from durable artifacts and modular arithmetic alone, using only
pen, paper, and a calculator*. In extreme cases, the sharing process can
also be performed manually.

The main design elements are:

- BIP39-native Shamir sharing over GF(2053).
- A linear consistency layer of row checksums, column checksums, and a
share-bound Global Integrity Check (GIC).
- A proof that this layer has minimum detection distance d = 4, so all 1-,
2-, and 3-cell passive errors are detected.
- Explicit separation between passive fault detection and active
substitution detection.
- Optional computational verification layers: transport hash,
mnemonic-bound Blinded Identity (BI), wallet-bound Recovery Verification
Address (RVA), and manifest audit hashes.
- An optional Reduced Mode for smaller QR/manual transcription burden, with
a bounded deviation from exact perfect secrecy.
- Support for recursive composition for advanced custody topologies,
treated as operationally complex rather than the baseline use case.

*I am specifically looking for review of:*





*1. The confidentiality claim for the unrestricted arithmetic share layer,
including the interaction with deterministic linear checksum fields.2. The
minimum-distance proof for the linear consistency layer.3. The Reduced Mode
leakage/bias bound and whether this mode should exist at all.4. The
substitution-detection framing, especially the distinction between
arithmetic consistency, manifest audit hashes, BI, and RVA.5. Any
operational threat-model gaps that would make this unsuitable even as a
backup format.*

Important limitations:

- The linear consistency layer is not authentication. An adversary who can
rewrite a share can recompute consistent linear checks.
- Pre-recovery substitution detection via manifest audit hashes depends on
an uncompromised, separately stored manifest.
- Fully manual recovery without RVA has weak substitution detection.
- Prototype implementations are experimental, unaudited, and may lag the
current v0.6.0 whitepaper/test vectors. *I am asking for review of the
design and analysis before treating the implementation work as mature*.
- This is not intended for active transaction authorization, MPC wallets,
or day-to-day custody operations.

Current artifacts:

Whitepaper:
https://github.com/GRIFORTIS/schiavinato-sharing/blob/main/whitepaper/WHITEPAPER.pdf

LaTeX:
https://github.com/GRIFORTIS/schiavinato-sharing/blob/main/whitepaper/WHITEPAPER.tex

Test vectors:
https://github.com/GRIFORTIS/schiavinato-sharing/tree/main/test_vectors

Review notes:
https://github.com/GRIFORTIS/schiavinato-sharing/blob/main/docs/review.md

I would be grateful for criticism, especially if there is a simpler way to
frame the construction, an error in the security argument, or a reason the
Reduced Mode or manifest model should be removed.

Best regards,

Renato Schiavinato Lopez
GRIFORTIS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20260512/a51405ac/attachment.htm>