what jimichi does not protect
a tool that hides some metadata is easy to overtrust. these are the edges, stated plainly.
- the mailbox
- two clients talk under an end-to-end layer, so the mailbox at the exit holds only records of a constant size that it cannot read. it still sees both circuits of a conversation and links them through the queues: the time of every put and fetch, the outcome of a put, the kind and number of a record. together with an observer of both entry links it may link the two clients; how well that does is not measured. a client without the end-to-end layer still has its messages read by the exit.
- a stolen client key
- the hash ratchet has no diffie-hellman step, so there is no recovery after a compromise: whoever takes the current chain key of a direction reads its later records until a new handshake. past records stay closed. whoever holds the private identity key of a client can make handshakes in its name and forge the first handshake record as its contact's to it; that resets only a session that is absent, unconfirmed or stale, and opens no past record.
- a global observer
- the model does not cover an adversary who watches every link at once.
- a compromised device
- if your phone or computer is taken over while it runs, jimichi cannot help. a container file seized or copied at rest is within the model. side-channel attacks on the primitive implementations are outside the model as well.
- root on a relay host
- only the key buffers are locked against swap, and locking does not stop a privileged reader. against root on the machine hosting a node, process-level measures do not work.
- the cooperative memory view
- the key assay observes only three selected client cell keys as exact bytes in voluntarily exported Object payloads. protected primary buffers are outside this view even while live. a zero count establishes neither erasure nor resistance to a privileged reader.
- connection timing
- each circuit opens and closes its own tcp connections along the chain. those moments match and are visible to a global observer; the attack here does not measure them yet.
- an active timing mark
- the measured timing-mark fixture does not establish resistance to arbitrary active attacks or a relay-period threshold. its primary endpoint requires a correct declaration and a responsive original circuit. all-six-circuit closure at 75 ms is availability loss; wrong active and sham declarations remain reported.
- denial of service
- a node gives one address at most its share of links, handshakes and setups and bounds the life of circuits. load from enough addresses to fill the shared caps, filling the setup-tag cache over time, one address that keeps several pairs of nodes busy and so influences which chains survive, and stopping a node are neither prevented nor measured. any node of either circuit, or the mailbox, stops a conversation for as long as it keeps at it.
- coercion
- the client container gives a cover story, not immunity: every container has two regions, so a coercer who knows the software will demand a second password. a surrendered password together with the file gives the identity key, the fetch capability and the contact card of that volume for the life of the container.
where the results stop.
the testbed
- in the cluster the nodes are containers on a single machine. the correlation series do not run there: every node and every client runs inside one process, connected over loopback. network delay, loss and jitter are neither reproduced nor emulated.
- the separation between operators is modelled only as the number of rogue nodes in the choice of a chain.
- the correlation attack runs where the true flow labels are known. carrying the estimates to a real network needs care.
- the dataset is synthetic: message traffic is generated, messages of one size with exponential gaps between them, not captured from real users.
- latency needs a clock finer than a millisecond, so latency runs happen on linux, not on a windows host.
- the correlation series run with as many nodes as hops, in a fixed order, without certificates or onion key rotation, with links between nodes that are not authenticated and with the per-address limits off. the choice of the chain is measured separately and without traffic.
the measurements
- the baseline attack is passive: an observer counts frames per window on the entry link and on the last link between nodes and correlates the counts, on the forward direction only. an auc near 0.5 says that this attack fails, not that a stronger one would.
- the historical f0f1885 c25519 timing-mark series delays one encrypted client-entry flow and scores completed forward frames into the last relay, including padding. it uses a known epoch/common loopback clock, fixed candidates and a bounded code/lag search. the primary endpoint combines correct attribution with an open original circuit and an echoed reserved probe. wrong active and sham declarations remain visible; at 75 ms all six original circuits closed in every execution. the repeat block is the independent unit. shared-host effects, backpressure and closure affect evidence; global no-mark calibration does not bound wrong attribution with a mark. load was observed without post-hoc exclusion, not isolated experimentally. zero observed primary outcomes establish neither zero population probability nor a safe pacing threshold.
- failed attempts and closed or empty candidates stay in the accounting. a circuit is responsive only if it stays open and a reserved probe echoes before cutoff. a successful send return alone does not prove delivery. the published passive tables contain no detection-rate result for this active experiment. no resistance threshold is established.
- connection timing and a learned correlator are not measured yet. the published flow-linking table uses the passive attack; chain selection is measured, and of cost only round-trip latency, bandwidth multiplier and primitive benchmarks. the cooperative client cell-key series is complete, with its separate bounded Object-payload view. external acquisition, disk/swap/history, other secrets and recorded-traffic decryption remain unmeasured beyond v0.4.0. the remaining full node-observation measurements are required for v0.4.0, in design and not implemented; the client container measurements remain planned.
- the correlation series run on the echo topology: the last relay sends every message back. the conversation of two clients through a mailbox does not enter the numbers, and measuring that topology, two entries and the mailbox, is planned.
- the forged conversation in the lab shows offline deniability on concrete keys and measures nothing. deniability of sending is not measured: the distinguisher of payload and cover cells is in place, but it measures relays that forward at once, not the setting the property is claimed for. having nothing to surrender after a session is not measured yet.
messages and delivery
- a message has to fit one cell: at most 444 bytes over three hops. a longer one is refused with an error and not sent; there is no fragmentation and there are no size classes. the wire length says nothing about a message only because a message never spans cells. between two clients the body of a record is at most 368 bytes, the text of a testbed message at most 363.
- delivery is not guaranteed. at a constant rate a client without the end-to-end layer queues at most 256 messages and drops a new one without an error when the queue is full; a message in the queue or on the way is lost when its circuit closes. nothing acknowledges or resends a message.
- a -peer client gives no reliable delivery either. a refused put only delays a message, but a record the mailbox has stored is not put again, so a message is lost with it when its lifetime at the mailbox runs out, its queue is evicted or it is lost in a fetch reply. a body whose put has an unknown outcome is sent again, so a duplicate is possible, and the order of messages is not kept across refusals.
- there is no isolation per contact. a -peer client has one contact per process, one circuit and one queue; a second contact needs a second process. circuits and queues per contact are planned. there are no groups and no multiple devices.
conversations through a mailbox
- the mailbox sees both circuits of a conversation and links them through the queues: per circuit the fetch capability in clear, the put queue, the time of every request, the outcome of a put, the kind of a record, its number and the copies of one record. together with the entries it gets the graph of the pair, and together with an observer of the links of both entries it may link the two clients by a correlation attack. how well that does is not measured. queues without a lasting identifier and circuits per contact are planned.
- the exit of a -peer client is pinned to the mailbox: a rogue mailbox is in every conversation of its clients, and with a rogue entry it holds both ends of the chain, with probability 1/4 on the testbed. what such a mailbox knows of the route when it follows the protocol is derived from the protocol: on the side of a -peer client it names only the middle hop. what it sees and links is not measured.
- before the session the puts carry handshake records only, so the mailbox sees the moment of the handshake. with cover puts, the default, a client puts a record on every tick, a dummy one when no message waits, and the mailbox cannot tell a real record from a dummy. without them it also sees the moment and number of real messages. a refused put shows the contact and the mailbox that the other side does not fetch.
- with cover puts each side puts one record and fetches one on every tick, so nothing works off a backlog: every tick on which a side does not fetch, during a rebuild of its circuit or a pause of its process, leaves one more record of the peer in its queue, and every later record of the peer waits that many ticks longer. the backlog is bounded by the queue depth, 16 records by default: past it a put is refused and the peer resends, possibly out of order, so a record waits at most 16 ticks longer, 3.2 s at a rate of 200 ms.
- the mailbox removes a record when it hands it out, and a record is not put again once a copy of it was stored: a record whose every stored copy is lost in fetch replies, together with the receiver's circuit, is gone. a real message is then lost; a lost handshake record costs a 60 s wait and a new handshake; after the initiator's first record after the handshake is lost, the responder sends no real message until the initiator's next record opens, up to 30 s without cover puts. the responder has no way to ask for that record.
- once the node that stopped a conversation lets go, the conversation recovers by a rebuild and a new handshake within about 5 min. three refused replies within 10 min, or 10 min without a circuit, end the client.
- the queues of the mailbox can be exhausted: n queues that cannot be evicted cost about n/2 setups of short circuits per queue lifetime, or n open circuits with one request each per lifetime, for up to 24 h, and such queues stand in the way of new pairs. quotas are planned.
- the identity and the pinned contact of a -peer client live only in process memory: a restart of either client gives a new identity and needs a new introduction. the client container is built, but the -peer client that keeps its identity in it across restarts is planned.
- the introduction on the testbed trusts the cluster's api: whoever may read the client pods' logs and forward their ports can pin any contact card before the first pin or after a restart of the client. a script, not people, compares the card hashes. a client that is offered another card after the pin refuses it and stops until the operator restarts it.
- the logs of the testbed clients reach the disk of the cluster node: a line per message and a counters line every minute give the time and number of messages, and the hash of the pinned card links the logs of the two clients of a pair.
cryptography and memory
- the gost implementation is not a certified cryptographic facility. the algorithms are the same and checked against the standards test vectors, but no protection class is claimed.
- the gost library comes from a mirror of its author's module, pinned by version. whether its code equals the author's release has not been checked against an independent source yet.
- the two suites do not mix: a node runs one suite and a client refuses an anchor or a descriptor of the other, so gost users and c25519 users form separate networks. both handshake flights have the same size on both suites; plain http descriptors still name the suite.
- every derived key is bound to the transcript of its exchange, the suite and the scheme version, but only the tests of wire and link keep the content of the transcript right: the interface guarantees that no key can be derived without a transcript, not that the transcript holds everything it should. there is no formal model of the setup or of the link handshake; a model of the setup is planned.
- links use the noise symmetric transitions and share a token machine with the compatible end-to-end profile. standard noise vectors exercise the production link transitions with only a standard cipher and fixed ephemeral inputs substituted. production uses custom xchacha or gost algorithm combinations, so stock noise wire interoperability and a proof of either combination are not claimed.
- there is no negotiation of the key scheme or link version: incompatible sides fail the handshake without fallback. nodes and clients are updated together. with node authentication on, the peer identity is bound to the exchange; a side that binds different identity bytes derives different keys.
- libraries keep their own copies of keys on the go heap. the aead working key stays there for the life of the circuit or link and is never wiped: it remains until that memory is reused. secmem protects only its own buffers.
- the cooperative key assay matches only exact contiguous bytes of three client cell keys within parsed Object payloads of one voluntary go 1.27.3 export. stacks, globals, runtime and system regions and mmap payloads are outside the view, including the protected primary buffers while live. a complete parse does not give complete heap or process coverage, and the runtime may silently omit data.
- none and all change several memory measures together. fewer matches may mean that buffers moved outside the view; the assay isolates no individual measure or process hardening. extra matches cannot distinguish library copies from compiler or runtime copies induced by the export, and transformed key state is not searched. a zero count proves neither erasure nor an erasure deadline.
- each checkpoint uses a fresh process and keys: during the circuit, just after successful cleanup or at least one monotonic second later. independent snapshots do not trace a key lifetime; natural gc and actual delays belong to this schedule. failed, unsupported and unavailable observations are excluded, never zero matches. all 360 registered observations evaluated. c25519 exact bytes remained observable under all after close; gost post-close zeros do not prove erasure or exclude transformed states. host cpu had 30 series samples, 3-33%, median 11.5%, mean 12.4%, including assay work; unrelated load cannot be isolated; no load exclusion or performance claim. relay, link, setup, end-to-end, ratchet and vault secrets remain unmeasured.
- only the secmem buffers are locked against swap. the copies on the heap lie on ordinary pages and can be written to swap; locking all process memory is planned.
- message plaintext is not wiped anywhere. the client wipes neither its messages nor its replies, and the exit does not wipe the plaintext it opens: all of it stays in process memory until that memory is reused. it is not key material, and the key memory measures do not cover it.
- the end-to-end layer is shaped like a noise handshake but is not an instance of noise. there is no formal model of the kk handshake over the crypto interface, and the gost composition is checked by a harness matched on c25519.
- a -peer client holds its identity key, its fetch capability and the current ratchet chains in locked memory until its process ends and writes none of them to disk. surrendered, the identity key opens only future handshakes, and the current chain only the later records of its direction.
- on the gost suite every signature leaves copies of the signing scalar and the one-time number on the heap. when certificates are issued from a windows host, the ca key stays in unlocked memory without dump prevention while it issues.
- forward secrecy of the circuit layers reaches as far as the life of a node's onion key. a node replaces that key on a timer and releases the replaced one once every descriptor that named it has expired: a setup cell kept by a neighbour opens for at most the rotation period plus the descriptor lifetime and the clock allowance after its key was first published. the shortest window a node can be configured for is 36 minutes. node memory taken after the release does not open the cell, and a wire capture alone cannot be read without the ephemeral link keys.
- rotation does not cover the hop keys of circuits that are alive when memory is taken, the link key, which lives as long as the process, or the copies of released keys and setup secrets that the libraries left on the heap. the window holds only while rotations succeed and the node can act: a sleeping host or a frozen process keeps its memory until it runs again.
- rotation is the node's own doing and a client cannot check it: a descriptor shows that the published key changed, not that the replaced one was released. the measurement baseline runs without rotation, and there a node's layers can be opened for the whole time it ran once its key is stolen.
- the frame keys of a link and the hop keys of a circuit do not change while the link and the circuit live: cells under a hop key are bounded only by the counter limit, frames under a frame key only by the frame number. rotation inside links and circuits is planned.
- the cell format has constant size and replay protection but is not full sphinx: nothing else hides a node's position in the chain.
- a key from a password is cheaper to guess offline in the gost suite than in c25519: the gost suite stretches a password with pbkdf2 and hmac-streebog-512, which needs no memory, since the tc26 recommendations have no memory-hard function, while c25519 uses argon2id with 64 mib. the iteration count matches the processor time of argon2id only for the streebog of the testbed in linux containers; with an optimised streebog, on gpus and on dedicated hardware a guess costs less, by how much is not measured. the client container takes this key.
node authentication
- the client takes node keys only from a bundle verified against a trust anchor, the public key of the certificate authority, and checks every bundle on its own: a listed bundle that fails the check counts as a node the entry left out, and the entry's own bundle must pass, or the client refuses to build the circuit. whoever can change the anchor in the client's configuration decides which nodes the client trusts.
- the ca key exists only while certificates are issued. whoever holds it, the operator or someone who stole it during issuance, can certify an identity of their own for any name and address and, with a position in the network, substitute nodes. a node certified by another ca joins no chain while the client holds the anchor of the testbed and node authentication is on, which a lab test with real nodes checks; a client that draws such a node as its entry still asks it for its mirror before refusing it, so that node sees the address of the client and the moment it starts. how often a randomly drawn chain meets the nodes of the key holder is computed and sampled; what each of them knows of the route is derived from the protocol, and what they see and link is not measured. past circuits stay closed to such a substitution.
- issuance on the testbed trusts the operator's access to the cluster. whoever controls the host or its docker network can substitute what passes between the ca and a node during issuance and impersonate that node.
- there is no revocation beyond the certificate's expiry and a node restart with a new issuance under a new ca. a signing key taken from the memory of a live node impersonates that node until whichever comes first.
- a node process takes one certificate and one roster, and node keys live only in process memory, so every restart needs a new issuance, and an issuance needs fresh processes of all nodes; until then clients refuse the node and it extends no circuit. whoever has the operator's access to a fresh node can enroll it under a ca of their own first: clients holding the operator's anchor refuse that node, and it stays out of service until it restarts.
- the same access lets them send a node its roster before the operator does. the node list of a roster is not authenticated: such a roster must name the anchor that certified the node and gives it as peers only nodes whose descriptors verify under that anchor, so it can leave nodes out but not add one.
- nodes publish their descriptors themselves and there is no directory, so a node could show different keys to different roster nodes, and so to the clients of different entries. with -consistency, on by default, the nodes read each other's mirrors once a minute and keep every descriptor a node signed: two of its descriptors that break a rule, such as two onion keys under one epoch, are a proof that every node and every client verifies under its own anchor, and the node is refused by all of them. what stays is a window: for up to 201 s on the testbed after a rotation first reaches an honest mirror, two honest mirrors may carry adjacent epochs, at most twice per 16 min, and the key that opens a setup cell then tells the node which of the two groups of mirrors the entry belongs to, one bit per circuit built inside the window. a refused node also shortens the list of every client by one.
- with node authentication on, setup and links bind the node identity certified by the trust anchor. a kk link binds both identities and the initiating relay address used for a verified roster lookup. the address only selects a record; the first authenticated transport frame confirms the initiator's possession of the final keys. certificate hashes are not in the transcript. issuance checks roster addresses, signing keys and onion keys for duplicates, but not link keys.
- certificates and descriptors carry validity times, so the clocks of nodes and clients must agree within the allowed skew.
links between nodes
- with node authentication on, client-entry links use nk and authenticate the entry. relay-to-relay links use kk and authenticate both peers against verified roster descriptors. an authenticated relay refuses nn and an unknown or expired kk peer without fallback. clients remain unauthenticated to the entry; a client nk link does not claim relay membership.
- the responder confirms the initiator's final keys only when the first transport frame opens and sends no application data before it. the first kk flight is replayable and can be forged after the responder's static key is disclosed; it carries no circuit setup. the version, role and kk address selector remain visible. both handshake flights and transport frames have the same fixed size.
- the baseline without node authentication extends a circuit to any address named in the setup cell, and its links between nodes are not authenticated: they hide headers from a passive observer only. its client takes the unverified keys of every hop from the entry alone. no experiment block compares it with the authenticated configuration; the correlation series run without certificates as well.
- every node mirrors the verified bundles of the roster nodes it holds, and the client asks its entry alone, for every node it lists, so the request does not show the chain. the entry cannot alter a bundle: an altered one fails the check and counts as left out. it can withhold the mirror, and the client then exits and draws another entry at its next start; a -peer client does so only before its first circuit, and on a rebuild asks the same entry again until it exits after 10 min. it also sees when a client prepares a circuit: the request for the descriptors precedes the setup.
- a node lists a peer's bundle in its mirror only from its start on the node's clock until 2 min 6 s before it expires, so a client whose clock differs within the allowed skew still finds it valid; outside that window the peer counts as a node left out. the node keeps the descriptor, and extends circuits to the peer, until it expires. after a peer restarts, the mirror serves its previous bundle for up to the descriptor lifetime, and circuits through that peer fail at setup: the new process holds another link key and does not pass the link handshake.
- whoever installs a roster chooses which hosts a node polls on the info port: the node asks every roster address for its descriptor when its entry is due, and goes on asking, with a 5 s pause between passes, for as long as the peer is missing or the entry stays due, which includes a peer that still serves a descriptor it has not signed again. no roster address is asked for its descriptor more often than once in 5 s; with -consistency the node also reads the mirrors of four roster nodes drawn at random once a minute, over a path of its own. a roster names every host once, so the bound holds per host as well, but only per spelling: a host reached under several names, or under a name and an ip address, gets one request per such address in a pass. a peer whose entry ended with its certificate is asked once a minute from then on, until the node restarts. the addresses are ip literals and dns names only, and an answer counts only if it verifies under the roster's anchor.
choice of the chain
- the node list of a client is static: there is no node discovery and no directory signed by several parties that would settle which nodes exist. the setup cell bounds a chain at four hops on c25519 and three on gost.
- the entry may leave a bounded number of listed nodes out of its mirror, one by default, and a listed bundle that fails the check counts against the same bound; the chain is then drawn among the rest. a rogue entry that leaves out an honest node raises the chance that the exit is rogue as well.
- a node that withholds its descriptor from the others removes itself from their mirrors, and they extend no circuit to it. when more nodes do so than the client allows, only the mirrors of the withholding nodes satisfy it: with two such nodes of five and an allowance of one, every chain that comes up enters through one of the two and ends at an honest node. the case is computed and sampled. a larger allowance gives a rogue entry more room to steer.
- a node that refuses or breaks the circuits it does not like decides which chains survive: a client without the end-to-end layer exits on a failure, draws a new chain at its next start and keeps no account of failures. this selective denial of service is neither prevented nor measured.
- a -peer client does not exit when a circuit ends but rebuilds it through the same entry: first the same chain, and new middle hops only when that chain cannot be dialled, at most twice per process. so a rogue entry that closes every circuit through an honest middle hop gets at most three draws of the middle hop. on the testbed, with an honest mailbox and two rogue nodes among the other four, its colluder ends up as the middle hop with probability 7/8 under a rogue entry that leaves an honest node out of its mirror, against 1/2 for a single draw, and with the middle hop the entry learns which mailbox the client uses.
- the far side drives the redraws as well: a rogue mailbox that leaves every request through an honest middle hop unanswered gets its colluder as the middle hop with probability 19/27 under an honest entry instead of 1/3, and the middle hop sees the entry, so the mailbox learns the entry of its client. both values are checked by enumerating every outcome of the draws.
- the bound holds per process. a client that cannot build a circuit for 10 min exits, and the new process draws a new entry with a fresh budget, and a new identity that has to be introduced again. which processes survive is the same unmeasured selective denial of service.
- there are no guard nodes: a client without the end-to-end layer draws a fresh entry for every circuit, a -peer client one for every process, so the chance that at least one chain had a rogue entry and a rogue exit grows with every restart of the client.
- the node counters are exact sums and carry no circuit identifiers, but with few circuits a sum describes single ones: on the testbed, with two clients, the nodes whose counts of cells grow are the nodes of their chains, and the counters also show the entries and the mailbox. whoever reads the node output learns that.
replay and cell order
- a node remembers a tag of every circuit setup cell it opened for as long as the onion key that opened it lives, and drops a copy. the number of tags under a key is bounded: a full node refuses new setups under that key rather than forget a tag, until the next key is published, or until it restarts when rotation is off. anyone who builds circuits can fill the cache over time. this is a denial of service.
- a tag holds no key, but a memory dump gives an upper bound on the number of circuits set up under the keys the node holds, and together with the onion key and a kept setup cell it confirms that the node carried that circuit.
- cell counters take a value of their own on every link and follow strictly one after another: a copy, a gap or a reorder closes the circuit. a neighbouring node can cause one with a single cell. a party on the wire cannot put a frame of its own on an authenticated link, but a frame it damages or a connection it breaks closes the circuit all the same. this is a denial of service. the client checks every reply the same way and closes its circuit at the first one that fails, or at a frame from its entry that does not open, which anyone on the wire can cause; a reply that never arrives is noticed only by waiting. a -peer client then rebuilds its circuit through the same entry and exits after three such replies within 10 min. between two clients a record the mailbox or a node changed does not open at the recipient and is dropped.
node limits
- a connection is admitted or refused before any key agreement, and one address gets at most its share of links, handshakes and setups. once a shared cap is used up the node refuses new connections. this is a denial of service; each slot is held at most until its deadline, the idle timeout or the circuit lifetime runs out.
- a node cannot tell a relay from a client, since the responder of a link does not authenticate the initiator, and any node can be an entry, so every node keeps the per-address limits. at a middle or exit node every circuit that came through one relay arrives from that relay's one address, and those circuits share one address's allowance: one client can use it up for every other client whose chain crosses the same two nodes in the same order.
- one address can keep several such ordered pairs of nodes busy at once. its allowance is counted at every node separately, and a chain of its own crosses up to three pairs on c25519 and two on gost: on an otherwise idle network that is, through n entries, up to 3n ordered pairs on c25519 and 2n on gost, 15 and 10 of 20 with five nodes. a chain that crosses a busy pair fails at setup: a client without the end-to-end layer exits and draws another, and for a -peer client two such circuits in a row give one of its two redraws, so the address influences which chains survive. a holder of the ca key with rogue nodes in the roster can keep the pairs between honest nodes busy and leave the pairs through its own nodes free. what that costs and how far it raises the share of surviving chains its nodes hold is not measured; the measurement is planned.
- on the testbed a cell port takes connections from client and relay pods only, where the cluster's network plugin enforces network policies. the testbed runs two clients with one circuit each, so the shared allowance does not bind there.
timing
- sending on a node's own clock needs the node period a few percent shorter than the client's; the testbed uses 5%. with equal or longer periods a missed tick is never caught up, the node's queue fills up sooner or later, and the circuit closes.
- a link is covered only if the node sending on it has the measure on. the client cannot check that its nodes do.
- a node does not mix: it adds no random delay, gathers no batches and does not reorder cells between circuits. it forwards a cell at once or, with own-clock sending, one frame per tick in the order of arrival. random delays and mixing at nodes are planned.
- the circuit setup cell leaves at once, not on the node clock, and marks the start of a circuit on every link.
- without own-clock sending the exit's reply leaves once the request is handled. a mailbox reply has a constant length, but the work per request is only bounded, not constant, and the difference of microseconds enters the moment of the reply. on the testbed the exit sends on its own clock.
- a circuit is torn down after the idle timeout and at the end of its lifetime. a client without the end-to-end layer does not rebuild it: the client process exits and builds a new circuit at its next start. a -peer client rebuilds it through the same entry. the moment depends only on the node parameters and the last cell; the lifetime shows only the age of a circuit, which the connection open time already shows.
deniability
- the moment of sending is hidden only at a constant rate with the relays sending on their own clocks, which the testbed sets: in the immediate mode, the default of the client, a cell leaves when the user sends, and without cover traffic every data cell is a message, while with relays that forward at once the moment of the reply from the exit depends on the kind of cell. a -peer client sends a request on every tick, and from the mailbox the moment of sending is hidden only with cover puts, once the session is established and while the contact fetches.
- deniable authentication between clients is offline only. the handshake is made of key agreements only and the client has no signing key, so the recipient can build a transcript with the same messages, distributed like the genuine one, from its own keys alone: a transcript, even with the recipient's private keys, does not prove the sender's participation to a third party.
- it does not hold for a witnessed transcript: a mailbox or an observer of the sender's link colluding with the recipient keeps an independent record of who sent the ciphertexts and when. online deniability, against a judge acting with the recipient during the session, deniability of metadata and a sender's device compromised before the session are not claimed either.
- the argument rests on the symmetry of the key agreement, which the tests check, and on the transcript holding no other random value; there is no formal model.
the client container
- the container is one file of a constant size: a salt and two sealed regions. a region without a volume holds an empty volume under a key that was thrown away, and which region a volume takes is random. the file holds no key material in any form, not even encrypted: the identity key and the fetch capability are derived from the volume key at every opening. yet the file with the password of a volume reproduces them, so against seizure of the file together with the password the strength is that of a key stored under a password.
- what is claimed: the file in one state and the password of one volume do not show whether a second volume exists. this rests on stated assumptions about the password stretch, the aead and the key derivation and on reasoning without a formal proof, and holds only for a generated password of the second volume, which jimichi vault init makes itself. a generated password is printed once; terminal history and redirected output are not covered. for a password a person chose, which jimichi vault init takes with -stdin, it is not claimed on either suite, since such a password lies within an offline search; on gost a guess is also cheaper, the stretch needing no memory, by how much is not measured. that the file without a password looks like random bytes rests on an assumption that is not proven for kuznyechik-mgm. even so, a seizer learns that it is a container: the command line that names it, its path and its constant size give it away; what is hidden is whether it holds one volume or two. the distinguisher that will measure the claim is planned.
- the file is written once, at creation, and an opening only reads it, so its states after creation are the same byte for byte: seizures on different days, backups and synchronisation give nothing beyond one state. a write retried after a failure writes the same bytes. what remains is the filesystem: mtime, ctime and the creation time show when the container was made and atime the openings, and how many traces of the creation are kept by journals, shadow copies, wear-leveling and trim is not measured. a temporary file left by a creation killed before its link is another container with its own salt; it is removed at the next start, but removal does not wipe the blocks on the drive.
- the second volume is a cover story, not immunity. a coercer who knows the software will demand a second password, and the story holds only while it is used: an inactive queue of the decoy at the mailbox and a decoy contact that never answers give it away.
- a surrendered volume gives its identity key and fetch capability, by derivation, for the whole life of the container: one can pose as the owner to the contact, take and delete the records of the owner's queue and see whom the owner talks to. there is no rotation or revocation, and the only way out is a new container on both sides. changing the password changes the identity, and the pin on the contact's side is permanent, so a new introduction needs a new container there too. changing the contact likewise means a new container, a new identity and a new introduction, and the contact card of a second volume is needed already at creation.
- an active adversary between seizures can damage a region or replace the other region with a fresh empty volume. a changed volume does not open, but to the owner of the second volume a replacement looks like a wrong password, and a container recreated on the same device shows at the next seizure that a second volume existed.
- a running device is not claimed: copies of the password, of its stretch and of the identity key stay in library memory on the heap and can reach swap, the page file and the hibernation file. these representations are outside the cooperative cell-key assay and remain unmeasured. on gost the time of an opening on the device itself tells volumes apart, though it says nothing about the key, and side channels are outside the model.
- the -peer client does not use the container yet, and it will have limits of its own: a constant fetch capability is a constant queue by which the mailbox will link every run with that container, a restart for any reason will leave the client locked until the operator opens the volume, and the times of log lines will show the starts and the openings.
- the container is bound to its key scheme, its stretching cost and its identity derivation: changing the scheme or the cost makes earlier containers impossible to open, changing the derivation gives them other identities, and there is no migration. a container that can be updated, with a message history, is not built; against several states it would need a measure of its own.