Cryptography-Digest Digest #226, Volume #14      Tue, 24 Apr 01 19:13:01 EDT

Contents:
  Re: XOR TextBox Freeware:  Very Lousy. (David Schwartz)
  Re: RSA-like primes p and q ("Tom St Denis")
  Re: Censorship Threat at Information Hiding Workshop (David Wagner)
  Re: Censorship Threat at Information Hiding Workshop ("Tom St Denis")
  Re: Security proof for Steak ("Henrick Hellström")
  Re: Security proof for Steak ("Tom St Denis")
  Re: Security proof for Steak ("Henrick Hellström")
  Re: Security proof for Steak ("Tom St Denis")
  Re: Delta patching of encrypted data ("Anon")
  Re: Censorship Threat at Information Hiding Workshop ("Roger Schlafly")
  primitive elements in GF(2^W) ("Tom St Denis")
  Re: Gurus:  Please show weaknesses in this (Brett)

----------------------------------------------------------------------------

From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: XOR TextBox Freeware:  Very Lousy.
Date: Tue, 24 Apr 2001 14:12:29 -0700


"David Formosa (aka ? the Platypus)" wrote:

> >       In any realistic application, the XOR function is
> > crackable. Generally,
> > you attack the means of distributing the OTP. The big flaw in XOR is it
> > shifts the burden of keeping the cipher secure from the cipher itself to
> > the user.
 
> Isn't this the rule of good crypto?  All streanth should be in the
> key?

        Then why use any crypto at all? If you had a way to distribute and
secure a key that was the same length and sensitivity as the plaintext,
just call the plaintext the key and send all zeroes over the unsecured
channel.

        DS

------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: RSA-like primes p and q
Date: Tue, 24 Apr 2001 21:30:10 GMT


"John Savard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 24 Apr 2001 12:54:43 GMT, "Tom St Denis"
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Yup.  In fact (p-1)/2 should be a large prime which simplifies the
> >description (and is more secure).  Of course making such primes takes an
> >awfully long time...
>
> Actually, it's not that bad. There's a downloadable program somewhere
> for finding Sophie Germain primes and similar numbers, and it works
> quite well.

I could write my own in about 3 minutes...  Or use maples safeprime ... :-)

Tom



------------------------------

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: 24 Apr 2001 21:30:56 GMT

Paul Pires wrote:
>As Donald Nash pointed out,
>copyright  theft is the stealing of ones labors or services that one has secured
>their rights to.

Once again, this is a misleading metaphor.  Theft of physical property
deprives the owner of the property.  "Theft" of intellectual property
may deprive the owner of the chance to get paid for another copy of the
IP, but doesn't deprive the owner of the original good.  Using the word
"theft" to refer to uncompensated copying of IP may be effective rhetoric
when trying to sway the public with soundbites, but to the better-informed
it is likely to simply come off as deceptive or disingenuous.  As always,
whoever establishes their metaphor in the public eyes is in a good position
to get their favorite laws passed, but such metaphors can be deceiving.

------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Tue, 24 Apr 2001 21:42:47 GMT


"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9c4rag$6n5$[EMAIL PROTECTED]...
> Paul Pires wrote:
> >As Donald Nash pointed out,
> >copyright  theft is the stealing of ones labors or services that one has
secured
> >their rights to.
>
> Once again, this is a misleading metaphor.  Theft of physical property
> deprives the owner of the property.  "Theft" of intellectual property
> may deprive the owner of the chance to get paid for another copy of the
> IP, but doesn't deprive the owner of the original good.  Using the word
> "theft" to refer to uncompensated copying of IP may be effective rhetoric
> when trying to sway the public with soundbites, but to the better-informed
> it is likely to simply come off as deceptive or disingenuous.  As always,
> whoever establishes their metaphor in the public eyes is in a good
position
> to get their favorite laws passed, but such metaphors can be deceiving.

Right on.  The biggest problem is that copying music without permission is
wrong, but what do you call it?  It's not theft for sure because as you
stated they get to keep their copy, but it's not legitimate since you didn't
acquire your copy lawfully.

Anyways, this is OT for this group, may I suggest follow-ups move to emails
or another group please?

Tom



------------------------------

From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 23:45:19 +0200

"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:jskF6.47671$[EMAIL PROTECTED]...
>
> "Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
> news:9c4ht3$sqo$[EMAIL PROTECTED]...
> > It is close to, but not really MDS. If I remember correctly, there is no
> > differential for the most significant byte input that will affect more
> than
> > 7 bits of the least significant byte output (the correct figure could be
> > read directly from the 4x256-dword matrix representation, should I be
> > wrong). This is a deliberate design choice:
>
> MDS design has nothing todo with bit level diffusion it's more abstract
than
> that.  If you have a 4x4 MDS transform the output/input difference must be
> in at least five components, etc..


Well, yes, but what I wrote implies (by the pidgeon hole principle) that the
matrix cannot be MDS. With our matrix, there has to be at least two
input/output pairs that differ in at most four bytes.


--
Henrick Hellström  [EMAIL PROTECTED]
StreamSec HB  http://www.streamsec.com



------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 21:48:25 GMT


"Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
news:9c4s7a$eba$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:jskF6.47671$[EMAIL PROTECTED]...
> >
> > "Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
> > news:9c4ht3$sqo$[EMAIL PROTECTED]...
> > > It is close to, but not really MDS. If I remember correctly, there is
no
> > > differential for the most significant byte input that will affect more
> > than
> > > 7 bits of the least significant byte output (the correct figure could
be
> > > read directly from the 4x256-dword matrix representation, should I be
> > > wrong). This is a deliberate design choice:
> >
> > MDS design has nothing todo with bit level diffusion it's more abstract
> than
> > that.  If you have a 4x4 MDS transform the output/input difference must
be
> > in at least five components, etc..
>
>
> Well, yes, but what I wrote implies (by the pidgeon hole principle) that
the
> matrix cannot be MDS. With our matrix, there has to be at least two
> input/output pairs that differ in at most four bytes.

Ah.... so you mean that only two pairs of inputs will cause a maximal
distance?  That's not entirely good.

Why may I ask didn't you go for a pure MDS design?    If it's linear anyways
shouldn't ya make the most of it?

Tom



------------------------------

From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Wed, 25 Apr 2001 00:03:17 +0200

"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:JwmF6.49296$[EMAIL PROTECTED]...
>
> "Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
> news:9c4s7a$eba$[EMAIL PROTECTED]...
> > Well, yes, but what I wrote implies (by the pidgeon hole principle) that
> the
> > matrix cannot be MDS. With our matrix, there has to be at least two
> > input/output pairs that differ in at most four bytes.
>
> Ah.... so you mean that only two pairs of inputs will cause a maximal
> distance?  That's not entirely good.

No, the converse. There are collisions, but mostly a large distance between
input/output pairs.


> Why may I ask didn't you go for a pure MDS design?    If it's linear
anyways
> shouldn't ya make the most of it?

A pure MDS design would cause the key stream output to be a random
permutation (instead of a random function) of the prior cipher text byte,
and that would make an apparent distinguisher. That's why we permuted the
rows of the matrix so that it wouldn't be MDS, and added a rotation after
the post whitening.

In fact, the MDS matrix of TwoFish seems to be safe gaurded in a somewhat
similar fashion. There is a rotation and a Pseudo-Hadamard Transform, and
one purpose of these ought to be to break up the byte-wise distinguishers
that the MDS matrix presents.

So, in a manner of speaking, I don't agree that a pure MDS design would be
to make the most of it. It makes more sense in a block cipher, or, maybe, in
stream ciphers with a smaller state than Steak.


--
Henrick Hellström  [EMAIL PROTECTED]
StreamSec HB  http://www.streamsec.com



------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Security proof for Steak
Date: Tue, 24 Apr 2001 22:13:33 GMT


"Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
news:9c4t8p$fji$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:JwmF6.49296$[EMAIL PROTECTED]...
> >
> > "Henrick Hellström" <[EMAIL PROTECTED]> wrote in message
> > news:9c4s7a$eba$[EMAIL PROTECTED]...
> > > Well, yes, but what I wrote implies (by the pidgeon hole principle)
that
> > the
> > > matrix cannot be MDS. With our matrix, there has to be at least two
> > > input/output pairs that differ in at most four bytes.
> >
> > Ah.... so you mean that only two pairs of inputs will cause a maximal
> > distance?  That's not entirely good.
>
> No, the converse. There are collisions, but mostly a large distance
between
> input/output pairs.
>
>
> > Why may I ask didn't you go for a pure MDS design?    If it's linear
> anyways
> > shouldn't ya make the most of it?
>
> A pure MDS design would cause the key stream output to be a random
> permutation (instead of a random function) of the prior cipher text byte,
> and that would make an apparent distinguisher. That's why we permuted the
> rows of the matrix so that it wouldn't be MDS, and added a rotation after
> the post whitening.
>
> In fact, the MDS matrix of TwoFish seems to be safe gaurded in a somewhat
> similar fashion. There is a rotation and a Pseudo-Hadamard Transform, and
> one purpose of these ought to be to break up the byte-wise distinguishers
> that the MDS matrix presents.
>
> So, in a manner of speaking, I don't agree that a pure MDS design would be
> to make the most of it. It makes more sense in a block cipher, or, maybe,
in
> stream ciphers with a smaller state than Steak.

Ahh but it depends on how far the distinguisher can go.  Often it's only a
few rounds and after that the output differences are indistinguishable from
random.  For example, if you took fixed sboxes and plugged them into a 4x4
MDS and used that as your round function, if you used say 20 rounds (i.e
8-byte block cipher) it should be secure.

Tom



------------------------------

From: "Anon" <[EMAIL PROTECTED]>
Subject: Re: Delta patching of encrypted data
Date: Tue, 24 Apr 2001 23:19:25 -0000

Eek!  This is why us engineer types have to talk to you theoretical people
sometimes!

If I assume that the attacker will be able to pick up strings of zeroes and
strings of FFs in my file - the most common repeating patterns - then
they'll be able to get a value for an encrypted string, which will expose
the bytes following each such string.  I'm byte oriented - I have to be, or
else my original delta patcher won't work - so it does only expose a byte.
But how much will that expose my key, given that the attacker will now have
a larger set of plaintexts and matching ciphertexts to work with? or to put
it another way, what is the relationship between number of available
plaintext/ciphertext pairs and the exposure of the key?

Thanks
"David Wagner" <[EMAIL PROTECTED]> wrote in message
news:9c2e67$m7t$[EMAIL PROTECTED]...
> Benjamin Goldberg  wrote:
> >That depends on what kind of PFB chaining you use.  Suppose that you
> >hash the key and the prior 8 bytes of pt to get the next byte of
> >keystream.  If there are two positions in the file with the same
> >plaintext, then there will be two positions in the file with the same
> >ciphertext -- however, the actual *contents* of the ciphertext will not
> >be directly revealed, just that they are the same.  Further, the first
> >differing byte (ie, one past the end of the strings we are looking at)
> >will be revealed in that we can know the XOR of the two plaintext bytes.
>
> Yes, and if it is a block-oriented PFB, then it's not just the subsequent
> byte, it's the subsequent block, usually 64 or 128 bits or so.
>
> Although the xor of two 64-bit or 128-bit plaintexts does not always
> reveal both plaintexts, I would expect that it will leak information
> frequently enough that this is not a good property.



------------------------------

From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Censorship Threat at Information Hiding Workshop
Date: Tue, 24 Apr 2001 21:26:45 GMT

"Paul Pires" <[EMAIL PROTECTED]> wrote
> > Theft and infringement are two different words for the simple reason
that
> > they are two different things.
> True, but infringement is not the term that describes copyright theft.

The term "copyright theft" would mean stealing someone's copyright.
It happens, but it is not what interests anyone here.

> Infringement is used to denote that a specific territory granted by
> patent or fiat has been encroached upon.

Yes. That is what happens when unlicensed MP3s are downloaded,
according to the RIAA. (In this case, there is also an argument that
it is often not infringement either.)

> .. Why is music and the written word labor or services?
> Cause the law defines it as such.

What law is that?




------------------------------

From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: primitive elements in GF(2^W)
Date: Tue, 24 Apr 2001 22:34:50 GMT

I was wondering about a good way to find primitive elements in a Galois
Field of degree W characteristic two.

My thoughts are that you factor 2^W - 1 which is the order of the field and
you find an element such that g^((2^W - 1) / q) != 1 for all q that divide
2^W-1.  I.e for W=8 (i.e 8-bit elements) you look for some base element such
that

g^3 != 1
g^5 != 1
g^17 != 1

If g isn't 1 then it must be primitive right?
--
Tom St Denis
---
http://tomstdenis.home.dhs.org



------------------------------

From: Brett <[EMAIL PROTECTED]>
Subject: Re: Gurus:  Please show weaknesses in this
Date: Tue, 24 Apr 2001 18:56:49 -0400
Reply-To: [EMAIL PROTECTED]

"M.S. Bob" wrote:

> I would strongly recommend at least one historic book on cryptography.
> Whether it is the "bible", _The Codebreakers_ by David Kahn or the quick
> and gentle, _The Code Book_ by Simon Singh, or one of dozens about the
> Engima in WWII, read at least one real life account of how cryptographic
> systems have failed "in the field."

        I'm reading "The Code Book" right now ... and find it fascinating.

Brett

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to