Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
tird — Steganografisches Speicher- & Dateiverschlüsselungstool | Kitploit
Tools/GitHubGitHub/hakavlad/tird
Verschlüsselungs-/EntschlüsselungstoolsForensikSteganografieDatenwiederherstellungKryptographiePrivatsphäre
GitHubhakavlad/tird

tird

Steganografisches Speicher- & Dateiverschlüsselungstool

Repository anzeigen
222vor 2 MonatenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

🏠 Startseite    📑 Spezifikation    📜 Handbuchseite    📄 Eingabeoptionen    📖 Tutorial    ❓ FAQ    📥 Installation


Logo: Visualisierung von Zufallsdaten

tird & tirdFS

Releases PyPI

tird /tɪrd/ (ein Akronym für „this is random data“) ist ein Dateiverschlüsselungstool, das Metadaten minimiert und verschlüsselte Daten verbirgt.

Mit tird können Sie:

  1. Dateien erstellen, die mit Zufallsdaten gefüllt sind, um sie als Container oder Schlüsseldateien zu verwenden.
  2. Die Inhalte von Blockgeräten und regulären Dateien mit Zufallsdaten überschreiben, um Container vorzubereiten oder Restdaten zu vernichten.
  3. Dateiinhalte und Kommentare mit Schlüsseldateien und Passphrasen verschlüsseln. Das verschlüsselte Datenformat (Cryptoblob) ist ein gepolsterter uniformer Zufallsblob (PURB): Es sieht aus wie Zufallsdaten und hat eine zufällige Größe. Dies reduziert Metadaten-Leaks aus Dateiformat und -länge und ermöglicht es, Cryptoblobs in Zufallsdaten zu verstecken.
  4. Steganografische (verborgene, nicht nachweisbare) benutzergesteuerte Dateisysteme (tirdFS) in Containerdateien und Blockgeräten erstellen. Im Gegensatz zu VeraCrypt und Shufflecake enthalten tirdFS-Container keine Header; der Benutzer gibt die Datenpositionen im Container an und ist dafür verantwortlich, diese Positionen getrennt zu halten. Jede zufällig aussehende Region einer Datei oder eines Blockgeräts kann als Container verwendet werden.
  5. Schnellen Zugriff auf entschlüsselte Daten mithilfe von Zeitverschlüsselung verhindern.

tird bietet eingebaute plausible Abstreitbarkeit, selbst wenn verschlüsselte Dateien außerhalb von Containern gespeichert werden. Es hilft auch, erzwungene Schlüsselpreisgabe-Angriffe abzuwehren (Gummischlauch-Kryptoanalyse, xkcd 538).

[!WARNING] Bevor Sie tird verwenden, lesen Sie bitte den Abschnitt „Warnungen“. Die Sicherheit hängt nicht nur vom Werkzeug ab, sondern auch von Ihren Handlungen: sichere Schlüsselspeicherung, Arbeiten in einer sicheren Umgebung und Vermeidung des Debug-Modus mit echten Daten.

Formatstabilisierung und eine formale Spezifikation sind für v1.0.0 geplant.

Ziele

  1. Dateischutz: Gewährleisten Sie den Schutz einzelner Dateien, einschließlich:
    • Vertraulichkeit und Integrität durch authentifizierte symmetrische Verschlüsselung.
    • Minimieren Sie Metadaten-Leaks, einschließlich des Verbergens der Anwesenheit verschlüsselter Daten.
    • Verhindern oder widerstehen Sie erzwungenen Angriffen.
  2. Stabiles Format: Behalten Sie ein stabiles verschlüsseltes Datenformat ohne kryptografische Agilität für die Langzeitspeicherung bei.
  3. Einfachheit: Priorisieren Sie Einfachheit und vermeiden Sie Feature Creep; lehnen Sie die Implementierung von Funktionen ab, die nicht direkt mit den primären Sicherheitszielen zusammenhängen.

Funktionen

  • Verschlüsselte Blobs im PURB-Format: zufällige Größe und gleichmäßig zufällige Inhalte; metadatenbegrenzt (nur die Gesamtgröße gibt preis — keine Header, Typen oder Klartexthinweise).
  • Gepolsterte und verschlüsselte Kommentare: keine Klartexthinweise über den Inhalt.
  • Einbettung versteckter Daten (optional): verstecken Sie Cryptoblobs in zufälligen/verschlüsselten Containern für plausible Abstreitbarkeit.
  • Zeitverschlüsselung (optional): langsame offline PoW-basierte Schlüsselableitung zur Verzögerung der Entschlüsselung (Anti-Zwang).
  • Robuste authentifizierte Verschlüsselung: vollständig bindend, quantensicher ChaCha20-BLAKE2b AEAD.
  • Starke Schlüsselstreckung: Argon2id (libsodium „sensitive“-Profil) — 1 GiB Speicher, 1 Lane, 4 Durchläufe (Standard und Minimum).
  • Beliebiges Schlüsselmaterial: Schlüssel ableiten aus Passphrasen, Dateien, Blockgeräten oder Verzeichnissen — die Reihenfolge spielt keine Rolle.
  • Eingabeaufforderungsbasierte CLI: intuitiv und interaktiv, keine Flags zum Merken.
  • [TODO] Stabiles, dokumentiertes Format: geplant für langfristige Archivierung und Interoperabilität.

Verwendung

Sie müssen keine Befehlszeilenoptionen auswendig lernen, um tird zu verwenden. Dieses Tool verfügt über eine eingabeaufforderungsbasierte CLI: Starten Sie es einfach, wählen Sie eine Menüoption und beantworten Sie die folgenden Fragen.``` $ tird

root@kitploit:~
                   MENU
———————————————————————————————————————————
0. Exit              1. Info & Warnings
2. Encrypt           3. Decrypt
4. Embed             5. Extract
6. Encrypt & Embed   7. Extract & Decrypt
8. Create w/ Random  9. Overwrite w/ Random
———————————————————————————————————————————

A0. SELECT AN OPTION [0-9]:

root@kitploit:~
## Eingabeoptionen

Es gibt 4 Gruppen von Eingabeoptionen: A (Action), D (Data), K (Keys), P (Proceed). Sie sind der einfacheren Beschreibung halber nummeriert.```
+——————————————————————+————————————————————————+
| A0. SELECT AN OPTION | A. Select an action    |
+——————————————————————+————————————————————————+
| D1. INPUT FILE PATH  |                        |
| D2. COMMENTS         | D. Enter data,         |
| D3. OUTPUT FILE PATH |    data location,      |
| D4. OUTPUT FILE SIZE |    data size           |
| D5. START POSITION   |                        |
| D6. END POSITION     |                        |
+——————————————————————+————————————————————————+
| K1. KEYFILE PATH     | K. Enter values        |
| K2. PASSPHRASE       |    related to          |
| K3. TIME COST        |    key derivation      |
+——————————————————————+————————————————————————+
| P0. PROCEED?         | P. Confirm to continue |
+——————————————————————+————————————————————————+

Eine detaillierte Beschreibung dieser Optionen mit Beispielen finden Sie hier.

Nutzlast

Die Nutzlast, die während der Erstellung des Cryptoblobs verschlüsselt wird, besteht aus:

  • Inhalt einer Datei (optional): Eine reguläre Datei oder ein Blockgerät (komplette Festplatte/Partition). Wenn nicht angegeben, wird eine leere Datei als Nutzlast verschlüsselt.
  • Kommentare (optional): Beliebige UTF‑8-Zeichenkette, bis zu 1 KiB. Standardmäßig wird der Eingabedateiname verwendet. Entschlüsselte Kommentare werden bei der Entschlüsselung angezeigt.

Die Angabe der Nutzlast in der Benutzeroberfläche sieht wie folgt aus:``` D1. FILE TO ENCRYPT (OPT): files.zip I: path: 'files.zip'; size: 2,824,230,648 B (2.6 GiB) D2. COMMENTS (DEFAULT='files.zip'): The X-Files, zip (секретные материалы) I: comments will be shown as ['The X-Files, zip (секретные материалы)']

root@kitploit:~
## Eingabe-Schlüsselmaterial

`tird` bietet die Möglichkeit, die Inhalte von Schlüsseldateien und eine Passphrase zur Ableitung von Einmal-Schlüsseln zu verwenden.

- **Schlüsseldateien (optional):** Null, eine oder mehrere Schlüsseldateipfade; die Reihenfolge der Eingaben spielt keine Rolle. Ein Schlüsseldateipfad kann sein:
  - Eine <ins>reguläre Datei</ins>. Der Inhalt der Schlüsseldatei wird gehasht, und der Digest wird für weiteres Key-Stretching und Schlüsselableitung verwendet.
  - Ein <ins>Blockgerät</ins>. Wird wie eine reguläre Schlüsseldatei behandelt: Der Inhalt wird gehasht.
  - Ein <ins>Verzeichnis</ins>. Alle Dateien im Verzeichnis werden gehasht und als Schlüsseldateien verwendet.
- **Passphrase (optional):** Bis zu 2048 Bytes nach Unicode-[Normalisierung](https://www.unicode.org/reports/tr15/) (Form C); kann weggelassen werden.

Die Angabe von IKM in der Benutzeroberfläche sieht wie folgt aus:```
K1. KEYFILE PATH (OPT): key 
    I: path: 'key'; size: 32 B
    I: reading and hashing contents of 'key'
    I: keyfile accepted
K1. KEYFILE PATH (OPT): 
K2. PASSPHRASE (OPT): 
K2. CONFIRM PASSPHRASE: 
    I: passphrase accepted

Verschlüsseltes Datenformat

  • PURB-Format:
    • Daten, die zufällig aussehen und keine identifizierbaren Header enthalten; sie können ohne die entsprechenden Schlüssel nicht von zufälligen Daten unterschieden werden. Diese Eigenschaft ermöglicht es, Kryptoblobs zwischen anderen zufälligen Daten zu verstecken.
    • Randomisierte Größe: Die Auffülllänge wird gleichmäßig zwischen 0% und 25% der ungefüllten Kryptoblobgröße gewählt (entspricht bis zu 20% der endgültigen Kryptoblobgröße).
  • Kommentare werden vor der Verschlüsselung auf eine feste Größe von 1 KiB aufgefüllt (oder gekürzt), wodurch ihre ursprüngliche Länge vollständig verborgen wird.
  • Bilateral angewendete Salze: Das Überschreiben des Anfangs oder Endes des Kryptoblobs (oder das Speichern eines unvollständigen Kryptoblobs) macht eine erfolgreiche Entschlüsselung unmöglich.
 Kryptoblob-Schema anzeigen``` +————————————————————————————————————————————————————————+ | CSPRNG output: | | Salt for key stretching used with Argon2 (16 B) | +————————————————————————————————————————————————————————+ | ChaCha20 output: | | Encrypted pad_ikm (8 B) | +————————————————————————————————————————————————————————+ | CSPRNG/BLAKE2 output: | | Randomized padding (0-25% of the unpadded size) | | + MAC tag (32 B) | +————————————————————————————————————————————————————————+ | ChaCha20/BLAKE2 output: | | Encrypted payload file contents + MAC tags (0+ B) | +————————————————————————————————————————————————————————+ | ChaCha20/BLAKE2 output: | | Encrypted padded comments (1 KiB) + MAC tag (32 B) | +————————————————————————————————————————————————————————+ | CSPRNG output: | | Salt for pre‑hashing IKM used with BLAKE2 (16 B) | +————————————————————————————————————————————————————————+ ```

Weitere Einzelheiten finden Sie in der Spezifikation.

Geringe Beobachtbarkeit und Minimierung von Metadaten

Während der Inhalt einer verschlüsselten Nachricht geschützt ist, sind deren Größe, Herkunft, Zielort … nicht geschützt. Daten werden verborgen, Metadaten werden sichtbar. Manchmal reicht das aus, damit Ihr Feind Ihre Geheimnisse aufdecken kann.

— Loup Vaillant

Wir töten Menschen aufgrund von Metadaten.

— Michael Hayden


Vs.
  • PURB format:
    • Verschlüsselte Dateien sehen aus wie zufällige Daten.
    • Verschlüsselte Dateien haben eine zufällige Größe: Sie geben die Nutzlastgröße nicht preis.
  • Kommentare sind konstant aufgefüllt, sie geben weder ihre Größe noch ihre Existenz preis.
  • Es wird nicht nachgewiesen, dass die eingegebenen Schlüssel falsch sind.
  • Eingabeaufforderungsbasierte CLI: Keine Preisgabe der verwendeten Optionen durch die Shell-Historie.
  • Der Ausgabedateipfad wird vom Benutzer festgelegt und ist standardmäßig nicht mit dem Eingabedateipfad verknüpft.
  • Optional: Verstecken von verschlüsselten Daten in Containern.

tirdFS — Benutzergesteuertes Steganografisches Dateisystem

tird verwendet eine Technik, die wie folgt beschrieben wird:

Das Verbergen von Daten innerhalb von verschlüsselten Daten oder innerhalb von Zufallsdaten. Die zu verbergende Nachricht wird verschlüsselt und dann verwendet, um einen Teil eines viel größeren Blocks von verschlüsselten Daten oder eines Blocks von Zufallsdaten zu überschreiben (eine unknackbare Verschlüsselung wie das one-time pad erzeugt Chiffretexte, die ohne den privaten Schlüssel vollkommen zufällig aussehen).

Sie können Dateien verschlüsseln und Cryptoblobs in Container an beliebigen Positionen einbetten. Nach dem Schreiben des Cryptoblobs müssen Sie sich dessen Position im Container (Start- und Endposition) merken, die später zum Extrahieren der Cryptoblobs verwendet wird. Auf diese Weise können Sie tirdFS — ein verstecktes, headerloses, benutzergesteuertes Dateisystem — innerhalb eines Containers erstellen:

  • Es ist versteckt, weil es unmöglich ist, zwischen zufälligen Containerdaten und Cryptoblob-Daten zu unterscheiden, ebenso wie die Position geschriebener Cryptoblobs zu bestimmen, ohne die Positionen und Schlüssel zu kennen.
  • Es ist headerlos, weil Container keine Header enthalten; alle Daten über Cryptoblob-Positionen müssen vom Benutzer separat gespeichert werden.
  • Die Startposition des Cryptoblobs im Container ist benutzerdefiniert, und der Benutzer muss sowohl die Start- als auch die Endposition getrennt vom Container speichern. Deshalb wird es als benutzergesteuertes Dateisystem bezeichnet.

tirdFS ist kein gemountetes Dateisystem mit internen Metadatenstrukturen. Es ist ein benutzerverwaltetes verstecktes Speichermodell, das aus unabhängig platzierten Cryptoblobs besteht.

Jede Datei, Disk oder Partition, die größer ist als die minimale Cryptoblob-Größe (1160 B), kann ein gültiger Container sein. Cryptoblobs können in jeden Bereich eingebettet werden.

Beispiele für gültige Container sind:

  1. Speziell erzeugte Dateien mit Zufallsdaten.
  2. Festplattenbereiche, die Zufallsdaten enthalten. Zum Beispiel können Sie eine Festplatte mit Zufallsdaten überschreiben, sie in FAT32 oder exFAT formatieren und einen großen Teil der Platte nutzen, wobei Sie einige dutzend MB vom Anfang freilassen. Die Platte erscheint leer, es sei denn, Sie fügen einige Dateien hinzu.
  3. LUKS-verschlüsselte Volumes.
  4. VeraCrypt-Container, auch solche, die bereits versteckte Volumes enthalten.

Beispiel einer Containerstruktur:``` +—————————+—————————————+ <— Position 0 of the container | | | | | Random data | | | | | +—————————————+ <— Cryptoblob1 start position | Header- | | | less | Cryptoblob1 | | | | | Layer +—————————————+ <— Cryptoblob1 end position | | Random data | | Cake +—————————————+ <— Cryptoblob2 start position | | | | | Cryptoblob2 | | | | | +—————————————+ <— Cryptoblob2 end position | | Random data | +—————————+—————————————+

root@kitploit:~
**Benutzerverwalteter Header**

Ein separater benutzerverwalteter `tirdFS`-Textheader könnte wie folgt aussehen:```
[100000000:100345765] secret_video.mp4
[100345765:234765345] various_secrets.zip
[12654876456:14765345098] Epstein_files_part1.zip

Das heißt, es sollte normalerweise den Ort jedes Kryptoblobs im Container sowie einen kurzen Kommentar enthalten. Der Benutzer kann jedoch selbst bestimmen, wie Positionen gespeichert werden und was in einen solchen Header aufgenommen wird.

Visualisierung der Einbettung

Das folgende Bild veranschaulicht, wie schwierig es ist, einen zufälligen Daten-Eintrag von einem anderen zu unterscheiden, und den Prozess der Einbettung von Kryptoblobs in einen Container.

 Bilder anzeigen

Leerer Container mit Zufallsdaten: Container

Ein im Container eingebetteter Kryptoblob: Eingebettet1

Zwei im Container eingebettete Kryptoblobs: Eingebettet2

Drei im Container eingebettete Kryptoblobs: Eingebettet3

Animation: Visualisierung der Einbettung: GIF: Visualisierung der Einbettung

Speichern und Mitführen versteckter verschlüsselter Daten

Überall hinfahren. Es ist dein Recht.

— Kyle Rittenhouse

Bitte schauen Sie sich den folgenden Screenshot an.

Screenshot

Es sieht so aus, als ob dieser 16-GB-Volume nur eine einzige 8,7 MiB große Datei enthält. Ist das wirklich wahr? Vielleicht ja, vielleicht nein.

Das Dateisystem sagt uns, dass sich hier nur eine Datei befindet. Aber gibt es wirklich nur eine Datei auf dem Volume? Das können wir mit dem Dateisystem nicht feststellen. Tatsächlich können sich Daten außerhalb des Dateisystems befinden und für Dateisystem-Tools nicht erkennbar sein. Die 15,2 GiB freien Speicherplatzes könnten von einem versteckten Dateisystem belegt sein. Dieser „freie" Speicherplatz könnte mit versteckten verschlüsselten Daten gefüllt sein.

Können wir die Existenz dieser Daten widerlegen? Ja, zum Beispiel durch die Untersuchung des Entropie-Levels dieses freien Speicherplatzes mit binwalk. Eine niedrige Entropie deutet auf eine wahrscheinliche Abwesenheit versteckter Daten hin. Eine hohe Entropie beweist nicht von sich aus das Vorhandensein versteckter verschlüsselter Daten. Bereiche mit hoher Entropie können entweder nur Restdaten oder versteckte verschlüsselte Daten sein.

Wenn Sie daran interessiert sind, Daten außerhalb des sichtbaren Dateisystems zu verstecken, dann steht Ihnen tird zur Verfügung, um Ihren Dateien einen Tarnumhang zu verleihen.

Zeitverschlüsselung

TLE Bild

Zeitverschlüsselung (Time-lock encryption, TLE) kann verwendet werden, um zu verhindern, dass ein Angreifer bei einer Kompromittierung des IKM (z. B. bei Nötigung des Benutzers) schnell auf Klartexte zugreifen kann. In unserer Implementierung handelt es sich eigentlich um eine PoW-basierte Zeitverriegelungs-Schlüsselableitung. Die Eingabeoption „Zeitkosten" gibt die Anzahl der Argon2-Durchläufe an. Wenn Sie eine ausreichend hohe Anzahl von Durchläufen angeben, wird deren Ausführung eine beträchtliche Zeit in Anspruch nehmen. Ein Angreifer wird jedoch auf ähnlicher Hardware die gleiche Zeit benötigen. Die Ausführung von Argon2 kann nicht durch Parallelisierung beschleunigt werden, daher ist zu erwarten, dass der Zeitaufwand eines Angreifers ungefähr dem des Verteidigers entspricht.

Diese TLE-Implementierung arbeitet offline, anders als tlock.

Legen Sie den gewünschten Wert für TIME COST fest:``` K3. TIME COST (DEFAULT=4): 1000000 I: time cost: 1,000,000 W: decryption will require the same "TIME COST" value!

root@kitploit:~
**Plausible TLE:** Der Gegner kennt den tatsächlichen Wert des Zeitaufwands nicht, sodass Sie die Anzahl der Durchläufe plausibel falsch darstellen können. Der Gegner kann Ihre Behauptung nicht widerlegen, bis er versucht, den Cryptoblob mit dem angegebenen Zeitaufwandswert zu entschlüsseln.

## Befehlszeilenoptionen

`tird` erfordert für den normalen Gebrauch keine Befehlszeilenoptionen.```
$ tird --help
tird v0.30.0
        A tool for encrypting files and hiding encrypted data.
        Homepage: https://github.com/hakavlad/tird

Usage:
    tird [--unsafe-debug] [--unsafe-decrypt]

    Start without options for normal usage.

Options:
    --help            print this help message and exit
    --unsafe-debug    enable unsafe debug mode
    --unsafe-decrypt  release plaintext even if MAC verification
                      failed (dangerous)

Examples:
    $ tird
    $ tird --unsafe-debug

Unsicherer Debug-Modus

[!WARNING] Der Debug-Modus ist nicht für den Einsatz in der Produktion vorgesehen!

Starten Sie tird mit der Option --unsafe-debug, um während der Programmausführung einen Blick unter die Haube zu werfen.

Das Aktivieren des Debug-Modus zeigt zusätzlich:

  • Dateioperationen:
    • Öffnen und Schließen von Dateideskriptoren.
    • Tatsächliche Pfade zu geöffneten Dateien.
    • Bewegung von Dateizeigern.
  • Bytekaden im Zusammenhang mit kryptografischen Operationen: Salze, Passphrasen, Digests, Schlüssel, Nonces und Tags.
  • Einige andere Informationen, einschließlich verschiedener Größen.

Unsicherer Entschlüsselungsmodus

[!WARNING] In diesem Modus kann der zurückgegebene Klartext von einem Angreifer modifiziert oder ersetzt worden sein!

Im unsicheren Entschlüsselungsmodus gibt tird Klartext auch dann frei, wenn die Authentifizierung fehlschlägt. Nur verwenden, wenn Sie Verfügbarkeit über Integrität priorisieren, wenn Sie einen Cryptoblob im normalen Modus nicht erfolgreich entschlüsseln können.

Abwägungen und Einschränkungen

  • tird unterstützt nicht:
    • Public-Key-Kryptografie.
    • Dateikomprimierung.
    • ASCII-armored Ausgabe.
    • Reed-Solomon-Fehlerkorrektur.
    • Aufteilen der Ausgabe in Blöcke.
    • Verwendung von Standard-Streams zur Verarbeitung von Dateien (nicht für automatisierte Skripte gedacht).
    • Low-Level-Blockdevice-Lesen und -Schreiben unter MS Windows. Daher können diese Geräte nicht als Keyfiles verwendet, nicht überschrieben und nicht verschlüsselt oder eingebettet werden.
  • tird bietet nicht:
    • Eine grafische Benutzeroberfläche.
    • Einen Passwortgenerator.
  • tird kann (verschlüsseln/einbetten) nicht mehr als eine Datei in einem Durchlauf verarbeiten. Die Verschlüsselung von Verzeichnissen und mehreren Dateien wird nicht unterstützt.
  • tird bereinigt keine Dateisystem-Metadaten (atime, mtime, ctime).
  • tirds Verschlüsselungsgeschwindigkeit ist nicht sehr hoch (bis zu 730 MiB/s in meinen Tests auf moderner Hardware).

Warnungen

Kryptografie kann helfen, aber sie wird Sie nicht vor Missbrauch, Schwachstellen, Social Engineering oder physischen Bedrohungen schützen.

— Loup Vaillant

GEFAHR MINEN
  • ⚠️ Der Autor hat keinen Hintergrund in Kryptografie.
  • ⚠️ Der Code hat keine automatisierte Testabdeckung.
  • ⚠️ tird wurde keiner unabhängigen Sicherheitsprüfung durch Menschen unterzogen.
  • ⚠️ tird ist in einer kompromittierten Umgebung wirkungslos; die Ausführung in solchen Fällen kann katastrophale Datenlecks verursachen.
  • ⚠️ tird ist wahrscheinlich unwirksam bei Verwendung kurzer und vorhersagbarer Schlüssel.
  • ⚠️ tird löscht seine sensiblen Daten nach der Verwendung nicht aus dem Speicher; Schlüssel können nach Programmende im Speicher verbleiben.
  • ⚠️ Sensible Daten können in den Swap-Bereich gelangen.
  • ⚠️ Dateisystem-Zeitstempel werden nicht bereinigt – können operative Metadaten preisgeben.
  • ⚠️ tird sortiert Digests von Keyfiles und Passphrasen nicht in konstanter Zeit.
  • ⚠️ Überschreiben von Dateiinhalten garantiert keine sichere Vernichtung von Daten auf dem Medium.
  • ⚠️ Sie können einem Angreifer nicht beweisen, dass Ihre zufälligen Daten keine verschlüsselten Informationen enthalten.
  • ⚠️ tird schützt Daten, nicht den Benutzer; es kann Folter nicht verhindern, wenn Sie unter Verdacht stehen.
  • ⚠️ Die Schlüsselableitung verbraucht 1 GiB RAM, was auf Systemen mit wenig Arbeitsspeicher zu Leistungsproblemen oder Abstürzen führen kann.
  • ⚠️ Integrität/Authentizität vor Verfügbarkeit – das Ändern auch nur eines einzelnen Bytes eines Cryptoblobs verhindert die Entschlüsselung.
  • ⚠️ Die Entwicklung ist nicht abgeschlossen, und es kann zu Rückwärtskompatibilitätsproblemen kommen.

Anforderungen

  • Python >= 3.9.2
  • cryptography >= 2.1 (bietet HKDF und eine schnelle ChaCha20-Implementierung)
  • PyNaCl >= 1.2.0 (bietet schnelle Implementierungen von Argon2 und BLAKE2)
  • colorama >= 0.4.6 (Windows-spezifisch)

Dokumentation

  • 📜 tird(1) Manpage
  • 📑 Spezifikation
  • 📄 Eingabeoptionen
  • 📖 Tutorial/Demo
  • ❓ FAQ/Begründung
  • 📥 Installation

TODO

Verbesserung der Dokumentation.

Feedback

Bitte stellen Sie Fragen, hinterlassen Sie Feedback oder geben Sie Kritik im Bereich Discussions.

Tool herunterladen