Instead of encrypting data, ZOSCII encodes messages as addresses pointing to characters in a shared ROM file (any binary file - photo, song, game ROM). Non-deterministic selection from multiple matching positions creates ~10^millions possible encodings.
Security comes from combinatorial explosion, not mathematics. No encryption = no export controls, quantum-proof by design.
Looks interesting for it's simplicity and ability to thwart encryption legislation.
Just a couple of points:
- It looks this could be described as a variation on one time pad. Instead of one pad, you're using up to 256 pads.
- It appears that the size of most messages will double.
- To encode will require substantial memory to hold the address lookup table. With a 64K ROM, as much as 1 Mb would be required. This could prove challenging on a 8 bit micro.
Intuition also tells me that you could probably achieve reasonably similar security by using a simple mathematical encryption method with a comparable sized (64K) secret key.
Part of the attraction of mathematical encryption is the use of short keys to facilitate frequent key exchange.
Thanks for the thoughtful analysis. I want to address the one-time pad comparison specifically, as this is a common misconception.
ZOSCII is fundamentally different from a one-time pad:
A one-time pad has a 1-to-1 relationship:
Each plaintext bit maps to exactly ONE ciphertext bit (via XOR with pad)
Given the pad, there's exactly ONE decryption
Security comes from the pad being unknown
ZOSCII has a many-to-many relationship:
Each plaintext byte can be encoded as ANY of ~256 different addresses (wherever that byte value appears in the LUT)
The same message can generate 256^(message_length) different address sequences
For a 10-byte message, that's approximately 1.2 × 10^24 different valid encodings of the identical plaintext
This creates exponential, not linear, ambiguity. With a 64KB LUT (65,536 addresses), you're working in a much larger combinatorial space than "256 pads" - you're selecting from 65,536 possible addresses with ~256 valid choices per byte.
Regarding practical implementation on 8-bit systems:
You don't need 64KB - that's just a practical good size. A 16KB LUT still provides millions of combinations and achieves 100% information-theoretic security. The LUT size is flexible based on your constraints.
For encoding sizes:
16-bit encodings: 2x original data size
32-bit encodings: 4x original data size
64-bit encodings: 8x original data size
Without preprocessing, an 8-bit computer only needs to hold the LUT itself in memory (16KB, 64KB, etc.). With preprocessing for faster two-way lookups, you need approximately 2.1x the LUT size plus the original table - but this enables near-instant encoding/decoding.
The security model is entirely different:
OTP security: "You can't determine the plaintext without the pad"
ZOSCII security: "Even with a candidate LUT, you cannot prove which of many valid plaintexts is the original"
This provides plausible deniability that OTP cannot achieve. The same address list could decode to "ATTACK TOMORROW" or "HELLO MOTHER" depending on which LUT you use - and there's no mathematical way to prove which interpretation is correct.
Regarding your point about mathematical encryption with comparable key sizes - yes, traditional crypto is more efficient. But ZOSCII isn't competing on efficiency; it's providing fundamentally different security properties: undetectable encoding with perfect deniability. The encoded output is indistinguishable from random data or any other legitimate data format.
Security comes from combinatorial explosion, not mathematics. No encryption = no export controls, quantum-proof by design.
Open source, working implementation available.