Newsgroup: it.comp.sicurezza.varie
Titolo: Cifrare file

Una curiosita' da sottoporre alle vostre critiche:
Sia A il file da cifrare, B un file (BMP, WAV) di dimensioni maggiori
(diciamo almeno il doppio..) di A.
Se io prendo il byte alla posizione 1 del file A, lo sommo al byte N
del file B (dove N e' un valore scelto da me, ovviamente tale che
N+A<=B), quel che risulta lo rimetto alla posizione 1 del file A, poi
prendo i1 byte 2 di A lo sommo al byte N+1 di B e rimetto in posizione
2 di A, ecc.
Alla fine avro' il file B immutato, il file A cifrato con chiave B (e
la chiave e' lunga come A...).
Per decifrarlo bisogna quindi conoscere la posizione di partenza in B,
e B stesso (oltre ad A...)
E' abbastanza sicuro il procedimento?
Quali problemi ci sono ? (a parte il pericolo di un "danneggiamento"
del file B)
,ciao,
Nebbia
,ciao,
Nebbia

del file B)
I problemi sono questi:
	1) randomicita' del file B. Se il file B contiene dati non
	   casuali (pensa a un file con tutti zeri!), o "sequenze"
	   che siano (a) costanti, (b) predicibili o (c) note, per
	   esempio RIFF ... per i file .WAV, e' possibile estrarre
	   dal file criptato pezzi del file sorgente. Da quelli e'
	   possibile risalire come prossimita' ad alcuni bytes del
	   file chiave, e cosi' riconoscere il file chiave (pensa,
	   per es., se ti cuccano l'hard disk - hanno 50000 files,
	   e non e' pratico tentarli tutti, soprattutto perche' la
	   certezza di trovare quello buono non c'e': potresti, il
	   file chiave, averlo tenuto su dischetto).
	2) riutilizzazione del file B. Indichiamo per brevita' con
	   (A x B) il procedimento di cifratura, e con (A x B) x B
	   la corrispondente decifratura. Se B e' costante, ed uno
	   cifra sia A che C con la stessa cifra, avra' poi, noti,
	   (A x B) e (C x B). (A x B) x (C x B) da' (A x C); ecco,
	   quindi, che se su N documenti A1,...,AN te ne sgamo uno
	   solo (Aj), da quello riottengo la chiave B, e da li' mi
	   decifro ogni bene.
	3) trasmissione del file B. Se vuoi mandare un "messaggio"
	   (A) in cifra, la controparte deve conoscere B. E quindi
	   devi trasmettergli prima B, su un canale sicuro...
Naturalmente, la trasmissione di B non deve essere per forza simultanea
alla trasmissione di A... durante un viaggio negli USA, io avrei potuto
portare con me un hard disk PCMCIA da 520 megabytes contenente "rumore"
random (ci sono ottime funzioni per ottenerlo). E a questo punto chi ha
quella PCMCIA puo' decifrare un messaggio del tipo:
19277569 [casino immondo]
XORando il casino immondo, con il contenuto dell'HD a partire dal punto
specificato. Io posso trasmettere fino a 520 megabytes da ora fino alla
consumazione dei secoli con la "certezza" che non me li decifri neanche
il buon Dio.
Eventualmente, posso utilizzare il primo blocco di dati per specificare
un nuovo punto di partenza ed uno skip factor ("dal byte X, prendendone
uno ogni Y). Poiche' anche una sottoripartizione di un insieme "random"
buono deve essere random (posso accertarmene con l'analisi Fourier), e'
si' vero che la sicurezza complessiva diminuisce teoricamente, ma, alla
resa dei conti, posso trasformare quei 520 mega in 520 giga senza paura
di farmi intercettare da qualcuno che abbia meno di 520 terabytes di HD
e svariati multi-giga-mips di potenza di calcolo. Almeno, non nel corso
della sua vita naturale :-)
Leonardo
".signature": bad command or file name

          1) randomicita' del file B. Se il file B contiene dati non
quindi un file bmp (la foto a colori del mio cane..//nebbia ..) o un
file wav (zombie, strawberries) sono "ricostruibili"... non ci posso
credere...(ossia se me lo dici ci credo ma resto allibito)
beh.. comunque posso dormire sonni tranquilli (*1)... tra l'altro e'
una cosa semplicissima da scrivere e (almeno nel mio caso con 1 unico
file non gigantesco) velocissima da eseguire... 
(*1) specialmente se il tutto passa solo su supporti removibili...
che dire... grazie come al solito....
ciao,
Nebbia

quindi un file bmp (la foto a colori del mio cane..//nebbia ..) o un
beh un BMP non compresso  si presenta piu' o meno cosi '
0001000
0010100
0100010
1111111    (e' una A)
1000001
1000001
quindi ... (certo dipende anche dal tipo di immagine, una foto con
molte sfumature di colore e' piu' varia)
Bonf

credere...
No, NON completamente, ma si puo' ricostruire una sequenza di N char
... e con quella sequenza ricercare, fra tutti i files del PC, quale
file la contiene (se si ottiene perche' nel file chiave c'era un tot
di zeri, questo metodo non funziona <grin>), e quello e' la chiave.
...forse. Potresti avercelo messo tu a spregio 8-)


unmaurizio che usa BMP true color ma forse cambia....
Casuali sui bits meno significativi, si'.
Leonardo che non e' la stessa cosa


1111111    (e' una A)
mi sembrava pero' che il formato BMP (a parte le intestazioni) fosse
(nel caso a 3 byte, 16milioni di colori)
unsigned char rosso 
unsigned char verde
unsigned char blu
...ecc fino alla fine...
quindi, una foto (anche se fatta su neve..) dovrebbe avere valori
parecchio variabili in quanto: se rosso=verde=blu=255 il pixel e'
bianco rosso=verde=blu=0 e' nero. le sfumature pero' darebbero valori
parecchio "casuali"
unmaurizio che usa BMP true color ma forse cambia....
,ciao,
Nebbia


Bonf

Il Mon, 08 Feb 1999 22:57:11 GMT, nob...@nowhere.world (Bonf) hai
scritto:
Sapevo io...
se ho ben capito quindi, proprio per il fatto che in una foto il
passaggio tra i colori avviene attraverso sfumature, cio' implica che
i valori che io credevo "abbastanza random" sono in realta' simili
(ossia variano di poco... quindi a livello di bit variano solo i bit -
significativi)
ho capito bene?
unmaurizio che usa anVA BMP truecolor ma cerca rumori random...
ciao,
Nebbia

unmaurizio che usa anVA BMP truecolor ma cerca rumori random...
Se ti serve un rumore random, ci sono tre metodi: prendere una funzione
pseudo-random veramente pseudo-random e inizializzarla con uno hash dal
valore letto dal registro VR della VGA, l'intervallo tra due tasti e il
bit meno significativo del registro posizione del mouse, tutti insieme,
dopodiche' generare una sequenza random "a bestia" :-);
Oppure: c'era un circuitino che essenzialmente amplifica il rumore shot
di un amplificatore differenziale e lo usa per pilotare un transistor.
Costava sulle 3 Klire. Con 50 Klire (compresa interfaccia IEEE 1284) ti
trovi a disposizione un dispositivo mappato in memoria, da cui leggi un
tale casino che solo il buon Dio saprebbe riprodurlo.
Il terzo metodo consiste nel prendere una Sound Blaster e regolarla per
acquisire dati sonori da... un filo di metallo. Salvo interferenze c'e'
solo un fruscio. Con "un po'" di lavoro, si regolano le cose perche' il
Veff del fruscio sia al 50%. A quel punto, hai una sorgente di rumore e
dovrebbe anche essere casuale - pero' di solito e' "rumore rosa", e non
"rumore bianco". Alcuni statistici potrebbero storcere il naso 8-)
Leonardo


L.S...@agora.stm.it
 wrote:
 >Costava sulle 3 Klire. Con 50 Klire (compresa interfaccia IEEE 1284) ti
 >trovi a disposizione un dispositivo mappato in memoria, da cui leggi un
 >tale casino che solo il buon Dio saprebbe riprodurlo.
Non direi, bisogna comunque lavarlo bene con una funzione di hashing
adatta, guarda l'ultimo numero di Phrack.
Un contatore geiger e un campione a bassa attivita` sono ancora meglio,
ma costa un po' di piu`.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *