1.1 Stream Cipher

Associated with a professional usage, the program in “enlarged” version is expanded fundamentally by the possibility of stream ciphering (see also “Processing Form and Statistics”). This means the possibility to store an achieved parameter state which can be reactivated and continued to code further datasets. In connection with that a set of parameters can be used potentially to encode as well as to decode data.

It’s true a “normal” parameter dataset used to store the state of stream ciphering isn’t a usual dataset but it is changed. This is because a recent parameter state is stored again in it at end. That is why you should make a copy of such a parameter dataset before processing to be able to fall back on a protected processing state. This copy can be deleted or can be overwritten by the new generated parameter dataset after successful processing.

Furthermore you have to take into account that you have to use different and therefore own parameter datasets both for encoding and decoding a data unit.

Stream ciphering should be used

§ first if you wish higher safety and

§ second if you want data transmission between two or more persons/offices involved using an uncertain and/or unsafe (public) connection (i.e. via internet).

Using stream ciphering the exchange of keys may be limited to a minimum. In contrary to the standard program which generates components at the beginning and in the following if a cycle of a pseudo random number process is finished (i.e. pseudo random numbers are repeated), you can control component exchanges in the expanded program (tightened up ciphering) more exactly.

In general the current internal operation key is used as an initial key to carry out a component exchange. Using the resulting components for coding, you have no possibility to generate the initial key in reverse processing (see “Examination of the Safety of the Algorithm in brief” too).

So if a set of components is compromised, all data coded before the last component exchange is not compromised but further data is.

To preserve the protection against compromising data coded after the next component exchange (naturally data coded with the compromised set of components is compromised too), it’s possible – if program works in highest cipher state – to “encode” the initial key by the components of a second parameter dataset, the component exchange parameter dataset, before a component exchange is carried out using this coded initial key.

To brake this barrier by an unauthorized third party (without any direct access to the component exchange parameter dataset), first an attacker has to compromise “plenty” of sets of components of the “normal” parameter dataset to have only basically a chance to get the set of components of the second parameter dataset.

Coding single datasets using stream ciphering, a component exchange is made at the beginning of every dataset.

If only the state of parameters of the component exchange parameter dataset is saved at end and all datasets are coded as one unit, a component exchange is made at the beginning of the processing of every unit. This is an absolute necessity to get adequate recovery points processing more than one unit (the intermediate state of the standard parameters can not be saved because there is no “normal” parameter dataset or this dataset may not be saved !).

If both a “normal” parameter dataset and a component exchange parameter dataset is used to save the processing state of stream ciphering and all datasets are coded as one unit, a component exchange is made at the beginning of the processing of the first unit. This is shown by the stream cipher usage value of the parameter dataset which indicates whether a parameter dataset is modified after initialisation or still in initial condition. This introduced component exchange is made to guarantee the dependency already of the first used set of components on the component exchange parameter dataset (afterwards it’s given automatically).