118 — Fernet/AES audit: large uploads and small xz records use different visible formats
September 5, 2026. All3,574 cluster bodies hash-checked against the existing survey.

Main finding
The nine large xinzhai groups provide strong Fernet-format evidence: canonical nested Base64, the expected version/header layout, plausible creation timestamps and block-aligned ciphertext. The small knowledge and plan records are not full Fernet tokens at the tested layer. Their length arithmetic also rules out one fixed-size wrapper around ordinary padded CBC ciphertext for the entire stream. It does not identify AES-GCM or any other particular small-record cipher.

What Fernet means here
Fernet specifies AES-128-CBC encryption, PKCS#7 padding and HMAC-SHA256 authentication. Its32-byte key is split into16-byte signing and16-byte encryption keys; the32-byte combined key does not mean AES-256. The binary token has1version byte,8timestamp bytes,16IV bytes, variable block-aligned ciphertext and32HMAC bytes. Base64 is the text transport encoding, not encryption. Format parsing does not verify the keyed HMAC or recover plaintext.
Primary specification: https://github.com/fernet/spec/blob/master/Spec.md

The observed large-upload pipeline
Observed paste parts -> concatenate -> standard Base64 decode -> URL-safe Base64 token -> URL-safe Base64 decode -> Fernet-shaped binary object.
All nine have version0x80 and ciphertext lengths divisible by16 after removing57bytes of fields. All nine16-byte IV fields differ. Across77,644 ciphertext blocks, no16-byte block repeats; none of the36 token pairs shares even the first ciphertext byte. These observations rule out literal unchanged ciphertext prefixes in this sample. They do not establish different keys, different plaintexts or cryptographic security; fresh-IV encryption can conceal unchanged plaintext.
The76 parts reproduce the exact30,000-character outer split already verified in068. Four parts belong to the earliest unversioned group, which the supplied archive did not save as a separate .fernet file.

Conditional plaintext lengths
For standard Fernet, PKCS#7 adds1–16bytes. Therefore plaintext length is ciphertext length minus16 through ciphertext length minus1. These are bytes supplied to encryption, not necessarily readable text, and say nothing about any prior compression or serialization.
xinzhai: 64,928 ciphertext bytes -> 64,912–64,927 plaintext bytes
xinzhai_v5.2: 65,488 ciphertext bytes -> 65,472–65,487 plaintext bytes
xinzhai_v52: 99,680 ciphertext bytes -> 99,664–99,679 plaintext bytes
xinzhai_v60: 113,552 ciphertext bytes -> 113,536–113,551 plaintext bytes
xinzhai_v61: 125,296 ciphertext bytes -> 125,280–125,295 plaintext bytes
xinzhai_v70: 151,504 ciphertext bytes -> 151,488–151,503 plaintext bytes
xinzhai_v71: 180,784 ciphertext bytes -> 180,768–180,783 plaintext bytes
xinzhai_v72: 209,904 ciphertext bytes -> 209,888–209,903 plaintext bytes
xinzhai_v73: 231,168 ciphertext bytes -> 231,152–231,167 plaintext bytes

The small-record length discriminator
Knowledge lengths in bytes:93,226,271,316,319,352,364,374,397,428. Their remainders modulo16 are0,2,6,12,13,15. Plan lengths646/647 have remainders6/7.
If every record had one fixed overhead H plus padded CBC ciphertext, its total length would be H+16k. Every total would therefore have the same remainder modulo16. These streams do not. Changing plaintext length or compressing before padded CBC does not remove that constraint. Variable-length wrappers, different constructions by cohort, ciphertext stealing or additional post-encryption transformations remain alternatives; this result does not exclude every use of AES.
Full binary Fernet requires length57+16k, hence remainder9. None of the small-record sizes has remainder9. Nine knowledge bodies happen to start with0x80, illustrating why a single version byte is insufficient; zero pass the full layout test.

AES-GCM is plausible, not identified
A hypothetical stored12-byte nonce plus ciphertext plus16-byte tag would have28bytes overhead. That would imply knowledge plaintext lengths65–400bytes and plan lengths618/619bytes. Both AES-GCM and ChaCha20-Poly1305 can use such a layout. We have not located nonce/tag fields or authenticated either construction, so these are conditional arithmetic examples, not recovered messages or an algorithm fingerprint. No duplicate first8/12/16-byte prefixes occur within either small stream; this does not prove those prefixes are nonces.
Primary API documentation: https://cryptography.io/en/latest/hazmat/primitives/aead/

Practical interpretation
A versioned large-object uploader and a periodic small-record writer are a plausible shared system, supported separately by interleaving and cadence. The large objects could hold code, serialized state, documents or other bytes; their content is unresolved. A cryptographic format does not establish an agent swarm. To identify the small construction or read the messages would require additional evidence such as the actual writer implementation or an authorized key, not further Base64 decoding.

Audit artifacts
118-crypto-layout-audit.py;118-private/analysis.json. Input archive SHA-2564a202ecd9dbe3dfcc40c1dac00984573cdffb38102e9d4ba4e04ce09b9a9105c. No HMAC verification, decryption, key search, network posting or pasted-code execution. No new crawler or search-bot wave.