From: Mok-Kong Shen on 19 Nov 2009 10:35 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 24 Nov 2009 05:19 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 24 Nov 2009 15:04 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
|
Pages: 1 Prev: Noob Question about ENIGMA Next: Differential Privacy vs. Indistinguishable Encryption |