Wofür ist SecretApp gedacht?

E-Mails sind wie Postkarten: Auf dem Weg zum Empfänger können sie an mehreren Stellen mitgelesen werden, und sie bleiben oft jahrelang in Postfächern liegen. Für ein Passwort, einen Vertrag oder eine Ausweiskopie ist das ungeeignet.

SecretApp gibt Ihnen stattdessen einen Link. Sie schicken nur diesen Link – der Inhalt selbst liegt nicht in der E-Mail. Der Link lässt sich genau einmal öffnen und verfällt danach.

So gehen Sie vor

• Text eingeben, Dateien hinzufügen oder beides.
• Wählen, wie lange der Link gültig sein soll.
• Wenn Sie möchten, ein Passwort vergeben.
• Auf „Geheimen Link erzeugen“ klicken.
• Den Link an den Empfänger schicken – per E-Mail, Chat oder wie Sie möchten.

Der Empfänger öffnet den Link, bestätigt mit einem Klick und sieht dann den Inhalt. Danach ist der Link verbraucht.

Warum ist das sicher?

Ihr Text und Ihre Dateien werden schon auf Ihrem eigenen Gerät verschlüsselt, bevor irgendetwas übertragen wird. Auf unserem Server kommt nur ein unlesbarer Zeichensalat an.

Der Schlüssel zum Entsperren steht im Link selbst – und zwar in dem Teil hinter dem Rautezeichen (#). Dieser Teil einer Internetadresse wird von Browsern grundsätzlich nicht an den Server gesendet. Der Schlüssel erreicht uns also nie.

Das bedeutet: Selbst wir als Betreiber können Ihre Inhalte nicht lesen. Und selbst wenn jemand in unseren Server einbräche und alle Daten kopierte, hätte er nur unlesbaren Zeichensalat.

Der Link funktioniert nur einmal

Sobald der Inhalt einmal angezeigt wurde, wird er gelöscht. Ein zweiter Aufruf zeigt nur noch einen Hinweis, dass der Link nicht mehr gültig ist.

Das hat einen praktischen Nebeneffekt: Falls der Empfänger den Link öffnet und feststellt, dass er bereits verbraucht war, ist das ein Warnsignal – dann hat möglicherweise jemand anderes mitgelesen.

Weil manche E-Mail-Programme und Virenscanner Links automatisch anklicken, zeigen wir zuerst eine Zwischenseite. Erst wenn ein Mensch dort auf die Schaltfläche klickt, wird der Inhalt geholt. So verbrennen automatische Prüfprogramme Ihren Link nicht versehentlich.

Das zusätzliche Passwort

Sie können ein Passwort vergeben. Dann reicht der Link allein nicht mehr aus – der Empfänger muss auch das Passwort kennen. Das Passwort selbst wird nie an unseren Server übertragen.

Das ist besonders sinnvoll, wenn Sie den Link über einen Weg schicken, dem Sie nicht ganz trauen. Wichtig: Übermitteln Sie das Passwort auf einem anderen Weg als den Link, zum Beispiel telefonisch. Beides in derselben E-Mail wäre sinnlos.

Wird das Passwort mehrfach falsch eingegeben, sperrt sich der Link und der Inhalt wird gelöscht. So kann niemand Passwörter durchprobieren.

Der Löschlink

Nach dem Erstellen erhalten Sie zwei Links: einen für den Empfänger und einen zweiten, mit dem Sie den Inhalt jederzeit vorzeitig löschen können – etwa wenn Sie sich vertan haben.

Bewahren Sie diesen Löschlink auf, solange Sie ihn brauchen. Er wird nur ein einziges Mal angezeigt und lässt sich später nicht wiederherstellen.

Wie lange bleibt etwas gespeichert?

Sie bestimmen das beim Erstellen: von einer Stunde bis zu einem Jahr. Nach Ablauf wird alles automatisch gelöscht, auch wenn der Link nie geöffnet wurde. Vorher gelöscht wird, sobald der Empfänger den Inhalt abgerufen hat.

Was Sie beachten sollten

• Der Link ist der Schlüssel. Wer ihn hat, kommt an den Inhalt – solange er noch nicht geöffnet wurde. Gehen Sie mit ihm so um wie mit dem Inhalt selbst.
• Geht der Link verloren, ist der Inhalt weg. Wir können ihn nicht wiederherstellen, weil wir den Schlüssel nicht haben. Das ist kein Mangel, sondern der Kern des Verfahrens.
• Kürzen Sie den Link nicht. Der Teil hinter dem Rautezeichen gehört dazu. Link-Verkürzungsdienste oder ein unvollständiges Kopieren machen den Inhalt unlesbar.
• Sicherheit endet nicht hier. Wenn das Gerät des Empfängers kompromittiert ist, hilft auch die beste Verschlüsselung auf dem Transportweg nicht.

Welche Daten fallen an?

Wir speichern die verschlüsselten Inhalte bis zum Ablauf oder Abruf. Zusätzlich merken wir uns für kurze Zeit, von welchem Internetanschluss Anfragen kamen – in verschlüsselter Form und nur, um massenhaften Missbrauch zu unterbinden. Diese Angaben werden nach spätestens zwei Tagen automatisch gelöscht.

Ein Benutzerkonto ist nicht nötig, und wir fragen weder Namen noch E-Mail-Adressen ab.

Für technisch Interessierte: das Verfahren im Detail

Dieser Abschnitt beschreibt genau, was im Browser und auf dem Server geschieht. Die Zahlen in eckigen Klammern verweisen auf die Quellen am Ende.

1. Schlüsselerzeugung

Beim Erstellen erzeugt Ihr Browser über die Web Crypto API einen zufälligen Hauptschlüssel mit 256 Bit [1]. Er wird Base64url-kodiert in das Fragment des Links geschrieben, also in den Teil hinter dem #. Das Fragment ist dem Client vorbehalten und wird bei einer Anfrage nicht an den Server übertragen [2]. Zusätzlich sendet SecretApp Referrer-Policy: no-referrer, damit nicht einmal der Pfad des Links an andere Websites weitergegeben wird.

2. Schlüsselableitung

• Ohne Passwort: Der eigentliche Inhaltsschlüssel wird mit HKDF-SHA-256 aus dem Hauptschlüssel abgeleitet [3].
• Mit Passwort: Aus dem Passwort wird mit PBKDF2-HMAC-SHA-256 und 600.000 Iterationen ein Zwischenwert gebildet [4]; der Hauptschlüssel aus dem Link dient dabei als Salt. Aus diesem Zwischenwert gewinnt HKDF-SHA-256 zwei voneinander unabhängige Werte: den Inhaltsschlüssel und einen Prüfwert für die Zugangssperre des Servers [3]. Weil der Hauptschlüssel in die Ableitung eingeht, sind beide Teile zwingend nötig: Wer nur den Link abfängt, kommt ohne Passwort nicht weiter – und wer nur das Passwort kennt, ohne den Link ebenso wenig.

Der Inhaltsschlüssel ist als nicht exportierbar markiert und verlässt die Krypto-Schicht des Browsers nicht. Das Passwort selbst verlässt Ihr Gerät nie.

3. Verschlüsselung

Text, Dateinamen, Dateitypen und Dateiinhalte werden mit AES-256 im Galois/Counter Mode (AES-256-GCM) verschlüsselt [5]. Jeder verschlüsselte Block erhält einen eigenen, zufälligen Initialisierungsvektor mit 96 Bit. GCM ist ein authentisiertes Verfahren: Ein Prüfwert mit 128 Bit stellt sicher, dass veränderter Chiffretext beim Entschlüsseln erkannt und verworfen wird. Dateien werden in Abschnitte von derzeit 4 MiB zerlegt, die jeweils einzeln verschlüsselt und hochgeladen werden.

4. Was der Server erhält

Der Server erhält Chiffretext, die Dateigrößen, die gewählte Gültigkeitsdauer und – falls ein Passwort vergeben wurde – den oben beschriebenen Prüfwert. Den Schlüssel aus dem Link und das Passwort erhält er nie. Darauf beruht das Zero-Knowledge-Prinzip: Der Betreiber hat zu keinem Zeitpunkt die Mittel, Inhalte zu entschlüsseln.

Der Prüfwert dient als serverseitige Zugangssperre: Der Server speichert davon nur einen Hash, gebildet mit Argon2id, ersatzweise mit bcrypt [6], und vergleicht ihn beim Öffnen. Nach wenigen Fehlversuchen (standardmäßig fünf) wird das Secret endgültig gelöscht. Da der Schlüssel aus dem Link in den Prüfwert eingeht, kann der Server daraus weder das Passwort ermitteln noch gängige Passwörter durchprobieren – und den Inhaltsschlüssel ebenso wenig berechnen.

5. Einmaliger Abruf und Löschung

Beim Öffnen setzt der Server das Secret in einer einzigen, atomaren Datenbankoperation auf „verbraucht“. Bei zwei gleichzeitigen Aufrufen gewinnt genau einer. Ein Secret ohne Anlagen wird unmittelbar danach vollständig gelöscht. Bei Anlagen bleibt ein kurzes Zeitfenster, standardmäßig eine Stunde, in dem nur der Empfänger die verschlüsselten Abschnitte mit einem einmalig ausgegebenen Download-Token abholen kann. Sobald alles abgeholt ist oder das Zeitfenster endet, werden Datenbankeintrag und Dateien gelöscht.

6. Einordnung nach BSI und NSA

• BSI: Die Technische Richtlinie TR-02102-1 „Kryptographische Verfahren: Empfehlungen und Schlüssellängen“ (Fassung 2026-01) empfiehlt AES mit 128, 192 oder 256 Bit und führt GCM als empfohlenen Betriebsmodus für authentisierte Verschlüsselung [7].
• NSA: Die Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) vom September 2022 legt AES-256 als symmetrisches Verfahren für US-Regierungssysteme aller Geheimhaltungsstufen fest – ausdrücklich auch mit Blick auf künftige Quantencomputer [8].
• Quantencomputer: Der Grover-Algorithmus halbiert die effektive Schlüssellänge symmetrischer Verfahren. AES-256 behält damit rechnerisch 128 Bit Sicherheit – ein Niveau, das weiterhin als ausreichend gilt.

Quellen

1. W3C: Web Cryptography API
2. IETF: RFC 3986, Abschnitt 3.5 (Fragment)
3. IETF: RFC 5869 – HKDF
4. NIST: SP 800-132 – Password-Based Key Derivation (PBKDF2)
5. NIST: SP 800-38D – Galois/Counter Mode (GCM)
6. IETF: RFC 9106 – Argon2
7. BSI: TR-02102 Kryptographische Verfahren
8. NSA: Announcing the Commercial National Security Algorithm Suite 2.0 (PDF)

What is SecretApp for?

Email is like a postcard: it can be read at several points along the way, and it tends to sit in mailboxes for years. That is a poor fit for a password, a contract or a copy of an ID document.

SecretApp gives you a link instead. You send only that link – the content itself is never in the email. The link can be opened exactly once and expires afterwards.

How to use it

• Enter text, add files, or both.
• Choose how long the link should stay valid.
• Set a password if you want to.
• Click “Create secret link”.
• Send the link to the recipient – by email, chat, however you like.

The recipient opens the link, confirms with one click and sees the content. After that the link is used up.

Why is this secure?

Your text and files are encrypted on your own device before anything is transmitted. All our server ever receives is unreadable scrambled data.

The key that unlocks it lives in the link itself – in the part after the hash sign (#). Browsers never send that part of a web address to the server. So the key never reaches us.

This means even we, as the operator, cannot read your content. And if someone broke into our server and copied everything, all they would get is unreadable scrambled data.

The link works only once

As soon as the content has been shown once, it is deleted. A second visit only reports that the link is no longer valid.

That has a useful side effect: if your recipient opens the link and finds it already used, that is a warning sign – someone else may have read it.

Because some email systems and virus scanners follow links automatically, we show a confirmation page first. The content is only fetched once a person clicks the button there, so automated checks cannot burn your link by accident.

The optional password

You can set a password. The link alone is then no longer enough – the recipient also needs to know the password. The password itself is never sent to our server.

This is worth doing when you send the link over a channel you do not fully trust. Important: pass the password along by some other route than the link, by phone for instance. Putting both in the same email would defeat the purpose.

If the password is entered incorrectly several times, the link locks itself and the content is deleted, so nobody can work through a list of guesses.

The deletion link

After creating a secret you get two links: one for the recipient, and a second one that lets you delete the content early – handy if you made a mistake.

Keep that deletion link for as long as you need it. It is shown only once and cannot be recovered later.

How long is anything stored?

You decide when creating it: from one hour up to a year. Once that time is up, everything is deleted automatically, even if the link was never opened. It goes sooner if the recipient retrieves the content.

Things worth knowing

• The link is the key. Whoever holds it can reach the content, as long as it has not been opened. Treat it as carefully as the content itself.
• Lose the link and the content is gone. We cannot restore it, because we do not hold the key. That is not a shortcoming; it is the whole point.
• Do not shorten the link. The part after the hash sign belongs to it. URL shorteners or an incomplete copy will render the content unreadable.
• Security does not end here. If the recipient's device is compromised, no amount of encryption in transit will help.

What data is collected?

We store the encrypted content until it expires or is retrieved. We also briefly record which internet connection requests came from – in encrypted form, and solely to prevent large-scale abuse. Those records are deleted automatically after two days at the latest.

No account is needed, and we ask for neither names nor email addresses.

For the technically curious: the scheme in detail

This section describes exactly what happens in the browser and on the server. Numbers in square brackets refer to the sources at the end.

1. Key generation

When you create a secret, your browser generates a random 256-bit master key through the Web Crypto API [1]. It is Base64url-encoded into the fragment of the link, the part after the #. The fragment is reserved for the client and is not sent to the server with a request [2]. SecretApp also sends Referrer-Policy: no-referrer, so not even the path of the link is passed on to other websites.

2. Key derivation

• Without a password: the actual content key is derived from the master key using HKDF-SHA-256 [3].
• With a password: PBKDF2-HMAC-SHA-256 with 600,000 iterations turns the password into an intermediate value [4], with the master key from the link serving as the salt. From this value HKDF-SHA-256 derives two independent values: the content key and a verifier for the server's access gate [3]. Because the master key goes into the derivation, both parts are strictly required: intercepting the link is useless without the password, and knowing the password is useless without the link.

The content key is marked as non-extractable and never leaves the browser's crypto layer. The password itself never leaves your device.

3. Encryption

Text, file names, file types and file contents are encrypted with AES-256 in Galois/Counter Mode (AES-256-GCM) [5]. Every encrypted block gets its own random 96-bit initialisation vector. GCM is an authenticated mode: a 128-bit tag ensures that tampered ciphertext is detected and rejected on decryption. Files are split into chunks of currently 4 MiB, each encrypted and uploaded separately.

4. What the server receives

The server receives ciphertext, file sizes, the chosen lifetime and – if a password was set – the verifier described above. It never receives the key from the link or the password. That is what the zero-knowledge principle rests on: at no point does the operator have the means to decrypt any content.

The verifier acts as a server-side access gate: the server stores only a hash of it, made with Argon2id or bcrypt as a fallback [6], and compares it on opening. After a few failed attempts (five by default) the secret is deleted for good. Since the key from the link goes into the verifier, the server can neither recover the password from it nor try common passwords against it – nor compute the content key.

5. One-time retrieval and deletion

On opening, the server marks the secret as consumed in a single, atomic database operation. If two requests arrive at the same time, exactly one wins. A secret without attachments is deleted completely right afterwards. With attachments there is a short window, one hour by default, in which only the recipient can fetch the encrypted chunks using a download token issued once. As soon as everything has been fetched or the window closes, the database record and the files are deleted.

6. How this aligns with BSI and NSA guidance

• BSI: the German Federal Office for Information Security's technical guideline TR-02102-1 “Cryptographic Mechanisms: Recommendations and Key Lengths” (version 2026-01) recommends AES with 128, 192 or 256 bits and lists GCM as a recommended mode for authenticated encryption [7].
• NSA: the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) of September 2022 specifies AES-256 as the symmetric algorithm for US government systems at all classification levels – explicitly with future quantum computers in mind [8].
• Quantum computers: Grover's algorithm halves the effective key length of symmetric ciphers. AES-256 thus retains 128 bits of security, a level still considered sufficient.

Sources

1. W3C: Web Cryptography API
2. IETF: RFC 3986, section 3.5 (fragment)
3. IETF: RFC 5869 – HKDF
4. NIST: SP 800-132 – Password-Based Key Derivation (PBKDF2)
5. NIST: SP 800-38D – Galois/Counter Mode (GCM)
6. IETF: RFC 9106 – Argon2
7. BSI: TR-02102 Cryptographic Mechanisms
8. NSA: Announcing the Commercial National Security Algorithm Suite 2.0 (PDF)