hakavlad/tirdStrumento di archiviazione steganografica e crittografia dei file
tird & tirdFS
tird /tɪrd/ (acronimo di "this is random data" — "questi sono dati casuali") è uno strumento di crittografia dei file che minimizza i metadati e nasconde i dati crittografati.
Con tird puoi:
tirdFS) all'interno di file contenitore e dispositivi a blocchi. A differenza di VeraCrypt e Shufflecake, i contenitori tirdFS non contengono intestazioni; l'utente specifica le posizioni dei dati all'interno del contenitore ed è responsabile di mantenere separate tali posizioni. Qualsiasi regione dall'aspetto casuale di un file o di un dispositivo a blocchi può essere usata come contenitore.tird offre negabilità plausibile integrata, anche quando i file crittografati sono memorizzati al di fuori dei contenitori. Aiuta anche a resistere ad attacchi coercitivi di divulgazione delle chiavi (crittanalisi con metodi brutali, xkcd 538).
[!AVVISO] Prima di usare
tird, leggi la sezione "Avvertenze". La sicurezza non dipende solo dallo strumento ma dalle tue azioni: conservazione sicura delle chiavi, operare in un ambiente sicuro ed evitare la modalità di debug con dati reali.
La stabilizzazione del formato e una specifica formale sono previste per v1.0.0.
Non devi memorizzare opzioni da riga di comando per usare tird. Questo strumento presenta una CLI basata su prompt: basta avviarlo, selezionare un'opzione dal menu e rispondere alle domande che seguiranno.```
$ tird
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]:
## Opzioni di Input
Ci sono 4 gruppi di opzioni di input: A (Azione), D (Dati), K (Chiavi), P (Procedi). Sono numerati per facilità di descrizione.```
+——————————————————————+————————————————————————+
| 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 |
+——————————————————————+————————————————————————+
Una descrizione dettagliata di queste opzioni con esempi può essere trovata qui.
Il carico utile che verrà crittografato durante la creazione del cryptoblob è composto da:
La specifica del carico utile nell'interfaccia utente appare come segue:``` 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 (секретные материалы)']
## Materiale di Chiave di Input
`tird` offre l'opzione di utilizzare il contenuto di file chiave e una passphrase per derivare chiavi monouso.
- **File chiave (opzionali):** Zero, uno o più percorsi di file chiave; l'ordine degli input non conta. Un percorso di file chiave può essere:
- Un <ins>file regolare</ins>. Il contenuto del file chiave verrà hashato, e il suo digest sarà utilizzato per ulteriore key stretching e derivazione delle chiavi.
- Un <ins>dispositivo a blocchi</ins>. Gestito come un file chiave regolare: il contenuto verrà hashato.
- Una <ins>directory</ins>. Tutti i file all'interno della directory verranno hashati e utilizzati come file chiave.
- **Passphrase (opzionale):** Fino a 2048 byte dopo la [normalizzazione](https://www.unicode.org/reports/tr15/) Unicode (forma C); può essere omessa.
Specificare l'IKM nell'interfaccia utente appare come segue:```
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
Per maggiori dettagli, fare riferimento alla specifica.
Mentre il contenuto di un messaggio crittografato è protetto, la sua dimensione, la sua provenienza, la sua destinazione… non lo sono. I dati sono nascosti, i metadati sono visibili. A volte, questo è tutto ciò di cui il tuo nemico ha bisogno per scoprire i tuoi segreti.
Uccidiamo persone in base ai metadati.
 Vs.  |
|---|
tirdFS — File System Steganografico Guidato dall'Utentetird impiega una tecnica che è descritta come segue:
Nascondere dati all'interno di dati crittografati o all'interno di dati casuali. Il messaggio da nascondere viene crittografato, quindi utilizzato per sovrascrivere parte di un blocco molto più grande di dati crittografati o di un blocco di dati casuali (un cifrario indistruttibile come il one-time pad genera testi cifrati che appaiono perfettamente casuali senza la chiave privata).
Puoi crittografare file e incorporare cryptoblob nei contenitori a partire da posizioni arbitrarie. Dopo aver scritto il cryptoblob, dovrai ricordare la sua posizione nel contenitore (le posizioni iniziale e finale), che verranno utilizzate in seguito per estrarre i cryptoblob. In questo modo, puoi creare tirdFS — file system nascosto, senza header, guidato dall'utente all'interno di un contenitore:
tirdFS non è un filesystem montato con strutture di metadati interne. È un modello di archiviazione nascosto gestito dall'utente costruito da cryptoblob posizionati indipendentemente.
Qualsiasi file, disco o partizione più grande della dimensione minima del cryptoblob (1160 B) può essere un contenitore valido. I cryptoblob possono essere incorporati in qualsiasi area.
Esempi di contenitori validi includono:
Esempio di struttura del contenitore:``` +—————————+—————————————+ <— 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 | +—————————+—————————————+
**Intestazione gestita dall'utente**
Un'intestazione di testo `tirdFS` gestita separatamente dall'utente potrebbe apparire come segue:```
[100000000:100345765] secret_video.mp4
[100345765:234765345] various_secrets.zip
[12654876456:14765345098] Epstein_files_part1.zip
That is, it should typically contain the location of each cryptoblob in the container plus a brief comment. However, the user is free to determine how to store positions and what to include in such a header.
The next image visualizes how hard it is to distinguish one random data entry from another and the process of embedding cryptoblobs in a container.
Empty container with random data:
One cryptoblob embedded in the container:
Two cryptoblobs embedded in the container:
Three cryptoblobs embedded in the container:
Animation: visualization of embedding:
Porta tutto con te. È un tuo diritto.
Guarda il seguente screenshot.
Sembra che questo volume da 16 GB contenga un solo file di 8,7 MiB. È davvero così? Forse sì, forse no.
Il filesystem ci dice che qui c'è un solo file. Ma c'è davvero un solo file sul volume? Non possiamo determinarlo usando il filesystem. In realtà, i dati potrebbero trovarsi al di fuori del filesystem ed essere non rilevabili dagli strumenti del filesystem. I 15,2 GiB di spazio contrassegnati come liberi potrebbero essere occupati da un filesystem nascosto. Questo spazio "libero" potrebbe essere occupato da dati crittografati nascosti.
Possiamo confutare l'esistenza di questi dati? Sì, ad esempio esaminando il livello di entropia di questo spazio libero utilizzando binwalk. Bassa entropia indica una probabile assenza di dati nascosti. Alta entropia non, da sola, prova la presenza di dati crittografati nascosti. Aree con alta entropia possono essere solo dati residui o dati crittografati nascosti.
Se sei interessato a nascondere dati al di fuori del filesystem visibile, tird è al tuo servizio per fornire un Mantello dell'Invisibilità per i tuoi file.
La crittografia a blocco temporale (TLE) può essere utilizzata per impedire a un avversario di accedere rapidamente ai plaintext in caso di compromissione dell'IKM (ad esempio, in caso di coercizione dell'utente). Nella nostra implementazione, si tratta in realtà di una derivazione della chiave a blocco temporale basata su PoW. L'opzione di input "Time cost" specifica il numero di passaggi di Argon2. Se si specifica un numero sufficientemente alto di passaggi, ci vorrà una quantità significativa di tempo per eseguirli. Tuttavia, un attaccante impiegherà la stessa quantità di tempo utilizzando hardware simile. L'esecuzione di Argon2 non può essere accelerata tramite parallelizzazione, quindi si prevede che il tempo speso da un attaccante sia approssimativamente lo stesso di quello speso dal difensore.
Questa implementazione TLE funziona offline, a differenza di tlock.
Imposta il valore TIME COST desiderato:```
K3. TIME COST (DEFAULT=4): 1000000
I: time cost: 1,000,000
W: decryption will require the same "TIME COST" value!
**TLE plausibile:** L'avversario non conosce il valore effettivo del costo temporale, quindi è possibile rappresentare in modo plausibile un numero errato di passaggi. L'avversario non può confutare la tua affermazione finché non tenta di decifrare il cryptoblob utilizzando il valore del costo temporale specificato.
## Opzioni da riga di comando
`tird` non richiede opzioni da riga di comando per l'uso normale.```
$ 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
[!WARNING] La modalità debug non è pensata per l'uso in produzione!
Avvia tird con l'opzione --unsafe-debug per guardare sotto il cofano mentre il programma è in esecuzione.
L'attivazione della modalità debug mostra inoltre:
[!WARNING] In questa modalità, il testo in chiaro restituito potrebbe essere stato modificato o sostituito da un attaccante!
Nella modalità decifratura non sicura, tird rilascerà il testo in chiaro anche se l'autenticazione fallisce. Usala solo se dai priorità alla disponibilità rispetto all'integrità, quando non riesci a decifrare con successo un cryptoblob in modalità normale.
tird non supporta:
tird non fornisce:
tird non può gestire (crittografare/incorporare) più di un file in una singola passata. La crittografia di directory e più file non è supportata.tird non igienizza i metadati del filesystem (atime, mtime, ctime).tird non è molto elevata (fino a 730 MiB/s nei miei test su hardware moderno).La crittografia può aiutare, ma non ti salverà da abusi, vulnerabilità, ingegneria sociale o minacce fisiche.
tird non è stato sottoposto ad audit di sicurezza indipendente da esseri umani.tird è inefficace in un ambiente compromesso; eseguirlo in tali casi può causare disastrose fughe di dati.tird sia efficace se utilizzato con chiavi brevi e prevedibili.tird non cancella i propri dati sensibili dalla memoria dopo l'uso; le chiavi potrebbero persistere in memoria dopo la chiusura del programma.tird non ordina i digest dei keyfile e delle passphrase in tempo costante.tird protegge i dati, non l'utente; non può impedire la tortura se sei sospettato.HKDF e un'implementazione veloce di ChaCha20)Argon2 e BLAKE2)tird(1)Migliorare la documentazione.
Sentiti libero di fare domande, lasciare feedback o fornire critiche nella sezione Discussioni.