{"id":"08d045c8-f714-46ab-8683-e7672cf45fe1","arxiv_id":"2411.13827","paper_version":1,"verdict":"REJECT","confidence":"HIGH","novelty_score":2.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"A relay-based, end-to-end encrypted file transfer protocol using sPAKE2 and NaCl secretbox is proposed and benchmarked against WebRTC, FTP, and SCP.","lead":"The authors designed a relay-based file transfer tool that encrypts file chunks with a password-derived key and benchmarks it against WebRTC, FTP, and SCP. The paper is worth a look because it claims end-to-end security against a malicious relay, a claim the described design appears to break.","discovery_kind":"incremental","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The relay can read the file: it learns the passphrase and brokers the sPAKE2 exchange (Sections 3.2 and 3.1.2), so it can run an active MITM, establish separate keys with each client, and decrypt the NaCl chunks; the claim in Section 3.1.1/3.3 is unsupported.","rationale":"The security claim is the core contribution of the paper, so the strongest load-bearing concern is that the relay can decrypt the transferred file. The reader correctly identifies the design contradiction: the relay receives the secret passphrase (Section 3.2), stores it, and brokers the sPAKE2 message exchange. An active relay that knows the password can impersonate each side to the other, derive two independent session keys, complete key confirmation on both legs, and read or even alter the file without detection. This is not a novelty or benchmarking objection; it is a correctness flaw in the central thesis. The only way to preserve the claimed property would be to keep the passphrase secret from the relay or use a verifier that does not allow impersonation, but the paper does the opposite by design. The concrete MITM test would definitively show whether the described implementation is vulnerable. Because this is the same load-bearing flaw identified by the reader and it invalidates the strongest claim, the REJECT verdict should stand unchanged.","tokens_in":8340,"tokens_out":4462,"duration_ms":46713,"concrete_test":"Run the described relay-based implementation with a relay modified as follows: after the receiver submits the passphrase, the relay stores it; during the sPAKE2 handshake the relay generates its own ephemeral private keys for both legs and replaces the forwarded public shares; it completes key confirmation on each leg using the transcript values it controls. Then have the sender transmit a 1MB test file and check whether the relay can decrypt the first 16KB chunk with either leg's derived session key. If the key opens the chunk, the malicious relay has read the file and the central claim fails. A complementary formal check is to model the protocol in ProVerif with the relay as attacker who knows the passphrase and query whether the attacker obtains the file; a successful trace is definitive.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.1.1 claims the mechanism is end-to-end encrypted so \"even the relay server cannot read the contents of the data packets,\" and Section 3.3 claims the protocol is secure against malicious relay servers. The design contradicts this: Section 3.2 says the receiver sends the secret passphrase to the relay, the relay stores it in SQLite, and the relay is \"responsible for exchanging the sPAKE2 messages.\" Since sPAKE2 is password-authenticated, an entity that knows the password can mount the standard active MITM attack: it replaces Alice's and Bob's ephemeral public shares with its own, derives session key K_A with Alice and K_B with Bob, and computes the corresponding confirmation MACs for both legs. Both clients see successful key confirmation and believe they are talking to each other. The relay can then decrypt the NaCl secretbox chunks with the key it shares with the sender and read the file; it can also re-encrypt with the key it shares with the receiver if it wants to avoid detection. The authenticated encryption detects modification but not this attack because the relay holds valid keys. The sPAKE2 security claims in Section 3.3 hold only against an attacker who does not know the password; the relay is given the password by design. Thus the central security property is false as stated unless the relay is assumed honest, which is exactly what the malicious-relay claim rules out.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a relay-server-based device-to-device file transfer protocol that combines sPAKE2 for key establishment and NaCl secretbox for authenticated encryption, with WebSockets/TCP for transport. The authors claim the scheme is end-to-end encrypted so that the relay server cannot read file contents, and that the protocol is secure against malicious relay servers. The paper also provides a qualitative comparison of security properties across several file transfer methods and a set of benchmark timings for different file sizes.","tokens_in":8602,"tokens_out":2870,"duration_ms":26748,"significance":"If the security claims were correct, the work would offer a useful open-design, relay-based file transfer alternative with strong end-to-end encryption and good performance for large files. The paper also provides a transparent comparison with WebRTC and other protocols. However, the central security property is undermined by the protocol design itself: the relay receives the passphrase and brokers the sPAKE2 exchange, enabling a straightforward active man-in-the-middle attack that decrypts the file. The benchmark results also lack statistical grounding. Given these issues, the contribution does not currently meet the standard for a security venue.","major_comments":[{"comment":"The claim that the mechanism is end-to-end encrypted so that \"even the relay server cannot read the contents of the data packets\" (Section 3.1.1) and that the protocol \"is secure against malicious relay servers\" (Section 3.3) is contradicted by the design described in Section 3.2. There, the receiver sends the secret passphrase to the relay, which stores it in SQLite, and the relay is \"responsible for exchanging the sPAKE2 messages.\" An entity that knows the password and controls the transcript can perform the standard sPAKE2 man-in-the-middle attack: it replaces each client's ephemeral public share with its own, derives a key with the sender and another with the receiver, and completes key confirmation on both legs. Both clients consequently believe they are authenticating each other, while the relay can decrypt each NaCl secretbox chunk with the key it shares with the sender, read the file, and re-encrypt it with the key it shares with the receiver. The security argument in Section 3.3 only considers an eavesdropper who must guess the password; it does not cover the relay, which is given the password by design. The central security claim is therefore false unless the relay is assumed honest, which is exactly what the malicious-relay claim rules out.","section":"Sections 3.1.1, 3.2, 3.3"},{"comment":"The performance benchmarks in Table 3 report single timing values for each protocol and file size with no error bars, no trial count, and no statistical measure such as variance or median across runs. Since the times differ by small margins (e.g., 3s vs 1.80s for 1MB, 49s vs 41.32s for 100MB) and the setup depends on network conditions, the claimed performance advantages are not supported. The paper should provide multiple runs, confidence intervals, and details about the test environment and network conditions before drawing conclusions about relative performance.","section":"Section 4, Table 3"},{"comment":"The paper states in Section 3.1.1 that \"no data is stored on the relay server,\" but Section 3.2 says the relay uses \"a minimal SQLite3 database to store connection-related information (passphrase, IP addresses, etc.).\" Storing the passphrase and IP addresses is a direct contradiction of the earlier claim. This is not merely a presentation slip; it is part of the design that enables the man-in-the-middle attack described above, and it also weakens the advertised privacy/transparency properties.","section":"Sections 3.1.1 and 3.2"}],"minor_comments":[{"comment":"The variable names for the private keys are swapped in the sPAKE2 description: Alice's private key is first introduced as Skb with x as its value, and Bob's as Ska with y, but then Alice's key K is computed as h*Ska*(S - w*N) and Bob's as h*Skb*(T - w*M). The subsequent algebra equates Ska with x and Skb with y, which contradicts the initial definitions. This does not change the underlying mathematics, but it should be corrected for clarity.","section":"Section 3.1.2, Step 4"},{"comment":"The heading \"Empirical Results\" for Table 2 is misleading; the table contains qualitative security attributes (e.g., whether end-to-end encryption is used) rather than experimental measurements. Consider renaming it to \"Security Comparison\" or similar.","section":"Section 4, Table 2"},{"comment":"The sentence \"Offline analysis of the password or any other parameters is not possible because the protocol relies upon online communication between the parties\" is inaccurate for sPAKE2, which is designed to resist offline dictionary attacks even if an attacker records a transcript. The protocol does allow offline password guessing against a captured transcript; the resistance is computational, not absolute. Revise the claim to avoid overstating the property.","section":"Section 3.3"},{"comment":"Table 3 reports times for \"Our Implementation\" but does not specify whether the sending or receiving time is reported for the relay-based approach; the table notes \"(receiving)\" for the relay-based rows, but the comparison with other protocols presumably measures end-to-end transfer. Clarify what timing is measured for each protocol.","section":"Section 4"}],"recommendation":"reject","confidential_remarks":"The paper's security model is the core contribution, and the design gives the relay both the password and full control of the PAKE transcript, enabling a trivial MITM. This is not a fixable local issue; it invalidates the main claim. The authors would need to redesign the protocol (e.g., using a PAKE that does not reveal the password to the relay, or having the clients exchange the password out-of-band and perform the PAKE directly) and then re-evaluate the security analysis. The benchmark section is also under-powered, but that alone would not justify rejection. I recommend rejection, with the possibility that a substantially revised design with a corrected security model could be resubmitted as new work."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know. First, the paper's main security claim—that even a malicious relay cannot read the transferred file—is false as stated. Second, the design is a re-implementation of Magic Wormhole's architecture (relay + PAKE + NaCl-style secretbox), so even if the claim were fixed, the novelty would be thin.\n\nThe paper does some things well. It gives a plain, readable description of a working relay-based file transfer prototype: sPAKE2 for key agreement, NaCl secretbox for authenticated encryption, WebSocket relay, 16KB chunks. The comparison with WebRTC is fair at a high level, and the performance numbers, while not rigorous, show the relay approach is in the same ballpark as SCP and WebRTC for files up to 1GB. If the goal was to build a tool and write it up, this is a reasonable student project.\n\nThe soft spot is load-bearing. Section 3.2 states that the receiver sends the secret passphrase to the relay server, the relay stores it in SQLite, and the relay is responsible for exchanging the sPAKE2 messages. Since sPAKE2 is a password-authenticated key exchange, an entity that knows the password and controls the transcript can run the textbook active MITM: replace both sides' ephemeral keys, derive separate session keys with each client, pass key confirmation, and decrypt every chunk. The receiver's integrity check does not catch this because the relay holds valid session keys. So the claims in Sections 3.1.1 and 3.3—that the relay cannot read the data and that the protocol is secure against malicious relays—are wrong unless the relay is assumed honest, which is exactly what those claims rule out.\n\nThere are smaller issues. The benchmark table has no trial counts or error bars, Magic Wormhole is not benchmarked, and no code is provided. The sPAKE2 write-up has a minor key-labeling error (Ska/Skb swapped) but the math still works out.\n\nBottom line: this is a survey-plus-prototype paper, not a security research result. A reader might use it as an example of how to build a relay-based file transfer, but the central security property is contradicted by the design, and the comparison to prior art is not developed enough to justify serious referee time. I'd desk-reject and, if the authors care, point them to the MITM issue and to Magic Wormhole's design as a reference.","headline":"The relay learns the passphrase and brokers the sPAKE2 exchange, so the central claim that it can't read the file is false; the novelty over Magic Wormhole is thin.","tokens_in":9167,"tokens_out":2632,"would_cite":false,"duration_ms":22520,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A relay server can pass device-to-device files end-to-end encrypted without reading them.","keywords":["network security","peer-to-peer","file transfer","WebRTC","sPAKE2","relay server","end-to-end encryption","authenticated encryption"],"falsifier":"Run the protocol with a deliberately modified relay that learns the passphrase, substitutes its own sPAKE2 public share in each leg, completes the confirmation MACs with both clients, and then decrypts the chunk stream with the separate session key it derived in each leg; if the modified relay recovers the original file, the claim that the relay cannot read the data is false.","tokens_in":8085,"feed_emoji":"🔐","tokens_out":6735,"duration_ms":58094,"temperature":0.7,"pith_summary":"The paper proposes a device-to-device file transfer protocol in which a relay server does not store files; it simply holds two WebSocket connections and forwards encrypted chunks in full duplex. The authors try to establish that combining a password-authenticated key exchange (sPAKE2) with NaCl's authenticated encryption gives an end-to-end secure channel: a one-time passphrase yields a fresh session key, each 16 KB chunk is encrypted and integrity-protected, and the relay never sees plaintext. They compare the stack with WebRTC's, arguing that a single relay replaces STUN, TURN, and signaling servers, and they report benchmarks for files from 1 MB to 1 GB. If the claim holds, private large-file transfer becomes possible without trusting a storage provider and without users performing NAT traversal themselves.","feed_headline":"A relay server can pass files end-to-end encrypted without reading them","feed_subtitle":"A passphrase-derived session key plus authenticated encryption keeps the relay a blind forwarder for files up to 1 GB.","key_machinery":"The load-bearing mechanism is sPAKE2, a password-authenticated key exchange in which two parties who share a possibly weak passphrase derive a strong session key. In the protocol, clients agree on an elliptic-curve group with generator $P$, blind ephemeral public keys $X = xP$ and $Y = yP$ by adding a memory-hard hash of the password times fixed group points, and arrive at the same $K = hxyP$; transcript hashing and MAC confirmation make a wrong password fail the handshake. The second load-bearing piece is NaCl's Crypto Secret Box, an authenticated-encryption primitive applied to each 16 KB chunk, so any relay tampering is detected. The relay itself does the work of looking up the two clients by passphrase and gluing their TCP connections.","core_discovery":"On its own terms, the central claim is that a relay-based transfer can be end-to-end encrypted while the relay remains a purely mechanical forwarder. The clients run sPAKE2 through the relay, derive a shared $K = hxyP$, confirm the transcript with MACs, and then use NaCl's Crypto Secret Box to send chunks of 16384 bytes. The paper states that the design is 'secure against malicious relay servers': a relay that changes a data packet is detected by the receiver, and the relay cannot read the contents of the data packets. The empirical section reports that the implementation meets the design goals of security, performance, and transparency, and that for 512 MB and 1 GB files in the tested environment it outperforms plain FTP and the WebRTC data-channel implementation.","pith_inferences":["Inference: the paper's claim of being 'secure against malicious relay servers' covers a relay that tampers with or passively observes chunks, but not one that acts as a man in the middle; a relay that holds the passphrase and controls the sPAKE2 transcript can impersonate both clients and read the file.","Inference: a concrete hardening step the paper leaves implicit is to keep the passphrase out of the relay's hands, for example by exchanging the sPAKE2 messages through the relay while agreeing the passphrase through a separate out-of-band channel, or by using an asymmetric PAKE that does not require the relay to learn the password.","Inference: the same relay design could extend to multi-file or multi-recipient sessions, but each recipient would need its own PAKE run and key, which would multiply the relay's forwarding cost."],"forward_implications":["Files up to at least 1 GB can be transferred with no file data retained by the relay.","Because the relay is full-duplex, the receiver can begin receiving chunks before the sender has uploaded the whole file.","Any packet the relay or another intermediary modifies is rejected by the receiver's authenticated-encryption check.","Weak shared passphrases still yield strong session keys because the handshake is built on sPAKE2 with a memory-hard hash.","In the benchmark environment, the relay implementation transferred 512 MB and 1 GB files faster than plain FTP and the tested WebRTC data channel."],"supporting_citations":[{"why":"Describes Magic Wormhole, a prior relay-based file transfer tool whose limitations the proposed protocol aims to counter.","marker":"[7]"},{"why":"Specifies the sPAKE2 PAKE whose message flow, transcript hash, and key-derivation steps the design reuses.","marker":"[9]"},{"why":"Defines NaCl's authenticated encryption (Crypto Secret Box) used to encrypt and integrity-protect each 16 KB chunk.","marker":"[10]"},{"why":"Documents WebRTC's RTCDataChannel API, the mechanism used for the comparison WebRTC file-transfer implementation.","marker":"[11]"},{"why":"Describes WebRTC's DTLS-based security architecture, the baseline protocol the paper compares against its relay approach.","marker":"[13]"}],"fun_headline_variants":["Blind relay forwards encrypted files without reading them","End-to-end encrypted file transfer with a relay that can't snoop","Secure D2D file transfer: relay sees nothing but ciphertext","Relay-based file transfer: secure, fast, and relay can't read data"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The security claim holds only if the relay server does not actively impersonate either client; the described implementation gives the relay the passphrase and the full sPAKE2 transcript, so an actively malicious relay could establish separate keys with each side and read every chunk.","fun_headline_variants_meta":{"raw":{"variants":["Blind relay forwards encrypted files without reading them","End-to-end encrypted file transfer with a relay that can't snoop","Secure D2D file transfer: relay sees nothing but ciphertext","Relay-based file transfer: secure, fast, and relay can't read data"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000541,"raw_usage":{"total_tokens":2580,"prompt_tokens":920,"completion_tokens":1660,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":536,"completion_tokens_details":{"reasoning_tokens":1585}},"tokens_in":536,"tokens_out":1660,"duration_ms":10945,"temperature":1.0,"reasoning_tokens":1585,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:49:41.920111+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the protocol with a deliberately modified relay that learns the passphrase, substitutes its own sPAKE2 public share in each leg, completes the confirmation MACs with both clients, and then decrypts the chunk stream with the separate session key it derived in each leg; if the modified relay recovers the original file, the claim that the relay cannot read the data is false.","supporting_citations":[{"cited_title":"Magic wormhole","cited_arxiv_id":null,"evidence_quote":"Describes Magic Wormhole, a prior relay-based file transfer tool whose limitations the proposed protocol aims to counter."},{"cited_title":"Ladd and B","cited_arxiv_id":null,"evidence_quote":"Specifies the sPAKE2 PAKE whose message flow, transcript hash, and key-derivation steps the design reuses."},{"cited_title":"Cryptography in nacl","cited_arxiv_id":null,"evidence_quote":"Defines NaCl's authenticated encryption (Crypto Secret Box) used to encrypt and integrity-protect each 16 KB chunk."},{"cited_title":"O’Reilly Media, Inc","cited_arxiv_id":null,"evidence_quote":"Documents WebRTC's RTCDataChannel API, the mechanism used for the comparison WebRTC file-transfer implementation."},{"cited_title":"Webrtc security architecture","cited_arxiv_id":null,"evidence_quote":"Describes WebRTC's DTLS-based security architecture, the baseline protocol the paper compares against its relay approach."}],"review_version":1}