This week, we begin to reverse engineer the home-grown encryption algorithm discussed last week. Last week I offered you five examples of "encrypted" text that were generated by a home-grown crypto system. Your job was to reverse engineer the algorithm. . .
This week, we begin to reverse engineer the home-grown encryption algorithm discussed last week. Last week I offered you five examples of "encrypted" text that were generated by a home-grown crypto system. Your job was to reverse engineer the algorithm.

Well, the week went by and folks did take a stab at it, but no one managed to break it yet. So I'm extending the contest another week. This article will provide the first part of the algorithm which should get you started. Once you get through this layer, you should be able to work through the solution in a few shifts.[2] If you break the code, write me email and the best writeup describing the algorithm will get a copy of Hacking Linux Exposed, Second Edition.

So, let's look at the first part of my reverse engineering.

We had only encrypted data to work with, and some idea of what acceptable contents would look like, in this case, normal English text. You might argue in an ideal world you would not have any idea what the plaintext would look like, but in the real world you can usually hazard a guess. For example if you find encrypted-looking text in a database, the field name will probably indicate what it is. If an email contains only an encrypted body, then it is likely composed of readable characters.

The five encrypted strings were as follows:

# String 1 !!@!1P!=P!?P!=P!?`!>`!<0!?0!;0!?0!=@!B`!,`!>@!A0!,P!>@!B@!A`

# String 2 !T`!M0!TP!V0!X0!Y0!C@!P0!Y0!W0!UP!Y@!H@

...