Author: Jack Kowalski https://entropment.com Patent Pending Programmer friendly DataEntroper explanation; open code and exe plus docs are available on: https://entropment.com/ Imagine you're writing a 3D engine and you have a camera matrix. Instead of moving the camera around the world, you rotate the entire world around the camera — but in a very weird, high-dimensional way. How Entropment (the "not-cipher" projection) actually works — simplified for programmers: You take your data — text, binary, image bytes, whatever — and treat it as one big flat vector of 64-bit IEEE floats. Entropment handles this conversion automatically. You have a secret key. The key controls a long sequence of rotations — not clean 3D quaternion rotations, but 16-dimensional rotations done in sedenions (a 16D algebra obtained by repeatedly doubling complex numbers via Cayley–Dickson construction). These rotations are deliberately nasty for floating-point: they incorporate fractional powers, arcsin, and other transcendental functions that behave horribly in finite precision. Every rotation introduces tiny rounding errors — standard FP behaviour. In a normal 3D engine you would normalize the quaternion after each step to kill drift. Here you do the opposite: you never normalize. You let the error accumulate on purpose. After many such rotations (typically 52–100+ steps, roughly mantissa bits + some deterministic extra rounds for added cruelty), the original numbers are massively scrambled: - small initial errors explode - values crawl slowly toward zero (crawling zero-divisors) - others shoot toward infinity or become NaN - huge chunks of bits vanish into overflow, underflow, or denormals What you send is this heavily distorted buffer. It looks like garbage — but it's completely deterministic garbage. The receiver with the exact same key performs the inverse sequence of rotations. Because the operations are almost invertible in exact arithmetic, he ends up very close to the original data. How close? On the correct key → usually 1–2.5% of bits are flipped (≈20–25 Hamming errors per 1024 bits). That's low enough for standard error correction (Reed-Solomon, LDPC, even simple repetition + interleaving) to recover everything perfectly. On a wrong key — even one bit different: → error rate jumps to ~50–60%. The buffer still looks semi-plausible (not full of obvious NaNs), but it's mathematically useless — impossible to recover. Extra details on loops, key changes, and fake injections: For single blocks it's straightforward — one key, one sequence. For longer messages (sequences of blocks), the app processes in a loop with extra "cruelty": - Keys are not static: there's a "keyring" (a ring of derived keys managed inside the Hardware Security Module simulator) that mutates deterministically each iteration. - Mutations include shifts, additions, rotations left/right, and value injections based on fast hashes (SplitMix53, SHA parts, etc. — basically "give me some extra bits" operations). - Fake injections ("fejki") are semi-plausible fake keys or buffers deliberately inserted to create an obfuscation plateau. Nearby / wrong keys produce outputs that look reasonable (e.g., only 1–2 NaNs but 15/16 seemingly valid bits) but are junk — designed to waste attacker time on false leads. The legitimate user skips or discards them after full decryption (he knows which ones are fake because he has the correct keyring logic). The attacker model we test against: OmnipotentEve - Think god-mode Eve from crypto: infinite compute, full knowledge of the algorithm, sees all traffic, can brute-force anything. - Here hardness doesn't come from key size — it comes from the sheer cost of enumerating mutations + performing the flops per attempt. - Each brute-force try requires simulating full loops: recursive CD multiplications, transcendental ops that force FP drift, and keyring mutations. - The crawling errors and structural irreversibility eat compute — even billions of FLOPs usually fail without the exact key sequence. - OmnipotentEve can break individual blocks (including fake ones, since she has infinite tries and can test every possible key), recovering lots of bits. You can tune what "a lot of bits" means to trigger puzzle-solving in a decision tree — but putting it all together into coherent plaintext remains astronomically expensive due to the keyring mutations and sequence cruelty. Key programmer takeaways: - This is not classical encryption. The information is mathematically present — it's just projected into a form that's extremely hard to interpret without the exact rotation sequence. - Zero randomness. Same key + same input = always identical output (per block; across sequences deterministic extra cruelty is layered on). - Floating-point rounding, overflow, NaN propagation, gradual denormal crawl — these are the core security features, not bugs. - You don't need huge keys. A 52-bit or 64-bit key is sufficient — the real cost for an attacker is the astronomical number of floating-point operations needed to brute-force. Simply: You rotate the entire message many times in 16D floating-point hell, deliberately amplify every tiny FP error until it eats most of the useful bits, send the resulting mess — and only someone with the exact same key (and keyring logic) can rotate it back to something almost identical to the original.