From: Mok-Kong Shen on
Hi,

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
From: Jose Sanchez on
Mok-Kong Shen wrote:
> Hi,
>
> 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

You can sit here trying to explain imaginary, hand-waiving ideas or
else you can state something concrete and try to prove something about
it. If you want to be scientific about it, do the latter.

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!
From: Mok-Kong Shen on
Jose Sanchez wrote:
[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