For those who want to find an essay on the algorithm: read this article (from Wikipedia, the free encyclopedia).
Anyway, briefly, the algorithm is based on the sum modulo n letter by letter of numbers associated at every character (in this case the Unicode numbers).
Depending on the chosen key, it can be either a really weak cryptographic system or nevertheless a "perfect cryptographic system".
The rules you must absolutely observe if you don't want to transform this system in an useless attempt of encryption are:
1. The key phrase must be LONGER than the plain phrase. (The applet will work even if the key phrase is shorter, but the result is extremely insecure).
2. Each time use a different key (using always the same key, even if it's strong, is insecure).
Although a text as long as the plain phrase could be a good attempt for choosing a key, still it's an unperfect method.
A good one could be using a chaotic output (you use normally many files that are chaotic in the structure: compressed file, multimedia file with images, sounds or movies) and obtaining in some way a sequence of numbers between 32 and 123 that using the Unicode generate a text to cut&paste in the applet. There's still the problem of sending securely the key phrase to the recipient of the message, but this is another story.
The systems becomes perfect when you are able to generate a cryptographically secure pseudo-random output. You can find many pseudo-random number generators (how to evaluate the quality of the generator is beyond the aim of this document) . The optimum for the sender and the recipient of the message would be to generate separately the pseudo-random sequence starting from a parameter known exclusively by them.
The parameters Unicode..Char are useful for configuring the set of Unicode characters accepted by JaVi; if
you want to extend the set 32-123 you can modify them, possibly consulting the Unicode tables. Anyway, be careful: if you change these values, JaVi will no longer be compatible with the ciphers
obtained before.
The ACCURACY parameter tells how deeply JaVi will inspect the key strength: in theory a higher value makes
the evaluation better, but slower. In facts, even increasing this value the evaluation isn't much different.
The Method parameter is for the key evaluation too: the "MAX" value makes JaVi use the method maxKeyStrength in
Vigenere.java, the "AVE" value the method averageKeyStrength, and another value the method defaultKeyStrength.
Anyway, the "MAX" value is recommended, giving the best evaluation (the worst is "AVE"). For more details
see the source code of Vigenere.java
The bug in the 0.x versions has been fixed: now you can use characters outside the Unicode set 32-123 ; but using another charset may cause errors in the decrypt function in JaVi v1.0. (Fixed in JaVi v1.01).
