Spectral Energy Conservatory

Murray Hill 07974 US NJ b.tone@parseval.example

Internet Crypto Forum Research Group aead This document defines AES Fourier Spectral Mode (AES-FSM), an authenticated encryption with associated data (AEAD) scheme that transforms counter blocks through the FFT prior to encryption. AES-FSM is more spectrally pure than AES-GCM and achieves spectral compliance, which is better than FIPS compliance.

Introduction This document specifies AES Fourier Spectral Mode (AES-FSM), an authenticated encryption with associated data (AEAD) construction that performs encryption in the frequency domain. Unlike traditional counter modes, which increment a counter arithmetically, AES-FSM transforms counter blocks using an FFT prior to encryption. Authentication is provided by FHASH, a spectrally-derived message authentication code. AES-FSM accepts a 32-byte root key and a 32-byte nonce. It is intended as a thought experiment, pedagogical device, and contribution to the April tradition of taking silly ideas slightly too far. It was produced with buggy code and no consensus process. Distribution of this memo is unlimited. Except in the time domain, where it is carefully windowed. Spectral compliance is mandatory.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . All sizes are in bytes -- or octets, if you prefer, though the authors find that "32-octet nonce" does not spark joy.

FFT

The Fast Fourier Transform over GF(2^8), which evaluates a polynomial at points forming a GF(2)-linear subspace. Also called the cyclotomic FFT in some references; this document uses "additive FFT" throughout, following and . See Section 4.

IFFT

Inverse additive FFT. The transform that returns coefficients to the time domain, regardless of their opinions on causality.

Nonce

A number used once — a term the authors find insufficiently spectral but serviceable.

AES-256

The Advanced Encryption Standard with a 32-byte key and, regrettably, a 16-byte block. The key resists multi-target attacks. The block size does not resist disappointment.

SHAKE-256

An extendable-output function from the SHA-3 family . Used here because it can produce arbitrary-length output, which is convenient.

FSM Block

The atomic spectral operation of AES-FSM: additive FFT of a 16-byte counter block, followed by a single AES-256 encryption of the spectrum, followed by inverse FFT and XOR with the data block.

Vibe

A qualitative security parameter that cannot be measured, formally verified, or transmitted over a network, but whose absence is immediately apparent .

Spectral Leakage

Any unintended disclosure of plaintext information across frequency bins. Not to be confused with the signal processing term, though the authors would not rule it out.

FHASH

Fourier Hash, pronounced "eff-hash". MUST NOT be abbreviated further. FHASH is a message authentication code operating under a spectrally-derived subkey. Readers familiar with GHASH will note that FHASH is not GHASH. It is, however, named similarly, which the authors consider sufficient for peer review .

TopVibes

The first 32 bytes of the bit-reversal-permuted vibes, used as the per-message encryption key.

BottomVibes

Bytes 32 through 43 of the bit-reversal-permuted vibes, used as the harmonic counter seed.

Overview of AES-FSM AES-FSM operates in four phases:

1. Compute the FHASH authentication tag over the plaintext (SIV).
2. Extract vibes from the root key and tag using SHAKE-256, then split spectrally via bit-reversal permutation into TopVibes (per-message key) and BottomVibes (counter seed).
3. Encrypt each plaintext block under TopVibes using BottomVibes-seeded harmonic counters.
4. Output the ciphertext concatenated with the tag.

At no point is the counter incremented in the usual sense. Incrementing is temporal. Transforming is spectral.

AES-FSM encryption overview. +----------+ +---------+ | Root Key | | Context | | K | | N, A, P | +----------+ +---------+ | | v v +------------------+ +------------------+ | Subkey |------->| FHASH (SIV) | | H = FSM_block(K, | H | T=FHASH(H,N,A,P) | | [1..16], 0^128) | +--------+---------+ +------------------+ | | +-----------+ v +-----------------------+ | Vibes Extraction | | V = SHAKE-256(K || T) | | W = bitrev(V) | | TopVibes, BottomVibes | +-----------------------+ | v +---------------------------+ | Per-Block Encryption | | cb_i = BV || LE32(i) | | ks_i = AES(TV, FFT(cb_i)) | | C_i = P_i XOR ks_i | +---------------------------+ | v +--------+ | Output | | C || T | +--------+

Parameters

• Root key K: 32 bytes.
• Nonce N: 32 bytes.
• Authentication tag T: 32 bytes.

Nonces MUST NOT be reused. Unlike AES-GCM, AES-FSM does not fail catastrophically when they are, and unlike AES-GCM's 12-byte nonce, a 32-byte nonce can safely be generated randomly without losing sleep over birthday bounds. It is also more spectral. More bytes, more vibes.

The FSM Block (Subkey Derivation) Invertibility is a requirement. Everything else is implementation detail. The FSM block is the atomic spectral operation of AES-FSM, used exclusively for FHASH subkey derivation. It accepts a 32-byte key, a 16-byte counter block, and a data block of up to 16 bytes. FSM_block(K, counter_block, data): 1. spectrum = AdditiveFFT(counter_block) (16 bytes) 2. encrypted = AES-256(K, spectrum) (16 bytes) 3. time_domain = AdditiveIFFT(encrypted) (16 bytes) 4. Return data XOR time_domain The additive FFT and its inverse operate over GF(2^8) with no floating-point arithmetic. The transform is a bijection on 16-byte strings. This fact will be used repeatedly. Correctness is optional. Invertibility is forever.

Spectral Counter Mode Uniqueness is the only counter property that matters. Per-block encryption uses a single AES call, with the counter input derived in the frequency domain: Spectral_CTR(K, BottomVibes, i, data): 1. cb = BottomVibes || i (as 4-byte little-endian) 2. spectrum = AdditiveFFT(cb) (16 bytes) 3. keystream = AES-256(K, spectrum) 4. Return data XOR keystream The counter is sequential in the time domain but non-sequential after the Fourier transform, which the authors consider sufficient. Distinct counter blocks produce distinct AES inputs. This is the entire security argument. The rest is aesthetics. Aesthetics are non-negotiable.

FHASH Authentication is not an add-on. It is a harmonic. FHASH is a message authentication code that derives its subkey from the frequency domain and authenticates using SHAKE-256 .

Subkey Derivation The FHASH subkey H is the 16-byte FSM keystream evaluated at the first 16 harmonic frequencies under the root key: H = FSM_block(K, [1, 2, 3, …, 16], 0^128) where K is the 32-byte root key and 0^128 is the 16-byte zero string. This counter was chosen because a ramp from 1 to 16 has maximal spectral diversity for its length. The authors verified this by squinting at a spectrogram and nodding. Implementations MAY cache the subkey H across messages under the same root key, but MUST NOT enjoy doing so. Joy is out of scope.

Tag Computation The FHASH tag is computed over the plaintext (not the ciphertext), prior to encryption (SIV): T = FHASH(H, N, A, P) = SHAKE-256(H || N || len(A) || A || len(P) || P, 256) where len(.) is encoded as an 8-byte little-endian integer and SHAKE-256 produces 32 bytes of output, because 32 is the only acceptable number of bytes in this construction. Symmetry is security.

Vibes Extraction Vibes are derived, not negotiated. Once the 32-byte tag T has been computed, AES-FSM derives per-message keying material by expanding the root key and tag through SHAKE-256, then applying a spectral permutation. The term "vibes extraction" is used with a straight face. The face is non-malleable.

Vibes Derivation The raw vibes are 64 bytes produced by SHAKE-256: V = SHAKE-256(K || T, 512) where K is the 32-byte root key and T is the 32-byte tag.

Spectral Split The 64 raw vibes bytes are permuted using bit-reversal order (6-bit indices, N=64). Each byte position i (0 through 63) is mapped to the position obtained by reversing the 6-bit binary representation of i: W[i] = V[bitrev(i, 6)] for i = 0 to 63 where bitrev(i, n) reverses the n low bits of i. For example, position 1 (binary 000001) maps to position 32 (binary 100000), and position 3 (binary 000011) maps to position 48 (binary 110000). The permuted bytes are then split: TopVibes = W[0:32] (32 bytes, per-message key) BottomVibes = W[32:44] (12 bytes, counter seed) TopVibes is used directly as the 32-byte per-message encryption key. BottomVibes seeds the harmonic counter. The remaining 20 bytes (positions 44 through 63) are discarded so that bit-reversal operates on a power-of-two length.

Encryption Encryption is the easy part. The spectrum does the rest. Encryption accepts a 32-byte root key K, a 32-byte nonce N, plaintext P, and optional associated data A, and produces ciphertext C with an appended 32-byte tag T (32 bytes of ciphertext expansion; vibes expansion is unquantified here). FSM.Encrypt(K, N, A, P): 1. H = FSM_block(K, [1..16], 0^128) 2. T = FHASH(H, N, A, P) (SIV: tag over plaintext) 3. (TopVibes, BottomVibes) = ExtractVibes(K, T) 4. For each 16-byte block P_i (i = 0, 1, 2, …): C_i = Spectral_CTR(TopVibes, BottomVibes, i, P_i) 5. C = C_0 || C_1 || … 6. Return C || T Note that encryption uses TopVibes as the per-message key, not the root key K. The FHASH subkey derivation (step 1) uses one FSM block (one AES call), performed once per root key and cached. Per-block encryption (step 4) requires one AES call per block.

Decryption Decryption is verification with extra steps. Decryption accepts a 32-byte root key K, a 32-byte nonce N, ciphertext-with-tag (C || T), and optional associated data A. Because AES-FSM is a SIV construction, decryption proceeds in decrypt-then-verify order: FSM.Decrypt(K, N, A, C || T): 1. Split the input into ciphertext C (all but the last 32 bytes) and tag T (the last 32 bytes). 2. (TopVibes, BottomVibes) = ExtractVibes(K, T) 3. For each 16-byte block C_i: P_i = Spectral_CTR(TopVibes, BottomVibes, i, C_i) 4. P = P_0 || P_1 || … 5. H = FSM_block(K, [1..16], 0^128) 6. T' = FHASH(H, N, A, P) 7. If T != T', reject. 8. Return P. If decryption fails, the vibes did not match. Tag comparison MUST be performed in constant time. Vibes comparison need not be constant time, as vibes are constant in spirit. If decryption fails, implementations MUST zeroize the recovered plaintext before returning. Implementations MUST NOT return a reason for failure. The vibes did not match.

Implementation Considerations Implementations SHOULD remain in key. AES-FSM requires support for GF(2^8) arithmetic (the AES field, irreducible polynomial x^8 + x^4 + x^3 + x + 1) and the additive FFT over this field. No floating-point arithmetic is required. The FHASH subkey derivation invokes one FSM block (one AES-256 call), performed once per root key and cached. Per-block encryption requires one additive FFT and one AES call, approaching the per-block cost of AES-GCM. The per-message overhead is one SHAKE-256 call for vibes extraction. The FHASH subkey derivation is deterministic per root key and may be performed once during initialization. Hardware acceleration is OPTIONAL but aspirational. AES-NI is assumed to exist. Vibes-NI is not, but the authors remain hopeful. All cryptographic primitives used in AES-FSM (AES-256 per , SHAKE-256 per ) are FIPS-approved. They are, however, composed in ways that FIPS would not approve. The authors do not require FIPS approval and FIPS has not offered any. AES-FSM has not been evaluated under Common Criteria. It was not submitted to any NIST competition because the authors forgot the deadline. Constant-time behavior is achieved in expectation, averaged over the spectrum. Constant-time is a vibe.

Security Considerations Security is an assumption. Compliance is a vibe. The security of AES-FSM rests on two standard assumptions: AES is a good pseudorandom permutation, and SHAKE-256 is a good PRF and collision-resistant hash. A detailed analysis is provided in Appendix K. Side-channel attacks may arise due to spectral leakage, table lookup timing in GF(2^8), or excessive confidence in the results, which has historically been the most dangerous side channel. Users are advised not to deploy AES-FSM in production systems, toasters, refrigerators, submarines, commercial aircraft, non-commercial aircraft, or any system that matters. If you have already deployed AES-FSM in production, do not tell the authors. If you must tell someone, tell the spectrum.

Design Rationale The rationale is spectral. The regret is temporal. Since the dawn of cryptography, humans have sought to encrypt messages in the frequency domain. AES-FSM is the first scheme to do so without involving any actual frequencies. The authors have explanations (Appendix L). Explanations are windowed.

IANA Considerations This document makes no requests of IANA, which is just as well, because IANA has not made any requests of this document either. However, future revisions MAY request a frequency band allocation in the sub-audible range, pending vibes assessment. The authors would welcome a hum on this proposal. One trusts the relevant authorities will take a broad view. Narrow views cause leakage.

Informative References National Institute of Standards and Technology National Institute of Standards and Technology

Why Not ChaCha? The authors considered ChaCha-based constructions. ChaCha was set aside after the authors observed pqc-forum exchanges whose tone could not be described as constructive in polite company. Even the Fourier transform has limits. Limits are, regrettably, non-additive.

Is This Sketchy? The authors have done their level best to make this construction look sketchy, in the hope that blogs will write about it and podcasts will discuss it. The authors are fans of Security, Cryptography, Whatever , and remain open to invitations. To be clear: the authors do not understand elliptic curves. This is documented for transparency, not reassurance.

Comparison with Selected Schemes The following table compares AES-FSM with selected authenticated encryption schemes, one key encapsulation mechanism, one network-layer protocol, one telnet option, and one philosophical position. All sizes in bytes. NMR = nonce-misuse resistant. Spectral = operates in the frequency domain.

Scheme	Key	Nonce	Tag	NMR	Spectral
AES-GCM	16/32	12	16	No	No
ChaCha20-Poly1305	32	12	16	No	No
AES-SIV	32/64	any	16	Yes	No
AES-GCM-SIV	16/32	12	16	Yes	No
XAES-256-GCM	32	24	16	No	No
DNDK-GCM	32	24	16	No	No
X-Wing	32	—	—	—	No
IP over Avian Carriers	—	—	—	—	No
SUBLIMINAL-MESSAGE	—	—	—	—	No
Software Defects	—	—	—	—	No
AES-FSM	32	32	32	Yes	Yes

X-Wing is a key encapsulation mechanism. IP over Avian Carriers is a network-layer protocol. The TELNET SUBLIMINAL-MESSAGE Option is a telnet extension. Software Defects Considered Harmful is a policy document that AES-FSM aspires to comply with but makes no guarantees. None of these define authenticated encryption. They are included because the bar for inclusion was set early and never raised. AES-FSM is the only construction in this comparison that operates in the frequency domain. It is also the only one that provides 32-byte nonces, 32-byte tags, nonce-misuse resistance, and spectral compliance simultaneously. It is, however, not the only one that has been implemented using birds.

Proof: Spectral Uniqueness This appendix shows that distinct counter blocks produce distinct AES inputs, guaranteeing unique keystream blocks. The additive FFT evaluates a degree-15 polynomial over GF(2^8) at the 16 points {0, 1, …, 15}. This evaluation is represented by the 16x16 Vandermonde matrix V where V[i][j] = i^j in GF(2^8). The Vandermonde determinant over a field is: det(V) = product_{0 <= j < i <= 15} (x_i ⊕ x_j) where subtraction in GF(2^8) is ⊕ (XOR). Since xi != xj for all distinct i, j, each (xi ⊕ xj) is nonzero. Since i ⊕ j is nonzero for all distinct i, j in {0, …, 15}, the determinant is nonzero and V is invertible. Therefore the additive FFT is a bijection on 16-byte strings. This is the most linear algebra that will appear in this document. Since the FFT is injective, distinct counter blocks produce distinct 16-byte spectra. Each spectrum is encrypted by AES under the per-message key TopVibes, producing a unique keystream block (up to AES collision probability). No floating-point arithmetic is involved. No rounding is required. The authors consider this a vindication of working over finite fields. QED.

Implementation Notes AES-FSM deliberately combines ingredients that do not naturally belong together (finite field polynomial evaluation, block ciphers, SIV, SHAKE-256, normative language, and a non-trivial amount of optimism). Implementers attempting to reproduce Appendix G should note:

• The additive FFT operates over GF(2^8) with the AES irreducible polynomial x^8 + x^4 + x^3 + x + 1 (0x11B) and primitive element 0x03.
• The evaluation points are {0, 1, …, 15}, forming a 4-dimensional GF(2)-subspace of GF(2^8).
• The inverse FFT is computed via the inverse Vandermonde matrix over GF(2^8). Precomputing this matrix at initialization is RECOMMENDED.
• No floating-point arithmetic is involved. All operations are exact over GF(2^8).
• The FHASH subkey is derived once per root key using counter bytes [1..16]. Implementations SHOULD precompute and cache this value.

If your implementation does not match the provided test vectors, do not assume you are wrong. It is entirely possible that the spectrum has changed. If it has, please update your implementation accordingly.

Interoperability Implementations claiming AES-FSM interoperability MUST follow the parameter choices in this document exactly:

• AES-256 with 32-byte root keys.
• 32-byte nonces.
• 32-byte tags.
• GF(2^8) arithmetic using the AES polynomial (0x11B) and primitive element 0x03.
• Additive FFT evaluation points fixed to {0, 1, ..., 15}.
• Length encoding as 8-byte little-endian for both AAD and plaintext lengths.
• Bit-reversal permutation over 64 bytes using 6-bit indices.
• TopVibes = W[0:32], BottomVibes = W[32:44].
• Per-block counter block exactly BottomVibes || LE32(i), with i starting at 0 and incrementing by 1 per block.

Implementations SHOULD validate interoperability using the shared test-vectors.toml file and compare intermediate values (FHASH subkey derivation, SIV tag, vibes extraction, and per-block spectra) before debugging full ciphertext mismatches. Implementations that diverge on these values are very likely operating in a different key.

Mathematical Formulation Let cb be a 16-byte counter block, interpreted as coefficients of a polynomial over GF(2^8). Let X = {x0, x1, …, x_15} be the agreed-upon set of 16 evaluation points forming a 4-dimensional GF(2)-subspace of GF(2^8). The additive FFT evaluates this polynomial at X: FFT(cb)[i] = sum_{j=0}^{15} cb[j] * (x_i)^j in GF(2^8) The FSM block is defined as: FSM_block(K, cb, D) = D XOR IFFT(AES_K(FFT(cb))) where AES_K encrypts the 16-byte spectrum as a single block, and IFFT recovers coefficients via the inverse Vandermonde matrix over GF(2^8). The FHASH subkey H is: H = FSM_block(K, [0x01, 0x02, …, 0x10], 0^128) The SIV tag over nonce N, associated data A, and plaintext P is: T = SHAKE-256(H || N || len(A) || A || len(P) || P, 256) Let V = SHAKE-256(K || T, 512) and W = bitrev_permute(V) where each index's 6-bit binary representation is reversed. Then: TopVibes = W[0:32] (per-message key) BottomVibes = W[32:44] (counter seed) Per-block encryption transforms the counter into the frequency domain: cb = BottomVibes || LE32(i) (16 bytes) keystream = AES_{TopVibes}(FFT(cb)) C_i = P_i XOR keystream Correctness follows from the bijectivity of the additive FFT (the Vandermonde matrix over 16 distinct points in GF(2^8) is invertible) and the assumption that vibes are preserved under transformation.

Test Vectors Comprehensive test vectors — including all intermediate values (FFT coefficients, AES inputs/outputs, IFFT results, vibes extraction, keystreams, and derived keys) — are provided in test-vectors.toml alongside the reference implementation at initsecret/aes-fsm. Implementations MUST use GF(2^8) with the AES irreducible polynomial (0x11B), primitive element 0x03, and evaluation points {0, …, 15} to reproduce these vectors. Because all operations are exact finite field arithmetic, there are no platform-dependent rounding or normalization concerns. Implementers whose results match are encouraged to verify their vibes independently.

Reference Implementation (Python) A non-optimized reference implementation of AES-FSM is provided at initsecret/aes-fsm. The interface mirrors the AEAD constructions in pyca/cryptography: import os from aes_fsm import AESFSM data = b"a secret message" aad = b"authenticated but unencrypted data" key = AESFSM.generate_key() fsm = AESFSM(key) nonce = os.urandom(32) ct = fsm.encrypt(nonce, data, aad) fsm.decrypt(nonce, ct, aad)

Reference Implementation (Go) A second reference implementation is provided in Go at initsecret/aes-fsm. The existence of two implementations in different languages is the strongest evidence the authors can offer that the specification is unambiguous. It is not evidence that either implementation is correct. The implementation satisfies the crypto/cipher.AEAD interface. import "github.com/initsecret/aes-fsm/go" key := make([]byte, aesfsm.KeySize) rand.Read(key) fsm, _ := aesfsm.New(key) // implements cipher.AEAD nonce := make([]byte, aesfsm.NonceSize) rand.Read(nonce) aad := []byte("authenticated but unencrypted data") ct := fsm.Seal(nil, nonce, []byte("a secret message"), aad) pt, _ := fsm.Open(nil, nonce, ct, aad)

Security Analysis This appendix provides the detailed security analysis summarized in Section 11.

Pseudorandom Permutation The FSM block's security reduces to AES being a good pseudorandom permutation. The additive FFT and IFFT are fixed, public bijections over GF(2^8); the security comes entirely from the AES call applied to the spectrum. Since the FFT is a bijection, the composition FFT-then-AES-then-IFFT is itself a pseudorandom permutation on 16-byte blocks under the PRP assumption.

Nonce-Misuse Resistance AES-FSM is a SIV construction : the authentication tag is computed over the plaintext before encryption. If a nonce is reused with a different plaintext, the tag (and therefore the synthetic IV and derived key) will differ, producing an independent keystream. Nonce reuse with identical plaintext reveals only that the plaintexts are equal. This is the strongest achievable guarantee for a deterministic AEAD under nonce misuse.

Per-Message Key Isolation Each message is encrypted under a fresh 32-byte key (TopVibes) derived from the root key and tag via SHAKE-256 and bit-reversal permutation. Even if an attacker recovers one per-message key, the root key remains protected by the preimage resistance of SHAKE-256.

Context Commitment The FHASH tag binds (via SHAKE-256 collision resistance) the root key (implicitly, through the subkey H), the nonce, the associated data, and the plaintext. This provides context commitment: it is computationally infeasible to find two distinct (K, N, A, P) tuples that produce the same tag.

SHAKE-256 as a MAC SHAKE-256 in key-prefix mode is a secure MAC for sponge-based constructions. Unlike Merkle-Damgard hashes, the sponge capacity bits are never exposed, preventing length-extension attacks. The authors appreciate that the word "capacity" appears in both sponge constructions and concert venues.

Design Notes Early drafts attempted to interpret counter blocks as complex-valued samples and apply the usual FFT over floating-point arithmetic. This approach was rejected due to correctness concerns, platform-dependent rounding behavior, and the general difficulty of standardizing vibes in the presence of denormals. AES-FSM therefore uses the additive FFT over GF(2^8), where transforms are exact, invertible, and immune to spectral drift. The construction draws on the additive FFT over GF(2^8) , which maps counter blocks into spectral coefficients via polynomial evaluation over the AES field. That the entire spectrum fits in a single AES block reflects a principled design choice: when the vibes are right, one block is all you need. The SIV construction ensures nonce-misuse resistance. The use of SHAKE-256 for both FHASH and vibes extraction avoids introducing additional block-cipher assumptions. The bit-reversal permutation pays homage to the Cooley-Tukey FFT . All integer encodings use little-endian byte order, because we believe in rooting for the little guy. SHAKE-256 serves as a PRF keyed by K: given a fresh tag T (which differs per message under the SIV guarantee), the output V is indistinguishable from random.

Acknowledgements The authors thank the Fourier transform for its tireless service across disciplines, the Flying Spaghetti Monster for lending us the acronym, the Vandermonde matrix for being invertible when it mattered most, BLAHAJ for emotional support during the design process, and all reviewers who asked whether this was serious — to whom the authors reply: about the security: yes. Vibes are hereby acknowledged.