Prev: Any recommendations for frequency analysis software?
Next: Linear Equivalence and Involutions
From: Maaartin on 16 Mar 2010 16:40
On Mar 16, 5:04 pm, Thomas Pornin <por...(a)bolet.org> wrote:
> According to J.D. <degolyer...(a)yahoo.com>:
> Maybe a better definition of stream cipher would be the following: a
> "stream cipher" is a symmetric encryption system such that, for a given
> key K, any sequence s of n bits can be encrypted into an n-bit output,
> without needing n to be a multiple of some value (e.g. 8 or 128), and
> such that the first r output bits, for all r < n, are also the output of
> the stream cipher with the same key K over the first r bits of s. In
> simpler words, any bit can be encrypted into another bit, without even
> knowing if there will be subsequent bits of input. This precludes
> "ciphertext stealing" from being considered as a way to get a stream
> cipher.
>
> Phelix is a self-synchronizing stream cipher.

But in the paper I see:
The plaintext P and ciphertext C are both sequences of bytes of the
same
length, with the restriction that 0 ≤ ℓ(P) < 264. Both are manipulated
as a
sequence of words, Pi and Ci, respectively. The last word of the
plaintext and
ciphertext might be only partially used. The “extra” plaintext bytes
in the
last word are taken to be zero. The “extra” ciphertext bytes are
irrelevant and
never used.

So it's not a stream cipher according to your definition. It can't be
used to encrypt e.g., 123 bits without making the output longer, can
it? But that's just nitpicking.

I've never seen a pair of definitions for stream and block ciphers,
which are clear, non-overlapping and include all symmetric ciphers.
For example, a block cipher in CBC mode is obviously a symmetric
cipher, but neither stream nor block cipher according to most
definitions I've seen.

Is Phelix really self-synchronizing? I don't see why and can't find
this claim either in the paper nor elsewhere.
From: Maaartin on 16 Mar 2010 16:42
On Mar 16, 5:04 pm, Thomas Pornin <por...(a)bolet.org> wrote:
> According to J.D. <degolyer...(a)yahoo.com>:
> Maybe a better definition of stream cipher would be the following: a
> "stream cipher" is a symmetric encryption system such that, for a given
> key K, any sequence s of n bits can be encrypted into an n-bit output,
> without needing n to be a multiple of some value (e.g. 8 or 128), and
> such that the first r output bits, for all r < n, are also the output of
> the stream cipher with the same key K over the first r bits of s. In
> simpler words, any bit can be encrypted into another bit, without even
> knowing if there will be subsequent bits of input. This precludes
> "ciphertext stealing" from being considered as a way to get a stream
> cipher.
>
> Phelix is a self-synchronizing stream cipher.

But in the paper I see:
The plaintext P and ciphertext C are both sequences of bytes of the
same
length, with the restriction that 0 ≤ ℓ(P) < 264. Both are manipulated
as a
sequence of words, Pi and Ci, respectively. The last word of the
plaintext and
ciphertext might be only partially used. The “extra” plaintext bytes
in the
last word are taken to be zero. The “extra” ciphertext bytes are
irrelevant and
never used.

So it's not a stream cipher according to your definition. It can't be
used to encrypt e.g., 123 bits without making the output longer, can
it? But that's just nitpicking.

I've never seen a pair of definitions for stream and block ciphers,
which are clear, non-overlapping and include all symmetric ciphers.
For example, a block cipher in CBC mode is obviously a symmetric
cipher, but neither stream nor block cipher according to most
definitions I've seen.

Is Phelix really self-synchronizing? I don't see why and can't find
this claim either in the paper nor elsewhere.
From: J.D. on 16 Mar 2010 18:06
@Maaartin

> I've never seen a pair of definitions for stream and block ciphers,
> which are clear, non-overlapping and include all symmetric ciphers.
> For example, a block cipher in CBC mode is obviously a symmetric
> cipher, but neither stream nor block cipher according to most
> definitions I've seen.

I don't see why the definitions for block and stream ciphers should
necessarily have to include all symmetric ciphers. It's not like we
are talking about block-ciphers and "non-block-ciphers". In that
vein, I do not consider block cipher _modes_ to themselves be block
ciphers (except arguably ECB mode) -- they are symmetric cipher
algorithms that use a block cipher as a component. But my use of the
terminology may be idiosyncratic in this regard...

> Is Phelix really self-synchronizing? I don't see why and can't find
> this claim either in the paper nor elsewhere.

Actually I don't think it is self-synchronizing, as generally that
means the key-stream is computed from previous ciphertext digits
(instead of from plaintext digits as in Phelix); and self-
synchronizing stream ciphers can recover from errors, while Phelix is
designed not to do so (because otherwise the authentication capability
would be lost). That said, I see nothing logically necessary about
stream ciphers having to be either "self-synchronizing" or
"synchronous"...

From: WTShaw on 19 Mar 2010 03:05
On Mar 16, 5:06 pm, "J.D." <degolyer...(a)yahoo.com> wrote:
> @Maaartin
>
> > I've never seen a pair of definitions for stream and block ciphers,
> > which are clear, non-overlapping and include all symmetric ciphers.
> > For example, a block cipher in CBC mode is obviously a symmetric
> > cipher, but neither stream nor block cipher according to most
> > definitions I've seen.
>
> I don't see why the definitions for block and stream ciphers should
> necessarily have to include all symmetric ciphers.  It's not like we
> are talking about block-ciphers and "non-block-ciphers".  In that
> vein, I do not consider block cipher _modes_ to themselves be block
> ciphers (except arguably ECB mode) -- they are symmetric cipher
> algorithms that use a block cipher as a component.  But my use of the
> terminology may be idiosyncratic in this regard...

Classification is the problem. Trying to force every cipher into one
of two categories can be misleading. As it goes ciphers can be complex
with a combination of primitives involve. I favor the category of
Hybrid as a catch-all, with possible new classifications that might
better describe one or certain related ciphers that might be grouped.
Having for many years discussed one area of ciphers that I have worked
with, the classification for em that is is both new and descriptive of
the process; the classification is Spiral with a narrow definition. I
see other possible classifications for ciphers that are outside of the
major two groups, but Hybrid is broad enough for many.

Block, stream, and spiral are sufficiently pure in meaning to be
recognizable in many cases. Can you suggest others that actually do
the same, really tell the story? Care should be made not to exclude
from classification ciphers that are not identical, like stream
ciphers include many possibilities beyond a very narrow definition
used previously in this thread. To use classification as a personal
tool to downgrade other related methods is extremely self-serving.
For instance, Spiral should suggest even new ideas we should all be
open to rather than to mark my territory. I y say that I found
something new, different, interesting, and productive, and related
efforts should be encouraged and not otherwise.
>


First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: Any recommendations for frequency analysis software?
Next: Linear Equivalence and Involutions