Proxy Alice: Predictive Messages For Concealed Communication

Abstract

Traditional cryptography protects message content but doesn’t hide the fact that two parties are communicating. Steganography can conceal messages within other data, yet the data flow itself often remains detectable. “Proxy Alice” introduces a theoretical approach where Bob locally generates most of Alice’s messages without needing constant updates from her — reducing the observable communication footprint.

Introduction

In cryptography, the primary goal is to protect message confidentiality from unauthorized observers.

However, in many scenarios, the very fact that two parties are communicating can also be sensitive.

Traditional steganographic approaches aim to hide the existence of a message within other data. Yet, these methods still require a flow of data.

Fundamentally, you can’t hide the fact that communication is happening, because every act of communication generates a signal of some sort.

The only way to keep communication truly secret is to prevent Alice from sending messages to Bob.

Enter Proxy Alice.

Proxy Alice presents a theoretical approach to reduce the frequency of overt communication by preemptively generating messages that reflect “what Alice would send” under a wide range of predictable conditions which are observable by both Alice and Bob.

In essence, Bob would possess a program — Proxy Alice — capable of producing these messages offline, without requiring Alice to transmit them in real time.

Consequently, Alice only needs to send messages when she wants to update the algorithm, or when new information arises which only she knows. This minimizes detectable traffic and thereby conceals communication in most routine cases.

System Architecture

Most messages follow predictable patterns. By encoding these patterns in an algorithm, Bob can locally compute what Alice would have sent.

Proxy Alice

Proxy Alice is a rule-based or machine-learning model (for example, a Prolog program) that encapsulates Alice’s expected decision-making.

It encodes logic such as “If input X then generate message Y.”

Function Library

Proxy Alice has has a secondary “function library” for edge cases, consisting of functions that generate specific messages. Then, if Alice wants to share new information that closely matches an existing template, she can send Bob a function identifier and parameters instead of an entire new message.

Language Model

Proxy Alice might include an embedded LLM trained on Alice’s communication style, with a shared seed or low temperature, so that it can deterministically generate a given message “in the way Alice would have said it.”

Alice runs the same generation on her side to verify intelligibility and accuracy.

Algorithm Update Mechanism

Whenever Alice encounters a situation outside the scope of the current Proxy Alice, she generates an “algorithm update message”, and shares it using traditional cryptography and steganography.

The message might contain small additions or modifications to the decision rules or to the function library.

These updates would occur infrequently enough to avoid detection under normal circumstances.

Feedback Loop

Bob can note inaccuracies or misunderstandings in the messages generated by Proxy Alice, and send feedback to Alice using traditional cryptography and steganography.

Alice incorporates this feedback into the next algorithm update to improve accuracy and alignment.

The number of actual messages sent would be fewer than with traditional systems.

Example Workflow

1. Alice creates a “Proxy Alice” program that captures the majority of scenarios for which she typically needs to send messages to Bob.
2. She sends this program to Bob once, ideally by physical exchange.
3. Bob’s local copy of “Proxy Alice” accepts real-time inputs (e.g., sensor data, business metrics, or personal preferences) and generates the messages that Alice would have sent if she were actively present.
4. Bob reads and interprets these messages without needing direct, real-time communication from Alice.
5. Alice faces a situation not covered by the existing program.
6. She prepares an “algorithm update” containing new rules or expansions of existing templates.Alice covertly sends the update via a secure or obfuscated channel.
7. Bob installs the update in “Proxy Alice,” enabling future offline generation of messages under these new scenarios.
8. Bob provides feedback on the local output quality.
9. Over time, updates improve “Proxy Alice,” reducing the likelihood of requiring subsequent changes.

Security Benefits

Frequent message exchanges are replaced by local computations and infrequent updates, making real-time communication patterns virtually invisible.

By shifting the burden of message creation to Bob’s Proxy Alice, there are fewer data traces that can be detected.

The system can be tailored to specific domains or industries, as long as predictable routines can be modeled.

Limitations

This approach hinges on Alice’s messages being largely predictable from known inputs.

If reality is highly dynamic and unpredictable, frequent updates become necessary, reducing stealth.

Also, designing a robust Proxy Alice that accurately captures complex decision-making may require substantial effort, including a well-structured knowledge base and advanced inference mechanisms.