Security at Dragy

1. How a transfer is protected

Whatever route a transfer takes, the same steps happen on your devices:

1. The devices agree on a secret. They run an Elliptic-Curve Diffie–Hellman exchange (ECDH on the P-256 curve). Each side keeps its private part to itself; only public values cross the network.
2. Keys are derived for this transfer. The shared secret is fed through HKDF together with per-transfer random values, so every transfer gets its own fresh keys that are never reused.
3. Files are sealed in chunks. Your device splits each file into chunks and encrypts every chunk with AES-256-GCM. Each chunk is authenticated and bound to its position, and the end of the stream is authenticated too.
4. The other device checks everything. It decrypts and verifies each chunk. If anything was changed, dropped, duplicated, reordered or truncated, verification fails and the file is rejected rather than saved corrupted.

2. The encryption

Encryption uses your platform’s built-in, well-reviewed cryptography (the Web Crypto API in browsers) rather than custom primitives. Transport between devices and our server is additionally protected by TLS, and WebRTC connections by DTLS — but Dragy’s own end-to-end layer doesn’t depend on either.

3. Knowing who you’re talking to

Encryption only helps if you’re encrypting to the right device. Dragy authenticates the other side in a way that fits how you connected:

• Your own devices (signed in). Every signed-in device generates its own key pair on the device. Its public key is registered with your account; the private key never leaves the device. Transfers between your devices are mutually authenticated with these keys, so each side proves it is the device it claims to be.
• Codes and QR codes. The 12-character code is also the secret the session is authenticated with. Our server stores only a hash of it, so it can match the two devices without being able to join or read the session. Only someone who knows the code can complete the connection.
• Anonymous Nearby. Devices that haven’t met before show five verification emoji derived from the session keys, on both screens. If they match, no one is in the middle. If they don’t, cancel the transfer.

4. Routes

Dragy picks the most direct route that works. Encryption is the same on all of them.

• Local network. On the same Wi-Fi or LAN, devices connect directly over WebRTC; data never leaves your local network.
• Direct. On different networks, devices connect peer-to-peer over the internet. Cloudflare’s STUN service (stun.cloudflare.com) helps them discover a path; it sees the network addresses involved, never your data.
• Encrypted relay. If no direct path exists, our server forwards the already-encrypted data between the two devices. It holds data only in transit, stores nothing, and has no keys.
• Cloud, for offline devices. If one of your own devices is offline, the encrypted transfer waits in storage until it comes back, then is deleted — after 7 days at most. Limits: 5 GB per account, up to 5 GB per transfer.

5. What our server can and can’t see

Because the server never has your content, nobody can obtain it from us — not an attacker, not an employee, and not an authority with a court order. What we can be required to disclose is limited to the metadata above; our Law Enforcement Guidelines explain how we handle such requests. For the same reason we can’t scan for abuse: we rely on reports, and can disable a reported share link.

6. Threat model, in plain language

What Dragy is designed to protect against

• Someone watching the network — on public Wi-Fi, at your internet provider or anywhere in between — reading or changing your files.
• Our own servers being curious or compromised. The relay and cloud see only ciphertext, and a breach of our storage wouldn’t expose file contents or names.
• Tampering. Altered, reordered, duplicated or truncated data is detected and rejected.
• Impersonation. Device keys, connection codes and verification emoji make sure you’re sending to the device you intended.

What Dragy can’t protect against

• A compromised device. Malware on the sending or receiving device can see files before encryption or after decryption.
• Sharing secrets. Anyone who gets a connection code while it’s active, or the full URL of a share link before it expires, can receive what it unlocks. Share them only with the people you intend.
• Skipped checks. If emoji on an anonymous Nearby transfer don’t match and you continue anyway, you may be connected to someone else.
• Metadata. Our server and network providers can see that devices are connecting, when, from which IP address, and roughly how much data moves. For stored transfers, we see their size and time.
• Your IP address, to the other device. Devices that connect directly exchange network addresses, so the device you connect with can learn your IP address (see our Privacy Policy).
• What the recipient does. Once a file arrives, the person on the other end can keep or forward it.

7. Accounts and sign-in

• Passwords are hashed with scrypt; we never store or see them in plain text.
• Optional two-step verification with any TOTP authenticator app.
• New devices can be signed in by scanning a QR code from a signed-in device, so you don’t type your password on every device.
• Sign-in and connection attempts are rate-limited to slow down guessing.

8. Apps, downloads and this website

• Downloads. We publish SHA-256 checksums for every installer in SHA256SUMS.txt. Download Dragy only from this site or an official app store listing.
• No trackers. Neither the apps nor this site contain analytics, advertising or third-party tracking code, and neither sets cookies. What the app keeps on your device is listed in Cookies & Local Storage.
• This website is static, loads no third-party scripts, fonts or images, and is served with a strict Content Security Policy.

9. Reporting a vulnerability

If you believe you’ve found a security problem in Dragy, please tell us privately at [email protected]. Our security.txt (RFC 9116) lists the same contact.

Please include

• what you found and where (app and version, platform, URL or endpoint);
• steps to reproduce, and a proof of concept if you have one;
• the impact you think it has;
• how you’d like to be credited, if at all.

What we ask

• Give us reasonable time to fix the issue before you disclose it publicly.
• Only test against your own accounts and devices. Don’t access, change or delete other people’s data, and stop as soon as you reach data that isn’t yours.
• No denial-of-service testing, spam, social engineering, or physical attacks.

What we commit to

• We acknowledge reports within 3 business days and keep you updated.
• We won’t take legal action against good-faith research that follows these guidelines.
• With your permission, we’ll credit you once the fix is released.

10. Contact

• Security reports: [email protected]
• Privacy questions: [email protected]
• Abusive share links or accounts: [email protected] — see Report abuse
• Requests from authorities: [email protected] — see Law Enforcement Guidelines
• Everything else: [email protected]

See also our Privacy Policy and Terms of Service.