[Sify] AlOne. Nuovo codice crittografico simmetrico.
mi dareste un parere è il mio primo approccio ad un codice crittografico
http://www.albericolepore.org/alone-nuo ... immetrico/
http://www.albericolepore.org/alone-nuo ... immetrico/
Risposte
Nella seconda riga scrivi
"Alberico Lepore":ma se i numeri sono almeno 3 allora almeno uno di loro sarà divisibile per 3. La non divisibilità per 2 è invece una condizione inutile perché già espressa dal termine ‘dispari’.
La chiave è composta dalla moltiplicazione di n numeri dispari consecutivi non multipli di 2 e di 3 .
ciao vict
non ho capito
Si non ho spiegato bene: n deve essere dispari
ma se i numeri sono almeno 3 allora almeno uno di loro sarà divisibile per 3.
non ho capito
La non divisibilità per 2 è invece una condizione inutile perché già espressa dal termine ‘dispari’.
Si non ho spiegato bene: n deve essere dispari
Per prima cosa il metodo non è molto ben formalizzato. Per cui andiamo per gradi. Chiamo \([K, S]\) la tua chiave. Supponiamo quindi di avere il simbolo \( Y = 8 \) come nel tuo esempio.
Per prima cosa calcoli \( T = 17\,S + Y.\) Come viene scelto il numero \(17\)? E' a discrezione del codice che genera la sequenza da inviare? Rimane costante o viene fatto variare per ogni simbolo che viene inviato?
A questo punto scrivi l'equazione \( x^2 + 6\,T\,x = K \) e invii il numero intero \( X = \left \lfloor{x}\right \rfloor . \) E' corretto? Da come hai definito l'operazione sembrava infatti facessi semplicemente un troncamento o fai qualcosa di diverso come un arrotondamento?
Da parte del ricevitore hai il tuo valore \(X\) che utilizzi per calcolarti \(t\) da \( X^2 + 6\,t\,X = K. \) Questo valore non sarà tuttavia intero per cui di nuovo prendi \( T = \left \lfloor{t}\right \rfloor . \) Da cui quindi hai che \( Y = T \pmod S . \) Anche qui non so se stai effettivamente facendo un troncamento o un arrotondamento o altro.
Così a prima vista non sono sicuro funzioni. Che si tratti cioè di un processo effettivamente invertibile e che non ci possano essere dei problemi per alcuni valori. Riguardo alla sua sicurezza sono ugualmente scettico. Se infatti il valore \(17\) fosse costante, avresti in pratica un sistema lineare in \(S,\) \(Y_i\) e \(K.\) Considerando inoltre che \(S\) non è poi spesso davvero una incognita, potresti probabilmente calcolare tutto in \( \pmod S \) e togliere anche il problema del valore costante e casuale. Non ho comunque fatto una analisi approfondita e questi sono più che altro impressioni. Non credo comunque che abbia poi tanta importanza il metodo scelto per calcolare \( K. \) Anzi, usare una chiave generata con un metodo così rigido può forse aggiungere un ulteriore limite alla sicurezza del metodo.
Per prima cosa calcoli \( T = 17\,S + Y.\) Come viene scelto il numero \(17\)? E' a discrezione del codice che genera la sequenza da inviare? Rimane costante o viene fatto variare per ogni simbolo che viene inviato?
A questo punto scrivi l'equazione \( x^2 + 6\,T\,x = K \) e invii il numero intero \( X = \left \lfloor{x}\right \rfloor . \) E' corretto? Da come hai definito l'operazione sembrava infatti facessi semplicemente un troncamento o fai qualcosa di diverso come un arrotondamento?
Da parte del ricevitore hai il tuo valore \(X\) che utilizzi per calcolarti \(t\) da \( X^2 + 6\,t\,X = K. \) Questo valore non sarà tuttavia intero per cui di nuovo prendi \( T = \left \lfloor{t}\right \rfloor . \) Da cui quindi hai che \( Y = T \pmod S . \) Anche qui non so se stai effettivamente facendo un troncamento o un arrotondamento o altro.
Così a prima vista non sono sicuro funzioni. Che si tratti cioè di un processo effettivamente invertibile e che non ci possano essere dei problemi per alcuni valori. Riguardo alla sua sicurezza sono ugualmente scettico. Se infatti il valore \(17\) fosse costante, avresti in pratica un sistema lineare in \(S,\) \(Y_i\) e \(K.\) Considerando inoltre che \(S\) non è poi spesso davvero una incognita, potresti probabilmente calcolare tutto in \( \pmod S \) e togliere anche il problema del valore costante e casuale. Non ho comunque fatto una analisi approfondita e questi sono più che altro impressioni. Non credo comunque che abbia poi tanta importanza il metodo scelto per calcolare \( K. \) Anzi, usare una chiave generata con un metodo così rigido può forse aggiungere un ulteriore limite alla sicurezza del metodo.
Ciao apatriarca
scusami se non ti ho risposto prima ma stavo perfezionando il codice
ora credo sia buono
http://www.albericolepore.org/altwo-nuo ... immetrico/
scusami se non ti ho risposto prima ma stavo perfezionando il codice
ora credo sia buono
http://www.albericolepore.org/altwo-nuo ... immetrico/
Ora è perfetto
AlEr . Codice crittografico simmetrico a chiavi dinamiche.
http://www.albericolepore.org/aler-codi ... dinamiche/
AlEr . Codice crittografico simmetrico a chiavi dinamiche.
http://www.albericolepore.org/aler-codi ... dinamiche/
Per il momento è solo una funzione invertibile tra due insiemi, definita usando un metodo complicato. Per definirlo crittografico dovresti come minimo cercare di analizzare le proprietà statistiche del risultato e vedere se resiste ai più comuni attacchi.
cosa intendi per il più comune degli attacchi ? il bruteforce sulle chiavi ?
-----------------------------------------UPDATE-------------------------------------------
Immagina una chiave costituita da tre chiavi del tipo dell'esempio cioè [9601 , 99992 , 3475]
partendo da [1,1,1] per assurdo, impiegheresti 99992*99992*99992=999760019199488 un numero di 15 cifre per arrivare alla chiave.
Quindi se lo cifriamo la seconda volta 15*15=225 cifre circa
se lo cifri la terza volta 225*15=3375 cifre circa (cicli)
---------------------------------------------------------------------------------------------
Quindi se lo cifriamo la seconda volta 15*15=30 cifre circa
se lo cifri la terza volta 30*15=45 cifre circa (cicli)
-----------------------------------------UPDATE-------------------------------------------
Immagina una chiave costituita da tre chiavi del tipo dell'esempio cioè [9601 , 99992 , 3475]
partendo da [1,1,1] per assurdo, impiegheresti 99992*99992*99992=999760019199488 un numero di 15 cifre per arrivare alla chiave.
Quindi se lo cifriamo la seconda volta 15*15=225 cifre circa
se lo cifri la terza volta 225*15=3375 cifre circa (cicli)
---------------------------------------------------------------------------------------------
Quindi se lo cifriamo la seconda volta 15*15=225 cifre circa
se lo cifri la terza volta 225*15=3375 cifre circa (cicli)
Quindi se lo cifriamo la seconda volta 15*15=30 cifre circa
se lo cifri la terza volta 30*15=45 cifre circa (cicli)
Non per essere cattivo ma... la prima regola del fight club e' "don't roll your own crypto"
che vuoi dire?
Che e' meglio non inventare nulla ma utilizzare quello che si sa essere gia sicuro.
A meno di essere esperto, molto, in materia e fare ricerca in quel campo.
E anche in quel caso, usare qualcosa dopo anni di studi sopra
From Phil Zimmermann's (PGP creator) Introduction to Cryptography (Page 54):
A meno di essere esperto, molto, in materia e fare ricerca in quel campo.
E anche in quel caso, usare qualcosa dopo anni di studi sopra
From Phil Zimmermann's (PGP creator) Introduction to Cryptography (Page 54):
When I was in college in the early 70s, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful government intelligence agencies. I felt so smug about my achievement.
Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.
From this humbling experience I learned how easy it is to fall into a false sense of security when devising an encryption algorithm. Most people don’t realize how fiendishly difficult it is to devise an encryption algorithm that can withstand a prolonged and determined attack by a resourceful opponent.
sai qualche cryptoanalista che mi potrebbe aiutare a capire la falla.
dai non potresti aiutarmi?
per piacere
per piacere
Per il momento hai solo dimostrato che la codifica sia effettivamente un processo invertibile. Non hai dimostrato però nulla sulle caratteristiche di questa codifica. Per esempio, come sono distribuiti i simboli nel messaggio codificato? Cosa si può dire della chiave codificando lo stesso simbolo più volte? Che cosa si può dire della chiave, avendo la possibilità di conoscere sia il messaggio codificato, sia quello in chiaro? Che caratteristiche ha il codice se si lavora in qualche aritmetica modulare?
Un primo grosso difetto del codice è che stiamo lavorando con numeri con un numero di cifre arbitrario. È quindi molto poco pratico per messaggi di una certa lunghezza.. Inoltre richiede una quantità potenzialmente illimitata di memoria e diventa via via più lento con l'aumentare della lunghezza del messaggio. Di fatto il codice così com'è è solo un esercizio di aritmetica senza alcuna utilità.
Un primo grosso difetto del codice è che stiamo lavorando con numeri con un numero di cifre arbitrario. È quindi molto poco pratico per messaggi di una certa lunghezza.. Inoltre richiede una quantità potenzialmente illimitata di memoria e diventa via via più lento con l'aumentare della lunghezza del messaggio. Di fatto il codice così com'è è solo un esercizio di aritmetica senza alcuna utilità.
Per esempio, come sono distribuiti i simboli nel messaggio codificato?
potrebbe essere un ulteriore cifratura
Cosa si può dire della chiave codificando lo stesso simbolo più volte?
un simbolo codificato più volte avrà quasi sicuramente una codifica diversa in quanto varia la chiave ed il numero casuale.
(*)potrebbe verificarsi un opzione remotissima che potrebbe avere la stessa codifica, ma la stessa codifica può ripetersi anche per simboli pre-codifica diversi
Che cosa si può dire della chiave, avendo la possibilità di conoscere sia il messaggio codificato, sia quello in chiaro?
(*)non si può risalire alla chiave
Che caratteristiche ha il codice se si lavora in qualche aritmetica modulare?
(*)non si può risalire alla chiave
Le tue risposte del tipo "(*)non si può risalire alla chiave" è quello che Phil Zimmermann chiamava "false sense of security". Non hai dimostrato nulla, neanche le poche cose che lui aveva verificato nella sua codifica imperfetta. Inoltre "potrebbe essere un ulteriore cifratura" non significa nulla in risposta alla mia richiesta di una analisi statistica della distribuzione di valori del messaggio cifrato. Fare una codifica crittografica minimamente sicura è molto difficile e non siamo noi che dobbiamo dimostrare che la tua codifica sia insicura, sei piuttosto tu che dovresti mostrarti come la tua codifica sia effettivamente sicura. E non qualcosa creato un po' a caso. Analizzare le proprietà di funzioni di questo tipo richiede tempo e non puoi aspettarti che altri lo usino al tuo posto. Soprattutto se non hai mai dimostrato alcuna comprensione delle basi della crittografia.
Piccolo suggerimento
Teoria
http://www.amazon.com/Introduction-Cryp ... b_title_bk
Pratica
http://www.amazon.co.uk/gp/product/0470 ... ge_o03_s00
Tempo:
2-3 anni
Poi ne riparliamo
Teoria
http://www.amazon.com/Introduction-Cryp ... b_title_bk
Pratica
http://www.amazon.co.uk/gp/product/0470 ... ge_o03_s00
Tempo:
2-3 anni
Poi ne riparliamo
perchè aspettare 2-3 anni quando potreste condividere le vostre conoscenze
"P_1_6":
perchè aspettare 2-3 anni quando potreste condividere le vostre conoscenze
Perche' si suppone che prima di fare qualcosa tu impari gli strumenti per farla.
E come parlare di colori ad un cieco dalla nascita per ora...
potreste dirmi almeno la falla.
Almeno inizierei a capire qualcosa
per piacere
Almeno inizierei a capire qualcosa
per piacere
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo