AES Fourier Spectral Mode

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 October 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. 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.¶

2. 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 [RFC2119]. 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 [CANTOR89] and [ADDITIVEFFT]. 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 [FIPS197] 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 [FIPS202]. 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 [VIBES].¶

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 [IGNORANCE].¶

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.¶

3. 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.¶

   +----------+                 +---------+
   | 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 |
                   +--------+

4. 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 [CANTOR89][ADDITIVEFFT] 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.¶

5. 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.¶

6. 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 [FIPS202].¶

H = FSM_block(K, [1, 2, 3, …, 16], 0^128)

T = FHASH(H, N, A, P)
  = SHAKE-256(H || N || len(A) || A || len(P) || P, 256)

7. 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.¶

V = SHAKE-256(K || T, 512)

W[i] = V[bitrev(i, 6)]    for i = 0 to 63

TopVibes    = W[0:32]     (32 bytes, per-message key)
BottomVibes = W[32:44]    (12 bytes, counter seed)

8. 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.¶

9. 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.¶

10. 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 [FIPS197], SHAKE-256 per [FIPS202]) 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.¶

11. 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.¶

12. 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.¶

13. 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.¶

Appendix A. 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.¶

Appendix B. 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 [SCW], and remain open to invitations.¶

To be clear: the authors do not understand elliptic curves.¶

This is documented for transparency, not reassurance.¶

Appendix C. 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.¶

X-Wing [XWING] is a key encapsulation mechanism. IP over Avian Carriers [RFC1149] is a network-layer protocol. The TELNET SUBLIMINAL-MESSAGE Option [RFC1097] is a telnet extension. Software Defects Considered Harmful [RFC9225] 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.¶

Appendix D. 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.¶

Appendix E. 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.¶

Appendix F. 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.¶

Appendix G. 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.¶

Appendix H. 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.¶

Appendix I. 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)

Appendix J. 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)

Appendix K. Security Analysis

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

Appendix L. 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) [ADDITIVEFFT], 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 [FOURIER]. 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.¶

Author's Address