The Scrambled Message

The password system and velociraptor rotation had reduced the internal threat. But the external threat — messages intercepted during pterodactyl transit — remained unsolved. Bretchka's competitor Skvelj, denied his inside source, had reportedly begun hiring pterodactyls to follow GlagalCloud's carriers and read the trays mid-flight. Whether this was true or one of Hyjop's embellishments was unclear, but the vulnerability was real: anyone who physically accessed a message tray could read its contents. The baskets were not locked. The pebbles were visible. The data was, in the language Glagalbagal was beginning to develop, in plain arrangement.

The Scramble

Glagalbagal's idea was to rearrange the pebbles before sending them, using a pattern known only to the sender and receiver. The scrambled arrangement would look like a valid record — pebbles in baskets — but the positions would be wrong. A spy reading the tray would see nonsense. The receiver, knowing the pattern, could unscramble it.

He started with a simple method: swap positions. For a record with eight baskets, he defined a swap table:

Position 1 goes to position 5. Position 2 goes to position 8. Position 3 goes to position 1. Position 4 goes to position 3. Position 5 goes to position 7. Position 6 goes to position 2. Position 7 goes to position 4. Position 8 goes to position 6.

The original record 10110010 would become, after scrambling: 10100101. The receiver, with the same swap table, would reverse the process and recover the original.

Glagalbagal carved a scrambling tablet for each customer. The customer kept a copy; GlagalCloud kept a copy. Messages were scrambled before sending and unscrambled upon receipt.

The Pattern

For two months, the system worked. Then Blortz identified a problem.

Blortz: I have been looking at Bretchka's scrambled messages. There are patterns.

Glagalbagal: There should not be patterns. The positions are rearranged.

Blortz: The positions are rearranged, but the same way every time. Bretchka's records always start with the location code — which is always the same, because she only has one location. After scrambling, that location code always ends up in positions 3, 1, 7, 5. Every single message has the same pebble pattern in those positions. A spy who intercepts enough messages would notice that these four positions never change and conclude they represent the location code.

The scrambling was a fixed permutation — the same swap every time. This meant that any pattern in the original data produced a corresponding pattern in the scrambled data, just in different positions. An observer who collected enough scrambled messages could begin to work out which positions corresponded to which fields, simply by looking at which positions were constant (location code — always the same), which changed monthly (count), and which changed rarely (animal type mix).

This was frequency analysis. The spy did not need to know the swap table. He just needed enough messages to see which patterns repeated and which varied.

The Changing Scramble

The fix, Glagalbagal realised, was to change the scramble for every message. If each message used a different swap table, the spy could not accumulate patterns across messages — the same original data would scramble differently each time.

But this created the old problem from Part 33: how did the sender and receiver agree on which swap table to use for each message, without the spy learning the table?

Glagalbagal devised a partial solution. Instead of a single swap table, he gave each customer a sequence of tables — a thick stone booklet with one table per page. Message 1 used table 1. Message 2 used table 2. And so on. Both the customer and GlagalCloud had identical copies of the booklet.

As long as the booklet remained secret, the scrambles were different for every message, and the spy had nothing to analyse across messages. Each message used a unique scramble, making frequency analysis useless.

Blortz: And when the booklet runs out?

Glagalbagal: We make a new one and deliver it by a trusted courier — a pterodactyl that we control, on a route we choose, during a time we do not announce.

Blortz: So the security of the entire system depends on the physical security of a stone booklet carried by a pterodactyl.

Glagalbagal: Yes.

Blortz: That is not ideal.

Glagalbagal: No. But it is what we have.

The Trade-off

The changing-scramble system was effective but expensive. Each customer needed a unique booklet. Each booklet required dozens of swap tables, each table carved on stone. The booklets were heavy, took days to produce, and had to be physically delivered. If a booklet was lost or stolen in transit, every message protected by it was compromised.

Glagalbagal accepted the trade-off for high-value customers — Bretchka, whose competitive intelligence was worth real money, and Thvajjik, whose tax data was legally sensitive. Lower-value customers continued with the fixed scramble, which was imperfect but better than plain arrangement.

The system was layered: passwords for access control inside the cave, fixed scrambles for routine messages, changing scrambles for sensitive messages, and physical courier security for the booklets themselves. Each layer added cost and complexity. None was perfect. Together, they made the system substantially harder to breach — not impossible, but expensive enough that most threats were not worth the effort.

Glagalbagal: Security is not a wall. It is a price. We are trying to make the price of breaching our system higher than the value of what it protects.

Blortz: A useful principle. But it means that as the value of your customers' data grows, the cost of security must grow with it.

Glagalbagal: Yes. And there is no finish line.