MGM Mode

1 Seal and open

The defaults are the key and nonce of RFC 9058's own first example. Seal, then play the receiver: change one bit of the ciphertext, the associated data or the tag and verify. MGM checks the tag before it decrypts anything, so a rejected message releases no plaintext at all.

2 One H, or one H per block

GCM authenticates with a single hash subkey H = E_K(0); its tag is a polynomial in that one H, so block i of m is weighted by H^m−i+1. MGM instead runs a second counter: Z₁ = E_K(1 ‖ ICN), stepped in its left half, and weights block i by H_i = E_K(Z_i). The weighted blocks are xored together and the sum is encrypted once more to give the tag.

The GCM column is computed with the same cipher and the same field as MGM, to show the structure side by side. It is not AES-GCM, which uses 128-bit AES and a bit-reflected field convention.

3 Check every value against RFC 9058

RFC 9058 Appendix A prints not just inputs and tags but every intermediate value. This runs the implementation on an example and sets each computed value beside the one the RFC prints.

4 Repeat the nonce

The encryption counter depends only on the key and the ICN. Encrypt two messages under the same ICN and they share a keystream, so xoring the ciphertexts cancels it.

What MGM does not give you: confidentiality for two messages that share an ICN under one key. Both still decrypt and verify; MGM has no check that fails here, because nothing it checks is wrong.

Receiver's verdicts

;

C1 ⊕ C2 (what an eavesdropper computes)

P1 ⊕ P2

C1 ⊕ C2 ⊕ P1 (message 2, read without the key)

Not shown, because it is not demonstrated here: a forged tag. GCM's nonce reuse hands an attacker H; MGM encrypts its sum before output, and this lab claims no forgery against it.

5 64 bits versus 128

RFC 9058 section 6 bounds an attacker's advantage against MGM's confidentiality by 3(s + 4q)² / 2ⁿ for s blocks in q messages under one key. The formula is the same for both ciphers; only n changes, and it sits in the exponent.

Magma (n = 64)

Kuznyechik (n = 128)

Real deployments act on this. RFC 9367's GOST cipher suites for TLS 1.3 change the record key inside a connection (TLSTREE): the key for record seqnum depends on seqnum & C₃, so one key lasts 2^{(trailing zero bits of C₃)} records. Computed from the RFC's constants:

The 64-bit birthday problem on its own, with a live collision search, is Feistel Forge's Sweet32 exhibit.

6 Magma's S-box: a choice the old standard left open

Magma is GOST 28147-89 with its loose ends tied. The 1989 standard defined the network but no S-boxes: RFC 5830 says plainly that "the standard doesn't define any S-boxes", and the tables were issued as secret parameters "in accordance with the established procedure". So "GOST" named a family of ciphers, one per table. GOST R 34.12-2015 fixed one table, id-tc26-gost-28147-param-Z, and also fixed the byte order (RFC 8891 Appendix B).

RFC 8891 A.4: Magma(fedcba9876543210)

Same key, same block, swapped table

—

The swapped table is a hypothetical made for this exhibit, not one of the historical parameter sets, and the variant is not a validated GOST 28147-89 implementation (that standard also reads keys and data little-endian).