CLASSICAL ENCRYPTION TECHNIQUES

1. Monoalphabetic Ciphers

Here is an example of a plaintext – ciphertext alphabet pair for each type of

cipher we have seen thus far.

1. A Caesar cipher with key 5:

plaintext alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ
ciphertext alphabet FGHIJKLMNOPQRSTUVWXYZABCDE

2. A Decimation Cipher modulo 26 with key 21:

plaintext alphabet ABCDEFGHIJKLMNOPQRSTUVWXYZ
ciphertext alphabet UPKFAVQLGBWRMHCXSNIDYTOJEZ

3. A Linear Cipher modulo 26 with key 7m + 9:

plaintext alphabet abcdefghijklmnopqrstuvwxyz
ciphertext alphabet PWDKRYFMTAHOVCJQXELSZGNUBI

These are all monoalphabetic ciphers, ciphers in which the same plaintext
letters are always replaced by the same ciphertext letters. Mono, meaning one,
indicates that each letter has a single substitute.

Keyword Ciphers

To use Keyword Cipher method to construct the ciphertext alphabet, pick a

keyword and write it down, ignoring repeated letters. Follow it with the letters
of the alphabet that have not yet been used.

Example: Find the alphabet pairs for the keyword COLLEGE.

Crossing out the letters that are making their second appearance leaves
COLEG. To encipher then we use the pair of alphabets

plaintext ABCDEFGHIJKLMNOPQRSTUVWXYZ
ciphertext COLEGABDFHIJKMNPQRSTUVWXYZ
Enciphering university then gives UMFVGRSFTY.

Around 1580 Giovanni Battista Argenti suggested that one

also pick a keyletter and begin the keyword under that letter of the plaintext.
The Argentis, Giovanni and his nephew Matteo, form one of the great cryptology
families of the middle ages. After many years of trying, in 1590 Giovanni finally
became papal secretary of ciphers in Rome, only to quickly weaken from the
frequent necessary trips to Germany and France. Before dying on April 24,
1591, he passed his knowledge to his nephew Matteo who succeeded him and
held the office during the reign of the next five popes.
To use Giovanni’s method with keyletter p we would start COLEG under
pqrst, giving
plaintext ABCDEFGHIJKLMNOPQRSTUVWXYZ
ciphertext JKMNPQRSTUVWXYZCOLEGABDFHI
Then university is enciphered as AYTAPLETGH. This method mixes the ciphertext
alphabet better.

2. PLAYFAIR

The Playfair cipher or Playfair square is a manual symmetric encryption technique

and was the first literal digraph substitution cipher. The scheme was invented in 1854 by
Charles Wheatstone, but bears the name of Lord Playfair who promoted the use of the
cipher.

The technique encrypts pairs of letters (digraphs), instead of single letters as in the
simple substitution cipher and rather more complex Vigenère cipher systems then in
use. The Playfair is thus significantly harder to break since the frequency analysis used
for simple substitution ciphers does not work with it. The frequency analysis of digraphs
is possible, but considerably more difficult. With 600 [1] possible digraphs rather than the
26 possible monographs, a considerably larger cipher text is required in order to be
useful.

Description

The Playfair cipher uses a 5 by 5 table containing a key word or phrase. Memorization of the
keyword and 4 simple rules was all that was required to create the 5 by 5 table and use the
cipher.

To generate the key table, one would first fill in the spaces in the table with the letters of the
keyword (dropping any duplicate letters), then fill the remaining spaces with the rest of the
letters of the alphabet in order (usually omitting "Q" to reduce the alphabet to fit; other versions
put both "I" and "J" in the same space). The key can be written in the top rows of the table, from
left to right, or in some other pattern, such as a spiral beginning in the upper-left-hand corner and
ending in the center. The keyword together with the conventions for filling in the 5 by 5 table
constitute the cipher key.

To encrypt a message, one would break the message into digraphs (groups of 2 letters) such that,
for example, "HelloWorld" becomes "HE LL OW OR LD", and map them out on the key table.
If needed, append a "Z" to complete the final digraph. The two letters of the digraph are
considered as the opposite corners of a rectangle in the key table. Note the relative position of the
corners of this rectangle. Then apply the following 4 rules, in order, to each pair of letters in the
plaintext:
 1. If both letters are the same (or only one letter is left), add an "X" after the first letter.
Encrypt the new pair and continue. Some variants of Playfair use "Q" instead of "X", but
any uncommon monograph will do.
2. If the letters appear on the same row of your table, replace them with the letters to their
immediate right respectively (wrapping around to the left side of the row if a letter in the
original pair was on the right side of the row).
3. If the letters appear on the same column of your table, replace them with the letters
immediately below respectively (wrapping around to the top side of the column if a letter
in the original pair was on the bottom side of the column).
4. If the letters are not on the same row or column, replace them with the letters on the same
row respectively but at the other pair of corners of the rectangle defined by the original
pair. The order is important – the first letter of the encrypted pair is the one that lies on
the same row as the first letter of the plaintext pair.

To decrypt, use the INVERSE (opposite) of the last 3 rules, and the 1st as-is (dropping any extra
"X"s, or "Q"s) that do not make sense in the final message when finished).

There are several minor variations of the original Playfair cipher.[5]

Example
Using "playfair example" as the key, (assuming I and J are interchangeable) the table becomes
(omitted letters in red):

P L A Y F
I R E X M
B C D G H
K N O Q S
T U V W Z
Encrypting the message "Hide the gold in the tree stump"
(note the null "X" used to separate the repeated "E"s) :
HI DE TH EG OL DI NT HE TR EX ES TU MP
^

1. The
pair HI
forms a
rectangle
, replace
it with
BM

2. The
pair DE
is in a
column,
replace it
with OD
3. The
pair TH
forms a
rectangle
, replace
it with
ZB

4. The
pair EG
forms a
rectangle
, replace
it with
XD

5. The
pair OL
forms a
rectangle
, replace
it with
NA
6. The
pair DI
forms a
rectangle
, replace
it with
BE
7. The
pair NT
forms a
rectangle
, replace
it with
KU
8. The
pair HE
forms a
rectangle
, replace
it with
DM
9. The
pair TR
forms a
rectangle `
, replace
it with
UI

10. The
pair EX
(X
inserted
to split
EE) is in
a row,
replace it
with XM

11. The
pair ES
forms a
rectangle
, replace
it with
MO
12. The
pair TU
is in a
row,
replace it
with UV
13. The
pair MP
forms a
rectangle
, replace
it with IF
BM OD ZB XD NA BE KU DM UI XM MO UV IF

Thus the message "Hide the gold in the tree stump" becomes "BMODZ BXDNA BEKUD
MUIXM MOUVI F". (Breaks included for ease of reading the ciphertext.)

The Hill Cipher was invented by Lester S. Hill in 1929, and like the other Digraphic Ciphers it
acts on groups of letters. Unlike the others though it is extendable to work on different sized
blocks of letters. So, technically it is a polygraphic substitution cipher, as it can work on
digraphs, trigraphs (3 letter blocks) or theoretically any sized blocks.
The Hill Cipher uses an area of mathematics called Linear Algebra, and in particular requires the
user to have an elementary understanding of matrices. It also make use of Modulo Arithmetic
(like the Affine Cipher). Because of this, the cipher has a significantly more mathematical nature
than some of the others. However, it is this nature that allows it to act (relatively) easily on larger
blocks of letters.
In the examples given, we shall walk through all the steps to use this cipher to act on digraphs
and trigraphs. It can be extended further, but this then requires a much deeper knowledge of the
background mathematics. Some important concepts are used throughout: Matrix Multiplication;
Modular Inverses; Determinants of Matrices; Matrix Adjugates (for finding inverses).
Encryption
To encrypt a message using the Hill Cipher we must first turn our keyword into a key matrix (a 2
x 2 matrix for working with digraphs, a 3 x 3 matrix for working with trigraphs, etc). We also
turn the plaintext into digraphs (or trigraphs) and each of these into a column vector. We then
perform matrix multiplication modulo the length of the alphabet (i.e. 26) on each vector. These
vectors are then converted back into letters to produce the ciphertext.
2 x 2 Example
We shall encrypt the plaintext message "short example" using the
keyword hill and a 2 x 2 matrix. The first step is to turn the keyword
 into a matrix. If the keyword was longer than the 4 letters needed, we
The keyword written as a
would only take the first 4 letters, and if it was shorter, we would fill matrix.
it up with the alphabet in order (much like a Mixed Alphabet).

With the keyword in a matrix, we need to convert this into a key

matrix. We do this by converting each letter into a number by its
position in the alphabet (starting at 0). So, A = 0, B = 1, C= 2, D = 3, The key matrix (each
etc. letter of the keyword is
converted to a number).
We now split the plaintext into digraphs, and write these as column vectors. That is, in the first
column vector we write the first plaintext letter at the top, and the second letter at the bottom.
Then we move to the next column vector, where the third plaintext letter goes at the top, and the
fourth at the bottom. This continues for the whole plaintext.

The plaintext "short example" split into column vectors.

Now we must convert the plaintext column vectors in the same way that we converted the
keyword into the key matrix. Each letter is replaced by its appropriate number.

The plaintext converted into numeric column vectors.

Now we must perform some matrix multiplication. We multiply the key matrix by each column
vector in turn. We shall go through the first of these in detail, then the rest shall be presented in
less detail. We write the key matrix first, followed by the column vector.

To perform matrix multiplication we "combine" the top row of the key matrix with the column
vector to get the top element of the resulting column vector. We then "combine" the bottom row
of the key matrix with the column vector to get the bottom element of the resulting column
vector. The way we "combine" the four numbers to get a single number is that we multiply the
first element of the key matrix row by the top element of the column vector, and multiply the
second element of the key matrix row by the bottom element of the column vector. We then add
together these two answers.

That is, we follow the rules given by the

algebraic method shown to the left.
The algebraic rules of matrix multiplication.
 In our case we perform the two calculations on
the right. We then right these two answers out
in a column vector as shown below.
The calculations performed when doing a matrix
multiplication.

The shorthand for the matrix multiplication.

Next we have to take each of these numbers, in our resultant column vector, modulo 26
(remember that means divide by 26 and take the remainder).

Reducing the resultant column vector modulo 26.

Finally we have to convert these numbers back to letters, so 0 becomes "A" and 15 becomes "P",
and our first two letters of the ciphertext are "AP".

The whole calculation: converting to numbers; the matrix multiplication; reducing modulo 26; converting
back to letters.
 
Encryption process of the first digraph.
Play
1 23456
This gives us a final ciphertext of "APADJ TFTWLFJ".

A typical stream cipher encrypts plaintext one byte at a time, although a stream cipher may be
designed to operate on one bit at a time or on units larger than a byte at a time.

A block cipher encrypts one block at a time. The block may be of size one byte or more or less.
That means we can also encrypt a block of one byte by help of a stream cipher as a stream.

So what is the exact difference between a stream cipher and a block cipher?
A block cipher is a deterministic and
computable function of k-bit keys and n-bit
(plaintext) blocks to n-bit (ciphertext) blocks.
(More generally, the blocks don't have to be
bit-sized, n-character-blocks would fit here,
too). This means, when you encrypt the same
plaintext block with the same key, you'll get the
same result. (We normally also want that the
function is invertible, i.e. that given the key and
the ciphertext block we can compute the
plaintext.)

To actually encrypt or decrypt a message (of

any size), you don't use the block cipher
directly, but put it into a mode of operation.
The simplest such mode would be electronic
code book mode (ECB), which simply cuts the
message in blocks, applies the cipher to each
block and outputs the resulting blocks. (This is
generally not a secure mode, though.)

Some early encryption schemes like the one

used by Caesar could be categorized as a "block
cipher with 1-character blocks in ECB-mode".
Or generally, everything that has a code book.

We usually use other modes of operation,

which include an initialization vector and
some kind of feedback, so that every block of
every message is encrypted a different way.

A stream cipher is a function which directly

maps k-bit keys and arbitrary length plaintexts
to (same arbitrary length) ciphertext, in such a
way that prefixes of the plaintext map to
prefixes of the ciphertext, i.e. we can compute
the starting part of the ciphertext before the
trailing part of the plaintext is known. (Often
the message sizes might be limited to multiples
of some "block size", too, but usually with
smaller blocks like whole bytes or such.)

If a part of the plaintext repeats, the

corresponding ciphertext usually is not the
same – different parts of the message will be
encrypted in different ways.
Often such stream ciphers work by producing a
keystream from the actual key (and maybe an
initialization vector) and then simply XOR-ing
it with the message – these are called
synchronous stream ciphers. Other stream
ciphers might vary the encryption of future
parts of the message depending on previous
parts.

Some block cipher modes of operation actually

create a synchronous stream cipher, like CTR
and OFB mode.

You should never reuse a key (and IV, if

applicable) of a synchronous stream cipher
(which includes block ciphers in streaming
modes) for different messages, since this can
lead to compromises. (And even for the same
message it will show that you repeated a
message.)

Note that in actual usage you will also want a

MAC, e.g. integrity protection, for your
message. (Some schemes are broken in case of
a chosen-ciphertext attack, for example, and
such a MAC will prevent this.)

answered Nov 11 '12 at

15:32

shareimprove this
answer

Paŭlo Ebermann♦
13.9k33473

When would you choose between a stream vs.

block? Is there a difference in security? Or
    
speed of encryption? –  anoopelias May 1 '13 at
8:07
 @anoopelias Block ciphers are generally slow as
compared to Stream ciphers. Also, I am not sure
but I think stream ciphers are good at providing
    
information security while block ciphers are
good at providingcomputational security – 
ps06756 yesterday

add a comment

up vote 7 down vote Mathematically, a block cipher is just a keyed

pseudorandom permutation family on the set
{0,1}n of n-bit blocks. (In practice, we usually
also require an efficient way to compute the
inverse permutation.) A block cipher on its own
is not very useful for practical cryptography, at
least unless you just happen to need to encrypt
small messages that each fit into a single block.

However, it turns out that block ciphers are

extremely versatile building blocks for
constructing other cryptographic tools: once you
have a good block cipher, you can easily build
anything from stream ciphers to hash functions,
message authentication codes, key derivation
functions, pseudorandom number generators,
entropy pools, etc. based on just one block
cipher.

Not all of these applications necessarily need a

block cipher; for example, many of them could
be based on any pseudorandom function which
need not be a permutation (but, conveniently,
there's a lemma that says a pseudorandom
permutation will, nonetheless, work). Also, many
of the constructions are indirect; for example, you
can construct a key derivation function from a
message authentication code, which you can
construct from a hash function, which you can —
but don't have to — construct from a block
cipher. But still, if you have a block cipher, you
can build all the rest out of it.

Furthermore, these constructions typically come

with (conditional) security proofs that reduce the
security of the constructed functions to that of the
underlying block cipher. Thus, you don't need to
carry out the laborious and unreliable task of
cryptanalyzing each of these functions separately
— instead, you're free to concentrate all your
efforts on the block cipher, knowing that any
confidence you'll have on the security of the
block cipher directly translates into confidence on
all the functions based on it.

Obviously, all this is very convenient if you're,

say, working on a small embedded platform
where including efficient and secure code for lots
of separate crypto primitives could be difficult
and expensive. But even if you're not on such a
constrained platform, writing and analyzing low-
level crypto code can be laborious due to the
need to pay attention to things like side-channel
attacks. It's easier to restrict yourself to a limited
number of low-level building blocks and to build
everything you need out of those.

Also, even on fast platforms with lots of memory,

like desktop CPUs, implementing low-level
crypto operations directly in hardware can be
much faster than doing them in software — but
it's not practical to do that for more than a few of
them. Due to their versatility, block ciphers are
excellent candidates for hardware implementation
(as in the AES instruction set for modern x86
CPUs).

What about stream ciphers, then?

Mathematically, a stream cipher — in the most

general sense of the term — is also a keyed
invertible pseudorandom function family, but on
the set {0,1}∗ of arbitrary-length bitstrings
rather than on blocks of limited length.

(There are some subtleties here; for example,

most stream cipher constructions require the
input to include a unique nonce value, and do not
guarantee security — in the sense of
indistinguishability from a truly random function
— if the same nonce is used for two different
inputs. Also, as there is no uniform distribution
on invertible functions from {0,1}∗ to itself to
choose random functions from, we need to define
carefully just what it means for a stream cipher to
look "indistinguishable from random", and this
definition does have practical security
implications — for example, most stream ciphers
leak the length of the message. Practically, we
usually also require that stream ciphers, in fact,
be "streaming", in the sense that arbitrarily long
input bitstreams can be encrypted — and
decrypted — using only constant storage and
time linear in the message length.)

Of course, stream ciphers are much more

immediately useful than block ciphers: you can
use them directly to encrypt messages of any
length. However, it turns out that they're also
much less useful as building blocks for other
cryptographic tools: if you have a block cipher,
you can easily turn it into a stream cipher,
whereas turning an arbitrary stream cipher into a
block cipher is difficult if not impossible.

So why do people bother designing dedicated

stream ciphers at all, then, if block ciphers can do
the job just as well? Mostly, the reason is speed:
sometimes, you need a fast cipher to encrypt lots
of data, and there are some really fast dedicated
stream cipher designs out there. Some of these
designs are also designed to be very compact to
implement, either in software or hardware or
both, so that if you really only need a stream
cipher, you can save on code/circuit size by using
one of those ciphers instead of a general block
cipher based one.

However, what you gain in speed and

compactness, you lose in versatility. For
example, there doesn't seem to be any simple way
to make a hash function out of a stream cipher, so
if you need one of those (and you often do,
because hash functions, besides being useful on
their own, are also common building blocks for
other crypto tools), you'll have to implement
them separately. And, guess what, most hash
functions are based on block ciphers, so if you
have one, you might as well reuse the same block
cipher for encryption too (unless you really need
the raw speed of the dedicated stream cipher).

answered Sep 22 '12 at

15:17

shareimprove this
answer

Ilmari Karonen
14.3k11461

I questioned whether it is necessary to have two

different terms. According to what you
explained, a stream cipher is simply a special
case of a block cipher, i.e. one for the limiting
    
case where the n in the set {0,1}^n is 1. So I
would argue for not maintaining the current
distinction of terminologies. –  Mok-Kong Shen
Sep 22 '12 at 15:42

@Mok-KongShen Actually, a stream cipher is

not simply a block cipher with block size 1 (other
than classic monoalphabetic ciphers, which can
be assumed to be both). A stream cipher usually
translates the bits/bytes/... of the stream
     differently, depending on the current internal
state of the cipher, while a block cipher for
same input has same output (and thus is usually
used in a "mode of operation" to create a
stream cipher). –  Paŭlo Ebermann♦ Sep 22 '12
at 15:57

     @PauloEbermann. IMHO you answered for me

a question of CodesinChaos conscerning
"dynamics and variability". –  Mok-Kong Shen
 Sep 22 '12 at 16:50

@Mok-KongShen No he didn't. The only

advantage a dedicated stream cipher has over a
block cipher in an appropriate mode is
     performance. You can't disregard chaining
modes, since nobody sane uses block ciphers
without appropriate chaining. –  CodesInChaos
Sep 22 '12 at 17:48

@CodesInChaos. Different applications have

different performance requirements. To encrypt
e.g. an email, one doesn't need the
    
performance that would be desirable for
encryption of, say, a video-file. –  Mok-Kong
Shen Sep 22 '12 at 18:02

show 1 more comment

A block cipher by itself does map n bits to n bits using a key. i.e. it's a keyed pseudo-
random permutation. It cannot accept longer or shorter texts.

To actually encrypt a message you always need a chaining mode. ECB is one such
chaining mode(and a really bad one), and it's not the pure block cipher. Even ECB
consists of "add-on processing operations". These chaining modes can have quite
different properties.

One of the most popular chaining modes, Counter mode (CTR) constructs a
up vote 5 synchronous stream cipher from a block cipher. Another mode, CFB constructs a self
down synchronizing stream cipher, with properties somewhere between those of CBC and a
vote synchronous stream cipher.

So your assumption that there are no ciphers between stream and blockciphers isn't
really true. Cryptographers just prefer building them from the well understood block
cipher primitive, instead of creating a completely new system.

I'd call Vigenère a stream cipher, albeit one with a much too short period. It uses a 26
symbol encoding instead of a 2 symbol encoding, but that doesn't mean it's not a stream
cipher. Look at Solitaire/Pontifex for a modern construction of a stream cipher with 26
symbols.

v
 Description of IDEA
Let the four quarters of the plaintext be called A, B, C, and D, and the 52 subkeys called K(1)
through K(52).

Before round 1, or as the first part of it, the following is done:

Multiply A by K(1). Add K(2) to B. Add K(3) to C. Multiply D by K(4).

Round 1 proper consists of the following:

Calculate A xor C (call it E) and B xor D (call it F).

Multiply E by K(5). Add the new value of E to F.

Multiply the new value of F by K(6). Add the result, which is also the new value of F, to E.

Change both A and C by XORing the current value of F with each of them; change both B
and D by XORing the current value of E with each of them.

Swap B and C.

Repeat all of this eight times, or seven more times, using K(7) through K(12) the second
time, up to K(43) through K(48) the eighth time. Note that the swap of B and C is
performed after round 8.

Then multiply A by K(49). Add K(50) to B. Add K(51) to C. Multiply D by K(52).