Designing a Secure Device-to-Device File Transfer Mechanism

Anushka Virgaonkar; Chaitanya Rahalkar

REVIEW 3 major objections 4 minor 12 references

Designing a Secure Device-to-Device File Transfer Mechanism

T0 review · 3 major / 4 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A relay server can pass device-to-device files end-to-end encrypted without reading them.

desk verdict 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. read the letter →

arxiv 2411.13827 v1 pith:3BIQ5VUI submitted 2024-11-21 cs.CR

Chaitanya Rahalkar , Anushka Virgaonkar This is my paper · ORCID

classification cs.CR

keywords networksecuritypeer-to-peerfiletransferWebRTCsPAKE2relayserverend-to-endencryptionauthenticated

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the 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.

The 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.

The 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.

There 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.

Bottom 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.

Referee Report

3 major / 4 minor

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.

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 (3)

[Sections 3.1.1, 3.2, 3.3] 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 4, Table 3] 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.
[Sections 3.1.1 and 3.2] 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.

minor comments (4)

[Section 3.1.2, Step 4] 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 4, Table 2] 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 3.3] 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 4] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the protocol's security claims rest on external sPAKE2 and NaCl properties, not on the paper's own outputs; the relay-MITM flaw is a correctness gap, not a circular derivation.

full rationale

The paper does not fit parameters, derive predictions from data, or invoke a load-bearing self-citation chain. Its core transfer design uses sPAKE2 and NaCl's authenticated encryption as external, published primitives; the security argument is inherited from their documented properties, so there is no equation or fitted value that reduces to an input. The strongest concern is the claimed resilience to malicious relay servers: Section 3.2 states the receiver sends the secret passphrase to the relay, which is 'responsible for exchanging the sPAKE2 messages,' and sPAKE2's man-in-the-middle resistance only holds when the password is unknown to the adversary. This makes the claim unsupported, but it is a gap between the assumed threat model and the described deployment, not a circular derivation: the claimed result is not equivalent to its inputs by construction. The paper's reliance on RFC-published sPAKE2 and NaCl is legitimate external support rather than self-citation or ansatz smuggling. Therefore the circularity score is 0.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the correctness and correct deployment of sPAKE2, the security of NaCl secretbox, and an unstated assumption that the relay server does not exploit its knowledge of the password to perform an active MITM. The benchmark also assumes a stable, uncharacterized network environment. No entities are invented.

free parameters (1)

chunk_size = 16384 bytes
File data is divided into 16K-byte chunks (Section 3.2); the size is chosen by hand and affects throughput characteristics, but no tuning study is reported.

assumptions (4)

standard math The computational Diffie-Hellman (CDH) assumption holds in the elliptic curve group used by sPAKE2.
Section 3.1.2 step (1) states the CDH assumption holds. The security claim depends on this.
domain assumption sPAKE2, when deployed as described, provides authenticated key exchange resistant to dictionary attacks and man-in-the-middle attacks.
Section 3.3 relies on the protocol's security properties. The deployment sends the passphrase to the relay and routes all PAKE messages through it, so the textbook security proof may not apply.
ad hoc to paper The relay server does not actively tamper with the PAKE exchange even though it receives the passphrase.
This assumption is never stated, but it is required for the end-to-end confidentiality claim. It is contradicted by the design in Section 3.2, where the relay stores the passphrase and brokers all messages.
domain assumption The network environment during benchmarks is stable and representative.
Section 4 reports single runs on unspecified links; variability is not quantified.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Designing a Secure Device-to-Device File Transfer Mechanism." pith.science (2026). https://pith.science/paper/3BIQ5VUI

@misc{pith2026241113827,
  author       = {Pith},
  title        = {Pith review of: Designing a Secure Device-to-Device File Transfer Mechanism},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3BIQ5VUI}},
  note         = {Machine review of arXiv:2411.13827}
}

read the original abstract

Secure, reliable, and fast transfer of files across the Internet is a problem attempted to be solved through many application-layer protocols. In this paper, we aim to design a secure, reliable, opendesign, and performant file transfer protocol that is inspired by the WebRTC protocol stack. Traditionally, transferring files involves a publicly exposed (available on the public network) third-party server that serves the uploaded files to the receiver. Here, the third party server has to bear the storage and bandwidth cost to transfer the files between the two parties. We propose a protocol that uses a relay server to relay the files from the client to the server. A relay server has several advantages over a regular file-hosting server. Firstly, a relay server does not retain the uploaded files, it simply relays them. Secondly, a relay server has a full-duplex communication channel and therefore the receiver is not required to wait for the sender to upload the files completely. In this paper, we study available file transfer approaches and their known flaws. We propose our idea and compare our stack with the WebRTC stack. Finally, we perform empirical analysis and, benchmark our device-to-device transfer approach along with other available options including WebRTC.

Figures

Figures reproduced from arXiv: 2411.13827 by the authors.

**Figure 2.** End-to-End Flow of the Transfer Mechanism [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** WebRTC Protocol Stack (From webrtcsecurity.github.io) transfer is done without the involvement of a third party. AioRTC, a Python-based WebRTC implementation library was used to test and benchmark the WebRTC-based transfer process. 3.5 Comparing WebRTC and our Relay-Based Approach [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

12 extracted references · 12 canonical work pages

[1]

Dropbox hack ’affected 68 million users

BBC Technology. Dropbox hack ’affected 68 million users. BBC News, Aug 2016

work page 2016
[2]

The overhead of confidentiality and client- side encryption in cloud storage systems

Eric Henziger and Niklas Carlsson. The overhead of confidentiality and client- side encryption in cloud storage systems. In Proceedings of the 12th IEEE/ACM International Conference on Utility and Cloud Computing , pages 209–217, 2019

work page 2019
[3]

Postel and J

J. Postel and J. Reynolds. File transfer protocol

work page
[4]

The secure shell (ssh) protocol architecture, 2006

Tatu Ylonen, Chris Lonvick, et al. The secure shell (ssh) protocol architecture, 2006

work page 2006
[5]

Openssh 8.3 released (and ssh-rsa deprecation notice), 2020

Damien Miller. Openssh 8.3 released (and ssh-rsa deprecation notice), 2020

work page 2020
[6]

Au- tonomous nat traversal

Andreas Muller, Nathan Evans, Christian Grothoff, and Samy Kamkar. Au- tonomous nat traversal. In 2010 IEEE Tenth International Conference on Peer-to- Peer Computing (P2P), pages 1–4. IEEE, 2010

work page 2010
[7]

Magic wormhole

Mark Williams, Cory Benfield, Brian Warner, Moshe Zadka, Dustin Mitchell, Kevin Samuel, and Pierre Tardy. Magic wormhole. In Expert Twisted, pages 253–284. Springer, 2019

work page 2019
[9]

Ladd and B

W. Ladd and B. Kaduk. Spake2, a pake, Feb 2020

work page 2020

Show all 12 references

[10]

Cryptography in nacl

Daniel J Bernstein. Cryptography in nacl. Networking and Cryptography library , 3:385, 2009

2009
[11]

O’Reilly Media, Inc

Salvatore Loreto and Simon Pietro Romano. Real-time communication with WebRTC: peer-to-peer in the browser . " O’Reilly Media, Inc. ", 2014

2014
[12]

Leveraging webrtc for p2p content distribution in web browsers

Christian Vogt, Max Jonas Werner, and Thomas C Schmidt. Leveraging webrtc for p2p content distribution in web browsers. In 2013 21st IEEE International Conference on Network Protocols (ICNP) , pages 1–2. IEEE, 2013

2013
[13]

Webrtc security architecture

Eric Rescorla. Webrtc security architecture. Work in Progress, 2013. 7

2013

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.

[1] [1]

Dropbox hack ’affected 68 million users

BBC Technology. Dropbox hack ’affected 68 million users. BBC News, Aug 2016

work page 2016

[2] [2]

The overhead of confidentiality and client- side encryption in cloud storage systems

Eric Henziger and Niklas Carlsson. The overhead of confidentiality and client- side encryption in cloud storage systems. In Proceedings of the 12th IEEE/ACM International Conference on Utility and Cloud Computing , pages 209–217, 2019

work page 2019

[3] [3]

Postel and J

J. Postel and J. Reynolds. File transfer protocol

work page

[4] [4]

The secure shell (ssh) protocol architecture, 2006

Tatu Ylonen, Chris Lonvick, et al. The secure shell (ssh) protocol architecture, 2006

work page 2006

[5] [5]

Openssh 8.3 released (and ssh-rsa deprecation notice), 2020

Damien Miller. Openssh 8.3 released (and ssh-rsa deprecation notice), 2020

work page 2020

[6] [6]

Au- tonomous nat traversal

Andreas Muller, Nathan Evans, Christian Grothoff, and Samy Kamkar. Au- tonomous nat traversal. In 2010 IEEE Tenth International Conference on Peer-to- Peer Computing (P2P), pages 1–4. IEEE, 2010

work page 2010

[7] [7]

Magic wormhole

Mark Williams, Cory Benfield, Brian Warner, Moshe Zadka, Dustin Mitchell, Kevin Samuel, and Pierre Tardy. Magic wormhole. In Expert Twisted, pages 253–284. Springer, 2019

work page 2019

[8] [9]

Ladd and B

W. Ladd and B. Kaduk. Spake2, a pake, Feb 2020

work page 2020