🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

8 total messages Started by Gerald Strom Sat, 25 Jul 1992 19:23
transposition ciphers
#502
Author: Gerald Strom
Date: Sat, 25 Jul 1992 19:23
353 lines
13752 bytes
The following is a little piece I wrote recently about transposition
ciphers.  As I am far from being an expert in this field, I hope I
didn't get too much wrong and I would appreciate comments.


                   TRANSPOSITION CIPHERS

                      Gerald S. Strom
               University of Illinois at Chicago

     When Julius Caesar wanted to keep his messages from being read
by his enemies (and probably a few friends as well), he devised a simple
substitution cipher whereby one letter was replaced by another.  This
Caesar Cipher is not secure by the standards of today but interestingly,
the method used, substituting one letter or character for another in a
regular way, is still the fundamental basis for encipherment in modern
ciphers systems.  The DES system developed by the United States
government, the various public key ciphers systems, as well as the
German Enigma cipher cracked by Allen Turing during World War II
using one of the first computers are all substitution ciphers whereby
letters in the plain (or un-enciphered) text are replaced by different
letters or characters to create the cipher (or enciphered) text.
     The cipher described here differs fundamentally from the
substitution ciphers systems in that it does not rely on replacing one
letter with another.  Instead, it is a transposition cipher that relies on
scrambling the letters of the plain text in a random fashion so that the
enciphered file has the same characteristics as the plain text file.  This
makes it difficult to break because the normal statistical methods use
to break ciphers do not work.  The letter counts, for example, will be
identical in the plain and cipher text files and this means that one
cannot use letter count correlations to guess what letters may have been
substituted for another.
     How does a transposition cipher work?  After all, randomizing the
letters in a file as a means of enciphering is only useful if there is some
way that they can be unscrambled again to their original order.  This is
where one of the otherwise problematic properties of random number
generators is a great virtue.  This property is that as implemented on
modern computers, random number generators always return the same
series of quasi-random numbers if given the same seed value.  To see
how this property can be used in a cipher, consider as an example a
string of fixed length, say one made up of the first five letters of the
alphabet: a, b, c, d, and e.  Now generate five random numbers from a
given seed and number them from 0 to 4.  Now sort the random
numbers but keep the original numbering associated with each number.
These original numbering numbers are now in random order and can be
used as an string or (array) index to randomize the order of letters.  For
example, after sorting the original numbering numbers may be in the
following order (3, 1, 0, 4, 2).  If this string of numbers is placed in an
array r, then encipherment takes place according to the following
formula:
 enciphered_text[i] = original_text[r[i]] (for i = 0 to 4)
Thus the original abcde string is now dbaec in the enciphered_text
string.
     Deciphering the enciphered text is simply the reserve of the
above operation.  Generate the same sequence of random numbers with
the same seed, number them and sort them.  This will result in
obtaining the same (3, 1, 0, 4, 2) sequence as above.  Now apply the
following formula:
 restored_text[r[i]] = enciphered_text[i] (for i = 0 to 4)
The first enciphered_text character is d so for i equal to zero above the
first character will be written into the fourth (base 0 remember)
position in restored_text (r[0] = 3), which is exactly where d should be.
     Listings 1 and 2 provide a simple implementation of this cipher
in ANSI C.  The first listing enciphers a file (but does not change the
file itself) and the second listing deciphers a file.  It can be seen that
there is a great deal of redundancy in the two listings and some may
choose to combine the routines into one file capable of both
encipherment and decipherment.
     There are several things to note about the implementation in the
listings. First, fixed size blocks of size 256 are used so that the program
actually randomizes the content of a file within blocks of 256 characters.
There is no particular reason why this block size was selected and
others, even variable ones based on some algorthim using the key, could
be used.   One factor to bear in mind, however, is that the programs
need to sort to both encrypt and decrypt and the length of the block will
have a significant impact on how long these sorts take.   In general, the
longer the block used, the longer program execution will take but the
more secure the encryption.  Readers may wish to try various block sizes
with various file sizes and determine if there is a general optimal block
size.  Remember though to use the same block sizes for encrypting and
decrypting.
     Second, note that the random number generator used is the
default rand() supplied with most compilers.  Similarly, this generator
is seeded with the standard srand().  Other generators would be used
but note that the int definition for num1 in the structure needs to be
changed to float if a floating point generator is used.  Actually, using
different random generators enhances the security because different
generators produce different sequences so that two files enciphered with
the same key but different generators will be enciphered differently.
     Third, the seed for the random number generator is derived in
the listings by adding the numeric values of the letters in the key to a
predetermined value (1947 in the listings).  This is obviously not a very
original or secure method and those interested in serious
implementations will want to use their creativity here, using a non-
obvious and "hard" method of deriving the seed from the key.
     One possibility is this regard is to use a random number generator
that takes a floating point number as a seed.  By using a creative
method of converting the integer values of the key letters into a floating
point number, the possible seeds becomes effectively infinite and
precludes the possibility of a brute force attempt to find the key.
     Fourth, a routine not implemented in the listings is to waste
some predetermined number of the random numbers before saving
those that will be used in the letter randomization.  This could be done,
for example, by predetermining a fixed number of times to execute a
loop calling the random number sub-routine or by varying this number
for different files based upon the key.
     Finally, note that all files are opened for reading or writing in
binary so that it is possible to encipher text files, executable files (i.e.
.EXE and .COM files) and archive or compressed files.  In fact, by first
compressing a file and then randomizing the content of the resulting
archive significantly increases the security of the encrypted file.
                              /*  LISTING 1
                          ENCRYPTION ROUTINE  */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX         512
#define NAME_SIZE   30
#define BLOCK_SIZE  256

typedef struct {
          unsigned int num1;
          int num2;
          } rnums;

void encrypt(FILE *, FILE *);
void no_memory(void);
int comp(rnums *, rnums *);
void reorder(int, int *);
FILE *open_file(char *, char *);

void main()
{
     char *key, *filein, *fileout;
    int i, seed = 1947;
     FILE *fin, *fout;

     if ((filein = malloc(NAME_SIZE)) == NULL)
          no_memory();
     if ((fileout = malloc(NAME_SIZE)) == NULL)
          no_memory();
     if ((key = malloc(MAX)) == NULL)
          no_memory();

     fprintf(stdout, "\nEnter name of input file: ");
     scanf("%s", filein);
     fprintf(stdout, "\nEnter name for output file: ");
     scanf("%s", fileout);
     fprintf(stdout, "\nEnter encryption key (256 max; ENTER ends): ");
     scanf("%s", key);

     fin = open_file(filein, "rb");
     fout = open_file(fileout, "wb");

    for (i = 0; i < strlen(key); i++)
        seed += *(key + i);
    srand(seed);
     encrypt(fin, fout);
    fclose(fin);
    fclose(fout);
}
void encrypt(FILE *fin, FILE *fout)
{
     register int i;
     int j, block_length, *source, *rnum;

     if ((source = malloc(MAX * sizeof(int))) == NULL)
          no_memory();
     if ((rnum = malloc(MAX * sizeof(int))) == NULL)
          no_memory();

     i = 0;
     block_length = BLOCK_SIZE;
     while (!feof(fin)) {
        if ((*(source + i) = fgetc(fin)) != EOF) {
                if (++i == block_length) {
                     i = 0;
                     reorder(block_length, rnum);
                     for (j = 0; j < block_length; j++)
                         putc(*(source + *(rnum + j)), fout);
                }
          }
          else {
                reorder(i, rnum);
                for (j = 0; j < i; j++)
                     putc(*(source + *(rnum + j)), fout);
          }
     }
}
void reorder(int n, int *num)
{
     int i;
     rnums rand_struct[MAX];

     for (i = 0; i < n; i++) {
        rand_struct[i].num1 = rand();
          rand_struct[i].num2 = i;
     }
     qsort(rand_struct, n, sizeof(rnums), comp);
     for (i = 0; i < MAX; i++)
          *(num + i) = rand_struct[i].num2;

}
int comp(rnums *e1, rnums *e2)
{
     if ((e1->num1 - e2->num1)> 0)
          return 1;
     else if ((e1->num1 - e2->num1) < 0)
          return -1;
     else
          return 0;
}
FILE *open_file(char *name, char *type)
{
     FILE *fp;

     if ((fp = fopen(name, type)) == NULL) {
          fprintf(stdout, "\ncannot open %s\n", name);
          exit(1);
     }
     return fp;
}
void no_memory(void)
{
     puts("\nCannot allocate memory -- Aborting\n");
     exit(1);
}
                              /* LISTING 2
                          DECRYPTION ROUTINE  */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX         512
#define NAME_SIZE   30          /* In case anyone has a long path */
#define BLOCK_SIZE  256

typedef struct {
          unsigned int num1;
          int num2;
          } rnums;

void decrypt(FILE *, FILE *);
void plant_seed(char *);
void no_memory(void);
int comp(rnums *, rnums *);
void reorder(int, int *);
FILE *open_file(char *, char *);

void main()
{
     char *key, *filein, *fileout;
    int i, seed = 1947;
     FILE *fin, *fout;

     if ((filein = malloc(NAME_SIZE)) == NULL)
          no_memory();
     if ((fileout = malloc(NAME_SIZE)) == NULL)
          no_memory();
     if ((key = malloc(MAX)) == NULL)
          no_memory();

     fprintf(stdout, "\nEnter name of input file: ");
     scanf("%s", filein);
     fprintf(stdout, "\nEnter name for output file: ");
     scanf("%s", fileout);
     fprintf(stdout, "\nEnter encryption key (256 max; ENTER ends): ");
     scanf("%s", key);

     fin = open_file(filein, "rb");
     fout = open_file(fileout, "wb");

    for (i = 0; i < strlen(key); i++)
        seed += *(key + i);
    srand(seed);
    decrypt(fin, fout);
    fclose(fin);
    fclose(fout);
}
void decrypt(FILE *fin, FILE *fout)
{
     register int i;
     int j, block_length, *source, *destination, *rnum;

     if ((source = malloc(MAX * sizeof(int))) == NULL)
          no_memory();
     if ((destination = malloc(MAX * sizeof(int))) == NULL)
          no_memory();
     if ((rnum = malloc(MAX * sizeof(int))) == NULL)
          no_memory();

     i = 0;
     block_length = BLOCK_SIZE;
     while (!feof(fin)) {
        if ((*(source + i) = fgetc(fin)) != EOF) {
                if (++i == block_length) {
                     i = 0;
                     reorder(block_length, rnum);
                     for (j = 0; j < block_length; j++)
                          *(destination + *(rnum + j)) = *(source + j);
                     for (j = 0; j < block_length; j++)
                          putc(*(destination + j), fout);
                }
          }
          else {
              reorder(i, rnum);
              for (j = 0; j < i; j++)
                *(destination + *(rnum + j)) = *(source + j);
              for (j = 0; j < i; j++)
                putc(*(destination + j), fout);
          }
     }
}
void reorder(int n, int *num)
{
     int i;
        rnums rand_struct[MAX];

     for (i = 0; i < n; i++) {
        rand_struct[i].num1 = rand();
          rand_struct[i].num2 = i;
     }
     qsort(rand_struct, n, sizeof(rnums), comp);
     for (i = 0; i < MAX; i++)
          *(num + i) = rand_struct[i].num2;

}
int comp(rnums *e1, rnums *e2)
{
     if ((e1->num1 - e2->num1)> 0)
          return 1;
     else if ((e1->num1 - e2->num1) < 0)
          return -1;
     else
          return 0;
}
FILE *open_file(char *name, char *type)
{
     FILE *fp;

     if ((fp = fopen(name, type)) == NULL) {
          fprintf(stdout, "\ncannot open %s\n", name);
          exit(1);
     }
     return fp;
}
void no_memory(void)
{
     puts("\nCannot allocate memory -- Aborting\n");
     exit(1);
}
Re: transposition ciphers
#504
Author: Jonathan Thornburg
Date: Sun, 26 Jul 1992 07:41
17 lines
1482 bytes
In article <92207.142318U27239@uicvm.uic.edu> Gerald Strom
<U27239@uicvm.uic.edu> writes:
>The following is a little piece I wrote recently about transposition
>ciphers.  As I am far from being an expert in this field, I hope I
>didn't get too much wrong and I would appreciate comments.
> [description and C code deleted]

Shouldn't you also point out that any transposition cipher can be
broken by multiple anagramming?  Kahn "The Codebreakers" discusses
this and gives a couple of examples of broken transposition ciphers,
I believe dating back to the US civil war and the 1884 (?) US
presidential election.

- Jonathan Thornburg
  <jonathan@einstein.ph.utexas.edu> or <jonathan@hermes.chpc.utexas.edu>
  University of Texas at Austin / Physics Dept / Center for Relativity
  and (for a few more months) U of British Columbia / {Astronomy,Physics}
Re: transposition ciphers
#508
Author: Jonathan Thornburg
Date: Sun, 26 Jul 1992 20:33
26 lines
1975 bytes
In article <92207.142318U27239@uicvm.uic.edu> Gerald Strom
<U27239@uicvm.uic.edu> writes [wrote]:
>The following is a little piece I wrote recently about transposition
>ciphers.  As I am far from being an expert in this field, I hope I
>didn't get too much wrong and I would appreciate comments.
> [description and C code deleted]

In article <1992Jul26.074121.15669@chpc.utexas.edu>
jonathan@chpc.utexas.edu (Jonathan Thornburg) [I] writes [replied]:
>Shouldn't you also point out that any transposition cipher can be
>broken by multiple anagramming?  Kahn "The Codebreakers" discusses
>this and gives a couple of examples of broken transposition ciphers,
>I believe dating back to the US civil war and the 1884 (?) US
>presidential election.

Oops, I must have missed a refresh cycle on my brain (this is what
comes of posting at 230am).  My statement was too strong.  I should
have said:
"Shouldn't you also point out that unless special precautions are
 taken to the contrary, transposition ciphers can be broken by
 multiple anagramming?"

- Jonathan Thornburg
  <jonathan@einstein.ph.utexas.edu> or <jonathan@hermes.chpc.utexas.edu>
  University of Texas at Austin / Physics Dept / Center for Relativity
  and (for a few more months) U of British Columbia / {Astronomy,Physics}
Re: transposition ciphers
#509
Author: jac54
Date: Mon, 27 Jul 1992 11:13
23 lines
1633 bytes
In article <1992Jul26.074121.15669@chpc.utexas.edu> jonathan@chpc.utexas.edu (Jonathan Thornburg) writes:
>In article <92207.142318U27239@uicvm.uic.edu> Gerald Strom
><U27239@uicvm.uic.edu> writes:
>>The following is a little piece I wrote recently about transposition
>>ciphers.  As I am far from being an expert in this field, I hope I
>>didn't get too much wrong and I would appreciate comments.
>> [description and C code deleted]
>
>Shouldn't you also point out that any transposition cipher can be
>broken by multiple anagramming?  Kahn "The Codebreakers" discusses
>this and gives a couple of examples of broken transposition ciphers,
>I believe dating back to the US civil war and the 1884 (?) US
>presidential election.
>
	Doesn't this only work with a route and/or block transpositions?
	When a transposition using a randomized mapping (transposition
	sites randomly assigned) it becomes much more difficult,
	especially if your map is a one-time pad.  Incidentally, there
	are only about 40 systematic routes through a 5x5 transposition
	block.  I tried working them out once, it's very character-
	building.

	Alec Chambers.
Re: transposition ciphers
#510
Author: Hal Feinstein
Date: Mon, 27 Jul 1992 13:56
31 lines
2204 bytes
>	Doesn't this only work with a route and/or block transpositions?
	(Stuff Deleted...)
>	Incidentally, there
>	are only about 40 systematic routes through a 5x5 transposition
>	Alec Chambers.


Transposition systems that were in use back during WWII used much larger
non-square type "blocks" for example 15 x 33 characters. The characters
were read off using some route that changed from message to message. The
one I looked at used a key word derived from a common book.  The key word
expands into instructions on how to select characters from the grid.
The grid contained lots of nulls that made things more difficult to solve.

Double transposition seems to have enjoyed a vogue up until sometime in the
'50. Spys seems to have liked it in WWII, the German Secret Service for one.
One account says that with the introduction of the computers most  
transposition systems became insecure. Experts I talk to doubt that any 
transposition system arse useful except perhaps for low grade tactical 
use.

Lance Hoffman, a Prof down here at
Geo Washington Univ and author of security books thinks that 
transpositions are probabily adaquate for business privacy use (*but not all 
cases*) .  It keeps non-experts out and given the pain of decrypting one 
of these, as a hacker I would probabily not bother fooling  with a files or 
messages so rearranged. 
 
A point of triva: back in '73 one of the ciphers submitted to NBS as a 
candidate for a national data encryption standard was a multiple transposition 
cipher. It didn't win. 
Re: transposition ciphers
#512
Author: Carl Ellison
Date: Mon, 27 Jul 1992 15:21
24 lines
1778 bytes
In article <92207.142318U27239@uicvm.uic.edu> U27239@uicvm.uic.edu (Gerald Strom) writes:
>This Caesar Cipher is not secure by the standards of today but
>interestingly, the method used, substituting one letter or character for
>another in a regular way, is still the fundamental basis for encipherment
>in modern ciphers systems.  The DES system developed by the United States
>government, the various public key ciphers systems, as well as the German
>Enigma cipher cracked by Allen Turing during World War II using one of the
>first computers are all substitution ciphers whereby letters in the plain
>(or un-enciphered) text are replaced by different letters or characters to
>create the cipher (or enciphered) text.

This is an inaccurate statement.  It gives the impression that all these
systems operate on individual characters and are as insecure as Caesar.

A transposition over, say, 25-byte blocks is a substitution just as DES is
a substitution over 8-byte blocks -- only the transposition is simpler.

A one time pad is a substitution cipher -- and about as secure as you can
get.

A self-inverse transposition was posted here a month or two ago --
operating over large blocks (up to 8K).  With FFT techniques, we can build
a much larger block DES -- eg., operating on 8K blocks.  I would prefer
the large DES over a large transposition.
Re: transposition ciphers
#421
Author: Gordon Burditt
Date: Tue, 04 Aug 1992 05:36
11 lines
994 bytes
Note that transposition ciphers can leak information in ways you
wouldn't expect.  Consider, for example, encrypted messages coming
in and out of Bush campaign headquarters.  Both a certain vice
president worried about his job and the opposition party could deduce
a lot simply from the presence or absence of the letter capital Q
in the messages.  With short messages (a few hundred characters) you 
could sometimes deduce phrases like 'health care', 'abortion', or 
'gun control' that could NOT be in the message.  

					Gordon L. Burditt
					sneaky.lonestar.org!gordon
Re: transposition ciphers
#449
Author: grady
Date: Fri, 07 Aug 1992 01:23
24 lines
1057 bytes
On the topic of traffic analysis and information
leakage, one of my customers for one of my
lexical databases, Moby Part-of-Speech, lives
at:

Finance and Accounting Office
P.O. Box 1685
Fort George G. Meade, MD 20755-6000


Duh... I wonder who this is :-)


Now for the traffic analysis: does this
mean my product is _new_ to them?  Do
they want to gloat over how superior
_their_ equivalent database is over mine?

Why did they get _this_particular database
over all my others...and why did it take them
this long to get it (since it was released
several years ago?

It's fun doing this to _them_ for a change. :-)
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads