A Public-Key Cryptosystem from Interleaved Goppa Codes

In this paper, a code-based public-key cryptosystem based on interleaved Goppa codes is presented. The scheme is based on encrypting several ciphertexts with the same Goppa code and adding a burst error to them. Possible attacks are outlined and the key size of several choices of parameters is compared to those of known schemes for the same security level. For example, for security level 128 bits, we obtain a key size of 696 Kbits whereas the classical McEliece scheme based on Goppa codes using list decoding requires a key size of 1935 Kbits.

💡 Research Summary

The paper proposes a new variant of the McEliece public‑key cryptosystem that retains the well‑studied binary and non‑binary Goppa codes but dramatically reduces the public‑key size by employing interleaved coding. An s‑interleaved Goppa code IΓ(L,g,s) consists of s parallel codewords of the same underlying Goppa code Γ(L,g). During encryption, the sender encodes s independent messages, each of length k, into s Goppa codewords of length n, then adds a single burst error that affects the same t = ⌊s·r/(s+1)⌋ positions in all s codewords. The error matrix E_t is chosen to be full‑rank and to contain only non‑zero field elements, which both improves decoding reliability and hampers information‑set attacks.

Key generation follows the classic McEliece recipe: a random non‑singular scrambler matrix S, a generator matrix G of the chosen Goppa code, and a random permutation matrix P are generated, and the public matrix is G_pub = S·G·P. The public key also includes the parameters t_IRS (the burst‑error weight) and the interleaving order s. The private key consists of (S, P) and a decoder D capable of correcting up to t_IRS errors in the s‑interleaved code.

Decryption proceeds by undoing the permutation, applying the interleaved decoder (typically the syndrome‑based algorithm of Nielsen, Schmidt, and Zeh, or any of the high‑probability decoders cited in the paper), and finally removing the scrambler S. The authors prove that if the interleaving order is set to s = t_IRS = r − 1 (where r is the degree of the Goppa polynomial), then the syndrome matrix used in decoding always has full rank, guaranteeing unique decoding with probability 1. Consequently, no decryption failures occur under this parameter choice.

Security analysis identifies two main attack vectors. First, the Metzner‑Kaptowski decoding attack: when s ≥ t_IRS and the error matrix is full‑rank, an adversary can compute a parity‑check matrix H_pub for the public code, multiply it by the received ciphertext matrix, and solve a simple linear system via Gaussian elimination to recover all plaintexts. Therefore, the scheme must enforce s < t_IRS. Second, classical information‑set decoding (ISD) and ball‑collision attacks apply unchanged because the burst error still has weight t_IRS; the interleaved structure does not increase the combinatorial difficulty of finding an error‑free information set. The authors estimate the work factor for ISD as O(n³ p^{m(t_IRS−s)}), which remains large provided s is sufficiently smaller than t_IRS.

Parameter selection is guided by these security considerations. For a 128‑bit security level the authors propose n = 1024, r = 50, s = 24, yielding t_IRS = 24. The resulting public key size is 696 Kbits, compared with roughly 1 935 Kbits for the classic Goppa‑McEliece scheme using list decoding. For 192‑bit and 256‑bit security, the key sizes are 1 210 Kbits and 1 938 Kbits respectively, still substantially smaller than the corresponding non‑interleaved constructions.

The paper concludes that interleaved Goppa codes provide a practical path to smaller keys without sacrificing the structural resistance that makes Goppa codes the most trusted class for code‑based cryptography. However, careful balancing of the interleaving order and burst‑error weight is essential: too large an s opens the system to the Metzner‑Kaptowski attack, while too small an s may increase decryption failure probability or reduce the decoding radius. Future work is suggested on tighter security reductions for the regime s < t_IRS, on optimizing the decoder to further lower failure probability, and on implementation aspects such as side‑channel resistance.