Privacy Policy — Krest

Last updated: 2026-08-10

This document describes which data Krest handles, where it goes, and what choices you have. Krest is built privacy-first: the app works without an account, and the cryptographic anchoring service never sees the content of your media.

1. Who runs Krest

Operator:   Hendrik Paul
Address:    Am Rande 13, 34128 Kassel, Germany
Email:      privacy@krestapp.com

2. What Krest processes — and what it does not process

2.1 Data that never leaves your device

• The photo / video bytes captured or selected for verification. A newly captured photo is held in the app's own storage on your device until its anchor exists, so that the proof can be embedded before the photo is written to your photo library (see Section 4). It is never uploaded during that time.
• The AES-256-GCM session key used to encrypt Krest-Share blobs.
• The Secure Enclave private key that signs your captures.
• Your Apple Photos library outside of items you explicitly pick.

Once you share an anchored file yourself, the proof block travelling inside it does leave your device — §2.8 sets out exactly what that block contains.

2.2 Data the Anchoring Relay sees

The relay accepts only opaque cryptographic material:

• A 32-byte device public key (anonymous; not linked to your Apple ID).
• A 32-byte Merkle-root hash plus a signature over it.
• An App-Attest assertion proving the request came from a genuine Krest install on a genuine Apple device.
• Standard request metadata (IP address, user agent, timestamp) which is retained for at most 30 days for abuse prevention and then deleted.
• If you have an active subscription or bought a Mint Pack: an Apple-issued purchase receipt (verified server-side to activate your entitlement), a numeric fraud-risk indicator Apple provides for that receipt, your subscription's expiry date, and your remaining allowance, credits and usage counters for the current period — both for mints (the credit that pays for anchoring a capture) and for force-anchors. The mint counter is derived from the entry count already contained in a signed Merkle root you submit anyway, so no additional data is collected for it. All of this is keyed only to the same anonymous device public key above — never to your Apple ID, name, or payment details, which Apple keeps and Krest never receives. Kept for as long as your device key is registered and the subscription/entitlement is active; deleted when you unregister the device or the subscription lapses and the data is no longer needed to administer it.
• If you use Krest Fortress under an enterprise/business plan: an operator-assigned customer identifier (optional — present only for enterprise customers, not for individual users).
• If you explicitly opt in to "Anchored on Bitcoin" notifications (paid plans only, off by default): an APNs device push token, the Apple push environment it was issued for (production/sandbox), and the time you last registered it. This is used for exactly one purpose — telling you once a capture is irreversibly confirmed on Bitcoin — and is sent to Apple to deliver that notification (see §6). The token is bound to the same anonymous device public key above; Krest never learns which capture or file a notification refers to, only that "some batch this device contributed to" is now confirmed (batch-level, never a content hash). You can withdraw this at any time in the app, which deletes the token immediately; it is also deleted automatically if Apple reports it as invalid, or, at the latest, within 24 hours of your subscription lapsing (see §4). This channel is used only for that one transactional confirmation — never for marketing, promotions or any other message.

The relay does not see, store or forward your media bytes, file names, sensor data, captions, contacts or any personal identifier.

2.3 Data the Share Relay sees

When you create a krest://share/<token> link, Krest uploads the already-encrypted ciphertext to a transport relay. The relay sees:

• The encrypted blob (random bytes).
• Token, byte count, MIME hint (image/jpeg, video/mp4, …), TTL.
• The device public key + App-Attest assertion (same anonymous key as above).

The relay never receives the decryption key — that travels solely inside the share link (URL fragment or query parameter you forward via WhatsApp, iMessage etc.).

Single-use links are deleted immediately after the first download. Otherwise, links expire at the TTL you chose (max 7 days on the Mini plan, 30 days on Pro/Max) and are purged.

2.4 Data the Lookup Service sees

When you verify someone else's content, the app sends only the SHA-256 hash of their file. The lookup service responds with the timestamp, Merkle proof and Bitcoin anchor it can find for that hash. We log nothing user-identifying.

2.5 Bitcoin anchoring

Krest writes Merkle roots into the Bitcoin blockchain via OP_RETURN transactions. The blockchain is by design public and permanent. The written data is a 48-byte hash — no media, no identity.

2.6 Legal bases (GDPR Art. 6)

We process the limited data described above on the following bases:

• Operating the verification service you request — registering your anonymous device public key, accepting Merkle roots, anchoring, lookup and share transport: Art. 6(1)(b) (performance of the service you asked for) and Art. 6(1)(f) (our legitimate interest in a functioning, abuse-resistant protocol).
• Short-lived request metadata (IP address, user agent, timestamp, retained at most 30 days): Art. 6(1)(f) (legitimate interest in security and abuse prevention).
• Subscription and Mint Pack data (Apple purchase receipt, Apple's fraud-risk indicator, expiry date, quota/credits/usage, and the optional enterprise customer ID): Art. 6(1)(b) (performance of the paid subscription/purchase contract you entered into) and Art. 6(1)(f) (legitimate interest in fraud prevention using Apple's own risk signal).
• Push notification token (APNs device token, push environment, last-registered time — sent only if you explicitly opt in): Art. 6(1)(a) (your consent, given through the in-app opt-in and the iOS notification permission prompt), which you can withdraw at any time with future effect by disabling notifications in the app.
• On-device permissions (camera, microphone, photo library, motion) are granted by you through iOS and used only on your device — the operator receives none of that sensor or library data, so it is not processed by us in the GDPR sense.

We do not carry out automated decision-making or profiling (Art. 22), and we do not process special categories of data (Art. 9) on our servers.

2.7 Backups

The Anchoring Relay periodically writes encrypted, off-site operational backups used solely for disaster recovery (e.g. total loss of the server). These cover the relay's device/registration state described in §2.2 — including your push-notification token if you opted in — as well as the append-only anchoring log that lets the relay recover proofs for captures that were anchored but not yet fetched by your device. Backups are encrypted before they ever leave the server; the decryption key is kept offline and is never stored on the relay itself. By default, this rolling backup history covers up to 24 hours before older backups are automatically deleted (see the internal operations runbook for the currently configured value — an operator may extend this for longer disaster-recovery coverage).

The deletion promise in §4 survives a restore. If a backup is ever restored — an event we expect to be rare, disaster-recovery only, never a routine operation — the same automated sweep that purges a push token no later than 24 hours after your subscription lapses runs again immediately on the restored data. This is not a manual process or a policy promise on paper; it is code that executes on every relay start (see §4). A token that had already become eligible for deletion before the backup was taken is therefore removed again within the same 24-hour bound, even though it was briefly present in the restored copy.

Separately, the relay operator also keeps encrypted, off-site backups of the Bitcoin anchor wallet's key material and of the deployment's operational secrets. Both are handled with the same encryption/access-restriction discipline described above, but contain no personal data — only Bitcoin private keys and operator infrastructure secrets.

2.8 What a Krest proof carries inside a file you share

When a capture is anchored, Krest appends a small block of printable text (typically well under a kilobyte) to the file itself, after the image data. This block is what makes a Krest photo checkable by anyone, on any device, without contacting Krest at all — and it is the only reason a proof survives reinstalling the app or sending the photo to someone else. Anyone who receives the file can read it.

It contains no device key, no location, no account or user identifier, and no sensor data.

What someone can infer from it. Captures made on the same device within the same batch (at most 128 captures, at most 24 hours) share the same batch root, and — when a batch held more than one capture — one entry of the Merkle proof is the content hash of another capture from that batch. Someone holding two such files can therefore tell that they were produced by the same device within the same batch window. Three limits apply: the batch root changes with every new batch, so files from different batches cannot be linked to each other this way; the batch root cannot be resolved to a device or to a person — no Krest service will translate it into a device key; and it says nothing about who that device belongs to. The one exception is the relay operator, who separately holds the device key described in §2.2 and could therefore group batches from one device — still without any name, account or contact data, because Krest has none.

This trade-off is unavoidable for the guarantee Krest makes: a proof that anyone can check without trusting us has to carry the hash chain that leads to the blockchain. A proof without that chain would not be a proof.

Separately from Krest, the photo file also carries the ordinary camera metadata your device writes (EXIF: capture time, camera model, exposure settings, and location if you have enabled it for the camera). Krest neither adds nor removes any of it — a verified capture must stay byte-for-byte identical to the sensor output, so stripping it would destroy the proof. If you do not want a file to carry either the proof block or that metadata, share it through a channel that re-encodes it; most messengers and social networks do this automatically, which removes the proof along with it.

3. Permissions Krest requests on your device

All permissions are opt-in and can be revoked any time in iOS Settings.

4. Data retention

5. Your rights under GDPR

If you are in the EU/EEA you have the right to:

• access, rectify and erase personal data we hold about you,
• restrict or object to processing,
• portability of your data,
• lodge a complaint with the supervisory authority of your country.

Because Krest is account-less, the relay does not store personal data that could be linked back to you as an individual. If you believe a piece of data is identifiable nonetheless, contact us with details and we will delete or rectify within the legally required period.

6. Transfers outside the EU/EEA

Server infrastructure currently runs in Germany (Hetzner Cloud). Bitcoin anchoring transactions are submitted to the public Bitcoin network and are therefore visible globally, but as stated above contain only non-identifying hash data.

A data processing agreement under GDPR Art. 28 is in place with the hosting provider Hetzner Online GmbH (Industriestr. 25, 91710 Gunzenhausen, Germany), which handles the short-lived request metadata on the server infrastructure. Processing takes place exclusively in Germany.

If you opt in to push notifications, your APNs device token is sent to Apple Distribution International Ltd. (Hollyhill Industrial Estate, Cork, Ireland; or Apple Inc., USA, for the underlying push service) solely to deliver the one "anchored on Bitcoin" notification described in §2.2 — Apple acts as the notification transport, not as a recipient of your capture content or any other data described in this policy.

7. Children

Krest is not designed for children under the age of digital consent in your jurisdiction (16 in most EU member states, 13 in the US per COPPA).

8. Changes

We may update this policy as features evolve. The "last updated" date at the top of this document reflects the most recent revision. Material changes will be announced in the app changelog.

9. Contact

For privacy questions or data-protection requests:

privacy@krestapp.com

See also: TERMS.md (terms of service) and IMPRESSUM.md (provider identification under § 5 DDG). German version: DATENSCHUTZ.md.