End-to-end encryption
in Revier3D.

1. Summary

Revier3D encrypts all hunting data client-side before it reaches the server. The server is a dumb, encrypted storage: it sees only ciphertext and cannot decrypt it. It does not know where your boundary is, not what you harvested.

Architecture: row-level encryption instead of per-field _enc columns. Each row is stored as a single encrypted JSON blob (data_enc). The server sees only metadata (id, revier_id, created_at, updated_at, deleted_at, vvec) for sync and tenant isolation. All fields (coordinates, game species, date, name, note, etc.) are in the blob.

The Revier Key (RK) is generated once at setup as 256-bit random and is not derived from the password; instead it is wrapped with a key derived from the password (KEK). This allows password changes without making data unreadable.

What the server ultimately knows: account email (login), Paddle payment data (billing), hunting-ground slug (URL), hunting-ground status (access control), storage used (quota). No hunting data, not even the position. Even 3D terrain and aerial imagery are encrypted.

There is no operator emergency key and no backdoor, not even during the beta. The only debugging path is the "Report error with data" button (section 6).

2. Threat model

2.1 What we defend against

• Server compromise. Full filesystem and database access, including live data and backups. Effect on encrypted data: attacker sees only ciphertext.
• Backup theft. Weekly tars, GPG-encrypted DB dumps, offsite tower mirror, R2. Photo mirrors sit unencrypted at the offsite location; E2EE makes them worthless.
• Subpoena / government request. Revier3D can hand over what it has. What it has is ciphertext.
• Insider threat. Operator staff and hosting provider (Alpenhost) have full system access. They see only ciphertext.
• Network MitM. TLS plus client-side encryption, defense in depth.

2.2 What we do not defend against

• Client compromise. Malware on the end device sees plaintext and the key in memory. E2EE does not protect against malware.
• Device theft without device lock. Whoever has the unlocked phone has the data. Device encryption and screen lock are the user's responsibility.
• Coercion. "Give me your password" is not a crypto problem.
• Metadata analysis. Timing, size and frequency of writes are visible. This is a deliberate limit.

3. Cryptographic design rationale

3.1 Argon2id (key wrapping function, KEK)

Why not PBKDF2 or scrypt? PBKDF2 is GPU- and ASIC-friendly and therefore inferior for password-based keys today. scrypt is a strong alternative, but Argon2id is the winner of the 2015 Password Hashing Competition with broader library support. The hybrid mode (id) protects both against side-channel attacks (memory-hard at the front) and GPU cracking (time-hard at the back).

Deliberately memory-hungry. 64 MiB per attempt makes mass cracking on GPUs uneconomical. On a user's end device 64 MiB is a negligible load; for an attacker with millions of attempts it is a volume-limiting barrier.

3.2 AES-256-GCM (data encryption, via WebCrypto non-extractable)

Why AES-GCM via WebCrypto instead of XChaCha20? Three reasons. First: crypto.subtle allows extractable: false; the key never leaves the browser's secure key store. An XSS attack can encrypt/decrypt data while the tab is open but cannot steal the key. That is the single most important step for maximum security. Second: AES-NI hardware acceleration makes AES-GCM faster than XChaCha20 in software on most devices. Third: nonce as counter (96 bit) completely eliminates nonce reuse, the only catastrophic failure mode in GCM.

3.3 ECDH P-256 (asymmetric, camera inbound and accounts, via WebCrypto)

Why P-256 instead of X25519? X25519 is not yet supported by WebCrypto in all browsers (not Safari). P-256 is universally supported and can be imported as non-extractable. The non-extractable gain outweighs the theoretical X25519 advantage. P-256 is the TLS standard for Apple, Google, Microsoft.

3.4 HKDF (key separation)

4. Key hierarchy

# Generated once when the hunting ground is created:
RK  = random(256 bit)            # Revier Key, generated ONCE, then constant

# Key separation via HKDF (purpose-specific subkeys):
RK_data = HKDF(RK, "data")       # Row encryption (AES-256-GCM)
RK_cam  = HKDF(RK, "camera")     # Camera file key decryption (ECDH P-256)
RK_meta = HKDF(RK, "metadata")   # Index/cache

# Wrapping 1: hunting-ground password (single mode, four friends share link+pw)
KEK = Argon2id(hunting_ground_pw, revier.kek_salt, m=64 MiB, t=3, p=1)
revier.rk_wrapped = AES-256-GCM(Enc, RK, KEK)   # via crypto.subtle

# Wrapping 2 (optional): accounts (multi mode, per member)
revier.rk_wrapped_account[i] = ECDH-Seal(RK, account_pubkey[i])   # P-256 via crypto.subtle

# NO operator emergency key. No backdoor. The promise applies from day 1.

# Data encryption (per entry):
file_key = random(256 bit)
cipher   = AES-256-GCM(Enc, plaintext, file_key, nonce=counter)   # via crypto.subtle
wrapped_file_key = ECDH-Seal(file_key, revier.pubkey)   # camera inbound
# All key handles are non-extractable (extractable:false).

The separation between RK (constant) and KEK (from password) solves the main problem of a derivation-based architecture: password change costs no data. A password change means only that the single wrapping rk_wrapped gets regenerated, a small blob operation. The encrypted data itself is never touched.

rk_version carries the key generation. At beta end the RK gets rotated and the entire stock is re-encrypted with the new RK: only then is an old, possibly compromised RK worthless.

5. Protocol details

5.1 Schema additions

Per table with encrypted fields (marker, foto, strecke, ansitz, wartung, schaden, belegung, buchung, sketch, kontrolle, nachsuche, fuetterung_log) new columns appear:

• <field>_enc: ciphertext (Base64), replaces the previous clear-text field
• kek_salt: per hunting ground (in revier), 128 bit
• rk_wrapped: in revier, wrapping 1 (hunting-ground password)
• rk_wrapped_account: in revier_membership, per account (ECDH P-256)
• rk_version: int, key generation
• pubkey: in revier, public P-256 key
• e2ee_aktiv: bool, migration can happen in stages

5.2 Migration

Existing hunting grounds migrate lazily: on first read after the update, the client decrypts the clear text from the legacy column, re-encrypts it with RK and writes it back into <field>_enc. Cloudflare cache (4 hours) and old clients can coexist in this phase; the legacy column stays until wave 3.

5.3 Photo delivery

The route /foto/<id> delivers ciphertext starting in wave 2. A service worker (sw.js) intercepts the request, decrypts client-side and returns a normal response. This keeps <img src="/foto/…"> in HTML unchanged, and native lazy-loading, caching and memory management of the browser continue to work.

6. Debugging without backdoor: "report error with data"

There is no operator emergency key, no administrative access, no backdoor. The promise "we cannot look inside" applies from day 1, not only after a beta phase.

For debugging encrypted errors there is the "report error with data" button: the client packs the broken record with surrounding context, encrypts it with the public operator key and uploads it. The operator can read exactly this one record with their private key on their machine. They have no standing access to any hunting-ground data.

This procedure remains after the beta and is the only debugging path.

7. Honest limits

Encryption that promises everything lies. The following data stays clear text, the minimum without which the server cannot function:

Concrete consequence: the server does not know where your boundary is, not where a marker stands, not what you harvested. It knows only: "Account #31 pays for Hunting Ground #71, which uses 2.3 GB."

Further conceptual limits:

• 3D build: temporary position exposure. During the build, the client sends the bounding box (4 numbers) to the server so it can fetch basemap.at/BEV tiles. The position is visible for a few minutes and then forgotten. The boundary itself stays encrypted. This is not at-rest exposure but a temporary build process.
• Forgotten password without recovery code = data loss. There is no "password reset" that rescues the data. That is the flip side of real E2EE and is explicitly stated in the terms.
• Locking out old participants. Whoever once had the hunting-ground password has seen the RK. Definitive lockout requires a new RK and re-encryption; old data stays readable for them, new data does not.
• Server-side search, sorting and aggregation disappear entirely. The client loads all rows, decrypts them and sorts/filters/searches locally in IndexedDB. With large hunting grounds (10,000+ entries) this may be noticeable on phones.
• Receipt OCR in the ledger dies or requires a WASM client download (~10 MB).
• Admin support. admin_enter disappears. Support runs via instructions and a "report error with data" button that uploads broken records asymmetrically encrypted.
• Ledger export (§ 132 BAO). Receipts are encrypted. The tax advisor accesses via /stb/<token>#<key> (fragment key, browser decrypts locally). On key loss, ledger data is also irrecoverable, this must be in the terms.

8. Verifiability (four levels)

"Trust us" is not enough for encryption. Four levels, ascending in persuasiveness:

1. Open client code from day one (GitHub). Necessary but weak: how does the user know the delivered JavaScript matches what is on GitHub?
2. Published bundle hash plus reproducible build. Every release names the hash of the delivered bundle; anyone can build from the tag and compare.
3. A guard that proves instead of claims. A test suite runs the real app and checks every outgoing request body: no sensitive field may appear in clear text. With counter-probe (crypto off, suite must go red). This is the in-house form of this project.
4. The page /sicherheit shows the logged-in user their own data side by side: left what the browser shows, right the raw row as it really stands in the database. The user sees alphabet soup with their own eyes. Plus, honestly: a second table with what is not encrypted.

Deliberately not: an external audit (Cure53 and others). Too expensive for the current stage, not necessary without paying customers. May follow later and is declared in this whitepaper as "not performed", not concealed.

9. Comparison with alternatives

Market research August 2026, measured rather than claimed. Evidence in PLAN-APP-SYNC-E2EE.md part A.

Defensible wording: No cloud-based hunting app was found that promises end-to-end encryption for hunting-ground data.

Revier3D positions itself between Waidly (local, isolated) and Revierwelt (cloud, observable): private like an offline app, but still shareable, backed up and reachable from anywhere.

10. Legal compatibility

This section examines whether full encryption is compatible with Austrian law and the GDPR. The assessment is based on the legal situation as of August 2026 and does not replace legal advice in individual cases.

10.1 Data retention (IP addresses)

The Austrian Constitutional Court (VfGH) declared data retention unconstitutional in 2014. There is no statutory requirement for web applications to store IP addresses. Revier3D is not a telecommunications provider under the TKG. Not storing IP addresses is not only legal but required by data protection law (GDPR Art. 5(1)(c), data minimization).

In criminal proceedings (§ 76 StPO), authorities can demand what is available. If nothing is stored, there is nothing to hand over. You cannot be compelled to store data that you do not want to store.

10.2 Right of access (GDPR Art. 15)

The user has the right to information about the processing of their data. With E2EE, Revier3D can provide information about metadata (account, email, tariff, storage, hunting-ground ID). The encrypted content cannot be disclosed because Revier3D cannot decrypt it. The user can view the content themselves (decrypting locally). Art. 15 is fulfilled.

10.3 Right to data portability (GDPR Art. 20)

The user can export their data in a structured, commonly used format. The export is client-side: the browser decrypts the data locally and generates the export format. The export is password-protected by default. Art. 20 is fulfilled.

10.4 Privacy through encryption (GDPR Art. 25, 32)

The GDPR explicitly requires encryption as a technical and organizational measure (Art. 32(1)(a)) and privacy by design (Art. 25). Full E2EE exceeds the requirements. E2EE is not only legal but the data protection optimum.

10.5 § 132 BAO (accounting record retention)

The user has a statutory 7-year retention obligation for accounting records. With E2EE, receipts and bookings are encrypted. On key loss without recovery code, this data is irretrievably lost.

This is the user's obligation, not Revier3D's. The terms (§ 2.4) explicitly state: "The responsibility for the tax accuracy of the entries and for compliance with retention obligations (in particular § 132 BAO) lies with the customer." E2EE does not change this, but increases the risk on key loss.

Revier3D mitigates this risk through: (1) recovery code at setup, (2) encrypted export as additional backup, (3) tax advisor access via a fragment-key link.

10.6 Government disclosure (StPO)

Public authorities can seize data (§ 76 StPO) or request information. Revier3D hands over what it has: account metadata and encrypted data blocks. The encrypted content cannot be decrypted and therefore cannot be disclosed. This is comparable to ProtonMail (Switzerland) and Tutanota (Germany), both of which operate legally in German-speaking jurisdictions.

Revier3D cannot rule out that a statutory obligation to log connection data (IP addresses) may be introduced in the future. Such an obligation would apply to metadata, not to hunting data. Even then, the encrypted content would remain unreadable.

10.7 No backdoor mandate

There is no Austrian legal basis that compels a software provider to weaken its encryption or build a backdoor. At EU level, the CSAR regulation ("Chat Control") is being discussed, which would provide for scanning of encrypted communication. As of August 2026 it is not adopted, targets messengers and not niche SaaS. With open code and reproducible builds, a covert backdoor would be detectable.

11. References

• RFC 9106: Argon2 Memory-Hard Function (for hashing keys from passwords).
• NIST SP 800-38D: Galois/Counter Mode (GCM) for AES.
• FIPS 197: Advanced Encryption Standard (AES).
• FIPS 186-4: NIST Curve P-256 (ECDH).
• RFC 5869: HKDF (HMAC-based Extract-and-Expand Key Derivation Function).
• RFC 8032: Edwards-Curve Digital Signature Algorithm (Ed25519).
• OWASP Password Storage Cheat Sheet: Argon2id recommendations.
• Libraries: crypto.subtle (WebCrypto API, AES-GCM + ECDH P-256 + HKDF, non-extractable), hash-wasm (Argon2id, WASM-based), @noble/ed25519 (license signing only, wave 5).
• Source code: revier3d/src/crypto/ (wave 1, starting August 2026), webmap/static/revier-crypto.js.
• Full plan: webmap/PLAN-APP-SYNC-E2EE.md in the repository.