Newsgroup: it.comp.sicurezza.crittografia
Titolo: VERNAM:ARMA BELLICA?

Ciao ragazzi,
vorrei chiedervi a voi che siete sicuramente piu' esperti una opinione su un
programma di criptaggio che ho trovato in rete,potrebbe anche essere
un'ottimo argomento di discussione volendo ma questo spettera' a voi
valutarlo.
Il programma in questione e il vernam scaricabile da
http://www.tonycrypt.com/Download.htm
 ho letto il suo articolo che vi
riporto qui di seguito:
Il sistema Vernam è un caso particolare della cifratura One time-Pad. La
cifratura detta a chiave infinita o one-time pad consiste nel generare una
chiave composta il più possibile da lettere, numeri e simboli disposti in
modo casuale, e di una lunghezza almeno pari alla lunghezza del testo da
criptare. Quindi per ogni carattere del testo in chiaro aggiungiamo (come
somma di valori ASCII ad esempio) un carattere della chiave, ottenendo il
testo criptato. E' facile intuire che una cosa del genere è praticamente
impossibile da decifrare, in quanto si basa su una chiave ottenuta in modo
assolutamente casuale (entropia massima) e senza la possibilità di
analizzare delle ripetizioni nel testo, in quanto la chiave ha appunto la
lunghezza stessa del testo. Questo sistema di codifica è usato per ottenere
i più alti gradi di sicurezza militare, ma ha il grosso difetto di non
essere impiegabile su vasta scala o per messaggi particolarmente lunghi.
Alcuni algoritmi sono stati costruiti approssimando il sistema a chiave
infinita con l'espansione di una chiave relativamente breve. Il sistema
"Vernam", ad esempio, usato nelle trasmissioni telegrafiche, usava lunghi
nastri di carta contenenti dei bit casuali, i quali erano aggiunti ai bit
del messaggio originario.
Il sistema Vernam può comportare degli svantaggi dovuti all'espansione della
chiave, se questa ha lunghezza molto inferiore a quella del messaggio da
cifrare. Risulta dunque conveniente usare chiavi molto lunghe e,
soprattutto, più casuali possibili. Si tratta di un algoritmo
efficientissimo, ma, essendo a chiave privata, comporta non pochi limiti.
E fin qui niente di strano ma la cosa che mi ha incuriosito e la seguente:
Dalla sezione download viene detto che tale software e considerato di
crittografia pesante ed non e ammessa in molti paesi perche' "CONSIDERATA
ARMA BELLICA"  dice che il suo uso e reato e che bisogna vedere se le norme
vigenti del nostro paese permettono di utilizzarlo...
Le mie domande ora sono:
Secondo voi e davvero cosi potente come si dice?
E realmente un'arma bellica come dice?
Dal vostro punto di vista se legale potrebbe essere meglio di tutti gli
altri software di criptaggio che circolano in rete?
Io non me ne intendo quindi spero che voi possiate fornirmi delle buone
delucidazioni,grazie e buon proseguimento.
Programma di crittografia basato sull'algoritmo Vernam. A differenza di
altri programmi di crittografia già pubblicati su Tonycrypt, il Vernam non
presuppone semplicemente scopi dimostrativi o didattici, ma è inteso ad una
reale ed assoluta protezione da qualunque forma di attacco crittoanalitico
(sempre che l'utente rispetti la condizione di non utilizzare ma più di una
volta la stessa chiave). L'utilizzo ripetuto della stessa chiave compromette
in modo estremamente grave la sicurezza dei dati trasmessi, perchè offre ai
crittoanalisti la possibilità di effettuare analisi di frequenze sui
messaggi. Pur ritenendo assolutamente sicuro ed inviolabile questo
programma, non ci assumiamo alcuna responsabilità riguardo a possibili danni
derivanti dal suo utilizzo. L'utente lo usi A SUO COMPLETO RISCHIO E
PERICOLO, senza alcuna garanzia da parte di Tonycrypt. Si fa inoltre
presente che la crittografia pesante (e lo è il Vernam) non è consentita in
molto Paesi, essendo spesso considerata arma bellica. Il suo impiego è
spesso considerato un reato; quindi, prima di utilizzare questo programma,
verificate che le leggi del vostro Paese lo consento

 
Nemmeno io me ne intendo, mi scuso se ho detto delle cavolate!
ciao
Marco

 messaggi.
...peraltro, come giustamente il sito dice, l'OTP è perfetto SE E SOLO
SE si seguono le sue "regole", appena si "esce" anche solo di poco da ua
di queste diventa facilmente da perfetto a... perfettamente rompibile.
(laddove alti sistemi come ad esempio AES "resistono" molto meglio: se
cifri due messaggi diversi con lo setsso OTP sei praticamente certo che
quei messaggi siano leggibili, mentre il migliore attacco conosciuto su
AES richiede almeno 2^110 messaggi conosciuti per ricavare la chiave).
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkDLBGwACgkQaJiCLMjyUvvBRACgzlOBJjCdd+tAoZIqrFrSopyU
Lg8Anijn7LRiTrQQnZLwBVirvY80HlGT
=5JQS
-----END PGP SIGNATURE-----

Ma non si potrebbe creare una versione di PGP modificata, in cui come
algoritmo simmetrico si usi l'OTP????
Il programma genera una chiave di sessione lunga quanto il msg, lo codifica,
e questa è la seconda parte del msg, poi codifica la chiave con un
algoritmo asimmetrico e il risultato diventa la prima parte del msg.
Poi il tutto può essere compresso con un algoritmo tipo gzip.
La dimensione dei msg codificati con PGP, grazie alla compressione, non è
molto maggiore di quella dei msg in chiaro, anzi direi simile.
Quindi in questo sistema, se il msg risulta lungo n byte, codificato sarà
ancora lungo n byte (usando XOR). La parte della chiave codificata (1a
parte) sicuramente sarà lunga almeno n byte, però per via del processo di
codifica, credo che possa raggiungere la lunghezza di 2n byte. (queste sono
mie stime, ovviamente avrò sbagliato tutto, ma a grandi linee, supponendo
che l'algoritmo di compressione faccia guadagnare un 50%, deduco questo da
una analisi superficiale del funzionamento di PGP)
Ora in totale, un msg codificato risultarebbe lungo n + 2n = 3n, ovvero 3
volte quello originale, però comprimendoslo cn gzip potrebbe avere
dimensione 3/2n. (supponendo di guadagnare un 50%)
E non considero troppo lungo un msg del genere, considerato il livello di
sicurezza che fornisce, ovverò viene eliminato un anello della catena e la
sicurezza del sistema viene basata sull'algoritmo asimmetrico.
Solo che credo di aver capito male qualche passagio nel funzionamento di
PGP, non è che la lunghezza finale del msg sia dovuta alla codifica della
chiave e non del testo semplice? Dato che il msg, nel funzionamento solito
di PGP viene compresso prima di essere cifrato, la differenza di dimensione
potrebbe essere dovuta alla cifratura della chiave, quindi se la chiave da
cifrare è lunga quanto un msg, il risultato finale non è più 3n, ma anche 5
etc etc n, e quindi diviene un'idea assurda.
Ok mi auto rispondo, è proprio così, se un alg. simmetrico riceve n bit,
deve restituire n bit (da Cristiano), quindi la lunghezza del msg dipende
dalla chiave.
Bhe posto lo stesso, magari a qualcuno che ha avuto la stessa idea può
servire :-D
        Manuel

 dimensione 3/2n. (supponendo di guadagnare un 50%)
1. tutti gli altri algoritmi mantengono la lunghezza (a meno di poco
padding), difficile convincere qualcuno ad usarne uno che produca output
più lunghi
2. le cose crittate per definizione non sono comprimibili: se fossero
comprimibili sarebbero distinguibili dal testo casuale, e quindi attaccabili
Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkDLjmsACgkQaJiCLMjyUvv/uwCgtJD05ZOe954PoXemYoNLp3Hb
dBIAn1E6RTG7jYq0E7OLwBVO2jjvP9JZ
=bAU3
-----END PGP SIGNATURE-----

 
Era sott'inteso che intendessi casuale, altrimenti che OTP sarebbe???
La chiave verebbe mandata crittata tramite l'algoritmo di crittografia a
chiave pubblica, come funziona ora PGP/GPG.
Sarebbe lo steso funzionamento di PGP di ora, solo con la chiave + lunga...

 Sarebbe lo steso funzionamento di PGP di ora, solo con la chiave +
lunga...
Forse non lo sai, ma attualmente nella catena di passaggi "RSA+AES" il
passo considerato più resistente è proprio "AES", quindi non ha molto
senso avere un "RSA+OTP"...
Oltre al fatto che la crittografia a chiave pubblica è *estremamente
lenta* quindi il sistema finale, oltre a non essere "molto" più sicuro
dell'originale è anche 3 volte meno efficente in spazio e PARECCHIE
volte meno efficente in tempo.
Se la crittografia asimmetrica non fosse così lenta, il passaggio
simmetrico potrebbe essere evitato tout-court, crtitando direttamente il
messaggio con RSA: questo sistema sarebbe "lento quanto il tuo", con
messaggi di lunghezza "normale" e nno duplicata, e sicuro esattamente
nello stesso modo.
(mandare "A xor K" assieme a "K", per quanto buona opssa essere la
chiave "K", è assolutamente identico a mandare direttamente "A")
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkDNZtwACgkQaJiCLMjyUvuLzQCgjIqNJxN5RpdSH0w0HdHWxYDB
essAn3cuyjgpkINLKRMSLZ614eoWM8BU
=oA3C
-----END PGP SIGNATURE-----

 
Si immaginavo che fosse quello il passo + resistente, ma la mia idea era di
aumentare ulteriormente la sicurezza utilizzando l'OTP al posto del'AES,
solo che ho capito che non è una saggia scelta.
Bhe grazie per li info!
        Manuel

 aumentare ulteriormente la sicurezza utilizzando l'OTP al posto del'AES,
Ma la sicuerzza si aumenta aumentando quella l'anello della catena MENO
resistente, aumentare quello già più resistente non cambia le cose,
perché l'anello più debole saerbbe comunque il "primo" a rompersi.
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkDNwUsACgkQaJiCLMjyUvvMUgCg9wAlY89REG4m6Lai2ZzWQ3f7
OOoAn0mLoq6rM5o37bZVEyLi0NMlUMk7
=wr0O
-----END PGP SIGNATURE-----

 attaccabili
Anche se non mi intendo di crittografia, su questo mi trovi in disaccordo.
L'algoritmo di Huffman ad esempio cerca le ricorrenze dei singoli byte e non
di parole (per parole intendo una serie di caratteri ripetuti più volte nel
testo), quindi  offre una buona compressione.
bye
-- 
Esistono 10 tipi di persone: chi conosce il binario e chi no.
Gestione Ottica - Gestionale per Ottici e Programmi Gratuiti su:
http://www.nicolaottomano.it

"Ottomano Nicola" <amici_...@nicolaTOGLIQUESTOottomano.it> ha scritto
nel messaggio news:BIxzc.37868$G%.15070@tornado.fastwebnet.it...

Ragazzi permettetemi intanto di ringraziarvi per le risposte anche troppo
tecniche per me :-),siete stati fin troppo gentili,ora mi rimane un
dubbio...quali programmi a parte pgp mi consigliate di usare?buon
proseguimento a tutti.

 testo), quindi  offre una buona compressione.
Cosa di quello che ho scritto ti suggerisce che parlassi di "parole"?
In genere quando faccio "affermazioni" lo faccio con cognizione di
causa, in caso contrario uso termini come "credo, penso, potrebbe essere
che"...
Comunque, questioni "di forma" a parte... una delle definizioni di
sicurezza di un algoritmo è, come accennavo, che il suo output è
indistinguibile da un insieme di dati casuali (nel senso di "rumore
bianco").
Quindi a prescindere che tu "veda" questi dati 1 bit alla volta, a
nibble, a byte, a word da 32 bit o "come ti pare", avrai sempre una
distribuzione media dei valori "omogenea".
Dato che l'algoritmo di Huffman sfrutta il fatto che alcuni simboli
possano essere più probabili di altri, per assegnargli codici di
lunghezza inferiore alla media (assegnando ovviamente codici più lunghi
della media a ciò che è meno probabile) non può lavorare sull'output di
un buon algoritmo crittografico, in quanto ogni simbolo avrebbe
probabilità praticamente identica agli altri.
Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkDO/UQACgkQaJiCLMjyUvvM2ACgooWqqu/o/4PwRYJcAIUzu8mU
rk8AniB6+ZIUs8ixOB7gu3kJTt72qAL1
=TXPf
-----END PGP SIGNATURE-----

 ha scritto nel messaggio
news:2j891lF...@uni-berlin.de...

Ti chiedo scusa ma non ho capito cosa vuoi dire...

 simbolo avrebbe probabilità praticamente identica agli altri.
L'algoritmo di cui parli tu è una variante. Si tratta dell'algoritmo di
Huffman Adattivo, molto utilizzato nella compressione post acquisizione
video (vedi il codec Huff YUV). Ha il pregio di "adattarsi" al flusso di
bit, ma la compressione è leggermente più bassa di quella normale.
Ora, a parte la precisazione tecnica, quello che vorrei dire è che
l'algoritmo di  Huffman che intendevo io non sfrutta il fatto che i simboli
siano più probabili, ma il numero di volte che un simbolo ricorre in una
sequenza di simboli.
E, per quello che dicevo prima, ci sono sempre (nella pratica) simboli che
ricorrono più volte degli altri (credo sia impossibile, leggi altamente
improbalile, che _tutti_ i simboli compaiano lo stesso numero di volte nella
stessa sequenza).
Però non avevo colto il tuo "per definizione", quindi solo in teoria e non
in pratica.


 verifica solo su numeri molto grandi).
Ma l'enigmista t'ha già detto che se ciò accadesse, significherebbe che
l'algoritmo non sarebbe valido.
In altre parole, se la frequenza di alcuni byte fosse significativamente
diversa da quella degli altri, l'algoritmo non sarebbe valido (il termine
"significativamente" è perfettamente definibile) .
Cristiano

 definibile) .
Questa discussione mi ha stuzzicato la voglia di approfondire. Allora sono
partito a fare alcune prove:
1-Prendo un file
2-Lo critto
3-Lo comprimo (con Huffman e con Zip)
4-Controllo quanto le affermazioni fatte siano riscontrabili nella realtà
Dunque:
I file in questione sono scaricabili da
www.nicolaottomano.it/public/Crittatura.zip
Il file in chiaro occupa 2.446 byte
Il file crittato con AES Rinjdael (password: prova) occupa: 3.397 byte
Il file compresso con Huffman occupa: 2.816 byte
Il file compresso con Zip (che usa Huffman+LZ77) occupa: 2.782 byte
Con questo non metto assolutamente in dubbio quanto detto da Lapo, ma voglio
precisare che nella realtà le cose possono essere diverse dalla pura e
semplice teoria.


 dalla pura e semplice teoria.
Puoi mettere in dubbio qualunque cosa, l'importante è che dimostri
adeguatamente ciò che asserisci.
Ti va di provare l'esperimento fatto nel modo giusto?
Cristiano

 in pratica.
No, anche in pratica.
Come ho detto la compressione funziona solo su "grandi numeri", quindi
la media campionaria e quella teorica tendono a coincidere.
Nota, peraltro, che il compressore di Huffman è paercchi "datato e oggi
come oggi essitono compressori molto milgiori, quindi al limite la prova
sarebbe da fare con quelli...
Comunque, se motivi "teorici" non ti convincono (povero Shannon),
vediamo di fare una prova pratica, provare per credere:
#!/bin/sh
echo Comprimo con "gzip -9"
gzip -9 <gpl.txt >gpl.txt.gz
echo Comprimo con "bzip2"
bzip2 <gpl.txt >gpl.txt.bz2
echo Critto con AES
gpg -c --cipher-algo AES256 --compress-level 0 <gpl.txt >gpl.txt.aes256
echo Comprimo con "gzip -9"
gzip -9 <gpl.txt.aes256 >gpl.txt.aes256.gz
echo Comprimo con "bzip2"
bzip2 <gpl.txt.aes256 >gpl.txt.aes256.bz2
...ed ecco il prevedibile output...
gpl.txt               18009
gpl.txt.gz             6846
gpl.txt.bz2            6190
gpl.txt.aes256        18060
gpl.txt.aes256.gz     18083
gpl.txt.aes256.bz2    18518
(nota che ho detto a GPG di non comprimere l'input con gzip, altrimenti
la dimensione non sarebbe stata comparabile con gpl.txt, ma con gpl.txt.gz)
A parte un piccolo overhead generato dagli "header" dei vari formati,
puoi ben vedere che un file con contenuto "che sembra casuale" *è*
incomprimibile (come la teoria prevede).
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkDQBoAACgkQaJiCLMjyUvsZiACg5KPX3GlSZKe0YsDkdAzpSi0I
Bg8AnihzxrKAypUBkX2lL158rTHP73U4
=o3Hu
-----END PGP SIGNATURE-----


Ciao,
un TJL73 rassegnato...


 ha scritto nel messaggio
news:2jaj0qF...@uni-berlin.de...

Ok, grazie mille,mi dovete scusare ma leggendo tutto quello che avete
postato mi sono trovato un po'in difficolta' dato che non sono esperto in
materia,comunque grazie mille. buon proseguimento a tutti.

 Ti va di provare l'esperimento fatto nel modo giusto?
Mi andrebba, ma... un paio di post più giù l'ha già fatto Lapo :-)
Mi piacciono queste discussioni. Mi aprono la mente a nuove conoscenze...
Una discussione che mi è stata molto utile è stata anche questa:
http://www.google.it/groups?hl=it&lr=&ie=UTF-8&threadm=nGLDb.31698%245o6.3619%40tornado.fastwebnet.it&rnum=2&prev=/groups%3Fq%3Dottomano%2Bgroup:it.comp.sicurezza.crittografia%26hl%3Dit%26lr%3D%26ie%3DUTF-8%26selm%3DnGLDb.31698%25245o6.3619%2540tornado.fastwebnet.it%26rnum%3D2


 incomprimibile (come la teoria prevede).
Ho provato con il tuo metodo (e non con il mio che fa anche il Base64) e
devo dire che hai ragione.
Una sola domanda:
Perchè non è possibile eliminare il Base64 da qui?
http://www.lapo.it/AES.html
Io prevederei una casella di spunta. :-)


 Io prevederei una casella di spunta. :-)
Perché in primis è così grezzo e sempliciotto che pensao nessuno lo
usasse (ci sarebbero ben altre feature da implementare, in caso [1]) e
in seconda istanza perché un file crittato contiene moltissimi caratteri
non stampabili: come potrebbero essere visualizzati come testo" a
schermo, se non codificati in hex o nel più corto base64?
[1] ad esempio se avessi tempo di modificarlo farei almeno le seguenti
modifiche:
1. usare il "counter" mode anziché CBC, per evitare l'overhead del padding
2. utilizzare le nuove funzioni della mia libreria it.lapo.crypto ed
evitare codice con copyright cryptix
3. usare SHAd-256 invece che SHA-1 come hash (sempre dalla mia libreria)
Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAkDQmm4ACgkQaJiCLMjyUvtyygCgkjPHJZoM4lxfJhcCYbB6gxtK
nSIAmgMTQu8WOSJ17zybAuLg5wAxyIAu
=4Xu+
-----END PGP SIGNATURE-----