Newsgroup: it.comp.sicurezza.crittografia
Titolo: [CSC-OTP] : Spiegazione :) [LUNGO]

Eccomi qui dopo tantissimo tempo che vi ho rotto le scatole finalmente 
in vacanza ho trovato il tempo per poter postare. Premetto so che 
riceverò solo critiche su critiche e so anche che molto probabilmente 
scriverò solo enormi puttanate ;) e quindi chiedo scusa in partenza ;) 
se non altro è una partenza verso qualcosa di costruttivo (almeno per me).
Le caratteristiche salienti dell'algoritmo sono:
- Non usa funzioni matematiche. Ho scelto questa strada in quanto ci 
sono ancora problemi non risolti (mi riferisco a quelli che potrebbero 
essere stati presi in considerazione) e visto che non sono un matematico 
ho preferito non impelagarmi in cose di cui non avrei capito nulla.
- Se immettiamo un testo in input da codificare ed una chiave fornisce 
un output diverso ogni volta che lo ricodifichiamo, per evitare attacchi 
di crittanalisi. Ad esempio se il testo da codificare è CIAO se lo 
codifichiamo 3 volte potrebbe sviluppare questi output FHSJJ, RWLMH, 
NLJRTH (esempio stupidello ma spero di aver reso l'idea)
- Funziona in stream e può essere facilmente implementato (questa è 
vecchissima come diceria :P )
Il suo funzionamento è semplice (almeno per me che l'ho creato ma sarà 
difficile per chi leggerà queste righe scritte in cinese :P).
Viene generato un keyfile personale, una sorta di chiave privata. 
All'internod i questo keyfile c'è la codifica in bit dei caratteri (nel 
mio caso ASCII). Non si ha una lunghezza standard per ogni carattere. Ad 
esempio questo è un tipo di keyfile:
.....
A = 0100111010101
B = 1101010011
C = 111100001110
D = 0001111000111100
.....
Logicamente devono tutti essere  maggiori di 1 byte (8 bit). Il keyfile 
servirà per la chiave inziale e per la creazione della chiave OTP. 
Quindi i passi da seguire saranno questi:
- Scelta della chiave iniziale
- Codifica della chiave iniziale
- Codifica del testo
La scelta della chiave iniziale nel nostro esempio potrebbe essere: ABC
La sua codifica: (A)0100111010101 (B)1101010011 (C)111100001110 che sono 
le sequenze di bit registrate nel keyfile.
Per la codifica del testo si procede in questo modo. Sappiamo che nel 
nostro caso (per i caratteri ASCII) ogni carattere è formato da 8 bit 
che formano 1 byte. Ora questi 8 bit andranno scritti solo in 
corrispondenza dei bit posti ad 1 nella chiave seguendo queste regole:
- Per ogni bit 0 della chiave generare un bit random
- Per ogni bit 1 della chiave scrivere un bit dell'informazione 
eseguendo lo XOR con il bit precededentemente scritto.
In questo modo con i bit che noi generiamo random avremo dei bit inutili 
che ci serviranno per evitare attacchi di crittoanalisi e fornendo un 
output sempre diverso.
[ESEMPIO PRATICO]
Chiave iniziale: 01101001010010011010010101010001111100101110101101
Informazione da codificare: 10010100 01010101
Come abbiamo spiegato al posto dei bit = 0 nella nostra chiave 
genereremo un bit random al posto dei bit = 1 della nostra chiave 
registreremo un bit della nostra informazione eseguendo lo XOR con il 
bit precedente.
Mostriamo come verrebbe registrata l’informazione mentre codifichiamo.
01101001010010011010010101010001111100101110101101 = chiave
  10 0  1 0  1  00 0  1 0 1 0   101                 = informazione
Quindi generando i bit random negli spazi vuoti e suddividendo tutto in 
byte avremo:
01101001 01001001 10100101 01010001 11110010 = chiave
0  1 11  0 01 10   1 11 0  0 0 001    101110 = bit random generati
Eseguendo lo XOR tra il bit precedente e il bit dell’informazione avremo
01101001 01001001 10100101 01010001 11110010 = chiave
0  1 11  0 01 10   1 11 0  0 0 001    101110 = bit random generati
  10 0  1  0  1  0 0 0  1 0  1 0   1 01       = informazione
01111110 00010100 01111000 01000010 01101110 = risultato
                                       |____| = Questi bit sono random 
ed                                                       						inutili
Per la decodifica leggeremo solo i bit che si trovano nello stesso punto 
dei bit della chiave = 1 eseguendo lo XOR con il bit precedente:
01101001 01001001 10100101 01010001 11110010 = chiave
01111110 00010100 01111000 01000010 01101110 = risultato codificato
Quindi:
01101001 01001001 10100101 01010001 11110010 = chiave
01111110 00010100 01111000 01000010 01001110 = risultato
  10 0  1  0  1  0 0 0  1 0  1 0   1 0110  0  = risultato decodificato
Convertendolo in byte ed eliminando i bit eccedenti:
10010100 01010101 = risultato decodificato
10010100 01010101 = informazione originale
[/ESEMPIO PRATICO]
Un'ultimo punto da spiegare è la generazione della chiave per la 
codifica OTP. Come sappiamo un buon OTP dovrebbe avere una chiave lunga 
almeno quanto il messaggio originale edovrebbe essere totalmente random. 
La chiave che viene generata dall'algoritmo è formata in questo modo. 
Inizialmente è formata solo dalla chiave che abbiamo scelto, 
ricodificata secondo le sequenze di bit che abbiamo nel nostro keyfile 
poi man mano che vengono letti caratteri dall'informazione ecco che si 
accodano alla chiave originale (sempre ricodificati mediante il 
keyfile). In questo modo ci siamo assicurati sempre di avere una chiave 
lunga e casuale per la codifica OTP che non viene eseguita direttamente 
tra l'informazione e la chiave ma tra il bit corrente ed il bit 
precedente per fornire sempre bit diversi in uno stesso punto 
dell'informazione.
Spero che sia stato un po chiaro e mi scuso per alcune incomprensioni. 
Adesso mi dedicherò ai test da effettuare (ho scaricato il PDF del NIST, 
la suite per l'approvazione dell'AES). Intanto ho scritto una bozza di 
documento tecnico se qualcuno vuole dargli un'occhiata ne sarei 
veramente felice.
Grazie di tutto :)
Questi sono i miei contatti:
capobec...@SPAMhotmail.com (Logicamente a chi mi scrive darò l'email 
ufficiale)
http://www.NOboundlessmindsSPAM.it/cscotp/cscotp.pdf
 <- Pseudo documento 
tecnico :P
Messenger vari
msn = 
NOcapobec...@hotmail.com
yahoo = 
NOcapo_be...@yahoo.it
icq = 217325174
ps. Levare NOSPAM per i link ;)
pps. CSC-OTP = Caos Stream Cipher - One Time Pad ... nome stupido 
booooohhhhhh!!! :P :D
Grazie ancora.
--
Enrico Scognamillo alias [CapoBecchino]

 output sempre diverso.
Sicuramente io non saprei da che parte cominciare per attaccare questo
algoritmo, naturalmente per valutarne l' effettiva bonta' abbiamo
bisogno di quel corredo di preparazione alla crittoanalisi e analisi
numerica piu' in generale che, come abbiamo detto, non abbiamo (e non solo
noi).
Una cosa che ho capito leggendo le descrizioni dei progetti degli altri
algoritimi, e' che spesso i meriti di un algoritmo sono piu' nel
design che nella effettiva sicurezza. infatti fare un algoritmo piu' forte
di uno gia' esistente e ben esaminato e' semplice: basta vedere che
aspettando AES hanno temporaneamente adottato triple-DES che altro non e'
che 3 applicazioni di DES con 3 chiavi diverse
(1 crypt, una Decrypt e 1 Crypt)
per un totale di 168 bits di chiave. Inoltre mettendo la 2 e la terza
parte di chiave uguali tra loro si ha la compatibilita' con i prodotti
DES.
Quindi la forza non e' il primo attributo, ma il design, cioe' ottenere
il massimo della forza con pochi cicli macchina, poche porte logiche
di circuiti integrati, semplice tecnologia.
Anche un algoritmo non fortissimo, ma geniale in certi aspetti progettuali
avra' alcune applicazioni, poi' come detto, aumentarne la forza sara'
sufficiente applicarlo piu' volte con chiave piu' lunga.
Quindi credo che un algoritmo che produce un Crittogramma piu' lungo del
corrispondente Datagramma perda gia' molti punti, ma non voglio mai
scoraggiare la creativita' di nessuno: Continua pure a svilupparlo.
Solo ti consiglio di ispirarti ache al lavoro degli altri. A me per esempio
ha impressionato molto il design di IDEA, (senza togliere niente a AES,
TWOFISH e lo stesso Blowfish che continuo a preferire)
Anche io ho una ideuzza da proporre all' attenzione di tutti, ma non sono
ancora pronto.
Ciao.
Roberto.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 grazie
Effettivamente applicare piu' chiavi in XOR non serve a niente, ma questo
solo perche' XOR e' una semplice combinazione lineare e reversibile.
Anche applicare piu' volte la stessa chiave non e' utile, anche con
algoritmi classici.
Ma come detto, 3DES docet, usare un obsoleto algoritmo come
DES che comunque ha dimostrato ottime qualita' di resistenza alla
crittoanalisi (la sfiga di DES e' solo la lunghezza delle chiave e
cade solo di brute-force) nonche' buone qualita' non-lineari, per
applicare PIU' CHIAVI diverse e quindi per ottenere quindi un
keyspace maggiore funziona.
Purtroppo 3DES a parita' di sicurezza e' lentissino.
(Guarda blowfish invece: 
http://www.schneier.com/blowfish-speed.html
)
Altra cosa che mi e' venuta in mente:
Un buon algoritmo NON DEVE RIVELARE LA KEY in caso di Known plan TEXT.
Va da se: XOR non e' utilizzabile in altro che in OTP.
Il tuo algoritmo purtroppo e' attaccabile in questo modo. Basta conoscere
o ipotizzare e ricercare in modo metodico un testo (dilatando i bits)
e vedere quando la chiave ottenuta con lo XOR si ripete. I Bits aggiuntivi
random che metti sono piu' un costo di gestione per chi usa l' algoritmo
piu' che una difficolta' per l' attaccante. Known plan TEXT e' il minimo
dell' attacco a un cifrario. Persino io, con le mie 0 competenze saprei
attuarlo.
Purtroppo credo che la tua idea debba essere ulteriormente sviluppata.
Devi fare in modo che se l' attaccante al tuo cifrario gia' conosce
parti del testo in chiaro non possa risalire alla chiave. Questo rende
necessario l' uso di sostituzioni non lineari.
Mi hai chiesto dei links su IDEA.
partendo da:
http://www.securitytechnet.com/crypto/algorithm/block.html
ho trovato:
http://www.media-crypt.com/
Attenzione che IDEA e' brevettato a livello internazionale.
Usa la somma, lo XOR e una operazione in un campo perche' i
progettisti si sono accorti che (2 pow 16) + 1 e' un numero primo
quindi, attribuendo a 0 il valore effettivo di 2 pow 16 hanno
implementato la moltiplicazione e la divisione (o meglio la
moltiplicazione per l' inverso moltiplicativo ottenuto con l' algoritmo
di Euclide.) (non vorrei per ora divagare su cosa e' un campo..)
Dai un' occhiata anche a Blowfish. E' una feistel-net classica
e usa delle substitution-box key-dependent. Blowfish ad oggi risulta
inattaccabile e considerando che ha piu' di una decina d' anni ...
AES non e' una Feistel-net e usa delle funzioni di algebra nei campi
di Galois non difficilissime, ma a me ancora non piace.
Attenzione che Blowfish ha il limite dei blocchi a 64 bits e quindi
gia' per questo non andava bene come standard AES.
Ciao
Roberto


 parti del testo in chiaro non possa risalire alla chiave. 
Ed infatti credo che non sia possibile a meno che di conoscere anche la 
chiave privata il che rende il tutto (come ogni buon cifrario) una 
stupidaggine :P (credo!!!)
Grazie per i link sottostanti .. andrò a studiare :P  e grazie ancora 
per il tempo che mi concedi ;)


 questo. ;)
Aspetta! Non vorrei aver letto male un dettaglio. lo XOR lo fai con
il bit precedente la sequenza, anche se fosse uno di quelli random
giusto? Quindi la chiave altro non e' che l' offset tra i bits da
considerare validi.
Non ho avuto il tempo di fare schemi quindi potrei dire ca**ate, pero'
mi figuro questo scenario, paragonabile a Known Plain Text:
L' attaccante si procura delle porzioni di testo in chiaro, (o le
ipotizza e non trascuriamo che esiste anche l' attacco Committed
Plain Text dove l' attaccante fa generare al sistema Crittogrammi
da dati forniti da lui) abbastanza grandi da contenere verosimilmente
la chiave che abitualmente gli utenti riescono a maneggiare con poco
costo (maneggiare grandi chiavi e' costoso).
Ora se ipotizza che la tua chiave possa essere minore di 1000 bits
di cui la meta' a 0 deve fare solo 250000 "dilatazioni" di bits e
corrispondente verifica se tale dilatazione porta a un testo
intelleggibile in qualche altro punto del flusso dati.
250000 perche' se 1000 bits di cui 500 a 1 ogni uno puo' essere scambiato
con ogni altro bit a 0 e per ogni sua posizione ogni altro bit a 1
puo' essere scambiato con i 500 bits a 0 per un totale di 500 x 500
posizioni.
Di solito ogni bit della chiave deve complicare il compito dell' attaccante
di una potenza di 2 (raddoppiarlo) e non di un passo. cosi' la lunghezza
della tua chiave da un costo quadratico al problema dell' attaccante e non
esponenziale.
Ipotizzo questo tipo di attacco, ma, come detto, potrei aver detto
qualche .... imprecisione visto che non ho fatto schemi, disegni,
calcoli e analisi meticolosa. Spero comunque che la faccia tu.
Presto lanceremo l' attacco al mio algoritmo.
Ciao.
Roberto.


 
Ciao
[CapoBecchino]

 [CapoBecchino]
ciao


 
Infatti ma rispondendo anche al tuo secondo punto, dovrebbe sapere anche 
del testo in chiaro e anche della sua posizione :D ma ci studierò su e 
ti farò sapere ;)
-- 
[CapoBecchino]