Cipher protects the content, not the fact and the path. We add a deniability layer + path cost without touching the cipher that already flows through the communication channel.
Our product is communication protection that uses a synthetic arithmetic channel. Market name is irrelevant for now; the product currently has the working name RIPA so we have something to put on the version directories. We run a technical venture; we know how to organise R&D, production and deployments - we do not know how to run a market-facing business. If we have to talk to a customer we draw straws to see who gets the short one. If we have to solve an analytical, production or organisational problem we pounce on it like a dog on a bone.
It would be nice to meet someone who is willing to take the socio-economic side of the venture. Each of us has experience as a technical director or other technical principal in closed, customer-isolated, specialised execution domains in technology. By habit we have always executed someone else’s product under a specification regime. Now we have our own and we have realised we never understood how our work was actually monetised - we never bothered with that. That was always someone else’s (socio-economic) job.
We have a working prototype with full functionality (modulation, keyring, rotation, fakes, AO_check, history, state save). Open and versioned code (RIPA_31, RIPA_32).
Company / brand - Data Entropment Labs, but we are recognised only among a handful of niche specialists.
Technical documentation, research notes, technical plan with phases, hardware, stack, timeline and target users.
Heavy mathematical description: notes_for_QCO_in_order.txt
Lighter analytical description: RIPA_QCO_EN.txt
Narrative analogy of the logic: programmer_friendly_Entroper_explanation.txt
Technical product plan (stack etc.): RIPA_Technical_Plan_EN-1.txt
Explanation of the hardness model: hardness_models_en.txt
guarantees and security model exists - change from November 2026: security_model_guaranties.txt
Marketing pitch: RIPA_Pitch.pdf
We do not yet have a production implementation (C/Zig + real HSM). Hardware in an enclosure. Independent validation (expensive; colleagues in the industry have read it and know that when it lands on someone they already feel sorry for that person). Customers and deployments. A larger team. This is an early project with a working core, a roadmap and deliberately described limitations. What is missing is the transition from prototype to something deployable and external confirmation, but as a project it already works. The fact that we have no salesperson has been a chronic pain for years.
It is a niche, high-margin investment with clearly stated (further) risk. Not “the next big thing”. Rather something for dual-use / defence / govtech funds.
The core itself is already written, partitioned and tested. There is no need to fund research from zero. There is a code, a coherent mechanism and FPU calibration. And parsers have an exceptionally hard time with the format in which this prototyping IDE stores projects.
Light secret + growing resistance. Protection that can even be carried as a phrase + path combinatorics that becomes very large under cover traffic. In the niche of this kind of application it is real value. Clear niche. Diplomacy, intelligence, air-gap, specialised links (making traffic analysis harder on a link that is already encrypted), sequence verification (remote control of machines, verification that the command sequence has not been substituted). No need to convince a mass market. Realistic hardware path on Pi Zero / STM32.
We have no independent validation (it is very expensive). There are not many recipients who truly need deniability + air-gap + identical toolchain. Sales will be long and relational, not scalable. Operational dependency is algorithmisable. It cannot be certified like cryptography; there is no such object. For some institutional recipients that is a barrier. Recipients must be educated. Bus factor is close to one (small group).
Worth investing in it if you treat it as a niche B2G / B2B product with high margin, you have access to recipients in this niche, or you know how to reach them. Our contacts are exclusively in technical verticals; they have zero influence on decisions and zero access to decision-makers. And those who do have access are juniors whom nobody yet takes seriously.
If you are looking for something scalable, need a fast return, have no path to institutional recipients (and do not know how to create one - we do not either), expect this to replace ordinary cryptography - then this is definitely not for you. The investment type is a small cheque, a concrete niche, technically non-trivial, market-wise narrow.
There are no alternative products. RIPA combines several things at once (traffic deniability + short secret + sequence verification + air-gap). Most existing solutions cover only part of this.
Deniable encryption / plausible deniability (storage) do not give a layer on live traffic, sequence verification, or resistance that grows with cover traffic.
Secure messaging with deniability does not give concealment of the very fact of communication inside cover traffic, an absurdly cheap starting secret, or hard sequence verification beyond a normal MAC.
Covert channels / steganography / traffic-analysis resistance usually do not give low bandwidth, lack hard sequence verification, or require continuous supervision. Most of them are exfiltration channels, not two-way communication with state synchronisation.
Air-gap + standard crypto does not give deniability. If someone sees the traffic they know something went through. The secret is of normal size.
Chaotic systems / synchronised chaos are mostly academic, occasionally used on specialised links. Few mature products. Ideologically close to RIPA (shared control signal, observer does not reconstruct the state), but rarely brought to a practical tool with deniability and cover traffic.
| Need | Closest alternative | What is missing vs RIPA |
|---|---|---|
| Deniability on disk | VeraCrypt / DEBridge | "No channel, no sequence verification" |
| Deniability in chat | Signal | "Weak in practice, no cover traffic" |
| Hiding traffic | Stego / mixnet / covert channel | Usually low throughput or no sync |
| Air-gap + confidentiality | HSM + AES | No deniability |
| Sequence verification | MAC / signature + counter | "No deniability, normal key size" |
| Short secret + growing resistance to path analysis | none | RIPA stands alone here |
There is no direct, mature substitute that combines traffic deniability (not only storage), a short, phrase-portable secret, sequence verification with desynchronisation detection, resistance that grows with cover traffic, and air-gap friendliness. One can assemble something similar from existing blocks (HSM + stego + ratchet + lots of cover), but it will be heavier, more expensive in secrets and weaker in traffic deniability than what RIPA offers in its model. In the narrow niche RIPA has no known competitor. Outside it, standard tools are simpler and sufficient.
Product roadmap for https://entropment.com/media/downloads/PAPERS_RIPA_Technical_Plan_EN-1.txt
| Phase | Scope | Timeline | Notes |
|---|---|---|---|
| External HSM | Extract logic onto Pi Zero / STM32, binary protocol, lockdown | 3 to 4 months | We have specialists from “exactly this” sector; some are already half-retired so they have time for us |
| ECC | Reed-Solomon for BER ~2.5%, tool + integration | within prototype | none |
| Fakes | RS-based fake buffers instead of pure random | within prototype | none |
| Production app | C++/Zig, arena, mprotect, fixed libm, HAL | additional 2 to 3 months | we also have specialists for this |
| E2E integration | Pipeline with air-gaps, examples | additional 2 months | lots of testing |
| Packaging | SDK / dongle / appliance | final | cutting, bureaucracy, documentation |
In total that is roughly nine months, so it is sensible to assume a year allowing for perturbations (conservatively). And as usual with projects (I have experience) in man-hours it will come out longer. The actual execution is fast - the testing and verification, reading and checking take most of the time, and here there are no ready patterns except our own. One must be very conservative with these estimates even though there is not much code and the embedded implementation looks simple. It looks simple, and slippage always appears. I know that with budget I can compress it to four or six months.
Assuming those ~7–9 months to something deployable, cost estimate (very rough) with a team from Europe (mainly Sweden, Switzerland) so remote, mostly mid and senior level:
1–2 embedded people (C/Zig + Pi/STM32) 8–14k EUR/month each, 1 person for ECC / cryptographic integration: 7–12k EUR/month, 1 hardware / mechanics (enclosure, USB, power): 4–8k EUR/month. Optionally someone for documentation / threat model: 3–6k EUR/month.
Because currently our embedded and hardware people are the same people (seniors), time compression is doubtful. By habit we work until it is good; those are the requirements and the custom in the industry.
With a small team (2–3 people) for 8 months that is roughly 300k EUR (conservatively) of pure labour. Hardware and tools such as Pi Zero 2 W / Compute Module for prototypes are a few hundred EUR. STM32H7 dev boards another few hundred EUR. Most of these things we already have on hand because that is what we do. Enclosures, USB, power, first series of dongles roughly 2–10k EUR. Laboratory / measuring equipment (if we take side-channel seriously) 5–20k EUR, though part of this equipment we either own or have access to.
Other items: patents - bureaucratic costs, a few thousand euro, depending on the jurisdictions in which protection would be sought. Independent review / attempted attack roughly 40k EUR; I know it is needed, we have specialists for it, they already read the project last year when it was still a sketch and later as it developed, but doing it formally is a cost and production of documentation. HSM certification (FIPS 140-3 / CC) if needed at all is 100k+ EUR and a long time; the full system will not fit classical certification profiles anyway.
MVP for HSM on Pi + RS + library + examples, roughly 150k EUR and half a year. Proper production prototype + STM32, memory protection, dongle, documentation, roughly 300k EUR and another three months. With independent review and first series + audit + small hardware series, roughly 450k EUR and another half year.
The core already exists. Rewriting into C/Zig is routine work. ECC (Reed-Solomon) is standard. Those things are cheap; the expensive parts come later. Proper HSM isolation, fixed toolchain across platforms, side-channel resistance, documentation for institutional recipients, hardware in an enclosure. From this stage there are already paths to product spin-offs. The most expensive (if needed at all) is certification. The full system will not enter FIPS/CC because it is not a tool of those categories. The HSM itself can be certified, but that is a separate, expensive track.
On verification and certification itself.
RIPA has no structure that lends itself to analysis. The entire structure was deliberately destroyed. The whole process is constructed so that the analytical toolkit is guaranteed not to be suitable for attack. And that means it is also not suitable for analysis. Every feature except the primary one (message deformation that prevents unauthorised reading) has been removed. The normal set of techniques bounces off every side, unable to find structure to analyse. It looks like trolling the analyst who takes it on. Literally (trolling) that is how it was described after contact with two 52-bit initialisation seeds that, on a one-and-a-half-megabyte image, provide hundreds of thousands of bits (“security”) of combinatoric problem.
Set of constructive inversions.
| Standard | RIPA |
|---|---|
| Key = secret that encrypts | Key = state that mutates the message |
| Error = defect | Error = alphabet / threshold |
| Alphabet = symbols | Alphabet = FPU residue |
| Oracle = “yes/no” | Oracle = “I do not reject” without the ability to indicate whether it is good |
| Message = content | Message = part of state evolution |
| Cover = optional | Cover = source of combinatorics |
| Analysis = look for structure | Analysis = structure is destroyed |
| 52 bits = weak | 52 bits = seed of the first coupling |
The message is coupled with the key (not encrypted by the key as usual). The current keyring state modulates the block. The same block (via G from backtrack on K1) mutates the keyring. The next block is based on the changed state. G is not transmitted. Both sides compute it locally if they have the same state and the same message. That is, as long as they are “on the same page” they see the same thing.
Analytically there is no single function “key → message”. There is the pair: state S produces a block from the message, message + state produce new S'. After the first real block there no longer exists an object “session key” independent of the content.
There is nothing to look for as “the key”. Finding the seed only gives the starting point. Thereafter the state depends on which blocks were real and what was in them. Known-plaintext does not disarm it. To use the open text of one block one must know the state at that moment. The state depends on the earlier path, which is unknown. There is no separation - in a classical cipher you can attack the transformation because the key is external. Here the transformation and the state are intertwined. An attack on one spoils the other. The oracle is only negative. Many things fit locally, and only one path maintains the state. Small secret at the start (seed). Strength grows with the number of real blocks and the amount of cover traffic, not with key size. An observer who does not know the path and K1 does not know which way the state went. One cannot “break the key” and then read further. One must break the path. Message and state continually shift the system beyond any analysable projection.
From the user’s side it looks completely different.
| Property | For the user in the niche | For the auditor and classical analyst |
|---|---|---|
| No analytical footholds | Advantage (harder to attack) | Disadvantage (cannot be audited) |
| Strength in the path, not in the key | Advantage (small secret, high cost) | Disadvantage (does not fit the model) |
| Toolchain dependency | Acceptable (controlled machines) | Disadvantage (lack of portability) |
| No reduction | Indifferent, since it works | Disadvantage (no proof) |
| Deniability / cover | Advantage | Hard to assess |
Reduction allows something to be proved, but it also allows attack, and then it remains only a question of when someone finds an optimisation of the inverse property (Shor, Grover). We chose no reduction, even if as a result nothing can be proved in the classical way. BER ensures there is no distance measure from success. We built it for an adversary so that the typical tools of the adversary (analytical, optimisational, known-plaintext, quantum in known forms) have no foothold. We adopted an adversary model in which every tool that depends on the key is opened immediately. A side effect is that it also hits anyone who tries to analyse it classically, including someone who only wants to understand or calibrate it. Here the logic is one-way. It creates a situation in which the adversary has no convenient place from which to start. In ordinary cryptography adding fakes to the ciphertext usually gives weak obfuscation, because the structure still reveals what is real, or the cost of discrimination is low. The message is coupled with the state - not masked by a keystream.
Even quantum tools give no advantage here. Shor and derivatives - there is no periodicity and no hidden algebraic structure to exploit. Quantum optimisation / QAOA etc. - no usable landscape. The surface in the representation is flat with a threshold. There is no hill-climbing. Speed-up by simulation - no quantum system to simulate. There is a classical FPU cascade. What remains is Grover on the space of path hypotheses. It gives the square root of the number of possibilities. With the combinatorics (see hardness_models_en.txt) the square root is still out of reach even assuming one can build an oracle that checks “whether this path is good” reasonably cheaply. And checking a path requires maintaining the keyring state and is very expensive. What remains is unstructured search of a huge space, with at most quadratic speed-up if it can even be sensibly posed. The tools that make quantum solutions dangerous for classical cryptography have no attack surface here. What remains is brute force on the paths, only slightly accelerated.
Risks exist (no independent attack, narrow niche, bus factor), but they are not at the level of “maybe it does not work at all”. Maybe nobody serious will want to buy it, or maybe someone will find a cheap shortcut we did not invent. The effort to MVP is civilian. Clients are few but large. The risk is mainly market and validation, but the product exists.
It is worth adding some kind of pitch, so as to encourage rather than scare with mathematics. As can be seen, we first dissect the technical drawbacks, whereas some advantages ought to be stated.
A gem of its kind. The hard work - inventing it and checking whether it works at all and how it works - is done. There is code, there is a model, the limitations are written down, there is a roadmap. There is no need to fund the discovery. What needs funding is the rewrite, the hardware and reaching someone who will buy it.
This solution in the development of communication was previously overlooked; it is thought through, has a working core and does not require exotic technology.
Part of communication (diplomacy, special links, institutions) wants to make difficult not only the reading, but the determination of whether and which part of the traffic was real. A classical cipher does not give that. Metadata and traffic analysis remain.
A layer on ciphertext. Small secret at the start. Cover traffic that cannot be cheaply discarded. State that depends on content - an observer without the path does not maintain synchronisation. It does not replace the cipher. It adds something the cipher does not have.
It works. There is a prototype, there is a model, there is code. The niche is narrow but paying (institutions, dual-use, specialised equipment). There is no direct competition in this class.
What is needed is a demonstrator (two devices that talk to each other). Someone for relations with institutional recipients. Closure of the production version (C/Zig, HSM, toolchain). 300k EUR to MVP, not a growth round.
Licence + deployment or a dongle for a specific recipient. Not a mass product. High margin, small number of clients.
Lack of independent analysis - a shortcut may exist (we ourselves look, but we have no idea). Dependency on toolchain and manner of use. Regulation after the first client (“dual use” without civilian application). Bus factor.
I know that this post will be read by a model anyway, so I emphasise - this is not cryptography, it does not meet the definition. It is not meant to replace cryptography and does not touch it at all. It is a transport layer.
If the model extracts 130 thousand bits of security it will not be lying; it is simply lost in math from the lack of a pattern in the training corpus. Do not believe the model - it is complicated, but on such scales of difficulty for the adversary.
The technology is agnostic. It does not know whether it is carrying coordinates, text or anything else. It sees a buffer.
We are looking for someone who is willing to take the socio-economic side of the venture - after this text it is clear that we are not good at it; we slide into tables, analyses, technicalities and caveats. We do not have that profile of reasoning.
-- Jack Kowalski