ATTENZIONE!!!! il presente help e' solo in bozza!
molte cose sono modificate rispetto alle cose previste inizialmente.
Help per il client irc coclide.asm.
;***********************************************************************************************
Intanto a maggior chiarimento delle Note Legali diciamo subito che l'uso di coclide e' vietato
per scopi non consentiti dalle leggi e in quei paesi dove per implicito o esplicito divieto
non sono consentite trasmissioni di messaggi cifrati.
;***********************************************************************************************
per compilare ed eseguire coclide, aprire una shell e:
compilare e linkare con nasm:
-----------------------------
nasm -f elf coclide-Kx.n.asm
ld -o coclide coclide-Kx.n.o
-----------------------------
avviare usando la sintassi completa (tutte le opzioni):
./coclide ZMZS [-s xxx.xxx.xxx.xxx(ircServer)] [-p Port] [-n Nickname] [-i Ident] [-r Realname] [-u User] [-d useriD] [+j]
oppure, avviare in modalita' ridotta:
./coclide ZMZS -n tuo_nick
;============================================================================================
La prima sensazione quando si ha a che fare con un qualcosa di nuovo, e' una sensazione di rigetto.
Nella migliore delle ipotesi e' una sensazione di fastidio per tutte le cose nuove che ci si
aspetta di trovare e per la fatica mentale che si dovra' affrontare per riuscire a capirci qualcosa.
Ebbene state su col morale.
NON E' NECESSARIO ARRIVARE NEMMENO ALLA DECIMA RIGA DI QUESTO HELP PER UTILIZZARE EFFICACEMENTE IL CODEC DI DEFAULT.
Basta infatti il comando:
/SCOD
per avviare una sessione CODEC con un nick|chan di default e il comando:
/UCOD
per disattivarla.
Non siamo ancora arrivati alla decima riga, quindi potete anche abbandonare il resto e andarvene a fare qualcos'altro.
.......... Ma...... non vi siete chiesti chi e' il destinatario di default?
Avrei potuto scriverlo qualche riga piu su, ma pazienza, ve lo dico ora:
il destinatario di default e' il canale #coclide che pero' si puo' cambiare col comando:
/MSG2 nick|#chan
Ora potete davvero abbandonare questo help e se siete abbastanza pratici di IRC potete scoprire
da soli le grandi potenzialita' di sicurezza che offre.
Ma.... per i piu pazienti ecco qui di seguito tutte le spiegazioni necessarie per un utilizzo
molto piu' efficace in termini di sicurezza di quanto non offrano le condizioni di default.
Cominciamo a vedere piu' da vicino cosa e' coclide.
Coclide e' un client irc completo, ma alquanto spartano, che pero' ha una prerogativa importante:
puo' inviare e ricevere messaggi criptati che soltanto altri client coclide che usano gli stessi codici possono decriptare.
Una volta attivato il CODEC tutto cio' che transita in rete e' inintellegibile e soltanto
un altro client gemello che abbia a sua volta attivato il codec e abbia usato le stesse kiavi
e la stessa sequenza e gli stessi codici PIN e' in grado di rendere intellegibile il messaggio.
Una volta connesso a irc si possono utilizzare tutti i comandi irc standard preceduti
dal carattere / proprio come se si trattasse di un client tipo Mirc, Xirc o Kvirc.
Ad esempio il comando:
/join #chan
Viene inviato al server in modo raw come comando irc scartando il carattere / (che quindi per irc
non ha alcun particolare significato) ma lo ha per il nostro client che lo interpretra come
carattere precedente un COMANDO da inviare al server o da eseguire anziche' come del semplice
testo da inviare al nick o al canale di default.
Il canale di default dove inviare tutti i messaggi e' #coclide che puo' essere joinato subito appena connessi se si usa l'opzione +j.
Volendo cambiare il destinatario dei messaggi di default per esempio in LARACROFT si digita il comando:
/MSG2 LARACROFT
e da questo momento in poi qualunque cosa digitiamo da tastiera viene inviato a LARACROFT anziche' al canale #coclide.
Cosicche' un messaggio del tipo:
Ciao come stai?
verra' inviato a LARACROFT come privmsg.
Se si vuole continuare a inviare messaggi a #coclide o a qualsiasi altro nick o canale basta dare il comando standard:
/PRIVMSG #coclide :ciao ragazzi come va?
Volendo ripristinare il canale #coclide come destinatario dei messaggi di default basta dare il comando:
/MSG2 #coclide
Il destinatario di default e' importante perche' SOLTANTO con esso viene intrattenuta una sessione
CODEC, tutti gli altri messaggi inviati utilizzando /PRIVMSG viaggeranno sempre in chiaro,
compreso un eventuale /PRIVIMSG al destinatario di default col quale stiamo parlando in modo CODEC.
Cosicche' se si avvia una sessione CODEC e si ha settato #coclide come destinatario di default,
qualunque messaggio digitato da tastiera senza essere preceduto dal carattere / viene prima
criptato e poi inviato al canale #coclide; ad esempio il messaggio:
Salve ragazzi, questo e' un messaggio criptato
Viene prima criptato e poi inviato al canale #coclide
Invece il messaggio
/PRIVMSG #coclide :Ecco questo e' un messaggio che viaggia in chiaro
Proprio come afferma il messaggio, sara' inviato in chiaro al canale #coclide.
;=================================================================================
PERCHE' FIDARSI DI COCLIDE?
1) Intanto e' Open Source.
Chiunque con una conoscenza anche minima di informatica puo' esplorarsi l'intero programma
e scoprire che non esiste null'altro di diverso di quanto esplicitato anche nei commenti all'interno dello stesso programma.
Il linguaggio utilizzato e' l'assembler, ma anche un programmatore appena discreto in C o C++
e' in grado di interpetrarne le funzioni chiave che per quanto in assembler sono funzioni dirette hanno molte cose in comune col C.
2) Gira solo su Linux (almeno per ora)
Nulla togliendo ai meriti di Microsoft e di Windows mi sia consentita la mia naturale diffidenza
verso un close system che potrebbe (anche se non lo fa) ma virtualmente POTREBBE:
INVIARE OVUNQUE IN GIRO PER IL MONDO A NOSTRA INSAPUTA TUTTE LE COSE CHE SI DIGITANO DA TASTIERA
Compresi i codici che abbiamo digitato e quindi: ADDIO SICUREZZA.
Ma poi.... se anche non lo fa di suo il sistema operativo Close System l'esperienza ci insegna
che esistono miriadi, eserciti di trojans che lo fanno allegramente da anni e in barba agli stessi firewalls.
Quindi se qualcuno vuole implementarsene o trasferirsene una versione su Close System
lo fa a suo rischio e pericolo e il sottoscritto non se ne assume alcuna responsabilita'.
3) Il programma coclide e' LIBERO, modificabile, personalizzabile, ecc. secondo i criteri della
GNU Public License e liberamente utilizzabile da chiunque ma solo per usi privati e non commerciali.
Per utilizzi diversi dagli usi privati contattare l'autore all'indirizzo:
vitogambi chiocchiola gmail punto com
4) Se le chiavi K11, K12 e K13 vanno attivate su richiesta e non vengono attivate di default
e' dovuto al fatto che sconvolgono radicalmente e in modalita' diverse persino la struttura
e le dimensioni dello stesso message packet. Si raccomanda di usarle con parsimonia e solo quando si diventa utenti esperti.
5) Tutte le chiavi sono modificabili dall'utente; (si raccomanda di non modificare quelle di default
scritte nel programma, ma utilizzando gli appositi comandi)
6) CPIN e CP01-13
Ci sono ben 14 codici PIN da 0 a 999999 che da soli basterebbero ad assicurare una sicurezza
spaventosamente alta. Un codice PIN generico e altri 13, uno per ogni chiave; questo significa
che persino la lunghezza delle chiavi e la loro forma sono modificabili dall'utente; oltre
naturalmente al NUMERO di codice generico che viene generato random da chi trasmette e criptato
e impacchettato con tutti i codici pin; solo la loro estrazione nella giusta sequenza consente
di ricostruire la lunghezza delle chiavi specifiche.
I CODICI PIN e il NUMERO RANDOM:
Le uniche 2 informazioni che viaggiano insieme al pacchetto ed in chiaro sono contenute
nei primi 6 bytes del messaggio e sono cosi strutturati:
-2 bytes : lunghezza del messaggio (che puo' essere al massimo fino a 512 bytes)
-4 bytes : Codice Random Integrato con i codici Pin (CRIP)
Il codice random integrato (CRI) viene generato nel seguente modo:
A) Quando si da invio al messaggio CODEC viene generato un numero casuale legato al tick counter
del PC, che diventa la base per le successive operazioni di CODIFICA e DECODIFICA.
B) Viene quindi effettuato uno XOR col CPIN GENERICO (da 0 a 999999) e quindi CRI diviene CRIP
e viene passato al primo CODEC della sequenza; Nel caso di sequenza di dafault viene mandato al CODEC K01.
C) Il codec K01 a sua volta effettua uno XOR di CRIP con il proprio CPIN_01, e il nuovo CRIP
ottenuto diventa quindi il puntatore alla chiave Numero_01 e la base per il successivo codec previsto nella sequenza.
D) La lunghezza della chiave 01 a sua volta viene calcolata nel seguente modo:
posti: LM = Lunghezza del Messaggio
NG = Somma Delle cifre del CPIN GENERICO
N1 = Somma delle cifre del CPIN 01
LK1 = Lunghezza chiave 01
avremo: LK1 = LM+NG+N1
E) Il nuovo CRIP viene quindi affidato alla chiave successiva che a sua volta lo modifica
effettuando uno XOR con il proprio codice PIN specifico e calcolandosi a sua volta il puntatore
e la lunghezza della propria chiave e cosi via fino all'ultima chiave di codifica.
F) L'ultimo CRIP viene scritto nei 4 bytes alla posizione 3-4-5-6 del messaggio.
G) Il coclide che riceve il messaggio effettua le operazioni inverse a partire dall'ultima chiave
della sequenza effettuando uno XOR con il proprio codice PIN e trovando cosi il puntatore
alla propria chiave e quindi passandolo al successivo decoder.
Quindi nessuno dei 14 codici PIN viaggia in rete, bensi un solo numero random che serve da base
per il calcolo dei puntatori alle chiavi e ha un senso solo per chi possiede i codici PIN ORIGINALI.
A pieno regime le possibilita' di sgamare i codici PIN sono dell'ordine di 1 su:
1.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000
cioe' un 1 seguito da 84 zeri, ovvero 10^84 (10 elevato alla 84esima potenza).
E siamo ancora all'inizio! Ci sono ancora le sequenza che possono essere modificate e.....
... le basi stesse delle chiavi che portano a numeri talmente grandi che e' quasi impossibile calcolarli e scriverli.
Ovviamente sia chi trasmette (scrive) che chi riceve devono avere gli stessi codici PIN (e la stessa sequenza delle chiavi).
I Codici PIN sono personalizzabili coi comandi:
/CPIN xxxxxx (cambia il codice PIN GENERICO in xxxxxx)
/CPNN yyyyyy (cambia il codice PIN NN in yyyyyy --- NN puo' essere da 01 fino a 13)
es.:
/CP03 123456 (cambia il codice PIN 03 in 123456)
-N.B.: I Codici PIN 00 e 10 coincidono, (sono la stessa cosa).
Per verificare i Codici PIN si da il comando:
/VPIN ;verifica tutti i codici PIN
;================================================================================
coclide utilizza 13 chiavi, delle quali 10 sono attivate di default mentre le kiavi 11, 12 e 13
si attivano singolarmente con comandi a parte:
Il numero presente nella versione di coclide individua fino a quale K(iave) e' stata implementata.
Ad esempio la versione coclide-K9.0.asm indica che e' stata implementata fino alla chiave N. 9.
La versione full con tutte le 13 chiavi sara' disponibile a breve.
(P.S.: sebbene non ancora implementate a pieno regime le altre chiavi possono essere comunque
gia' attivate e si possono utilizzare e personalizzare i relativi codici PIN.)
Le chiavi possono essere modificate singolarmente una alla volta col seguente comando:
/CODE Kxxxxxxxxxxxxx Nuova_chiave_immediata
oppure
/CODE Fxxxxxxxxxxxxx NomeFile.ext [-s Punto_di_inizio] [-e Punto_di_fine]
i valori delle x da 1 a 13 di K o di F xxxxxxxxxxxxx possono essere:
-void =i = invariato
-i =invariato
-d =default
-n =newcode
1° esempio:
/CODE Kiiin Questa e' una chiave valida
ha il seguente significato:
usa come 4^ key (n) la stringa "Questa e' una chiave valida"
2° esempio:
/CODE Fiiiin Divina_Commedia-Inferno.txt -s 1000 -e 31000
utilizzera' 30.000 caratteri dal file dell'Inferno della divina commedia come chiave N. 5,
a partire dal 1000esimo carattere fino al 31000esimo (compresi segni di punteggiatura e caratteri
speciali di formattazione, qualunque cosa -codificata da 0 a 255- e' valida e utilizzabile come dentello della chiave).
;===================================================================
Prima considerazione sulle chiavi da utilizzare:
Il programma COCLIDE usa degli algoritmi complessi per codificare un messaggio.
Anche utilizzando una sola delle 10 kiavi e' praticamente impossibile risalire al messaggio
originale se questa chiave e' tenuta segreta.
La chiave non deve essere inviata in nessun caso via internet e nemmeno utilizzando i normali
canali di trasmissione.
La condizione ideale (MASSIMA SICUREZZA) si ottiene se le chiavi sono conosciute da entrambi gli utenti A PRIORI.
La situazione ideale e' accordarsi di presenza sul numero di chiave e sul nome di un file
(per esempio di una foto o file .jpg che hanno entrambi nel proprio pc ) (chiamiamola ad esempio
foto_mare.jpg) e sui 2 numeri che rappresentano rispettivamente il numero X di caratteri (bytes)
da utilizzare come chiave e il numero a partire dal quale si devo estrarre gli X caratteri.
A questo punto entrambi digiteranno dai propri pc:
/CODE Fiiin foto_mare.jpg -s 800 -e 2000
Che utilizzera' come kiave4 1200 caratteri a partire dall'800° del file foto_mare.jpg.
E non pensate che 1200 chars siano inutili specie se vengono usati messaggi brevi tipo "ciao";
Ebbene, posto che i 1200 caratteri siano AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIII....ecc
se il messaggio e' "ciao", i 1200 caratteri serviranno a costruire una base chiave circolare dalla
quale verranno estratti gli N caratteri della chiave e questi serviranno a crittografare il
messaggio; per quanto breve il messaggio possa essere la lunghezza della chiave e' sempre
abbastanza grande da utilizzare un numero N che viene calcolato nel seguente modo:
N= lunghezza_messaggio +
Somma_CIFRE_CODICE_PIN_GENERICO +
Somma_CIFRE_CODICE_PIN_SPECIFICO_DELLA_CHIAVE
per cifre si intendono le 3 coppie di bytes che racchiudono i Codici PIN e siccome per i numeri
grandi fino a 999.999 possono essere al massimo:
12
255
255
ogni codice PIN avra una somma delle cifre al massimo di 522
di conseguenza la lunghezza chiave puo' essere al massimo di:
256 ; lunghezza max messaggio
522 ; CPIN GENERICO
522 ; CPIN specifico Della chiave
---------
1.300 ; LUNGHEZZA MAX della chiave
Ma la chiave varia in modo random il proprio punto di inizio che puo' essere compreso
tra 0 e 999999, e questa variazione si ha a ogni messaggio.
La funzione che genera il numero random come abbiamo detto e' una funzione legata al tick
di sistema che viene triggerato nell'istante esatto in cui si preme il tasto invio.
Di conseguenza, se il messaggio e' lungo 4 caratteri e la chiave e' lunga 4xN caratteri, la chiave
sara' passata "sopra" il messaggio N volte fino ad esaurimento della lunghezza della chiave.
Ad esempio, posta la chiave AAAABBBBCCCCDDDDEEEEFFFFGGGGHH e il messaggio "ciao" avremo:
al primo passaggio vengono usati i caratteri AAAA; al secondo passaggio vengono usati
i caratteri BBBB e cosi via; ma vediamolo con un esempio:
1° passaggio: ciao -----> vengono usati come kiave i char AAAA
2° passaggio: (su ciao modificato) -----> vengono usati i successivi chars BBBB
... e cosi via fino a LUNGHEZZA_CHIAVE.
se la frase e' "ciao come stai?" avremo, (posto che l'inizio chiave sia sempre a 1):
1° passaggio: ciao come stai? -----> vengono usati come kiave4 i char AAAABBBBCCCCDDD
2° passo: (su "ciao come stai?" modificato) -----> vengono usati i successivi chars DEEEEFFFFGGGGHH
fino a LUNGHEZZA_CHIAVE
e cosi via...
capito il meccanismo?
;--------------------------------
Caso limite sulla sicurezza:
Poniamo che esistono 2 sole copie del file foto_mare.jpg, una nel nostro pc e l'altra
nel pc del nostro amico col quale abbiamo intrattenuto la sessione CODEC; ebbene se alla fine della
sessione si distruggeranno le 2 copie dei file foto_mare.jpg, anche ammesso che qualcuno abbia
sniffato e registrato l'intera conversazione... ebbene, se si e' usato un numero abbastanza grande
di bytes come kiave allora possiamo affermare che e' PRATICAMENTE IMPOSSIBILE risalire
alla conversazone originale.
Mi rendo conto che qualcuno arriccera' il naso alla affermazione di Praticamente IMPOSSIBILE,
ebbene si, lo confermo! Poste quelle premesse (ovvero distruggere le uniche copie del file
usato come chiave) sfido chiunque a dimostrare il contrario, ovvero a dimostrare l'esistenza
di una possibilita' anche remota di risalire alla conversazione originale.
Anche ammesso che si provino un numero grandissimo di chiavi, si otterra' tutto e il contrario
di tutto e una miriade di soluzioni NON UNIVOCHE!.
(Naturalmente per "cancellare un file" intendo usare un bel wipe del tipo... riempire di zeri
lo spazio precedentemente occupato nell'hd dal file.).
;------------------------------------------
Vediamo ora come operano le chiavi prese singolarmente:
cominciamo dalla chiave 1 e facciamo un caso semplice:
immaginiamo che la kiave1 sia la parola "culla" e che il messaggio sia:
ciao come va la tua vita?
la prima operazione che viene effettuata sara' quella di permutare la prima lettera con la seconda,
la terza con la quarta e cosi via... in caso di lettere uguali si usa la prima diversa presente
nella successione; quindi usando la 1^ chiave "culla" avremo:
uilo uome vl al tcl vitl
nel caso di ripetizione di lettere si fanno permutazioni successive, ad esempio
usando la parola "collana" come kiave1 avremo prima la a permutata con la l e successivamente
la a si permuta con la n, quindi si avra':
1* passaggio:
oilc ocme vl al tul vitl
2° passaggio e frase finale:
oilc ocme vl nl tul vitl
come si vede son sparite le a.
L'operazione inversa si effettuera' a partire dalla fine, prima permutando le n con le a e poi
permutando le a con le l e quindi le c con le o.
;---------------------------------------------------
la kiave2 e' uno XOR con corrispondenza 1:1 sul messaggio;
k2 viene "granularizzata" tante volte quanto basta fino a coprire N volte l'intera lunghezza
del messaggio, tranne l'ultimo spezzone della chiave che si applica solo alla prima parte
del messaggio aumentandone ancor piu la complessita'.
Per esempio posto che il messaggio sia:
ciao
e la chiave sia ABCDEFGHIL
si effettueranno i seguenti passaggi
ciao xor ABCD = XXXX
XXXX xor EFGH = YYYY
YYYY xor IL = ZZYY
risultato finale sara' dunque ZZYY.
La chiave2 viene eseguita DOPO la chiave3; di conseguenza la sequenza di esecuzione sara':
in fase di codifica: K1, K3, (K12), K2, K4, K5, K6, K7, K8, K9, K10, (K11), (K13)
e in fase di decodifica: (K13), (K11), K10, K9, K8, K7, K6, K5, K4, K2, (K12), K3, K1
;----------------------------------------------------
La terza chiave usa un meccanismo quasi analogo alla chiave 1 ma questa volta facendo riferimento
al numero presente nei bytes di riferimento; numero che viene di volta in volta normalizzato alla
lunghezza del messaggio in modo da essere certi che le permutazioni avvengano sempre all'interno
del messaggio; andiamo con un esempio:
immaginiamo un messaggio tipo ABCDEF quindi lungo 6 caratteri e
poniamo che i numeri presenti nella chiave 3 siano i seguenti:
1,4,8,3,2,5
si comincia a permutare, e ABCDEF diventa:
1.4 DBCAEF
quindi si passa al successivo
4.8, ma come si vede 8 e' maggiore di 6 (lunghezza messaggio) quindi viene prima normalizzato
(8-6 = 2)
e quindi avremo la nuova coppia:
4.2 DACBEF
quindi al successivo
8.3 che normalizzato diventa 2.3
2.3 DCABEF
ancora 3.2 che lo rimette come alla precedente
3.2 DACBEF
e infine
2.5 DECBAF che e' il messaggio finale
;--------------------------------------------
Come chiave4 viene effettuato un doppio taglio con doppia inversione sui bit dei bytes individuati
dai bit di kiave4 se il bit corrispondente e' 1 altrimenti una rotazione a destra di tutti
e 8 i bit, esempio:
kiave4 (bit) 0100 0010
0 1 0 0 0 0 1 0
frase ???????? = (bit) abcdwxyz abcdwxyz abcdwxyz abcdwxyz abcdwxyz abcdwxyz abcdwxyz abcdwxyz
dopo kiave4 sara': zabcdwxy badcxwzy zabcdwxy zabcdwxy zabcdwxy zabcdwxy badcxwzy zabcdwxy
il tutto naturalmente ripetuto sempre N volte fino a esaurimento della lunghezza della chiave 4
;--------------------------------------------
K5 ADD immediato o da File
E' una semplice operazione di add su byte prendendo il byte da aggiungere al byte del messaggio
dalla posizione a cui punta la chiave e ripetendo l'operazione N volte sul messaggio fino
a esaurimento della lunghezza chiave. Ricordarsi che per effetto della formula:
L_chiave = L_messaggio + som_PIN_cod_XX + som_PIN_cod_generico la lunghezza chiave e' sempre
maggiore o almeno uguale alla lunghezza del messaggio.
L'operazione inversa di decodifica sara' un SUB, ed e' inutile ricordare che grazie all'intervento
del flag di carry se si superano i limiti del byte durante la somma viene settato il flag carry
di riporto; la stessa cosa avviene se si sottrae a un numero piu piccolo un numero piu grande,
di conseguenza viene garantito il ripristino esatto del numero originario.
;----------------------------------------------
K6 ROR complesso.
La Kiave 6 opera delle rotazioni complesse in base al numero presente nel byte di riferimento
della chiave e opera nel modo seguente:
siano:
N1 = il numero nel 1° byte della chiave
N2 = il numero nel 2° byte della chiave
N3 = il numero nel 3° byte della chiave
posti:
al = 1° byte del messaggio
ax = 1° e 2° bytes del messaggio
eax = primi 4 bytes del messaggio
si effettuano:
al ROR N1 ;su al N1 rotazioni a destra dei bits
ax ROR N2 ;su ax N2 rotazioni a destra dei bits (compresi anche gli 8 bit precedenti)
eax ROR N3 ;su eax N3 rotazioni a destra dei bits (compresi anche i 16 bits precedenti)
e si continua cosi fino a esaurimento della lunghezza chiave, nel caso di superamento della
lunghezza del messaggio, il tutto ricomincia dall'inizio del messaggio, gia parzialmente criptato.
Alla fine di kiave 6 sara' avvenuto un mescolamento dei bit sull'intero messaggio, o meglio su cio'
che del mesaggio avevano fatto le precedenti chiavi.
;----------------------------------------------------
K7, K8, e K9
indipendenti eppur connesse:
Proprio cosi: pur essendo indipendenti le tre chiavi sono interconnesse e sono state pensate
soprattutto per aumentare la complessita' dei files utilizzabili come chiavi di base.
Il loro funzionamento e' molto semplice, pur seguendo gli stessi criteri di complessita
delle altre chiavi.
Posta che la sequenza si lasci invariata il funzionamento e' il seguente:
il byte di K7 viene XORato col byte di K8 e il risultato con quello di K9 e il risultato finale
viene XORato col corrispondente byte del messaggio.
Perche' 3 XOR anziche' solo uno?
La risposta e' semplice
3 XOR, anche se alla fine dentro il byte puo' esserci solo un numero compreso tra 0 e 255
significano portare quel byte a una complessita' di gran lunga maggiore delle 256 combinazioni
possibili.
Infatti anche se "apparentemente" dentro il singolo byte del messaggio possono viaggiare "soltanto"
256 combinazioni, in realta' la complessita' che trasportano intimamente e' dell'ordine di miliardi
e miliardi di combinazioni possibili.
Immaginiamo di voler inviare un singolo byte:
solo in questo caso la complessita' e' di 256 combinazioni.
Ma se i byte da inviare diventano 2 anche non necessariamente nello stesso pacchetto
allora la complessita' e' 65.536.
E con 3 caratteri? Sale vertiginosamente a 16.777.216
Con 4 caratteri sale ancora a 4.294.967.296
Con 10 caratteri siamo gia circa a 1.210.000.000.000.000.000.000.000
e con 20 andiamo a 1.460.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000
e cosi via esponenzialmente e vertiginosamente.
Avete idea di che numero sia quello appena scritto?
1,46*10^48
Un numero piu' grande persino del numero di protoni presenti nel nostro universo
(se la memoria non mi fa brutti scherzi dovrebbe aggirarsi intorno a 10^31.)
Coclide e' proprio questo: un costruttore di complessita'.
Ma vediamo come opera il programma:
Una volta avviato il comando /SCOD qualunque messaggio venga scritto, prima di essere inviato
in rete subira' il seguente trattamento:
1) Il messaggio verra' manipolato da tutte le chiavi attive secondo la sequenza specifica della
sessione e alla fine verra' consegnato all'ultima fase di controllo prima di essere incapsulato
dentro uno stack TCP/IP
2) La fase di controllo procede alla verifica della presenza di caratteri non consentiti dal server
irc ( o che per questo hanno un significato particolare come i caratteri 0, 0xA e 0xD) e in caso
affermativo vengono ricodificati con una sequenza "standard" utilizzando una sequenza di caratteri
fissi (6 bytes per ognuno di quei codici); le probabilita' di conflitti col contenuto del
messaggio vero e proprio sono dell'ordine di 1 su 281.474.976.710.656, abbondantemente al di sotto
delle probabilita' che un packet vada perduto o vada in collisione nella rete.
3) durante la sessione e' possibile cambiare kiavi on the fly (al volo) mettendosi d'accordo
o scambiandosela attraverso la stessa conversazione o usando dei sillogismi del tipo:
"usiamo il film girato questa estate alla balera 2000,3000,8"
e quindi entrambi digiteranno
/CODE Fiiiiiiin Io_tu_e_paperino_in_balera.mov -s 2000 -e 3000
attivando cosi una nuova sessione con la sola kiave8 cambiata rispetto alla sessione precedente
che utilizzera' come Kiave8 1000 bytes del filmato "Io_tu_e_paperino_in_balera.mov"
a partire dalla posizione 2000.
La possibilita' di cambiare KIAVI al volo e' uno strumento potentissimo che rende ancor piu'
sicura la conversazione coclide potendosi usare dei riferimenti complessi per individuare
la nuova chiave ad esempio:
"usa K6 l'ultima riga (in genere di copyright) del calendario appeso alla parete di fronte a te".
4) La sequenza delle chiavi e' personalizzabile col comando:
/CSEQ XX YY
dove XX e YY sono i numeri di kiave di cui si vuole scambiare la sequenza
es1: /CSEQ 03 04 scambia fra loro la sequenza delle chiavi 3 e 4.
es2: /CSEQ 01 12 scambia fra loro la sequenza delle chiavi 1 e 12.
N.B.: le chiavi 7,8 e 9 operando in sincronia fra loro e' meglio non scambiarle con chiavi fuori
dal gruppo [7-8-9] (e viceversa).
Se lo fate...... cavoli vostri..... (ricordatevi che e' possibile farlo.... ma ragionateci sopra
su COME farlo, altrimenti non riuscirete piu a dialogare. Spiacente ma non vi do nessun altra
spiegazione... eheheheh. Rifletteteci su e chi trova la soluzione subito e' bravo).
5) Chi riceve il messaggio effettua le operazioni inverse e dopo gli innumerevoli passaggi il
messaggio originario, finalmente reso intellegibile, viene messo su un buffer e visualizzato sullo
schermo.
Venendo meno anche uno solo dei passaggi di crittografatura o se non viene usata la sequenza
corretta, cio' che apparira' sullo schermo sara' una serie di caratteri incomprensibili, (stavolta
compresa la presenza di eventuali zeri (codice 0) o 0xA (New Line) e 0xD (Carriage Return) ) in
quanto non viene effettuato alcun controllo (deliberatamente) su cio che viene inviato allo schermo.
:------------------------------------------
La kiave10 usa i bit della key per traslare a gruppi di 8 i byte
del messaggio originale verso l'inizio e per effettuare una ror di 2 bit se presente 1; esempio:
kiave10 (bit) 0010 0100 : 00 1 00 1 00
messaggio: AB (12345678) DE (12345678) GH
usando kiave10 il messaggio diventa: HG (78123456) ED (78123456) BA
il tutto ripetuto sui tutti i successivi gruppi di 8 bytes di messaggio.
:------------------------------------------
La chiave 11 verra' usata per individuare le coordinate dell'insieme di Mandelbroot su cui
calcolarne la velocita' di fuga verso l'infinito (velocita' parametrizzata da 0 a 255).
La velocita' di quel punto sara' presa come 2° operando dello XOR effettuato sul byte corrispondente del messaggio.
I bytes della chiave 11 saranno presi a gruppi di 4 per volta e poi al coprocessore sara' fatto
calcolare il reciproco (1/N) in modo da avere le coordinate dell'insieme di Mandelbrot
all'interno dell'intervallo (0,+1); (ovvero all'interno del primo quadrante).
;=========================================================================================
comandi accettati:
/ : / seguito da tutti i comandi irc verranno inviati in modo raw al server.
; / seguito da uno dei seguenti comandi coclide eseguira' il comando specificato:
/AK00 ... /AK13 = Attiva chiavi da 00 a 13. (Le chiavi da 1 a 10 sono gia' attive per default)
( K00 e K10 coincidono )
-------------------------------------------------------------------------------------
/CODE Kxxxxxxxxxxxxx [chiave immediata digitata al volo]
/CODE Fxxxxxxxxxxxxx nomefile [-s XXXXXX] [-e YYYYYY]
dove x individua la posizione del numero di chiave che puo' essere:
void = i = invariata
d = default
n = nuova key
dove K = K(ch)iave immediata
F = chiave da file, -s = start_point -e = end_point
XXXXXX e YYYYYY numeri di start file e end file.
-------------------------------------------------------------------------------------
/CPIN xxxxxx = Cambia il codice PIN generico (da 0 a 999999)
/CP00 ... /CP13 xxxxxx = Cambia i codici PIN delle singole chiavi (da 0 a 999999)
/CSEQ XX YY = Scambia la sequenza di codifica della chiave XX con la chiave YY
( /CSEQ e' sinonimo di /SEQK )
/DSEQ = Ripristina la sequenza delle chiavi di default 1 3 12 2 4 5 6 7 8 9 10 11 13
( /DSEQ e' sinonimo di /RSEQ )
/DK00 ... /DK13 = Disattiva chiavi da 00 a 13.
( Le chiavi 11, 12 e 13 sono disattivate per default)
/EMSG ON | [OF] = Messaggi in formato Esteso ON oppure OFF
/HELP = Esegue un breve Help.
( il comando /help (minuscolo) esegue l'help del server )
/MSG2 nick|chan = Cambia destinazione di default dei messaggi
/RPIN = Reset PIN code, resetta tutti i PIN CODE rimettendo i valori di default
/RSEQ = Ripristina la SEQuenza delle chiavi di default 1 3 12 2 4 5 6 7 8 9 10 11 13
( /RSEQ e' sinonimo di /DSEQ )
/RSTK = Esegue un ReSeT di tutte le (K)chiavi rimettendo le chiavi di default
/SCOD = Set CODe mode: Inizia una sessione CODEC
/SEQK XX YY = Scambia la sequenza di codifica della chiave XX con la chiave YY
( /SEQK e' sinonimo di /CSEQ )
/UCOD = Unset CODe mode: Termina sessione CODEC
/VERS = Versione N... del... e breve messsaggio di Copyright
/VK00 ... /VK13 = Verifica le (K)chiavi da 1 a 13 (la K00 e la K10 coincidono)
/VPIN = Verifica tutti i codici PIN
/VSEQ = Verifica la SEQuenza delle chiavi e quali chiavi sono attive
;====================================================================================
;BOZZE di APPUNTI
;-------------------------------------------------
;=====================================================================================
QUELLE CHE SEGUONO SONO:
SOLO BOZZE DI APPUNTI!!!!!!!!!!!!!!!!!!!!!!!!!!
;=====================================================================================
BOZZE DI APPUNTI!!!!!!!!!!!!!!!!!!!!!!!!!!
;=====================================================================================
BOZZE DI APPUNTI!!!!!!!!!!!!!!!!!!!!!!!!!!
;=====================================================================================
BOZZE DI APPUNTI!!!!!!!!!!!!!!!!!!!!!!!!!!
;=====================================================================================
WIPE : WIPE Nomefile Azzera (scrivendo una sequenza di 1111111111 un singolo file)
QUINDI CANCELLA IL FILE
WIPEALLS Come Wipe, su tutti i files utilizzati dalla sessione attuale CODEC
ALRM : ALRM Invia un allarme a tutti ed esegue operazioni di pulizia:
:-RINOMINA I FILES UTILIZZATI
;-esegue un WIPEALLS
BOZZE DI APPUNTI!!!!!!!!!!!!!!!!!!!!!!!!!!
;=====================================================================================
La XXXXesima kiave usa un algoritmo di permutazione leggermente diverso dalla kiave1
vediamone il funzionamento:
immaginiamo di avere come kiaveX la frase "nel mezzo del cammin"
ebbene: diamo un valore di "posizione" ad ogni lettera secondo la seguente codifica:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
a b c d e f g h i j k l m n o p q r s t u v w x y z
posta la kiaveX = "nel mezzo del cammin"
ovvero sara' chiave:
n e l m e z z o d e l c a m m i n
14 5 12 13 5 26 26 15 4 5 12 3 1 13 13 9 14
e avendo la frase originale:
ciao come stai? cambiamo key?
riscrivendola avremo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
c i a o c o m e s t a i ? c a m b i a m o k e y ?
quindi cominciamo a spostare gli n-esimi caratteri alla prima posizione.
14 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
i c i a o c o m e s t a ? c a m b i a m o k e y ?
quindi si rinumera in:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
i c i a o c o m e s t a ? c a m b i a m o k e y ?
5 1 2 3 4 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
o i c i a c o m e s t a ? c a m b i a m o k e y ?
quindi si rinumera in:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
o i c i a c o m e s t a ? c a m b i a m o k e y ?
12 1 2 3 4 5 6 7 8 9 10 11 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
s o i c i a c o m e t a ? c a m b i a m o k e y ?
quindi si rinumera in:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
s o i c i a c o m e t a ? c a m b i a m o k e y ?
13 1 2 3 4 5 6 7 8 9 10 11 12 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
t s o i c i a c o m e a ? c a m b i a m o k e y ?
quindi si rinumera in:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
t s o i c i a c o m e a ? c a m b i a m o k e y ?
5 1 2 3 4 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
c t s o i i a c o m e a ? c a m b i a m o k e y ?
quindi si rinumera in:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
c t s o i i a c o m e a ? c a m b i a m o k e y ?
26 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 27 28 29
k c t s o i i a c o m e a ? c a m b i a m o e y ?
quindi si rinumera in:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
k c t s o i i a c o m e a ? c a m b i a m o e y ?
26 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 27 28 29
k c t s o i i a c o m e a ? c a m b i a m o e y ?
quindi si rinumera in:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
k c t s o i i a c o m e a ? c a m b i a m o e y ?
15 1 2 3 4 5 6 7 8 9 10 11 12 13 14 16 17 18 19 20 21 22 23 24 25 26 27 28 29
k c t s o i i a c o m e a ? c a m b i a m o e y ?
e cosi via finche' si esaurisce l'intera sequenza della kiave3. Se il messaggio e' piu lungo
della lunghezza della kiave3 si continua ricominciando dall'inizio di kiave3.
Si nota infatti che le posizioni 27, 28 e 29 (ey?) non sarebbero modificate, invece esauriti
i primi 26 caratteri si passa ai successivi 26.
In fase di decodec si opera inversamente; si vede quanto e' lunga la frase e si cominciano a
riposizionare partendo dalla prima posizione gli n.esimi caratteri dell'm.esimo blocco.
le kiavi 11,7 e 9 operano nel seguente modo:
;------------------------------------------
kiave11 = rotazione x volte delle 4,8,16,32,64,128,256,512 lettere; esempio
sia sempre la frase originale:
ciao come stai? cambiamo key?
e sia la kiave5 ABCDEFGHIL
ciao --> sara' ruotato ASC(A) volte e lo stesso
com --> sara' ruotato ASC(A) volte
e st --> sara' ruotato ASC(A) volte
ai? --> sara' ruotato ASC(A) volte
camb --> sara' ruotato ASC(A) volte
iamo --> sara' ruotato ASC(A) volte
key --> sara' ruotato ASC(A) volte
? --> nessuna rotazione in quanto carattere singolo
quindi si avra (8);
ciao com --> sara' ruotato ASC(B) volte
e stai? --> sara' ruotato ASC(B) volte
cambiamo --> sara' ruotato ASC(B) volte
key? --> sara' ruotato ASC(B) volte
quindi ancora (16)
ciao come stai? --> sara' ruotato ASC(C) volte
cambiamo key? --> sara' ruotato ASC(C) volte
e ancora (32)
ciao come stai? cambiamo key? --> sara' ruotato ASC(D) volte
e cosi via; se la frase e' finita si prosegue di nuovo a partire da 4, 8, 16, 32 ecc fino
a esaurimento del codice.
Naturalmente nell'esempio sopra viene lasciata sempre la stessa frase originaria,
in realta gia al primo passaggio "ciao" potrebbe diventare ocia oppure aoci o iaoc o restare ciao.
;------------------------------------------
kiaveN = e' un numero intero (max 240 pari a 480char/2) e indica quanti tagli con inversioni effettuare sulla frase.
Ovviamente dipende dalla lunghezza della frase, in caso di (kiave7 > lungh_frase/2) sara'
usato lungh_frase/2.
esempio: ciao come stai? cambiamo key? --> lungh frase = 29 quindi sono consentiti max 14
tagli con inversione; poniamo kiave7 = 3 avremo
(5-5) (5-5) (5-4) inversioni
di conseguenza la frase diventera'
" emoc oaic" "bmac ?iats" "?yek omai"
che levando le virgolette " che abbiamo messo per maggior chiarezza, la frase sara':
" emoc oaicbmac ?iats?yek omai"
;------------------------------------------
;-------------------------------------------
Le kiaveP, Q e K operano in blocco e nel seguente modo:
Kiave6+Kiave8 (max 510) individua il Byte su Kiave0 da utilizzare come XOR
Kiave0 deve quindi essere "esteso" fino a 1000000, duplicandolo tante volte quanto basta fino
a raggiungere la lunghezza di 1000000 bytes
ma andiamo con un esempio:
sia kiave6 18 112 32 49 110
e sia kiave8 1 3 19
avremo:
| da qui in poi la sequenza di kiave6 ricomincia
Kiave6 (val ascii) 18 112 32 49 110 | 18 112 32 49 110 | 18 112 32 49 110 | 18 112 32 49 110
Kiave8 (val ascii) 1 3 19 | 1 3 19 | 1 3 19 | 1 3 19 | 1 3 19 | 1 3 19
| da qui in poi la sequenza di kiave8 ricomincia
i bytes da prendere da Kiave0 per fare lo XOR con "messaggio" sono dunque quelli alla posizione:
18+1 = 19
112+3 = 115
32+19 = 51
49+1 = 50
110+3 = 113
18+19 = 37
112+1 = 113
32+3 = 35
49+19 = 68
110+1 = 111
ecc ecc. fino a esaurire la lunghezza del messaggio.
;------------------------------------------
Esauriti Tutti i passaggi di codifica il messaggio viene consegnato AS-IS cosi com'e' nel buffer
buffer2send che e' strutturato cosi:
msg2send db "PRIVMSG "
nick2send db " :"
buffer2send times 480 db 0
fine_buff2send db 0xA,0xD
Come si vede quindi soltanto la parte esterna dell'incapsulamento e' in chiaro,
(PRIVMSG nick :) ........... e la chiusura 0xA e 0xD; queste ultime servono solo nel caso
di comunicazioni in chiaro; infatti nel caso di sessione CODEC tutti i caratteri
vengono manipolati dalle nostre routines ed esattamente fino a un max di 480 chars
dopo "PRIVMSG nick :"
Prima di essere inviato alla sock il messaggio ha ancora bisogno di essere trattato per eliminare
la presenza dei caratteri speciali (0, 0xA e 0xD) che il server interpetrerebbe in modo sbagliato
e di conseguenza viene inviato a una routine di sistemazione che sostituisce questi eventuali caratteri in:
0/A/D --> 0x3E,41,0xD3,0x98,14,1 (1/11/14) ;1 puo essere; 1= 0 ; 11 = A ; 14 = D
;---------------
;=======================================================
Eventuale K12
col comando
ZMZS AK12 oppure AF12 (da file)
(per disattivare)
ZMZS DK12 oppure DF12 (da file)
si attiva la 12^ chiave che si puo' rappresentare come K825
ovvero per i messaggi di solo testo sara' effettuata una traslazione da 8 bit a 5 bit.
Visto che 5 bit possono rappresentare fino a 2^5 = 32 caratteri si assumono:
A=0
B=1
....
Z=25
,=26
.=27
?=28
!=29
-=30
sp=31
,.?BA?.,= 10
,.?A?.,= 0
Caratteri estesi:
,.?K?., = (
,.?L?., = )
,.?M?., = [
,.?N?., = ]
,.?O?., = {
,.?P?., = }
,.?Q?., = _
,.?R?., = +
,.?S?., = *
,.?T?., = ^
,.?U?., = /
,.?V?., = %
,.?W?., = @
,.?X?., = &
,.?Y?., = $
,.?Z?., = ;
i 3 bit rimanenti saranno utilizzati per il prossimo byte e cosi via secondo il seguente schema:
dato il messaggio a 8 bytes ABCDEFGH, questo sara' compresso su soli 5 bytes secondo il seg.te schema
| A | B | C | D | E | F | G | H |
[12345] [678 12] [34567] [8 1234] [5678 1] [23456] [78 123] [45678]
A B C D D F G G
ecco perche' e' chiamata anche K825 ( Kiave 8 t(w)o 5)
;==========================================================
;Kiave13
I primi 2 bit di ogni byte della chiave individuano il numero di byte interessati a una operazione
di ROR o ROL, gli altri 5 bit identificano il numero di rotazioni sui bit da effettuare, l'ultimo bit se ROR o ROL
Es. /CODE Fiin File.ext [-s 3000] [-e 5000] dal quale vengono estratti come terza key
2000 caratteri a partire dalla posizione 3000 fino alla pos. 5000 del file File.ex
-in caso di omissione di -s si intendera' per default inizio file
-in caso di omissione di -e si intendera' per default la fine del file
-in caso di omissione di entrambi si considerera' l'intero file a partire dal primo bytes fino a un massimo di 1000000 di bytes.
;===========================================================
;--------------------
suggerimenti
per futuri ampliamenti
1) numero casuale al posto di puntatore calcolato
1.1) tale numero sara' un puntatore a una struttura all'interno di ogni chiave che punta a se stessa con i seguenti signoficati:
1 primi 4 bytes puntatore i successivi 2 bytes lunghezza chiave (max 65535) a cui si aggiuungera' il pin e la lunghezza del messaggio.
2) Per le chiavi da estrarre da file: prevedere ulteriori 2 numeri che individuano i numeri di
bit da 0 a + 8 da cui iniziare la sequenza e un secondo numero che identifica di quanti bit
deve essere il gap per COSTRUIRE il successivo byte
Ipotesi di comando:
/CODE Fiiin nomefile.txt [-s aaaa] [-e bbbb] [-b cccc] [-g dddd]
==================================================================
Numero Casuale: Viene generato al momento della codifica del messaggio;
questo numero casuale E' il puntatore all'inizio delle chiavi;
Il punto di attacco delle chiavi.
Al numero casuale viene effettuato uno XOR col codice PIN, e inviato
nel corpo del messaggio, dopo i primi 2 bytes iniziali.
Il PIN_CODE deve essere conosciuto da entrambi gli users a priori.
E' un numero scelto da loro (compreso tra 0 a 1.000.000) e interviene nel seguente modo:
la somma delle 3 coppie delle loro cifre (da 00h a 0FFh) a cui viene sommata la lunghezza
del messaggio attuale, individua la LUNGHEZZA della CHIAVE.
In fase di ricezione del messaggio col codice PIN deve essere effettuato uno XOR al numero
casuale che e' pervenuto nel corpo del messaggio, il risultato di questa operazione individua l'INIZIO della chiave.
;====================================================================
Insieme di Mandelbrot come chiave xxxxxxxxxxxx
a coppie di 6(?) + 6(?) bytes vengono individuati 2 numeri che sono la parte decimale delle
coordinate dell'insieme di mandelbrot dove andare a esplorare la velocita' di fuga da 0 a 255 di quel punto.
(La parte intera (0,1,2 sara' determinato dagli ultimi 2 bit di ogni sestetto
Quel numero sara' la chiave per fare lo XOR con messaggio.
(USARE algoritmo superveloce inventato da noi nel 1994 a 17 istruzuzioni macch. al coprocessore).
;====================================================================
il KVIRC usa in invio max 400 caratteri, eccoli:
;=======================================
stringhe da collaudo:
a
1
aa
11
ab
111
123
abc
abcd
abcde
abcdabcd
abcdabcde
12345678
123456789
123456789012
1234567890123456
12345678901234567
123456789012345678901234
12345678901234567890123456