AERN is an authenticated encrypted relay protocol for controlled anonymity domains. It provides certificate-anchored node admission, a managed proxy topology, post-quantum-capable tunnel establishment, fixed-size encrypted relay packets, encrypted route metadata, explicit ingress-to-egress relay sessions, encrypted fragmentation metadata, optional dummy traffic, randomized ingress delay, and backend-neutral transport callbacks.

AERN is designed for private, administered relay domains rather than open volunteer-node operation. The network is composed of a root trust anchor, a domain controller, authenticated proxy servers, authenticated clients, and local backend adapters. Regular relay traffic is carried by symmetric authenticated tunnel states derived from authenticated asymmetric key exchanges.

AERN Help Documentation
AERN Protocol Specification
AERN Summary Document
AERN Formal Analysis
AERN Integration Guide
RCS Formal Analysis

This repository provides the C-language reference implementation of the AERN protocol, developed by QRCS – Quantum Resistant Cryptographic Solutions Corporation.

AERN uses a controlled proxy mesh. Each APS proxy server is certified by the ARS root trust anchor and registered through the ADC domain controller. APS nodes synchronize topology state, exchange certificates, and establish authenticated peer tunnels with other APS nodes in the relay domain. Each peer tunnel maintains independent transmit and receive RCS cipher states and strict per-direction sequence counters.

A client obtains the authenticated APS topology from the ADC, selects an entry APS, and establishes an authenticated encrypted client-to-entry tunnel. The ingress APS creates a logical relay session to an egress APS and sends an encrypted session-open payload before releasing queued non-dummy data. The egress APS validates the session-open payload and returns an encrypted acknowledgement. Backend delivery occurs only after authenticated relay processing, session validation, and fragment reassembly where required.

Relay routes are expressed as compact one-byte APS route hints into the topology-sorted APS list. Route hints are serialized inside the encrypted relay plaintext and are not transmitted as clear relay header fields. Each relay packet uses a consumed-next-hop route path. An intermediate APS decrypts and authenticates the per-hop tunnel packet, consumes the next future-hop entry inside the encrypted relay state, reserializes the relay plaintext, and forwards the packet to the next APS through the corresponding authenticated tunnel.

AERN is built around authenticated membership and controlled topology. Device identities are represented by root-signed certificates. Administrative messages are authenticated by role-specific certificates and freshness metadata. Relay packets are protected by symmetric authenticated encryption, strict sequencing, and timestamp validation.

The protocol security goals include:

• certificate-anchored node admission;
• authenticated topology and revocation control;
• post-quantum-capable tunnel establishment;
• per-hop tunnel confidentiality and integrity;
• encrypted route-path and relay-session metadata;
• strict replay rejection for APS tunnel packets;
• explicit relay-session establishment before backend delivery;
• encrypted fragmentation metadata and bounded reassembly;
• backend-boundary separation;
• traffic-analysis mitigation by fixed-size packets, per-packet route variation, optional dummy traffic, and randomized ingress delay.

AERN is a low-latency controlled relay system. Dummy traffic and randomized ingress delay reduce deterministic timing linkage but are not represented as a complete defense against a fully global timing adversary.

AERN uses the QSC cryptographic library for cryptographic primitives, encoding utilities, networking support, and low-level platform services.

AERN relay traffic uses a fixed 1500-byte wire packet. The visible outer tunnel header is authenticated as associated data. Route state, relay-session state, fragment metadata, payload type, return flag, and backend payload bytes are encrypted inside the relay plaintext.

The compact route profile uses one-byte route hints. Hint value zero is reserved as the route terminator and unused-slot value. A single compact route-addressable APS domain therefore supports up to 255 APS ordinals.

AERN uses explicit ingress-to-egress relay sessions. The ingress creates a pending session, sends a 36-byte encrypted session-open payload, and queues non-dummy data until a 12-byte encrypted session-open acknowledgement is accepted. If the acknowledgement is not accepted before the session-open timeout, pending data is discarded and the session-open attempt fails.

Fragmentation is performed inside the encrypted relay payload layer. Each fragment carries the same session identifier and packet identifier, while the fragment sequence, fragment count, length, payload type, reserved byte, and direction flag remain encrypted. A terminal APS inserts fragments into the reassembly cache only after successful tunnel authentication and relay-header validation. Backend delivery occurs once, after the fragment set is complete, consistent, and bound to the active relay session.

The backend interface is a callback boundary. The relay core authenticates, decrypts, validates, reassembles, and classifies serialized packets. The backend adapter performs external transport integration and must not expose route paths, session identifiers, packet identifiers, fragment identifiers, or payload contents through ordinary operational logs.

AERN uses strict next-sequence processing for ordered APS tunnels. The replay window size is zero. A packet is accepted only if the authenticated sequence number equals the next expected receive sequence, the timestamp is within the configured threshold, and tunnel authentication succeeds.

AERN also defines local traffic-analysis controls:

A typical AERN domain is initialized in the following order:

1. Initialize the ARS and generate the root certificate.
2. Generate and sign the ADC certificate.
3. Start the ADC and configure domain, topology, registration, revocation, and remote signing policy.
4. Generate APS certificates and register APS nodes with the ADC.
5. Synchronize APS topology state and exchange APS peer certificates.
6. Establish authenticated APS-to-APS tunnel states.
7. Register clients and distribute authenticated APS topology.
8. Establish client-to-entry tunnels.
9. Bind ingress and egress backend callbacks.
10. Enable relay traffic, dummy traffic, ingress delay, replay policy, logging policy, and operational monitoring.

A production topology should contain at least three route-addressable APS nodes. The compact route format requires an ingress APS, at least one forwarding APS, and an egress APS for the full relay path model.

AERN is built together with the QSC library and the AERNTest validation project. Build QSC first, then AERN, then AERNTest. The complete validation sequence should be run before operational deployment or parameter-set changes.

Example source layout:

workspace/
  QSC/
  AERN/
  AERNTest/

Visual Studio build order:

1. QSC
2. AERN
3. AERNTest

Portable build outline:

cc -I./QSC -c QSC/*.c
cc -I./QSC -I./AERN -c AERN/*.c
cc -I./QSC -I./AERN -I./AERNTest -c AERNTest/*.c
cc -o AERNTest *.o

The command-line outline is intentionally generic. Select platform files, compiler flags, cryptographic parameter sets, and architecture-specific options according to the deployment target.

INVESTMENT INQUIRIES:
QRCS is currently seeking a corporate investor for this technology. Parties interested in licensing or investment should contact: contact@qrcscorp.ca
Visit https://www.qrcscorp.ca for a full inventory of QRCS products and services.

PATENT NOTICE:
One or more patent applications, provisional and/or non-provisional, covering aspects of this software have been filed with the United States Patent and Trademark Office. Unauthorized use may result in patent infringement liability.

License and Use Notice (2025-2026)
This repository contains cryptographic reference implementations, test code, and supporting materials published by Quantum Resistant Cryptographic Solutions Corporation for public review, cryptographic analysis, interoperability testing, and evaluation.

All source code and materials in this repository are provided under the Quantum Resistant Cryptographic Solutions Public Research and Evaluation License (QRCS-PREL), 2025-2026, unless explicitly stated otherwise.

This license permits public access and non-commercial research, evaluation, and testing use only. It does not permit production deployment, operational use, or incorporation into any commercial product or service without a separate written agreement executed with QRCS.

The public availability of this repository is intentional and is provided to support cryptographic transparency, independent security assessment, and compliance with applicable cryptographic publication and export regulations.

Commercial use, production deployment, supported builds, certified implementations, and integration into products or services require a separate commercial license and support agreement.

For licensing inquiries, supported implementations, or commercial use, contact: licensing@qrcscorp.ca

Quantum Resistant Cryptographic Solutions Corporation, 2026.
All rights reserved by QRCS Corp. 2026.