The Vigènere cracker I

This was one of the most exciting projects I have ever worked on. Was at the subject "Códigos y Criptografía" (Codes and Cryptography), and the challenge that our teacher proposed us was the development of an application able to break the Vigènere cipher.

For those who do not know how does Vigènere cipher works, I will try to shortly explain:

Simple ciphers like the Caesar cipher shifts the letters a determined number of positions (n), that means that replaces every single letter with the one that have n positions more in the alphabet.
For example, if we use the Caesar cipher to encrypt the word "ITBLOG" with a shift of 1, we get "JUCMPH".

As you have probably find out, there is a very small number of possibilies for this kind of cipher, in fact, the number of possibilities is exactly the number of different symbols that have the alphabet used.

Otherwise, more complex algorithms use a password in order to encrypt the message. In Vigènere the letters of the message are added to the letters of the password (repeated cyclically), getting the letters of the encrypted message.
For example, encrypting the message "ITBLOG" with the password "ABCD", we have to do this operation:

ITBLOG
+
ABCDAB
-----------
IUDÑOH

Notice that I am using the Spanish alphabet (for your knowledge, the letter 'ñ' is between 'n' and 'o').

So now, trying to break the cipher is a little bit more complicated, every letter is encrypted with it corresponding in the password, then the same letter could be encrypted in several different ways depending on which is the current used letter of the password. For example, T + B = U = S + C.

And that is enough for today, in the next entries I will explain how does the cracker algorithm works.

Service Pack 3

Little bit oldie, but still funny...

Dealing with SWT Browser "setText()" method

Some time ago, working at the TutorMates project, I needed to render some XHTML code with MathML in the SWT Browser. As you know, SWT Browser can be set to use the IExplorer or Mozilla engine, in this case, Mozilla (XulRunner) was used.

The problem was that the "setText(String code)" method wasn't able to recognize the content-type of the code; this means the render can't draw it properly. At that time, I wrote at Eclipse News reporting this unexpected performance and also posted the bug, but nobody answered a working solution.

The solution I have found for dealing with this problem is to generate a temporary file for every Browser object, then when "setText(String code)" is called, my class fills the temporary file with the received String and then opens that file by using the "setUrl(String url)" method and its temporary location.
This class have two constructors, one of them is the classic "BrowserFix(Composite parent, int style)" and the other is a new constructor with this format "BrowserFix(Composite parent, int style, String extension)", as you can imagine, the extra argument is used to set the content-type of the code by assigning a specific file extension.

Here you can see the difference between bad (left) and good (right) recognizing of the code content-type.

Download BrowserFix.java snippet