The big drawback with standard pseudo random generators is that they are easy to "break", that is, given a few consecutive random numbers, all parameters necessary to calculate the whole sequence of random numbers, are possible to figure out. Such consecutive random numbers may easily be found if standard files are encrypted. For example, the first two bytes in a bitmap file are normally "BM". In executable files, word processor documents and so, there are a whole lot of fixed, or easily guessed information, so given such a file encrypted with a standard pseudo random generator, and no additional favors, the data is very far from safe.

The reason for standard pseudo random generators to be so easliy broken is that the next pseudo random value is calculated only from the previous one (and a few parameters). This gives that whenever the same pseudo random value is received again, the generator has completed a full cycle, and any further values will be copies of this cycle. Also, the cycle length is normally quite short, so testing all possible start values is not impossible for a professional cryptanalyst. Finally, the statistical properties of these generators are not too good. From this, valuable information can be retrieved to simplify the search.

Having said this about pseudo random generators, how to motivate Ranrot in *Power Crypto*? First, Ranrot is far from a standard generator and lacks most of their deficiencies. Second, *Power Crypto* is able to make use of good cryptographic properties such as 'permutations', 'confusion', and 'diffusion' in various ways. Together, this will offer a very high level of security.

Ranrot is a family of methods published in 1999, from which **B3** is chosen in *Power Crypto*. All Ranrot methods have random cyclic length with a logarithmic distribution for well-chosen parameters. Extensive tests have been done by the author of Ranrot, showing that the cyclic lengths in all practical situations can be regarded as sufficient. From those tests, a number of practical design rules have been developed to fine-tune the algorithms and to avoid bad initial values. All these rules are implemented in *Power Crypto*.

For the calculation of the next value, three older are used, but not necessarily the three latest. Instead, an array of arbitrary many old values may be saved and chosen among. By ensuring the number of saved values and all relative positionings between the chosen elements are relative prime to each other, the time before the same three old values are used together again, is maximized.

A user-supplied key is used to initiate the array of old values. The biggest prime less than the length of the key is chosen as the number of saved old values. These values are of 4B of size, therefore, 4B (4 characters) from the key are used to initiate each old value.

The upper limit of key lengths is set by the Registry's restriction to store long strings. Normally, this restriction is around 16.000 characters (128.000 bits), which should be enough for any application. However, string keys in the Registry is just a matter of convinience, and has no importance for the functionality of *Power Crypto*. Using INI-files instead would remove the limit, but again, there is no real use for this.

A Key Generator is supplied that can generate keys of any length based on your mouse movements and the system time. Using long and complicated keys will add lot of 'confusion' to the process, that is, the relationship between the plain data and the encrypted data is hard to figure out.

For further information about Ranrot, see The Home Page of Ranrot.

Information about plain bytes that have been encrypted into certain bytes, is valuable information for a cryptanalyst. As shown above, an encryption "byte for byte" of a bitmap file, will reveal the two first generated random values, because the input data starts with "BM" and the two first output bytes are: "'B' + random value1 and 'M' + random value 2". Using Ranrot instead of a standard pseudo random generator will make this information far less valuable for a cryptanalyst, but nevertheless, it may be one of many pieces of information, and it might be the missing one.

However, *Power Crypto* uses Ranrot to scramble around the output bytes within each block of data. The user may choose whether the same (static) or different (dynamic) scrambling should be applied to different blocks. Also, the scrambling may be done more or less randomly. High randomness and dynamic scrambling is of course more powerful than low randomness and static scrambling, but the latter is faster.

As soon as permutations are used at some level, a lot of 'confusion' is added, with enhanced security as the result.

Spreading out the input data over a great part of the output data is another powerful method to upset cryptanalysts. That is, a change of a single byte in the plain data should result in changes of many bytes in the encrypted data.

where "None" means no such diffusion. "Some" is implemented by running Ranrot some extra steps after a block of data is encrypted but before the next block is cooped with. The number of extra steps is calculated as a sort of checksum of the data. This means that any change to a byte in a block will most likely result in Ranrot being in another state when the next block of data is encrypted (or decrypted). Therefore, all following blocks of data are affected by this change, to a relatively small amount of work. Changings close to the beginning of the plain data gives much more disturbances in the encrypted data, than if the changes come close to the end.

"All" is essentially implemented by running "Some" twice, the second time by reversing the input data stream, that is, the last byte is encrypted and written out first, the last but one comes out as number two, and so on. This will ensure that any changes in the plain data will affect all encrypted bytes, both before and after the changes. This will essentially double the work for *Power Crypto*, which also has to create a temporary file to store the result between the two sweeps (if the data comes from a file).

This kind of "diffusion", which very well may be used in parallel with the Permutations described above, will raise the security level for *Power Crypto* yet another step.

In the case of files, all bytes are normally encrypted, that is, to every byte is added a value between 0 and 255 (modulo 256). However, it is not necessary to work on all bytes, and in the case of text it is never done. Actually, the input data, whether it is plain or encrypted, is divided into two complementary sets, ENCRYPTED BYTES and NOT ENCRYPTED BYTES. Bytes that happen to belong to the first set are encrypted to another (or occasionally to the same) bytes in the same set, while bytes in the second set are left alone. This might be used, for example, on raw data files where only some data, perhaps the digits, are messed up with other digits, leaving any text alone. However, this is not normally the case. On the other hand, texts that are to be encrypted, copied, and pasted into emails will not work if all possible bytes are used. The null character (ASCII code = 0) is a typical byte that is hard to copy and paste. Unfortunately, many other bytes are also difficult to handle in various email programs. Therefore, as much as about 80, out of 256 bytes, have been removed from the standard set for encrypted bytes for text, because of problems with at least one of the more famous mail program. The problem may be that the byte is changed to another byte or simply removed.

There is also another type of problem: spaces, (horizontal) tabs and line breaks (SP, HT, CR, and LF). Email programs may insert line breaks if the lines are too long. They may also add spaces at the end of lines and replace tabs with spaces. This means that in the encrypted data, certain spaces may be encrypted data while others simply come for the email program. This is not acceptable for decryption. Therefore, SPs, HTs, CRs, and LFs are replaced by very uncommon characters within the set of encrypted characters before encryption, while SP, HT, CR, and LF themselves belong to the set of not encrypted characters. After encryption, there is no way to tell where to original spaces and line breaks have gone, but the are certainly no spaces, tabs or line breaks in the encrypted data. To make the data more manageable, line breaks are now introduced after every 72 byte. After copying, and pasting the data to and from email programs, extra line breaks and spaces may have been added. Therefore, before decryption starts, all spaces and line breaks are removed, because no one can originate from the real encrypted data.