Combining stream and block encryption techniques
Mok-Kong Shen
In my humble understanding, in stream encryption each plaintext bit is
processed independent of the others, while in block encryption it is a
goal of the cipher design to maximize the interdependence of processing
of the plaintext bits in a block (of a certain length) such that there
is high avalanche effect in the resulting ciphertext bits of the block.
In stream encryption, the plaintext bits are xored with a stream of
(pseudo) random bits generated by a PRNG (e.g. a congruential generator
or a common block cipher in counter mode) and there is thus a 'state'.
while in a (common) block encryption the key is constant for the whole
message and hence there is no 'state'. (See however my thread "Dynamic
change of encryption keys".)
It seems intuitively clear that it may be beneficial to employ a more
general form of processing, encompassing both types of techniques in
an optimal synergy instead of restricting oneself to either pure
stream or pure block encryption depicted above. Thus one could have
a block as processing unit and apply all the hitherto known block
processing techniques as one likes but additionally include stream
processing techniques, using a PRNG to generate bit sequences to xor
the bits (plaintext bits, ciphertext bits and bits between the rounds).
Since a PRNG is assumed available, we could further use it to (1) do
random substitutions (random choice of Sboxes, generation of new
Sboxes), (2) do random permutations (of bits or larger units),
(3) effect dynamic change of encryption keys for the block.
Thanks,
M. K. Shen
Mok-Kong Shen
> It seems intuitively clear that it may be beneficial to employ a more
> general form of processing, encompassing both types of techniques in
> an optimal synergy instead of restricting oneself to either pure
> stream or pure block encryption depicted above. Thus one could have
> a block as processing unit and apply all the hitherto known block
> processing techniques as one likes but additionally include stream
> processing techniques, using a PRNG to generate bit sequences to xor
> the bits (plaintext bits, ciphertext bits and bits between the rounds).
> Since a PRNG is assumed available, we could further use it to (1) do
> random substitutions (random choice of Sboxes, generation of new
> Sboxes), (2) do random permutations (of bits or larger units),
> (3) effect dynamic change of encryption keys for the block.
For completeness it may be mentioned that the benefit (though with
a trade-off of processing cost) of (3) comes from the fact that
the analyst has to break each block "individually", since the keys
used for the different blocks are all different. Thus even assuming
that he has a method that could recover the key of a block with one
pair of plaintext and ciphertext (this excludes linear and differential
analysis but algebraic analysis claims to potentially have such
capability), the total work (since there are n keys to be cracked for
a message of n blocks) would be so large as to be practically infeasible
or economically unjustifiable.
M. K. Shen
Mok-Kong Shen
[snip]
> The common scrambling algorithm combines both a stream cipher and a
> block cipher. It looks wonderful, until you realize that if the
> message length is congruent to 7 mod 8, then the tail part only gets
> encrypted by the stream cipher. So, if you know the plaintext, then
> can you determine the stream cipher state and reverse it in order to
> get the original key (without having to touch the block cipher at
> all)? Maybe!
Could you please be a little bit concrete. Which 'common' scrambling
algorithm is that that you mentioned above? Could you say the name
and perhaps refer to a source?
Thanks,
M. K. Shen
Mok-Kong Shen
Note that the above argument assumes that (3) alone is used when a PRNG
(block algorithm in counter mode or congruential generator (with
preferably postprocessing), etc.) is employed. If one simultaneously
also uses some of the other measures mentioned in the first of the two
quotes above, then even the potential chance of success of algebraic
analysis (for each one single block) could be reduced to any desired
level of practical immunity. Note that the goal of all these suggested
measures could be subsumed unter what I would like to term as
'variability', which in our case is obtained at runtime via a PRNG. The
natural existence of a trade-off between desired security and processing
cost (which tends to be more and more affordable with the advancement
of technology) should of course be stressed here once again.
M. K. Shen