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

[Renato Schiavinato Lopez]

> Following up on my post about Reduced Mode bias and lattice attacks: I
> had not quantified why the mode exists.
>
> Reduced Mode targets ceremonies where someone hand-copies a share QR
> onto a pre-printed template. Full Mode uses a 37×37 symbol, Reduced
> Mode 29×29. Naive area math says ~39% smaller; that is a weak proxy.
> Most cells are fixed (corner finders, timing, alignment, format
> strips) or stay white; the real cost is black modules in the payload
> region.
>
> For a representative 24-word share QR with structure pre-printed: Full
> ~530 black marks, Reduced ~305 — about 43% fewer. Grid area alone
> slightly understates that. Ballpark from reference encodings in the
> current paper, not a timed study; a later revision will expand the
> workload analysis.
>
> This does not answer the lattice question. If bias enables recovery
> from k-1 shares, drop Reduced Mode. If not, the trade-off is roughly
> ≤0.43 bits max bias (24-word topologies we emphasize) vs ~43% fewer
> marks per share.
>
> Feedback on both points is welcome.
> Renato


Hello everyone,

I would like to follow up on my previous posts regarding the "Reduced
Mode" bias and provide an update on a significant structural pivot in
the Schiavinato Sharing design, alongside a new direction for
software-assisted error correction.




1. Elimination of Reduced Mode (Mitigating Lattice Risks)

To eliminate any potential vulnerability to lattice-based attacks
(such as modeling the rejection-sampling bias as a Hidden Number
Problem), the Reduced Mode has been completely removed from the
specification.

Instead, to achieve the same operational goal -- fitting the share
payload tightly into a Version 3-L QR code (29x29) for easier
manual/hybrid transcription -- I have introduced the Compact Output
Profile.

In this profile:

   * Standard, unrestricted Shamir sharing over GF(2053) is preserved,
maintaining perfect information-theoretic secrecy.

   * The 3-byte space savings required to fit the V3-L QR payload
limits are achieved simply by truncating the Blinded Identity (BI)
metadata. While this introduces a higher probability of collisions
within the BI layer itself, the Recovery Verification Address (RVA)
still functions as the ultimate recovery verification method.

The security-versus-usability trade-off now shifts entirely to
non-critical identification metadata, leaving the core arithmetic tier
theoretically immune to distribution bias.

The previous lattice security question is therefore resolved by obsolescence.




2. A New Direction: Reed-Solomon over GF(2053) for Software Assisted Ceremonies

During recent informal review discussions, Prof. Jeroen van de Graaf
(UFMG) introduced me to the deeper nuances of Reed-Solomon codes. This
exchange triggered an idea to address a critical threat-model trap
that occurs when applying active error correction to human-transcribed
backups.

Schiavinato Sharing already features a passive, strict Linear
Consistency Layer (d = 4) structured as a two-dimensional
Single-Parity-Check Product Code. This interleaved block layout allows
for unequivocal 1-symbol syndrome localization and up to 3-symbol
error detection, yet it remains simple enough to be built and
validated by hand, requiring no software assistance.

However, I am now designing an optional digital-only Reed-Solomon
layer to be appended to the end of the global share payload (covering
both the shared mnemonic indices and the internal checksums).

Since the architecture's native alphabet operates over the prime field
GF(2053), the goal is to build this systematic RS(n, k) block directly
over GF(2053). This would allow an automatic reconstruction of up to 4
corrupted or unreadable words from a damaged artifact. A subsequent
verification pass would then check the corrected output against the
original linear layer to eliminate miscorrection risks.




3. Request for Review & Matrix Structure

I would highly value the community's insights on this specific addition:

a) What are your thoughts on running systematic Reed-Solomon codes
over a larger, non-power-of-two prime field like GF(2053) for
localized Mnemonic fault tolerance?

b) To keep the core data intact, the code must be systematic. How
would you approach designing or optimizing the generator matrix, using
a systematic Vandermonde approach specifically over a prime field like
GF(2053) to ensure optimal distance bounds?




The updated draft, test vectors, and implementation path will reflect
these changes in version 0.7.0.

Best regards,