Chi volesse trovare un approfondimento sull'algoritmo può farlo a questo link (da Wikipedia, l'enciclopedia libera).
Comunque riassumendo, l'algoritmo è basato sulla somma modulare lettera per lettera di numeri associati a ogni carattere (in questo caso i codici Unicode).
A seconda di come viene usato (e cioè in base alla chiave scelta) può essere un sistema crittografico veramente banale da scardinare o addirittura diventare nientemeno che un "sistema crittografico perfetto".
Le regole da seguire assolutamente per non trasformare questo sistema in un'inutile tentativo di crittazione sono:
1. La frase chiave dev'essere PIU' LUNGA della frase in chiaro. (L'applet funziona anche se la frase chiave è piu' corta, ma il risultato è assolutamente insicuro).
2. Ogni volta si deve usare una chiave diversa (utilizzare sempre una stessa chiave, anche se robusta, è poco sicuro).
Sebbene un testo lungo quanto la frase in chiaro possa essere un buon tentativo di chiave, è ancora un metodo imperfetto.
Un buon metodo potrebbe essere usare un output sufficientemente disordinato (molti file che usiamo correntemente sono disordinati nella struttura: file compressi, file contenenti immagini, suoni o filmati) e ricavare in qualche modo una sequenza di numeri tra 32 e 123 che attraverso lo Unicode generi un testo da copiare/incollare nell'applet. Rimane ancora il problema di scambiare la frase chiave con il destinatario, ma questo è un altro discorso.
Il sistema diventa perfetto quando si è in grado di generare un output pseudo-casuale crittograficamente sicuro. Si trovano molti generatori di numeri pseudo-casuali (provane uno). L'ideale per il mittente e il destinatario sarebbe generare indipendentemente la sequenza pseudo-casuale a partire da un parametro noto solo a loro due.
Cosa vuol dire output pseudo-casuale crittograficamente sicuro? Vuol dire che la sequenza di caratteri deve resistere ai più forti test statistici (per esempio il test universale di Maurer). JaVi fornisce un test che valuta la forza della chiave immessa (il test di Maurer è il migliore che io conosca, può darsi che lo implementerò in futuro; se qualcuno conosce una implementazione Java me lo faccia sapere!).
JaVi, nella classe Vigenere, fa un test che valuta le frequenze nella chiave delle sotto-stringhe di lunghezza da 1 a 30 . L'idea è che una chiave casuale sufficientemente lunga avrà le frequenze di ogni lettera molto vicine alla frequenza media (cioè 1/92, perchè in JaVi si usano 92 simboli alfanumerici dello Unicode).
E cosi' saranno le frequenze delle stringhe di lunghezza 2 ("aa","ab","ac", ecc.), lunghezza 3 e cosi' via. Per misurare di quanto si allontanano le frequenze ho usato la deviazione standard, cioè la radice quadrata della varianza. La varianza è data dalla formula:
n e' il numero di stringhe possibili per la lunghezza fissata
Quindi prima calcolo la deviazione standard per le stringhe di lunghezza 1, cioè tutti i caratteri nell'intervallo Unicode 32-123; poi per le stringhe di lunghezza 2, 3, ecc.. fino alla lunghezza della chiave o comunque fino a un massimo di 30. A questo punto ho un array con queste deviazioni standard: per essere più selettivo considero solo la peggiore, ovvero la piu' elevata, e ottengo la forza desiderata in percentuale. Questo metodo comunque non può valutare molto precisamente delle differenze minime tra chiavi forti: in pratica se la valutazione sara' dal 95% in su non è detto che altri test più forti non trovino invece dei difetti. Per essere più sicuri consiglio quindi di cercare in rete altri test come quello di Maurer.
I parametri Unicode..Char servono per configurare l'elenco di caratteri Unicode accettati da JaVi: se si vuole
estendere l'intervallo 32-123 si possono modificare a piacimento, se possibile consultando le tabelle
Unicode. Attenzione pero': modificando questi parametri JaVi non sara' piu' compatibile con
i crittogrammi prodotti in precedenza.
Il parametro ACCURACY regola la profondita' dell'indagine statistica condotta sulla chiave: in teoria un valore piu' alto
dovrebbe garantire una maggior precisione, a fronte di un rallentamento dell'applet. In realta' anche aumentando
questo valore la valutazione non e' significativamente diversa.
Anche il parametro Method serve per configurare la valutazione della chiave: il valore "MAX" fa usare il metodo maxKeyStrength
di Vigenere.java , il valore "AVE" il metodo averageKeyStrength e un qualunque altro valore il metodo defaultKeyStrength.
Il valore "MAX" e' comunque raccomandato, essendo il piu' affidabile (il meno affidabile e' "AVE"). Per avere piu'
dettagli consultare il codice sorgente di Vigenere.java
E' stato corretto il bug delle versioni 0.x in cui si potevano inserire solo caratteri nell'intervallo Unicode 32-123; pero' usare un altro intervallo potrebbe causare errori nella decifrazione in JaVi v1.0. (Corretto in JaVi v1.01).