@promovicz onion routing is a given, but onion routing is not a specific protocol or even encryption technique--it's a very general software pattern for this domain, much like iterators in c++, and it's very specifically for encryption and not anonymity. anonymity seeks to foil traffic analysis and is an information theoretic (i.e. statistical) guarantee.

source routing and QoS SLA negotiation

the problem of active network manipulation is largely mitigated by source routing (i.e. the sender specifies the route) through trusted nodes with per-datagram confirmation signals (i have a protocol for this) so that the source of packet loss or slowness is immediately and always visible to the sender. the protocol i have involves negotiating QoS expectations with each desired intermediate node for the duration of a session--nodes don't have to do the impossible (so they can use any old hardware), but they can't act erratically without notice. if nodes are "evil" but still implement the protocol correctly, they should be unable to perform traffic analysis, even if they coordinate (this is not assumed but proven).

[there are some further intricacies here to ensure that the remaining path hops are not visible to earlier nodes in the route, and that the logical identifier used to associate each incoming datagram with the previously-negotiated session ratchets in a secure way. using double ratchet as the session mechanism is essentially sufficient to solve this, but the reason that works is because the per-datagram confirmation message is used to advance the ratchet in the reverse direction.]

[note also that if the same fixed-length datagram is used for both routing and message data, then longer routes cut into message length, introducing an end-to-end delay predicated upon length. this is unavoidable but worth mentioning.]

neighbor mixing

source routing and per-datagram acks are a general form of network reliability, but this largely just augments the basic onion routing model, and doesn't do the actual mixing which mitigates passive surveillance. the loopix model is the first i've seen to actually formalize and mitigate traffic correlation. the most important constraint here is maintaining a constant bandwidth velocity between pairs of intermediate nodes, so that an adversary cannot observe any ebb or flow of traffic. this is achieved by (a) splitting messages into fixed-size datagrams (b) batching datagrams into the fixed bandwidth per round (c) padding any excess with random data. i consider that much to be relatively obvious, and loopix rises to this very low bar.

batch semantics

[loopix goes somewhat further and additionally injects a delay at each step according to a poisson process. they don't sufficiently justify this at all imho but it's an interesting idea. loopix uses a FIFO queue for intermediate batches, whereas nym (which sucks) sorts batches lexicographically. i would probably do neither and instead do radix bucketing, with the radix parameter ratcheting upon each batch. this is faster than either time-based (FIFO) or data-based (lexical) sorting, and would mitigate the ability of the next hop to infer anything from the relative ordering of messages within a batch.]

summary: source routing fixes bad protocols

with source routing, fixed bandwidth velocity, and negotiated QoS sessions at each step, the sender now has immense visibility into how each datagram travels, and can choose to route each individual datagram independently. this is not in itself a full mitigation yet, but it is a fundamental distinction that i have found in no other anonymity network, and in particular allows the sender to customize routing and message splitting with application-specific granularity. this is necessary to enable mitigations against chosen-plaintext attacks like CRIME and other inferences about relative packet ordering drawn from knowledge of the application protocol.

trashing tor: why network reliability is a security guarantee

it's worth examining what this means in the context of tor's focus on "latency". when tor focuses on "latency", it means that tor attempts to minimize the duration from the packet being sent from source to the packet being received by its intended target. this means tor is specifically architected to enable end-to-end traffic analysis on a per-packet basis. you mention store-and-forward in another reply, and indeed that is the fundamental basis of mixnet anonymity afaiu.

to some extent, networking inherently imposes a state machine by sheer causality constraints--you cannot receive a message until it has been sent, and the message must go through each node in sequence. a passive adversary therefore has >0 information that it can use to infer end-to-end transmission. with explicit QoS and confirmation messages, the ability of an adversary to actively manipulate traffic is largely mitigated--this is not cryptographically secure on its own, but the attacker cannot influence dynamic behavior without exposing that perturbation to the sender. this enables a whole class of mitigations which leverage dynamic behavior. it also enables post-hoc forensic analysis for previously undiscovered attack vectors.

revisiting ratcheting (we're too strong!)

the use of double ratchet sessions for each node may in fact be too strong--the reason we need an end-to-end double ratchet is to take advantage of its support for dropped and out-of-order messages, so that we can send chunks of an application message through different routes, and have the recipient reconstitute them in any order (QUIC is just literally just double ratchet, because TCP cannot do this). double ratchet also supports an asynchronous "mailbox" approach, where the recipient doesn't even need to be online at the same time.

this is essentially the opposite of intermediate nodes, which need to be online to establish a shared session with the sender. our goal for each intermediate step is just to leverage ratcheting for forward secrecy, without any indication of relative order, or indeed any connection between datagrams. intermediate nodes are not merely "untrusted" like the signal server--in fact, this model is specifically stronger than signal's assumptions, because individual intermediate nodes are additionally unable to induce a denial of service (this was a design criteria for this mixnet from the start, in response to experience using tor).

intermediaries from first principles

this might lead one to think: what's the point of sending messages through intermediaries and then testing for success? isn't that kind of circuitous? one answer might be: sure! in fact, a prototype of this scheme could be constructed by just extending the molly signal server to implement the constant-bandwidth batching mechanism, so there's no "routing" and only one "step". what that means though is that if the molly server gets hacked, it can now correlate your message traffic precisely, and you can't route around it if it tries to induce a denial of service.

fuck latency all my homies hate latency

finally, it reduces your throughput to exactly what the molly server can handle in constant-bandwidth batches. most networking applications aren't terribly sensitive to latency, but rather throughput (which is why tor's "latency" goal is excessively puzzling). with source-driven routing, messages can be sent in parallel routes, and if the sender and recipient agree upon terminal "mailbox" nodes, the end-to-end throughput can be as wide as the sum of all the constant-bandwidth connections across all the terminal "mailbox" nodes.

[note that in the initial "agreement" specifying mailbox nodes, the sender and recipient would use ephemeral identifiers for each terminal mailbox, not any global identifier. so even if an adversary controlled all the recipient's mailbox nodes, it wouldn't be able to link those mailboxes to a shared recipient.]

conclusion (inverting history)

so the above was something i independently devised a few months ago after reading up on the history of the internet and finding that vint cerf's ARPANET repeatedly and without fail chose the worst possible version of every protocol to form the modern internet. so by doing the polar opposite of ARPANET at each phase, i developed a pretty consistent system, without thinking of "mixing" as a goal yet. this was purely a thought exercise, upon realizing that corporate monopolies had led each stage of internet standards development, and knowing from google how corporate monopolies develop standards.

louis pouzin: a hater after my own heart

then i found out about louis pouzin (who invented most of the concepts and terminology of internetworking, e.g. "datagram"), and found that his CYCLADES network was shockingly similar to my approach (particularly in considering reliability to be a network guarantee, as opposed to TCP inducing replay attacks without explaining where a packet was dropped). pouzin would directly identify network reliability as a categorical failure of networking standards with memorable phrasing: https://sci-hub.st/10.1016/0140-3664(81)90035-9

The written description takes more than one hundred pages in natural English, which means that X.25 is a system in itself. Why such a monstrous logic was necessary to exchange packets without any guarantee of integrity will go down in history as an interesting design quirk.

after reading this openly fascist IEEE spectrum piece openly gloating over IBM's manipulation of OSI, i began to consider the internet as a weapon of US foreign policy, and sought to destroy it. eventually, i was able to understand my prior investigation into anonymous double ratchet chains as a form of network routing, and the above mixnet was largely assembled.

discovering felten: the first good cryptographer

but i didn't know the word "mixnet" yet. that would come after finding the work of edward felten, who started with OS design and then posted an incredible string of cryptography research, and also removed internet explorer from windows in US v. Microsoft as a fun side quest.

this would lead me to crowds, the first attempt i'd ever found to define anonymity in information theoretic terms, and finally to david chaum's "mixnets".

mixnets aren't that hard?

chaum's 1979 mixnets paper is extremely brief and speedruns my entire investigative process by proposing encryption of pseudonyms as a form of anonymity, then swiftly covering mixing as a routing protocol with confirmations for message transmission. it is exactly as simple as the subject deserves, and as far as i can tell no one has ever tried to implement it until crowds (good), loopix (fine), and nym (bad).

like felten, chaum is currently wasting his time on blockchain shit and not fixing the internet. particularly after learning that QUIC is just double ratchet with extra bullshit, it's pretty evident that the entire internet is worse than useless, and since no one else has a better idea, i might as well make a prototype.

how this all fits together

in the meantime, i also found that operating systems are all aggressively bad at their jobs, and that afaict absolutely no one has ever considered isolating i/o state as an extension to virtual memory isolation. this was a lengthy investigation resulting from learning via copy fail that linux (and POSIX) think every file is also globally mutable shared memory across all processes. since i have researched parallel i/o performance more than anyone else in the history of the world, i know this is a terrible way to architect a system. and a plan suddenly fell into place: