An Intro to Crypto Programming using Python

Jeffrey Dege


An introduction to computer-assisted cryptanalysis of classical ciphers using Python

Table of Contents

Introduction - what this is not
Learning about Python
The three ways of running Python code
The Monome-Dinome cipher
A Text class
Our first object
Our first module
Loading from a file
Pre-processing the input
Our first program
An Encryption class
The Key
Cryptanalysis I - the Row Digits
The Frequency count
The n-gram frequency count
The Row Digits
Cryptanalysis II - the Trick
Decrypting with an incorrect key?
Simplifying complex ciphers
Removing the row digits
Cryptanalysis III - Removing the guesswork
The Index of Coincidence
Coding The Index of Coincidence
Creating the programs
Creating the program framework
The complete source code

Introduction - what this is not

This is not an introduction for those who are absolute beginners at programming. Neither is it an introduction for those who are absolute beginners at cryptography. What it is is an introduction to some basic concepts of organizing code, and of applying them to the problem of cracking certain classical ciphers. If you know nothing of programming, are unfamiliar with Python, or do not know how to crack a simple substitution cipher, there are other tutorials out there for you. But if you have read those tutorials, have gotten your feet wet with Python, and have succesfully cracked at least a few simple substitution ciphers, this may be a good next step.

The basic premise of this tutorial is that writing software for your own use as a part of solving your own problems is a very different thing than writing software for others.

When writing software for others, there are necessarily trade-offs ease of use, flexibility, capability, error handling, etc., for which the proper balance is very different than when writing software for your self.

There is an old Unix joke that the only necessary error message is "Segmentation fault: core dumped". Generally, this sort of error "handling" is a very unfriendly thing to inflict on an innocent user, but if you wrote the software, and have the source code, simply letting the system error messages tell you what line of code the error happened on may well be the appropriate choice.

Creating intuitive user interfaces takes work, robust error handling even more work. If it's a program you wrote for yourself, that work may not be necessary, particularly if it's a program that was written to solve one particular problem, and which may well never be used again. The trick to using custom programming in your work in an effective manner is to develop toolsets with which you can easily construct programs to solve the problems that face you.

Decades ago, when most computer users were programmers, a number of books were written with guidance in this area. Unix, in particular, was designed with the aim of making programmers more productive. A number of groundbreaking books were written by the Unix design team at Bell Labs exploring these concepts: The Unix Programming Environment [Brian W. Kernighan and Rob Pike. Prentice Hall, Inc., 1984. ], Software Tools [Brian W. Kernighan amd P. J. Plauger, Addison-Wesley, 1976. ] Programming Pearls [Jon Bentley, Addison-Wesley, 1986. ]. Since then, there has been little discussion of it, as the emphasis in programming has shifted to writing software for others to use.