What OpenFlux Protects—and What It Leaves Exposed

OpenFlux contains several mechanisms that are easy to collapse into the word “security”: compression, optional authenticated encryption, reconnects, queues, and status reporting. This chapter separates them. It asks what the cryptographic wrapper protects, what a Yandex or MAX carrier can still observe, how local reliability mechanisms shape an application’s experience, and what the repository’s tests can actually establish. The useful judgment is not whether OpenFlux is simply secure or insecure, but which property each layer provides and where that property stops.

Payload protection is not carrier invisibility

Compression and encryption enter the transport path for different reasons. The compression wrapper first decides whether a packet is worth compressing. Small or incompressible data can be marked as raw; a larger payload is encoded with LZ4 only when the result is smaller than the raw representation plus its marker. On the receive path, the marker selects raw handling or decompression. This can reduce the number of bytes sent through a carrier, but it does not authenticate them or keep their contents secret.

OpenFlux’s optional encryption layer addresses a narrower security problem. It derives a master key from a shared secret using a password-hardening function, derives separate keys for the two traffic directions, and uses AES-GCM to encrypt and authenticate each packet. A random nonce makes each frame distinct. The small header identifies the OpenFlux format, version, and direction, and that header is authenticated along with the ciphertext. The receiver checks the direction and authentication tag before handing data to the outer decompression layer.

The directional design matters because the two endpoints do not use one undifferentiated key for both directions. A client-to-exit frame is expected to use one key and direction marker; an exit-to-client frame uses the other. A packet that arrives on the wrong side or carries the wrong direction is rejected. The receiver also keeps a bounded record of seen nonces, so a captured valid frame is not accepted repeatedly within the remembered replay window. This is meaningful packet-level protection under the shared secret, not a general statement about the safety of the whole connection.

flowchart LR A["Plaintext packet"] --> B{"Compression decision"} B --> C["Raw or LZ4 representation"] C --> D{"Encryption enabled?"} D --> E["AES-GCM with directional key"] D --> F["Unencrypted payload"] E --> G["Carrier framing and session"] F --> G G --> H["Carrier-visible timing, size, and service relationship"] G --> I["Queue and reconnect loop"] I --> J["Stats and log output"] E --> K["Tag, direction, and nonce checks on receive"] K --> L["Decrypt and decompress"] L --> M["Recovered packet"] H -.-> N["Anonymity and provider approval remain unproven"]

The wrapper order is part of the claim. In the main construction, compression is outside the optional encrypted transport. On send, the outer layer makes its compression decision before the inner encryption layer produces ciphertext. On receive, the encrypted layer verifies and decrypts before the outer layer interprets the compression marker. This arrangement allows compression to operate on the packet representation before encryption makes the data intentionally difficult to compress.

The result is not “the carrier sees nothing.” With encryption enabled, a carrier that does not hold the shared secret should not be able to read or alter the protected payload without detection.