Newsgroup: it.comp.sicurezza.varie
Titolo: criptaggio naturale ;)

Salve ragazzi,
è da un po' che no scrivo in NG con questo fine,
mi è stato chiesto di fare un programma che cripta cartelle e file
contenuti in esse.
Vorrei passare a questo mio amico un'applicazione con una certa
sicurezza pertando i dubbi vanno chiariti prima di intervenire,
vorrei realizzare una codifica a sostituzione con un dizionario N, e
su questa idea non mi sposto,
l'unica divergenza è questa,
a livello Hardware è possibile risalire al file originale pur avendo
riscritto il file con un contenuto diverso,
forse, riscrivendo il file in un'altra posizione e cancellando
l'originale sono sicuro, però il sistema operativo potrebbe tenere
traccia di questo,
cosa mi consigliate di fare per evitare che qualcuno riesca a
ritornare al contenuto originale avendo a disposizione la possibilità
di fare ciò che voglio del file? (tirare l'acqua del ces?)
bye duido

 su questa idea non mi sposto,
Con tutto il software di comprovata sicurezza che esiste (gnupg), con
tutti gli algoritmi sicuri che esistono (AES256, p.e.), vai a realizzare
tu un qualcosa con un algoritmo cosi' debole?
Scusa, ma fossi in te userei qualche cosa di gia' fatto.
-- 
HappyCactus - Linux User #209744 - 
http://pngstego.sourceforge.net
 
 
www.google.com
 - 
groups.google.com
/* Ci sono 10 categorie di persone al mondo: quelle che capiscono */
/* il sistema binario e quelle che non lo capiscono.              */

 di fare ciò che voglio del file? (tirare l'acqua del ces?)
Beh .. direi che dopo la codifica del file potresti inviarlo
ad un'altra macchina seguendo le specifiche di rfc1149
(vedi 
http://www.ietf.org/rfc/rfc1149.txt
) che tra l'altro oltre
ad essere wireless è difficilmente intercettabile :-)
Ciao
-- 
* ObiWan
DNS "fail-safe" for Windows 2000 and 9X clients.
http://ntcanuck.com
408 XP/2000 tweaks and tips
http://ntcanuck.com/tq/Tip_Quarry.htm

 Scusa, ma fossi in te userei qualche cosa di gia' fatto.
sono d'accordo con te, perchè mettersi a scrivere se le cose sono già
fatte, ma il mio amico vuole essere sicuro che nessuno possa risalire
al file originale e purtroppo, l'unica sicurezza che conosco è fare le
cose di propria mano, spero che su questo concetto camminiamo a
paripasso ;)
ObiWan mi ha consigliato di spostare il file su un'altra macchina,
purtroppo la macchina è unica, 1 disco fisso, un SO Win9.x.
Se poessi usare un floppy come contenitore avrei già risolto, ma il
file supera lo spazio disponibile.
L'ostacolo che vedo io è HD, forse potrei fare così,
- leggo il file origine
- scrivo in un'altra posizione il file codificato
( dove il contenuto HD è indefinito, perciò non si può risalire
all'originale )
- chiudo il file scritto
- riapro in scrittura il file origine e (apro+scrivo+chiudo) per N
volte un contenuto casuale,
non considerando i tempi d'esecuzione che saranno sicuramente più
lentini, per quente volte posso riscrivere il file per avere una certa
sicurezza?
bye duido

su questa idea non mi sposto,
Quella che dici tu e' una cifratura OTP ed in effetti e' sicura,
se prendi come base un bel CD pieno di rumore random. Pero', NON
e' questo che si intende quando si dice "a dizionario".
Leonardo
-- 
Questo messaggio e' NAGWARE. Per disattivare frecciatine, giochi
di parole, volgarita' gratuite ed inviti a rileggersi i messaggi
gia' passati e/o consultare 
http://groups.google.com
, effettuare
un versamento di 25 euro come tariffa di registrazione helpdesk.

 
Un sistama a dizionario è debole perché all'atto di un input I da sempre 
lo stesso output O
Cioè se dove trovo A metto B, il tutto diventa troppo semplice. Sarebbe 
più sensato fare qualcosa che dipenda anche dall'ordine...
tipo
per la codifica:
--->Input-->[XOR]-->[Cifratore]--+-->Output--->
               ^----[Memoria]-----/
per la decodifica:
--->Input-->[Decifratore]-->[XOR]---------------+-->Output--->
                               ^----[Memoria]----/

Ops ho fatto un errore...
Lo schema giusto di deco č:
  -+-->Input-->[Decifratore]-->[XOR]--->Output--->
    \----[Memoria]---------------^

 traccia di questo,
Se ti riferisci ai programmini di undelete, si, e' cosi'. L'ideale e' usare
una tecnica di wipe, che consiste nell'individuare i settori fisici del file
originale e scriverci dentro caratteri a caso, magari per piu' di una volta.
Tieni conto che una roba del genere e' comunque attaccabile. Basterebbe un
file leggimi, fargli un attaco statistico (basta sapere in che lingua e'
scritto, oppure un eseguibile windows, il primo kb, se non ricordo male, e'
sempre lo stesso, oppure anche una roba a forza bruta, facendo 255 tentativi
al massimo.
Perche' tanto odio?
Ciao
 Max

 sicurezza?
Gia', per quanto?
[1] Si considera infinita se e' a dimensione maggiore o uguale del
messaggio da cifrare


 al massimo.
ho considerato anch'io la struttura del file,
non conosco il contenuto dei documenti in questione ma so che sono
importanti e ho consigliato di salvarli in bmp.
bye duido

Sappiamo bene tutti e due che la teoria di un algoritmo sicuro è
impossibile,
ma è la stessa logica che lo evidenzia,
se ottieni un algoritmo reversibile di qualsiasi tipologia che ti
permetta questo tipo di operazione, e con questo comprendo anche tutti
gli algoritmi di compressione, ci siamo già risposti da soli,
reversibile significa poter ritornare all'origine e viceversa,
= nessuna sicurezza matematica...
Le tue parole sono giuste e capisco che non si può concludere una
risposta definitiva se non si hanno abbastanza conoscenze del tutto,
se non ti dispiace vorrei terminare il post con questa risposta, o se
preferisci sentiamoci in prv, mi sembra di divagare troppo in formule
concettuali,
ti ringrazio cmq per le dritte,
ringrazio anche tutti quelli che hanno risposto o letto il post
ps:
Leonardo aveva ragione, la cifratura che intendevo è OTP.
bye duido

 concettuali,
as you wish. 


 importanti e ho consigliato di salvarli in bmp.
mi sfugge il perche'.
HappyCactus forensis


se continuiamo così questo post si trasformerà in una chat,
il bmp una volta codificato non può essere attaccato sotto il punto di
vista statistico come un file di testo.
non può essere individuata parte della chiave considerando che un file
abbia sempre una stessa rappresentazione iniziale,
non può essere attaccato con forza bruta perchè la descrizione del
file non può essere indovinata a caso.
bye duido

abbia sempre una stessa rappresentazione iniziale,
In realta' e' vero il contrario. Nel caso del BMP classico di Windows,
e' noto all'incirca il primo kbyte del documento.
Inoltre, il formato BMP contiene pochissima informazione puntiforme, e
questo significa che tutta l'informazione che vedi arriva dalla chiave
crittografica.
Nel caso di una chiave di dimensioni ridotte, un po' di backtracking e
una quantita' tutto sommato ridotta di potenza di calcolo sbudella sia
il file che la chiave.
Si migliorano le cose, ma mica tantissimo, usando BMP bianco e nero.
A quel punto pero' forse e' il caso di usare il formato TIFF. Si puo',
con un po' di moccoli a girare, recuperare frammenti della chiave (che
a questo punto e' bene non sia ripetuta), un centinaio di bytes a ogni
file TIFF.
Leonardo
-- 
Tre cose sono da temere nel campo I.T.:
Un sysadmin con un cacciavite in tasca;
Un amministratore con un libro in mano;
Un utente con una grande idea in testa.

 vista statistico come un file di testo.
Ti rimando alla risposta di Leo.
Ribadisco, a questo punto, l'uso di un tool gia' fatto - gnupg, nella
fattispecie.


 il file che la chiave.
obbietivo centrato,
sbudellamento bit completato :)
concludendo serve solo una chiave di codifica + grande, non un formato particolare
bye duido