This week, we finally piece everything together to obtain a program to crack Caesar’s cipher without (much) human intervention.

So the Markov chain model gives us a way of assigning a score to a piece of text as a probability:

,

according to a model that estimates the likeliness of a symbol following an other. We saw how we estimate this probability last week. It basically reduces to scan a large body of text (the larger the better) and estimating frequencies, then converting frequencies into probabilities. Once the score engine is ready, we can finally assemble everything together and solve for the Caesar code automagically.

Cycling through keys and getting a score:

#!/usr/bin/env bash

key=9
message="attack the gauls at dawn"

for ((k=0;k<25;k++))
do
    cesar $k $(cesar $key "$message") 
done | compute-score matrix.txt

Producing:

product=7.7064e-69  log=-156.836 jccjltcqnpjdubjcmjfw
product=1.10597e-54 log=-124.239 kddkmudroqkevckdnkgx
product=1.08628e-38 log=-87.4155 leelnvesprlfwdleolhy
product=2.74988e-54 log=-123.328 mffmowftqsmgxemfpmiz
product=5.62482e-54 log=-122.612 nggnpxgurtnhyfngqnja
product=1.46081e-50 log=-114.75  ohhoqyhvsuoizgohrokb
product=4.27383e-51 log=-115.979 piiprziwtvpjahpisplc
product=6.22185e-75 log=-170.866 qjjqsajxuwqkbiqjtqmd
product=2.27773e-56 log=-128.122 rkkrtbkyvxrlcjrkurne
product=8.98141e-43 log=-96.816  sllsuclzwysmdkslvsof
product=7.42025e-57 log=-129.243 tmmtvdmaxztneltmwtpg
product=6.0041e-45  log=-101.824 unnuwenbyauofmunxuqh
product=7.90349e-53 log=-119.97  voovxfoczbvpgnvoyvri
product=5.10408e-62 log=-141.13  wppwygpdacwqhowpzwsj
product=3.1834e-69  log=-157.72  xqqxzhqebdxripxqaxtk
product=5.26779e-49 log=-111.165 yrryairfceysjqyrbyul
product=3.82049e-61 log=-139.117 zsszbjsgdfztkrzsczvm
product=4.59541e-32 log=-72.1577 attackthegaulsatdawn
product=3.90715e-53 log=-120.674 buubdluifhbvmtbuebxo
product=6.96003e-65 log=-147.728 cvvcemvjgicwnucvfcyp
product=2.09647e-66 log=-151.23  dwwdfnwkhjdxovdwgdzq
product=1.66271e-34 log=-77.7794 exxegoxlikeypwexhear
product=7.40958e-65 log=-147.665 fyyfhpymjlfzqxfyifbs
product=2.26381e-56 log=-128.128 gzzgiqznkmgarygzjgct
product=1.10932e-50 log=-115.026 haahjraolnhbszhakhdu

On the first column, we have scores yielded by the product formula, the second by the log-sum, and finally, the corresponding tentative decryption. In this form, we must scan for the maximum probability (or maximum log-sum) to discover the best candidate. It shows the correctly decrypted text at position (and indeed (mod 26), it’s the correct inverse—and it’s not like the key in itself has any value). It seems to be working correctly.

It’s easier if we sort it out:

#!/usr/bin/env bash

key=9
message="attack the gauls at dawn"

for ((k=0;k<25;k++))
do
    cesar $k $(cesar $key "$message") 
done | compute-score matrix.txt \
     | sort --numeric-sort \
            --reverse \
            --field-separator '=' \
            --key 3

and now:

product=4.59541e-32 log=-72.1577 attackthegaulsatdawn
product=1.66271e-34 log=-77.7794 exxegoxlikeypwexhear
product=1.08628e-38 log=-87.4155 leelnvesprlfwdleolhy
product=8.98141e-43 log=-96.816  sllsuclzwysmdkslvsof
product=6.0041e-45  log=-101.824 unnuwenbyauofmunxuqh
product=5.26779e-49 log=-111.165 yrryairfceysjqyrbyul
product=1.46081e-50 log=-114.75  ohhoqyhvsuoizgohrokb
product=1.10932e-50 log=-115.026 haahjraolnhbszhakhdu
product=4.27383e-51 log=-115.979 piiprziwtvpjahpisplc
product=7.90349e-53 log=-119.97  voovxfoczbvpgnvoyvri
product=3.90715e-53 log=-120.674 buubdluifhbvmtbuebxo
product=5.62482e-54 log=-122.612 nggnpxgurtnhyfngqnja
product=2.74988e-54 log=-123.328 mffmowftqsmgxemfpmiz
product=1.10597e-54 log=-124.239 kddkmudroqkevckdnkgx
product=2.27773e-56 log=-128.122 rkkrtbkyvxrlcjrkurne
product=2.26381e-56 log=-128.128 gzzgiqznkmgarygzjgct
product=7.42025e-57 log=-129.243 tmmtvdmaxztneltmwtpg
product=3.82049e-61 log=-139.117 zsszbjsgdfztkrzsczvm
product=5.10408e-62 log=-141.13  wppwygpdacwqhowpzwsj
product=7.40958e-65 log=-147.665 fyyfhpymjlfzqxfyifbs
product=6.96003e-65 log=-147.728 cvvcemvjgicwnucvfcyp
product=2.09647e-66 log=-151.23  dwwdfnwkhjdxovdwgdzq
product=7.7064e-69  log=-156.836 jccjltcqnpjdubjcmjfw
product=3.1834e-69  log=-157.72  xqqxzhqebdxripxqaxtk
product=6.22185e-75 log=-170.866 qjjqsajxuwqkbiqjtqmd

As we go down the sorted list, we see that solutions become progressively exponentially less likely; at least as estimated by the language model. This means that we only have to have a look at the very first few to ascertain that the decoding has succeeded.

And this means we can use the language model (despite its needing refinement, no doubt) for other ciphers/algorithms. And maybe we should.

To Be continued…

(Buy at Amazon.com)

This is a story of Tibia the cat that suddenly vanishes for five weeks before coming back. In full health, shiny coat, happy. Then vanishes again. Quickly, Caroline Paul catlover, couchridden following a plane crash, worries about Tibby, wondering where he was and why he didn’t come back sooner. Then begins a detective story: will a GPS and a camera attached to the cat reveal its whereabouts?

The book isn’t about a somewhat banal event—a cat that does just what it wants—but about the anguish, treason, and desperation felt by a true cat lover. The story (that involves mystery, death, and a few crackpots) is told in a lively and quirky style, Caroline being always on the verge of breaking down, at times being hilarious (in a sad way, I suppose), all making it very hard to put the book down (I went through it in a little more than one hour!).

(I must say that originally, it was the GPS part that drew my attention (as I have forthcoming projects involving GPSes); not especially the cat part, but it turns out that, despite the title, the book as little to do with technology, and everything to do with the love of pets.)

Read more on the book’s website.

While it’s ridiculously easy to break the cipher, even with pen-and-paper techniques, we ended up, last time, surmising that we should be able to crack the cipher automatically, without human intervention, if only we had a reasonable language model. This week, let us have a look at how we could build a very simple language model that does just that.

There are a lot of ways of building language models. In our case, we’re only interested in having something that gives a higher score to text that looks like reasonable text and very low scores to text that looks like gibberish. One way to do so, is to use a somewhat classical framework where we estimate the probability that we observe a given text fragment given it’s supposed to be, say, English.

That is, we want an estimation of

.

While we cannot really estimate the above directly, we can use, as a proxy, the following:

with having some default value, maybe “space.” That is, the model we will use is a first order Markov chain, where the probability of the entire sentence is estimated as the product of the conditional probabilities , the probability that is observed after ; the conditional probability that a given letter is observed after another. This leaves us with the much simpler task of estimating only .

*
* *

To estimate , we will simply construct a matrix , where is the number of distinct symbols in the language—let us say , and treat text as composed of bytes. Initially, all entries of are set to 1 (not zero, in order to deal with rare, but not impossible, observations, as we will make clearer in a moment). Then we scan a large amount of text, reading characters one by one. The pseudo-code looks something like

“ ”
while read s:

We then normalize row-wise the matrix . Why row-wise? Because we transform each row of to a probability distribution . That is, we want:

,

where we account for all possible successors, and that all probabilities sum to exactly one. Which brings us back to the initial value of for the entries of the un-normalized . We could have set to zero initially, and after we fill it (by scanning the text), the entries that are still zero correspond not to impossible combinations, but only to combinations that have not been observed while filling the matrix. So it may be quite possible later on, when estimating the score of a new piece of text to encounter combinations not seen while “learning” the matrix. This would yield a very, very bad score for such a text. Well, a score of zero. We just want it to be unlikely, so we must settle for a small, but non-zero probability to prevent the product from being zero whenever we observe a combination not seen during the learning phase.

*
* *

Let us now have a look at the implementation of the estimation of .

// compile with --std=c++11

#include <iostream>
#include <vector>
#include <algorithm>

#include <configuration>

int main()
 {
  std::vector<std::vector<int>> 
   matrix(charset_size, std::vector<int>(charset_size, 1));

  size_t nb_read;
  do
   {
    unsigned char page[page_size];
    std::cin.read((char*)page,page_size);
    nb_read=std::cin.gcount();

    int last=0;
    for (int i=0;i<nb_read;i++)
     {
      unsigned char next=page[i];
      if ( (next>=charset_min) &&
           (next<=charset_max) )
       {
        next-=charset_min;
        matrix[last][next]++;
        last=next;
       }
      else
       ; // skip, out of charset we're
      // interested in
     }
   } while (nb_read==page_size);

  for (int i=0;i<charset_size;i++)
   {
    size_t norm=0;
    for (int j=0;j<charset_size;j++) norm+=matrix[i][j];

    for (int j=0;j<charset_size-1;j++)
     std::cout << matrix[i][j]/(double)norm << ' ';
    std::cout << matrix[i][charset_size-1]/(double)norm << std::endl;
   }

  return 0;
 }

where the configuration file contains

#ifndef __MODULE_CONFIGURATION__
#define __MODULE_CONFIGURATION__

const size_t page_size=1000000; // sure, why not?
const size_t charset_min=0;
const size_t charset_max=255;
const size_t charset_size=charset_max-charset_min+1;

#endif
 // __MODULE_CONFIGURATION__

…various details on how you want to deal with files and charsets. You can then invoke

bzcat blob.txt.bz2 | make-matrix > matrix.txt

where blob.txt.bz2 is a large text file assembled from files from the Project Gutenberg.

It’s interesting to look at the matrix graphically. If we look at it as a histogram, we get something like

If we look at it as a (log) density plot, we get something like

*
* *

Evaluating scores, once the matrix is computed (and normalized), is rather straightforward. The implementation of

translates into

double product_score( std::string text,
                      const std::vector<std::vector<double>> & matrix)
 {
  double product=1.0;
  int last=0;
  for (int i=0;i<text.size();i++)
   {
    unsigned char next=text[i];
    if ( (next>=charset_min) &&
         (next<=charset_max) )
     {
      next-=charset_min;
      product*=matrix[last][next];
      last=next;
     }
   }

  return product;
 }

However, if the string is rather long, the above implementation will just give zero. To avoid the problem, we observe that

,

an expression that should be more stable, numerically. We get:

double log_score( std::string text,
                  const std::vector<std::vector<double>> & matrix)
 {
  double sum_log=0;
  
  int last=0;
  for (int i=0;i<text.size();i++)
   {
    unsigned char next=text[i];
    if ( (next>=charset_min) &&
         (next<=charset_max) )
     {
      next-=charset_min;
      sum_log+=std::log(matrix[last][next]);
      last=next;
     }
   }
  return sum_log;
 }

And we’re ready to assemble everything to form an estimator of how likely is the current piece of text to be actual, readable, English. Let us now apply this to the automatic breaking of Caesar’s cipher… next week.

To be continued…

While segregating structure and data makes sense in some cases (say, the index resides in memory but the leaves/data reside on disk), I found the solution somewhat unsatisfactory (but not unacceptable). So I gave the problem a little more thinking and I arrived at an algorithm that produces a tree with optimal average depth, with data in every node, in linear time and using at most extra memory.

The hard part to figure out with this algorithm is that you must create the tree starting at the root, do an in-order scan of the generated tree, but still scan the list from left to right. Turns out, however, that it’s not as complicated as it sounds.

The root (if the list is sorted) will contain list element number (C++: (n+1)/2), thus creating two sub-lists: one with elements from 0 to (n+1)/2-1, and the other with elements (n+1)/2+1 to n-1 (we assume that indexing starts at zero). The root of the left sub-list will be at the middle: again rounding, excluding the root, and creating two sub-lists. We split each list recursively until we have a degenerate list of one item; where we stop.

The best way of convincing oneself that the algorithm works properly is to implement it. Here I will abstract the copying from the list (or array-list, which would be more convenient). The minimal code would look like this:

////////////////////////////////////////
typedef int (*pivot_function_t)(int,int);

////////////////////////////////////////
class tree_node
 {
  public:
    int x;
    tree_node *left, *right;

  tree_node( tree_node *_left, int _x, tree_node *_right)
   : x(_x),
     left(_left),
     right(_right) {}
};

////////////////////////////////////////
template <pivot_function_t pivot>
tree_node * make_tree(int l, int h, int & src)
 {
  if (l==h)
   // degenerate list, a leaf!
   return new tree_node(nullptr,l,nullptr);
  else
   {
    int p=pivot(l,h);

    return
     new tree_node( (p-1>=l) ? make_tree<pivot>(l,p-1,src) : nullptr,
                    p, // here we would copy from list or array[src++]
                    (p+1<=h) ? make_tree<pivot>(p+1,h,src) : nullptr);
   }
 }

where the pivot function returns an integer that tells were to split the list. Possible functions:

//////////////////////////////
int pivot_round(int l, int h) { return (l+h+1)/2; }

//////////////////////////////
int pivot_random(int l, int h) { return l+(std::rand() % (h-l+1)); }

//////////////////////////////
int pivot_fibonacci(int l, int h)
 {
  static const int fibo[]=
   { 1,1,2,3,5,8,13,21,34,55,89,144,
     233,377,610,987,1597,2584,4181,
     6765,10946,17711,28657,46368,
     75025,121393,196418,317811,};

  int d=h-l;
  int i=0;
  while (fibo[i]<d) i++;

  return l+fibo[i-1];
 }

The pivot_round computes what we want. The others are given for comparison, with pivot_random being maybe indicative of a tree constructed from random insertions over time—so it might not be as stupid as it seems at first glance. The pivot_fibonacci is rather fanciful here, but, eh, why not.

To benchmark the quality of the tree, we will use the average node depth. First, we must find the optimal average depth for a tree with nodes. With a bit of algebra, we find that the average depth is given by:

.

(Don’t worry, I have an upcoming post that explains how to derive this expression.) With a formula for , we can launch experiments creating trees with arbitrary number of nodes and compare performance in terms of average depth vs the optimal average depth.

With running from 1 to 1023 (a tree with zero nodes isn’t very interesting!), we obtain the following graph:

The black (optimal) and green (center, or rounded split) overlap perfectly because the center split yields optimal average depth. The Fibonacci split isn’t as bad as I expected, but it yields trees with deeper branches that strictly needed, but not much (maybe 1.6 more?). The random pivot, shown in red, fluctuates wildly, and so is displayed with a moving average (with a window of 100). It does a lot worse than the other methods, but, again, not as much as I would have thought at first.

*
* *

Let us now have a look at what shape the trees actually are. If you know the average depth is optimal you kind of expect the trees to look all nifty like this one:

(The numbers in the nodes represent the index of the element in the original sorted list.) That’s the base case tree with (and that indeed we find with the center split: all trees shown here are svg made from the GraphViz representation of the trees generated by the code above). What if we have an “inconvenient” ? Say ? Well, it’s not what you expect:

but the average depth is still optimal.

*
* *

So, that’s the extra memory I was speaking of at the beginning? Simply the stack. Unlike other recursive algorithms such as Quicksort where you can split the current list in two very uneven sub-lists, picking the pivot in the center creates the most even sub-lists possible, and that, in turn, guarantees that the recursion depth is (or, “exactly “). There’s a hidden constant (for whatever the storage of one stack frame actually is), but the “big O” notation lets us get away with it.

*
* *

And there, you have a linear time (each node/list item is visited exactly once) with extra storage.

Caesar’s method can hardly be considered anything close to secure, but it’s still worthwhile to have a look at how you can implement it, and break it, mostly because it’s one of the simplest substitution ciphers.

Caesar’s cipher is a symmetric cipher, where the encryption and decryption keys are the same, and is very simple. Let be the key, an integer. Let , the sequence of letters to encode. Let us suppose for now that the alphabet is limited to A to Z, with no punctuation, nor diacritics, nor numbers.

The encryption is given by:

.

That is, each letter is “shifted” positions: A shifted 3 positions becomes D. The decryption is the inverse operation:

,

where always return a non-negative number.

If you encrypt a piece of text with :

Tomorrow, we attack the Gauls

becomes:

tomorrowweattackthegauls

before getting fed to the algorithm, which transforms it into:

wrpru urzzh dwwdf nwkhj dxov

which may superficially look completely and securely encrypted.

But stumbling into a cryptogram, say

igttu zgzzg iqmga ryutc kyzhg tq,

it suffices to try (at most) 25 keys:

: hfsst yfyyf hplfz qxtsb jxygf sp
: gerrs xexxe gokey pwsra iwxfe ro
: fdqqr wdwwd fnjdx ovrqz hvwed qn
: ecppq vcvvc emicw nuqpy guvdc pm
: dboop ubuub dlhbv mtpox ftucb ol
: canno tatta ckgau lsonw estba nk
: bzmmn szssz bjfzt krnmv drsaz mj

and yields cannot attack Gauls on west bank, which solves the cryptogram unambiguously.

*
* *

Caesar’s cipher is weak, and even with a pen-and-paper solving strategy, it cannot be very long before one cracks the code. For one thing, you don’t have to decipher the whole message before figuring out that the key you’re trying’s only yielding gibberish, and you don’t even have to start at the beginning of the message.

Still, if one wants to automate the process (let’s suppose we want to), the only missing piece is a language model that gives a score to each clear-text candidate, and allows us to pick the most probable one. Maybe we could do just that in a follow-up entry?

*
* *

So let us now look at the implementation. It assumes that the letters are lowercase. A direct implementation would give something like:

////////////////////////////////////////
//
// Encrypts string (in-place) using
// Ceasar's method
//
void encrypt( int key,
              std::string & message )
 {
  for (size_t i=0;i<message.size();i++)
   message[i]='a'+(ord(message[i])+key) % 26;
 }


////////////////////////////////////////
//
// Decripts string (in-place) using
// Ceasar's medthod
//
void decrypt( int key,
              std::string & message )
 {
  for (size_t i=0;i<message.size();i++)
   message[i]='a'+(ord(message[i])+(26-key)) % 26;
 }

where ord is an helper function that returns 0 for a and 25 for z. There’s just a small complication: as C++’s modulo % returns negative remainder on negative numbers, it is necessary to compensate for this by adding 26, safely performing the arithmetic on non-negative numbers.

*
* *

We will be back on (simple) language models that will help us automate the process of cracking Caesar’s cipher.

To be continued…

Turns out, one form that regularly comes up in my calculations is , and it bugged me a while before I figured out the right way of getting rid of them (sometimes).

Let us start by an abstract case:

where (for now), and where is some function that depends only on . grows by one each time doubles in magnitude. We can therefore write the preceding as

where you can verify that still progresses from to as before, but we now have a different grouping what allows us to replace by , and factor it out. We can now simplify the sums depending on as a function of as

where is an expression depending only on . Finally, you can obtain a simplified expression for , the initial goal.

*
* *

So, where does the bounds come from? As I said earlier, has natural boundaries of the form , with . Indeed:

0	1	1
1	2	3
2	4	7
3	8	15
4	16	31
…	…	…

The generator of the series at the far right of the table isn’t very hard to guess: .

It is a special case of a geometric series,

With , , it does simplify to the expected:

*
* *

So by knowing how to sum powers of two (or any other constant, for that matter), we could remove and get a simpler expression. While the change of variable and adapting the sums’ boundaries helps a great deal, it is the fact that the base of the logarithm is an integer that helps quite a lot. Indeed, can you see what’s the problem is the base of the logarithm is now ?

You guessed it right. Now, instead than having boundaries at integers of the form , we must find where the function changes between some and , which can be quite messier.

One of those constructs in C++ is the const (and other access modifiers) that explicitly states to the programmer that this function argument will be treated as read-only, and that it’s safe to pass your data to it, it won’t be modified. But is it all but security theater?

Let us start with a C-style program (that may be C++):

void le_troll_func(const char * buffer)
 {
  for (int i=0;buffer[i];i++)
   buffer[0]=0;
 }

This normally results in some compile-time error:

const-test.cpp: In function 'void le_troll_func(const char*)':
const-test.cpp:24:14: error: assignment of read-only location '* buffer'

The first observation is that despite const, one can discard constness using either C-style or C++-style casts. In C, we can easily re-write it as:

void le_troll_func(const char * buffer)
 {
  for (int i=0;buffer[i];i++)
   ((char*)buffer)[0]=0;
 }

…which compiles without so much as a warning. In C++, we can replace the cast by a const_cast:

void le_troll_func(const char * buffer)
 {
  for (int i=0;buffer[i];i++)
   const_cast<char*>(buffer)[0]=0;
 }

Even the C++ method modifier const is weak. Consider:

class inner_thingie
{
 public: int zoidberg; // why not?
};

class thingie
 {
 private:

  int x;
  inner_thingie * z;

  void le_troll_function() const { z->zoidberg=3; }

  void on_something_else() const { x=3; }
  

  thingie()
   : x(0), z(new inner_thingie)
  { }
 };

Cause compilation error (yes, without ‘s’):

const-test.cpp: In member function 'void thingie::on_something_else() const':
const-test.cpp:15:38: error: assignment of member 'thingie::x' in read-only object

So, while on_something_else() const behaves as expected, le_troll_function() const clearly does not. Apparently, if z is const, the constness isn’t transitive and does not apply to what z points to. ISO 14882:2003 §9.3.2.2 states that const on a function forces *this to be const, but does not imply it propagates, it is limited to this. tl;dr: const is shallow.

*
* *

If const doesn’t seem to enforce a great deal of constraints, is it still worth using? It is of little pragmatic importance—I have yet to find a compiler optimization that takes some real advantage of const—but if it is honored as it should be, const signs a contract between the function (class, library) and the user (the programmer). It helps distinguish functions that read-only data, and those that rewrite it. C (and C++) libraries have been extensively consted when the keyword was introduced to the language (for it hasn’t been there forever) for this reason. So, yes, I think it’s still worth using const, even with its limitations.

*
* *

The const “social contract” of const isn’t very strong, and a programmer can easily deconst data. But if a programmer does it deliberately, you’re to find him and taunt him. Even a second time.