Cryptosystem ME6 — User Manual
Chapter 5: Testing Cryptosystem ME6

5.1 The reliability test
Cryptosystem ME6 incorporates a test to demonstrate its reliability experimentally by encrypting and decrypting any number of files with randomly generated keys and checking that the result of decryption is the same as what was encrypted.

To perform the built-in reliability test first create a subfolder on a fixed disk (not a disk in drive A: or B:) called me6test (this can be a subfolder of a folder), then copy several files into it. You can use any number of files, of any size and type. Rename the files so that they all have extension .tst. (You can use the command rename  *.*  *.tst at a command line prompt).

Specify the operation as encryption, specify the me6test folder as the input folder and specify the input files as *.tst.

Specify some encryption key (either at the keyboard or by means of a keyfile) then click on Do it!

The reliability test has two forms, depending on whether you have specified that output files should be the same as input files or not.

If Output file(s) same? is No then when you click on Do it! a window such as the following appears:

Specify the number of times to perform the test (1 through 999) then click on Continue. ME6 will then encrypt all the *.tst files in the me6test folder to *.enc files, then it will decrypt all those files to *.dec files, then it will compare the *.dec files to the *.tst files.

If Output file(s) same? is Yes then when you click on Do it! a window such as the following appears:

As before, specify the number of times to perform the test (1 through 999) then click on Continue. ME6 first copies all specified *.tst files in the me6test folder to *.bak files. It then encrypts the *.tst files (the encrypted files have the same names as the original files) then decrypts them. ME6 then compares the resulting *.tst files with the original *.bak files.

The first performance of the reliability test uses the encryption key specified. If more than one test is performed then the tests after the first use randomly-generated keys.

If the file produced by decryption is not identical to the original plaintext file then ME6 immediately stops with an error message and displays the key being used.

If a hundred files are copied into the me6test folder, and the reliability test is performed a hundred times, and all 10,000 encryptions and decryptions reproduce the original plaintext then this is evidence that ME6 will always recover the original plaintext when decrypting an encrypted file. Since the completion of ME6 the test has been run hundreds of thousands of times with no failure.

5.2 Statistical tests
Ideally a cryptosystem should generate ciphertext which is indistinguishable from a sequence of randomly generated bytes. Such a sequence has the property that, given an initial segment (no matter how long) it is not possible to guess the next byte with a probability of success of greater than 1/256. In other words, complete knowledge of the sequence up to a certain point provides no information concerning the bytes which follow in the sequence.

For example, suppose a sequence of bytes was such that twice as many 1 bits occurred as 0 bits (among the bits making up the bytes). In this case, when asked to guess the next byte in the sequence, you are likely to be right more often than not if you choose a byte with more 1 bits than 0 bits. Thus a truly random sequence of bytes should have about as many 0 bits as 1 bits (though it is not likely to have exactly the same number of each).

Ciphertext produced by ME6 has been subjected to a number of statistical tests in an attempt to find some regularity that would distinguish it from randomly generated bytes. No such regularity has been found. Some of the tests applied to ME6 ciphertext are described below, with sample results.

In order to investigate whether statistical regularities in the plaintext carry over into statistical regularities in the ciphertext it is best to start with plaintext which consists of highly patterned bytes and which uses a key which is uniform. This minimizes the contribution of the irregularities of the plaintext to the randomness of the ciphertext.

Cryptosystem ME6 compresses the plaintext when possible (which is usually the case). This compression eliminates most regularities in the plaintext, and thus works against the purpose of this test, which is to see whether the encryption process itself removes all pattern. Thus in this test a version of the ME6 software was used which does not compress the plaintext (and which also does not interchange the two halves of each block, as described in 2.2.1 of Section 2.2).

For this test (and for the other tests described below) three files were created, each consisting only of repetitions of the 32-byte sequence AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH, their lengths being exactly 4 KB, 64 KB and 1024 KB. When viewed with a hex editor the first 256 bytes of each of these files looks like this:

Each file was encrypted using the 16-byte key PPPPPPPPPPPPPPPP (the hexadecimal representation of P is 50 and its binary representation is 01010000). The randomness measures for the plaintext files and for the encrypted files (with and without compression) are given below.

(a) Randomness

The randomness measures were as follows:

The plaintext:

                File    Size in bytes     Randomness
             4k1.tst            4,096          0.182
            64k1.tst           65,536          0.134
          1024k1.tst        1,048,832          0.106

The ciphertext (without compression):

                File    Size in bytes     Randomness
             4k1.en0            4,439          0.939
            64k1.en0           68,105          0.945
          1024k1.en0        1,089,368          0.947

The ciphertext (with compression):

                File    Size in bytes     Randomness
             4k1.en1              994          0.952
            64k1.en1           10,046          0.952
          1024k1.en1          161,387          0.940

These randomness values show that the ciphertext appears as if composed of randomly generated bytes (whether or not compression is used).

The first 256 bytes of 4k1.en0 look like this:

The graphical displays of randomness for the three ciphertext files (without compression) are:

(b) Byte frequency

One can count the frequency with which byte values occur in the three ciphertext files. The 20 most-frequent byte values are as follows:

File 4k1.en0 contains 4439 bytes and 256 different byte values.
  Rank     Byte      Frequency   ASCII value
    1   126 = 0x7E          30      ~
    2   164 = 0xA4          30
    3    57 = 0x39          27      9
    4    35 = 0x23          26      #
    5   128 = 0x80          26
    6   221 = 0xDD          26
    7   135 = 0x87          25
    8   171 = 0xAB          25
    9    69 = 0x45          24      E
   10    76 = 0x4C          24      L
   11   187 = 0xBB          24
   12    46 = 0x2E          23      .
   13    48 = 0x30          23      0
   14    54 = 0x36          23      6
   15    77 = 0x4D          23      M
   16    84 = 0x54          23      T
   17   124 = 0x7C          23      |
   18   184 = 0xB8          23
   19   193 = 0xC1          23
   20   210 = 0xD2          23

File 64k1.en0 contains 68105 bytes and 256 different byte values.
  Rank     Byte      Frequency   ASCII value
    1     5 = 0x05         327
    2    36 = 0x24         312      $
    3    99 = 0x63         307      c
    4   182 = 0xB6         302
    5    75 = 0x4B         301      K
    6    22 = 0x16         299
    7   250 = 0xFA         299
    8     0 = 0x00         298      null
    9     8 = 0x08         298
   10   143 = 0x8F         298
   11   188 = 0xBC         298
   12   236 = 0xEC         298
   13   120 = 0x78         296      x
   14   145 = 0x91         294
   15   247 = 0xF7         294
   16    28 = 0x1C         293
   17    53 = 0x35         293      5
   18   187 = 0xBB         293
   19   135 = 0x87         292
   20   195 = 0xC3         292

File 1024k1.en0 contains 1089368 bytes and 256 different byte values.
  Rank     Byte      Frequency   ASCII value
    1   203 = 0xCB        4395
    2   236 = 0xEC        4394
    3    12 = 0x0C        4393      formfeed
    4   174 = 0xAE        4388
    5   193 = 0xC1        4383
    6   108 = 0x6C        4380      l
    7    94 = 0x5E        4376      ^
    8    10 = 0x0A        4373      linefeed
    9   206 = 0xCE        4367
   10   214 = 0xD6        4365
   11    99 = 0x63        4362      c
   12   250 = 0xFA        4362
   13   209 = 0xD1        4359
   14    29 = 0x1D        4354
   15    91 = 0x5B        4354      [
   16   146 = 0x92        4354
   17   102 = 0x66        4351      f
   18   151 = 0x97        4348
   19   160 = 0xA0        4347
   20    21 = 0x15        4345

The byte values are thus distributed uniformly, which is what we would expect for ciphertext in which the bytes appear to be random.

(c) Bit comparison

The 4k1.en0 and 64k1.en0 were analysed as to their bit counts (1024k1.en0 was too large for the analysis program), not only for total bit counts but also for bit counts for the 8 positions within a byte. The results were:

4k1.en0 is 4439 bytes long.
Number of zero bits = 17949
Number of  one bits = 17563
Difference = 386, 1.087% of total bits
bit posn       7       6       5       4       3       2       1       0
  0 bits    2276    2252    2210    2240    2207    2265    2253    2246
  1 bits    2163    2187    2229    2199    2232    2174    2186    2193
   0 - 1     113      65     -19      41     -25      91      67      53
 % total   2.546   1.464  -0.428   0.924  -0.563   2.050   1.509   1.194

64k1.en0 is 68105 bytes long.
Number of zero bits = 273376
Number of  one bits = 271464
Difference = 1912, 0.351% of total bits
bit posn       7       6       5       4       3       2       1       0
  0 bits   34186   34373   34440   34043   33979   34115   34058   34182
  1 bits   33919   33732   33665   34062   34126   33990   34047   33923
   0 - 1     267     641     775     -19    -147     125      11     259
 % total   0.392   0.941   1.138  -0.028  -0.216   0.184   0.016   0.380

Bytes which are truly randomly generated should have about as many 0 bits as 1 bits. In ME6-ciphertext the number of 0 bits is in fact found to be close to the number of 1 bits, even for the individual bit positions within a byte, so this statistical test, like the others, does not distinguish ME6 ciphertext from randomly generated bytes.

(d) Kappa test

The kappa test is designed to detect repetitions of bytes at specified offsets in a file. Suppose that the elements of the ciphertext are any of the 256 possible bytes (0 through FF in hexadecimal). Consider the ciphertext to be a sequence of bytes (in a row). Now duplicate this sequence and place it beneath the first (with the first byte of the first sequence directly above the first byte of the second sequence). We now have a sequence of pairs of identical bytes. Slide the lower sequence to the right a certain distance, say, 8 places. Then count how many pairs there are in which the bytes are identical. If the sequence of bytes were truly random then we would expect about 1/256 of the pairs to consist of identical bytes, i.e., about 0.39% of them. We may analyse a file, calculating the indices of coincidence (also known as the kappa values) for one or more displacement values (a.k.a offset).

When we run such a program on ordinary English text we obtain values such as the following ("IC" stands for "index of coincidence"):

                  Offset    IC      coincidences
                   1      5.85%     2397 in 40968
                   2      6.23%     2551 in 40967
                   3      9.23%     3780 in 40966
                   4      8.31%     3406 in 40965
                   5      7.91%     3240 in 40964
                   6      7.88%     3227 in 40963
                   7      7.78%     3187 in 40962
                   8      7.92%     3244 in 40961
                   9      8.24%     3377 in 40960
                  10      7.98%     3268 in 40959
                  11      8.16%     3341 in 40958
                  12      8.09%     3315 in 40957
                  13      8.15%     3337 in 40956
                  14      7.97%     3264 in 40955
                  15      7.97%     3265 in 40954
                  16      8.07%     3306 in 40953
                  17      8.04%     3293 in 40952
                  18      7.85%     3214 in 40951

Typically only 80 or so different byte values occur in a file of English text. If these byte values occurred randomly then we would expect an index of coincidence for each displacement of about 1/80, i.e. about 1.25%. However, the distribution of characters in English text is not random ("e", "t" and the space character occur most frequently), which is why we obtain the larger IC values shown above.

The kappa test can be useful in breaking a weak cryptosystem. The index of coincidence for the displacement equal to the length of the encryption key will sometimes be significantly higher than the other indices, in which case one can infer the length of the key.

The offset value that is most likely to produce anomalies, in the case of ME6 ciphertext is the key size, in this case 16. The results of running the kappa test on the file 4k1.en0, testing all offset values from 1 through 512, are as follows:

Offset       IC       coincidences
     1      0.41%     18 in 4405
     2      0.45%     20 in 4404
     3      0.41%     18 in 4403
     4      0.39%     17 in 4402
     5      0.43%     19 in 4401
     6      0.43%     19 in 4400
     7      0.43%     19 in 4399
     8      0.43%     19 in 4398
     9      0.34%     15 in 4397
    10      0.30%     13 in 4396
    11      0.36%     16 in 4395
    12      0.43%     19 in 4394
    13      0.39%     17 in 4393
    14      0.34%     15 in 4392
    15      0.52%     23 in 4391
    16      0.25%     11 in 4390
    17      0.23%     10 in 4389
    18      0.30%     13 in 4388
    19      0.27%     12 in 4387
    20      0.36%     16 in 4386
            ...
   502      0.33%     13 in 3904
   503      0.54%     21 in 3903
   504      0.10%     4 in 3902
   505      0.38%     15 in 3901
   506      0.41%     16 in 3900
   507      0.44%     17 in 3899
   508      0.38%     15 in 3898
   509      0.21%     8 in 3897
   510      0.39%     15 in 3896
   511      0.49%     19 in 3895
   512      0.31%     12 in 3894

Average IC = 0.38%.  256 different byte values occur; kappa-r(256) = 0.39%.

The highest IC values were:

Offset       IC       coincidences
   134      0.61%     26 in 4272
    59      0.62%     27 in 4347
   344      0.64%     26 in 4062
   157      0.64%     27 in 4249
   120      0.68%     29 in 4286
   105      0.70%     30 in 4301

The results of the kappa test for 64k1.en0, with displacements from 1 through 10,000, are as follows:

Offset       IC       coincidences
     1      0.42%     288 in 68176
     2      0.42%     285 in 68175
     3      0.42%     286 in 68174
     4      0.43%     293 in 68173
     5      0.39%     266 in 68172
     6      0.44%     299 in 68171
     7      0.37%     252 in 68170
     8      0.44%     297 in 68169
     9      0.39%     265 in 68168
    10      0.44%     301 in 68167
    11      0.40%     274 in 68166
    12      0.37%     251 in 68165
    13      0.43%     292 in 68164
    14      0.41%     281 in 68163
    15      0.42%     286 in 68162
    16      0.37%     254 in 68161
    17      0.44%     297 in 68160
    18      0.35%     236 in 68159
    19      0.40%     274 in 68158
    20      0.41%     281 in 68157
            ...
  9995      0.37%     215 in 58182
  9996      0.38%     223 in 58181
  9997      0.38%     220 in 58180
  9998      0.41%     237 in 58179
  9999      0.39%     228 in 58178
 10000      0.38%     219 in 58177

Average IC = 0.39%.  256 different byte values occur; kappa-r(256) = 0.39%.

The highest IC values were:

Offset       IC       coincidences
  2018      0.47%     310 in 66159
    34      0.47%     319 in 68143
   372      0.47%     322 in 67805
  6417      0.48%     294 in 61760
  5132      0.48%     304 in 63045
  6263      0.49%     303 in 61914

Thus the kappa test reveals no regularities in this ciphertext, even though the plaintext consisted solely of repetitions of AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH and the key was the uniform PPPPPPPPPPPPPPPP.

The absence of any apparent regularities resulting from the encryption method is thus to be expected also in the case where the plaintext is much more diverse (as in normal English text), redundancy is eliminated by compression, and the key is not uniform.

5.3 Single-bit change
(a) Single-bit change in the key

When evaluating an encryption program it is reasonable to ask whether the encryption method used is something as weak as a repeated exclusive-or cipher, in which the bytes of the key are repeatedly XOR'd against those of the plaintext. In a such a cryptosystem each byte of the ciphertext is affected only by the corresponding byte in the key and not by every byte in the key. In this case the system is generally easy to crack (by using the kappa test to determine the length of the key, say n, and then considering the n sets of bytes each consisting of only the bytes encypted by a particular byte in the key).

When an attempt is made to break a cryptosystem this test is likely to be one of the first to be performed, namely, take some known plaintext and encrypt it with slightly different keys and compare the resulting ciphertext to see whether a particular change in the key produces a particular change in the ciphertext. With a strong cipher a change of a single bit in the key will have a cascade effect, producing large changes in the resulting ciphertext.

In this test some plaintext is encrypted, using Cryptosystem ME6, by two keys which differ only in a single byte (and only in a single bit). As stated above, the file 4k1.tst was encrypted (without compression) using the key PPPPPPPPPPPPPPPP to produce the file 4k1.en0 (4406 bytes). 4k1.tst was then encrypted using the key PPPPPPPPPPPPPPPQ, which differs from the first key only in a single bit, to produce the file 4k1.en2 (4355 bytes).

When 4k1.en0 and 4k1.en2 are XORed the result is 4k1.xor, the first 256 bytes of which are:

4k1.xor has a randomness measure of 0.949:

The kappa values show no anomalies (the highest IC with all displacements from 1 through 512 being 0.72%) and the bit count of the 4355 bytes is:

4k1.xor is 4355 bytes long.
Number of zero bits = 17537
Number of  one bits = 17303
Difference = 234, 0.672% of total bits
bit posn       7       6       5       4       3       2       1       0
  0 bits    2254    2156    2224    2171    2215    2137    2130    2250
  1 bits    2101    2199    2131    2184    2140    2218    2225    2105
   0 - 1     153     -43      93     -13      75     -81     -95     145
 % total   3.513  -0.987   2.135  -0.299   1.722  -1.860  -2.181   3.330

so these bytes appears to be random and ME6 passes this test (i.e., a single-bit change in the key used to encrypt a file results in ciphertext so different that XORing it with the first ciphertext produces what appears to be random bytes).

(b) Single-bit change in the plaintext

In this test two pieces of plaintext, differing only in a single byte (and in a single bit), were encrypted using the same key.

The two files of plaintext were the file 4k1.tst and a file 4k2.tst (both 4096 bytes in size) differing only in one byte (and in one bit) at the middle of the file, byte 2048, which is an @ (ascii 40) instead of an A (ascii 41).

Again the key used for encryption was PPPPPPPPPPPPPPPP. The resulting ciphertext files, 4k1.en0 and 4k2.en0, each 4439 bytes in size, are identical in the first 2218 bytes except for one byte. Then differences begin to appear:

From byte 2720 onwards the two files are completely different:

Thus changing a single bit in the plaintext causes all bytes in all ciphertext sub-blocks (ciphertext segments) following the ciphertext sub-block corresponding to the plaintext sub-block in which it occurs to be different (except for chance coincidences) until the end of the block is reached. And not only different, but so different that the differences appear to be random.

Changing a bit in the plaintext affects only the ciphertext up to the end of the block in which it occurs. A change of one or more bits in one block of plaintext does not affect the ciphertext produced for other blocks of plaintext.

5.4 Common key cryptotext XOR
It is convenient to use a single encryption key to encrypt many different files (a different key for each file would be a little more secure but a lot more inconvenient). In some cryptosystems this may result in what is called a "cryptotext-cryptotext compromise", meaning that a comparison of the cryptotexts produced with a common encryption key provides useful information to an unauthorized decryptor.

It was shown above that the XOR of two ciphertext files produced with the same key from plaintext files which differ in a single byte consists of garbage from a point in the XOR a few hundred bytes after the position of the byte at which the two plaintext files differ.

In this test we took two quite different plaintext files (of similar length), encrypted them using the same key, formed the XOR and applied the bit count and kappa tests to the XOR. In this test the normal version of Cryptosytem ME6 (i.e., including compression) was used.

The first file was eng1.txt (52,294 bytes) and the second file was eng2.txt (47,829 bytes), each consisting solely of English text. The key was once more unto the breach, the encrypted files being named eng1.enc (32,271 bytes) and eng2.enc (29,198 bytes). These two files were XORed to produce eng.xor (29,198 bytes), whose first 256 bytes are:

eng.xor has a randomness measure of 0.954:

The bit count test applied to eng.xor produces:

eng.xor is 29198 bytes long.
Number of zero bits = 116155
Number of  one bits = 117429
Difference = -1274, -0.545% of total bits
bit posn       7       6       5       4       3       2       1       0
  0 bits   14292   14503   14556   14658   14536   14580   14547   14483
  1 bits   14906   14695   14642   14540   14662   14618   14651   14715
   0 - 1    -614    -192     -86     118    -126     -38    -104    -232
 % total  -2.103  -0.658  -0.295   0.404  -0.432  -0.130  -0.356  -0.795
Clearly the bit frequencies are uniform.

The kappa test applied to eng.xor, with offsets from 1 to 10,000 produces:

eng.xor is 29198 bytes long.

Offset       IC       coincidences
     1      0.42%     124 in 29197
     2      0.42%     123 in 29196
     3      0.41%     119 in 29195
     4      0.45%     130 in 29194
     5      0.36%     104 in 29193
     6      0.40%     116 in 29192
     7      0.36%     106 in 29191
     8      0.41%     120 in 29190
     9      0.37%     108 in 29189
    10      0.34%      99 in 29188
    11      0.43%     125 in 29187
    12      0.37%     109 in 29186
    13      0.38%     111 in 29185
    14      0.44%     129 in 29184
    15      0.38%     112 in 29183
    16      0.40%     118 in 29182
    17      0.50%     147 in 29181
    18      0.38%     111 in 29180
    19      0.41%     121 in 29179
    20      0.39%     114 in 29178
            ...
  9992      0.38%      73 in 19206
  9993      0.41%      79 in 19205
  9994      0.42%      81 in 19204
  9995      0.41%      78 in 19203
  9996      0.42%      80 in 19202
  9997      0.35%      67 in 19201
  9998      0.42%      80 in 19200
  9999      0.38%      73 in 19199
 10000      0.39%      75 in 19198

Average IC = 0.39%.  256 different byte values occur; kappa-r(256) = 0.39%.

The highest IC values were:

Offset       IC       coincidences
  1536      0.52%     144 in 27662
  9819      0.53%     103 in 19379
  8806      0.53%     109 in 20392
  8738      0.53%     109 in 20460
  6254      0.53%     121 in 22944
  2423      0.53%     142 in 26775
  4291      0.56%     139 in 24907

Thus the kappa test reveals nothing remarkable in the XOR of the two ciphertext files produced using the same key.

5.5 Secret.enc
Anyone who doubts the security of the encryption algorithm used in Cryptosystem ME6 is free to try to recover the plaintext encrypted as secret.enc (it is a political analysis); this they will be unable to do.

Since secret.enc is 18,090 bytes long, if it were composed of randomly generated bytes then we would expect an average byte-value frequency of 70.66 with, of course, some variation among the 256 byte values. The byte-value frequency in fact ranges smoothly from 48 to 96 (whose average is 72). As the graphic at right shows, the randomness as 0.943.

The maximum kappa value for all offsets from 1 through 10,000 (for secret.enc) is 0.63% (kappa-256 = 0.39%). No information there either.


secret.enc is 18090 bytes long.
Number of zero bits = 72347
Number of  one bits = 72373
Difference = -26, -0.018% of total bits
bit posn       7       6       5       4       3       2       1       0
  0 bits    9062    9034    8981    9076    9005    9042    9102    9045
  1 bits    9028    9056    9109    9014    9085    9048    8988    9045
   0 - 1      34     -22    -128      62     -80      -6     114       0
 % total   0.188  -0.122  -0.708   0.343  -0.442  -0.033   0.630   0.000

The bit comparison test also gives no clue to assist an unauthorized decryptor.


Top of page Contents Cryptosystem ME6 Cryptography
Hermetic Systems Home Page