--- title: "Privatta Security & Encryption" description: "WebRTC DTLS encryption, single-use connection keys via an open-source signaling server, MAC whitelisting on the LAN, and a tamper-evident audit log." url: "https://royalsoftworks.com/products/privatta/security/" source: "https://royalsoftworks.com" format: "markdown" note: "Markdown rendering of the HTML page at `url`. Same content, same canonical URL." --- Security & privacy # There is nothing in the middle to break into. Most file-sharing security is about guarding a server full of everyone's files. Privatta has no such server. So the only question left is who is really on the other end — and that gets proved before a single byte moves. Pull-only You request every file — nothing is ever pushed to you 0 Bytes of your file that ever touch a server Stateless Open-source relay forgets each pairing the instant peers connect 2-factor A 32-char connection key and a 6-char security code, sent by different routes 01 At the door ## Four checks before anything opens. Over the internet, getting to a file means passing every check in turn — and the first two are meant to travel by different routes, so intercepting one gets you nowhere. A wrong attempt doesn't burn the connection: five tries are allowed before it locks and the host has to hand out a fresh key and code. 1 ### A key only they have You generate a one-time connection key and share it directly with the one person who should use it. It works exactly once and expires after 5 minutes. 2 ### A code that never travelled with it A 6-character security code is generated on your machine and never leaves it — send it by a different route than the key. The host checks it first, so a key on its own reaches a machine that will not answer. 3 ### A password they know — or guest access you granted Signing in with a username and password opens what you shared with that person. Without one, they connect as a guest and see only the files you marked for everyone. 4 ### Permission for that file Even then, the person only sees the specific files you shared with them. Everything else stays invisible. For your IT team - **Encryption** — WebRTC's built-in DTLS handshake, negotiated directly between the two machines - **Trust anchor** — Over P2P: a single-use 32-char connection key (5-minute expiry) minted by the relay, plus a 6-char security code generated on the host that never passes through it. MAC address on the LAN. - **Required together** — Connection key + security code + username and scrypt-hashed password (or explicit guest access to files marked Everyone) + file permission. On the LAN: MAC address + credentials + file permission. - **Intrusion response** — 5 wrong codes or passwords locks the connection until the host generates a fresh key and code — same rule on P2P and LAN All four checks pass The full model ## Ten protections, working together. ### Pull-only: nothing arrives uninvited The recipient's client always initiates the request for a specific file. There is no command path in the protocol that lets a sender push a file to a peer — a malicious or unwanted file cannot be delivered without the recipient actively requesting it. ### WebRTC transport encryption Every P2P connection is secured by WebRTC's mandatory DTLS handshake, negotiated directly between the two machines — the same transport security behind browser video calls, not a custom protocol of our own. ### A one-time key instead of standing trust Internet connections are gated by a single-use, 32-character key the host generates and shares out of band — it works exactly once and expires after 5 minutes. On the LAN, the connecting machine's MAC address is checked instead. ### A second factor that never travels with the key Since 1.1 the host also generates a 6-character security code. It is created on the host machine and never passes through the relay, so it is meant to go by a different route than the key — read out on a call while the key goes by chat. The host checks it before credentials and before listing a single file, which makes an intercepted key on its own worthless. ### Guests see only what you published A peer without an account on your machine can be let in deliberately: they still need both the key and the code, and once in they see exactly the files you set to Everyone. Anything narrower requires signing in as a user you created, and the panel tells you how many public files exist before you hand out a key. ### Rate-limited, then locked 5 wrong security codes or passwords locks the connection — over the internet or on the LAN — until the host issues a fresh key and code or re-approves the device. ### Trusted network ranges Pre-authorise VPN address ranges (Tailscale, ZeroTier, RFC 1918 private ranges), across every network interface on the machine, so remote teammates connect without weakening the model. ### Hashed credentials Account passwords are stored only as scrypt hashes — never in plaintext, and never written to the access log. ### You can verify what you installed The Windows installer and portable build carry an Authenticode signature issued to Royal SoftWorks, so Windows names the publisher rather than reporting an unknown one and you can check the signature yourself before running it. That signature is also what lets an installed copy confirm the build replacing it came from us. macOS signing is in progress. ### An open-source, stateless relay The relay that introduces two peers holds one in-memory table of pending pairings and nothing else — no database, no disk write. It forgets a pairing the instant its two peers connect, relays only the connection handshake — never a file or a password — and it's open source, so you can audit it or run your own instead of the default. 02 The record — Enterprise ## Every knock at the door, written down for good. On the Enterprise tier, Privatta keeps its own private log of every attempt to reach your files: who, from which device, which file, and whether it was allowed. Since 1.1 that covers internet sessions as thoroughly as local ones — the connection, every sign-in and refusal, each transfer and the disconnect — with each entry marked LAN or P2P. There is no delete button and no admin override: once an entry is written, nobody can remove or edit it, including you. Passwords never appear in it, and when a device tries its luck too many times, the connection locks until you approve it again. For your IT team - **Access log** — Local SQLite record: timestamp, channel (LAN or P2P), IP, machine name, MAC address, device ID, user, file, outcome. Passwords never written. Enterprise tier. - **Covers** — Sign-ins, refusals (including a wrong security code), file listings, denied files, completed and interrupted transfers, disconnects — on both transports since 1.1. - **Immutability** — There is no delete or clear operation in the code — the log is append-only by construction, not by policy. Entries are SHA-256 hash-chained, so an edit made outside the app is detected when the log is next opened. - **Brute-force defence** — 5 failed logins within 10 minutes locks the connection — on the LAN or over P2P — until a fresh key or re-approval. - **Privacy** — Requests never reveal whether a given file path exists. access.log LAN 192.168.1.24 alice merger\_terms.pdf allowed LAN 192.168.1.31 bob payroll.xlsx no permission P2P 83.44.17.6 guest (security code) refused P2P 83.44.17.6 guest press\_kit.zip allowed LAN 10.0.0.9—(unknown device) sealed · banned ## Bring this to your security review. The full protocol detail — handshake sequence, identity model, NAT traversal — is documented for procurement and IT architecture teams. [Read the whitepaper](https://royalsoftworks.com/products/privatta/whitepaper/) [Talk to us](https://royalsoftworks.com/contact/)