JaVi v0.8 - Java Vigenere
Manuale d'uso



Indice
1. Introduzione
2. La JaVi GUI
3.1. L'algoritmo di Vigenere
    2. Un po' di statistica
4.1. Le classi
    2. UML
5. Problemi e bugs conosciuti
6. Idee per il futuro



1. Introduzione

JaVi è un'implementazione Java dell'algoritmo di Vigenere per la crittografia. Attualmente funziona all'interno di un'applet Java (JaVi2Applet.java). E' costruito utilizzando i Java AWT e dovrebbe essere compatibile con la maggior parte dei browser.


2. La JaVi GUI (Graphical User Interface)



Il primo pannello grigio in alto contiene informazioni sulla versione, sul copyright e sulla licenza. Il pannello di sinistra da' una valutazione della forza della chiave, con la percentuale ottenuta dal procedimento descritto nel paragrafo 3.2. Sotto la percentuale un pannellino si colora di verde se la forza e' sopra il 90%, di giallo se e' sopra il 60%, di rosso altrimenti o se la chiave e' piu' corta della frase (compare il messaggio "Key Short!").

Il pannello centrale è diviso in 3 sottopannelli (panelPhrase, panelKey, panelEncrypted), che contengono rispettivamente la frase in chiaro, la chiave e la frase crittata. Il panelKey contiene anche due bottoni (buttonCrypt e buttonDecrypt) usati rispettivamente per crittare la frase in chiaro e per decrittare la frase crittata. Nota che l'area di testo contenente la chiave è editabile all'inizio. Si può inserire una chiave personalizzata, ed è questa la scelta consigliata: per farlo bisogna prima cliccare nella checkbox "Chiave editabile" nel pannello grigio scuro in basso. Se poi si volesse nascondere la chiave a uno sguardo indiscreto c'è la checkbox vicina "Chiave visibile". Il bottone "Resetta chiave" ripristina la chiave di default (per la cronaca composta dalle prime cifre di pigreco e del numero e).
Infine i bottoni colorati laterali permettono di passare dalla versione italiana a quella inglese.

Nota: ogni volta che viene caricata l'applet, la chiave sarà sempre la stessa: se si intende utilizzare più volte una chiave personalizzata bisognerà salvarla in qualche modo e copiarla/incollarla nella area di testo ogni volta.


3.1. L'algoritmo di Vigenere

Chi volesse trovare un approfondimento sull'algoritmo può farlo all'interno del sito: http://it.geocities.com/teutoburgo nella sezione Java al link
"Approfondimento sulla crittografia". 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.


3.2. Un po' di statistica

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.


4.1. Le classi

Le tre classi del package JaVi sono Javi2Applet, Vigenere e FrequenzaNijk. Vengono poi importati i package java.awt e java.applet per realizzare la GUI.
Il Business Object contenente l'algoritmo di Vigenere è ovviamente Vigenere.java. I due metodi fondamentali sono getEncryptedPhrase e getPhrase, e sono l'uno l'inverso dell'altro. Viene applicato l'algoritmo, carattere per carattere, operando sui codici Unicode di ogni carattere. L'intervallo ammesso è dal carattere Unicode 32 (' ' o spazio) allo Unicode 123 ('Z'). In questa versione quindi non sono ammessi i caratteri accentati ('è','à', ecc.) e l'invio a capo. Per informazioni sullo standard Unicode:
www.unicode.org
Gli ultimi metodi aggiunti servono tutti per valutare la forza della chiave: getKSPerCent da' la forza in percentuale prendendola da getKeyStrength, che a sua volta utilizza maxKeyStrength per scegliere la deviazione standard maggiore. defaultKeyStrength e averageKeyStrength non vengono usati ma si possono provare, ricompilando, per vedere le differenze con maxKeyStrength. Infine trovaStringhe serve per contare le frequenze relative alle sotto-stringhe di lunghezza k della chiave e per memorizzarle in una FrequenzaNijk.
L'altro BO e' FrequenzaNijk.java. Praticamente e' solo un bean per memorizzare la frequenza relativa a una singola stringa e ha solo i metodi set e get.

4.2. Diagrammi UML (Unified Modeling Language)
UML è un potente strumento di analisi e disegno di applicazioni a oggetti. Per saperne di più
leggi questo articolo (in italiano!)
Package JaVi

Class Vigenere

Class Javi2Applet

Class FrequenzaNijk

5. Problemi e bugs conosciuti

Ho testato l'applet su diverse piattaforme (Windows 98-NT ecc., Linux) e con diversi browser (Internet Explorer 5, Netscape Navigator 4) e finora ha sempre funzionato tranne su un vecchio PC con Windows 95 e Internet Explorer 3.0 . L'unico bug "strano" si e' verificato su Netscape Navigator 4.76: l'applet funziona ma il metodo per valutare la forza della chiave non da' il risultato corretto.
Per problemi di funzionamento o di compatibilità non riportati qui le segnalazioni vanno inviate tramite
questo form, con una descrizione sommaria del problema e della piattaforma su cui ha girato l'applet (processore, sistema operativo (con versione) e browser (con versione)).

Il bug principale è il fatto che si possano inserire solo caratteri nell'intervallo Unicode 32-123 (si potrà correggere facilmente, immagino).


6. Idee per il futuro

Con l'aiuto dei miei allievi ho rilasciato anche una versione come
applicazione standalone, oltre che come applet. Se qualcuno avesse voglia di contribuire allo sviluppo, sarei felice di saperlo. Comunicamelo tramite questo form.


Indice della documentazione
Bookmark and Share