Cryptography-Digest Digest #624, Volume #13       Sun, 4 Feb 01 01:13:01 EST

Contents:
  Re: Encrypting Predictable Files (SCOTT19U.ZIP_GUY)
  Re: Encrypting Predictable Files (Richard Heathfield)
  Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
  Re: ideas of D.Chaum about digital cash and whether tax offices are    (Darren New)
  Re: The prospects for a theoretical breakthrough in the factoring problem (David A 
Molnar)
  Re: RIJNDAEL is NOT patented
  Re: RIJNDAEL is NOT patented (Eric Lee Green)
  Silly(?) RC4 question (B. Wooster)
  Re: MIKE - alternative to SPEKE and PAK (Thomas Wu)
  New Block Cipher ("David Finch")
  Crypto-quote ("Police Suck")
  Re: Silly(?) RC4 question ("Scott Fluhrer")
  PGP Crack ([EMAIL PROTECTED])
  Re: Crypto-quote ("Jeff Moser")
  Re: Encrypting Predictable Files (SCOTT19U.ZIP_GUY)
  Re: PGP Crack ("Michael Brown")
  Re: Crypto-quote ("John A. Malley")
  Re: Pseudo Random Number Generator (Matthew Montchalin)

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Encrypting Predictable Files
Date: 4 Feb 2001 00:04:37 GMT

[EMAIL PROTECTED] (Richard Heathfield) wrote in 
<[EMAIL PROTECTED]>:

>"SCOTT19U.ZIP_GUY" wrote:
>> 
>> Take any file decrypt with a key you get a valid file and when you
>> reencrypt with same key you get the original file back. Try that with
>> any any other so called "non-snake-oil" file and see what you get.
>
>You seem to be suggesting that P = E(E(P, K), K).

   No it is more like P = E(D(P, K), K) 
   where P is any binary file. note also
   P = D(E(P, K), K)
   which is the normal situation. It just that
   encrypt methods like mine or Matts have no info added
   and you can interchange what you call the encryption
   direction.  In other words you could encrypt a file
   by using the normal decryption portion of the method
   and then recover the real message by using the normal
   encryption function. This is not allowed in most 
   encryption/decrption software packages since they add
   information during encryption that makes it easier for
   groups like the NSA to break it. But it is easy to test
   your package to see if it adds information.
      Just try to decrypt a arbitrary file and see if you
   get it back when you encrypt it.



   
David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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

Date: Sun, 04 Feb 2001 00:22:56 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files

"SCOTT19U.ZIP_GUY" wrote:
> 
> [EMAIL PROTECTED] (Richard Heathfield) wrote in
> <[EMAIL PROTECTED]>:
> 
> >"SCOTT19U.ZIP_GUY" wrote:
> >>
> >> Take any file decrypt with a key you get a valid file and when you
> >> reencrypt with same key you get the original file back. Try that with
> >> any any other so called "non-snake-oil" file and see what you get.
> >
> >You seem to be suggesting that P = E(E(P, K), K).
> 
>    No it is more like P = E(D(P, K), K)
>    where P is any binary file. note also
>    P = D(E(P, K), K)
>    which is the normal situation. It just that
>    encrypt methods like mine or Matts have no info added
>    and you can interchange what you call the encryption
>    direction.  In other words you could encrypt a file
>    by using the normal decryption portion of the method
>    and then recover the real message by using the normal
>    encryption function. This is not allowed in most
>    encryption/decrption software packages since they add
>    information during encryption that makes it easier for
>    groups like the NSA to break it. But it is easy to test
>    your package to see if it adds information.
>       Just try to decrypt a arbitrary file and see if you
>    get it back when you encrypt it.

I just tried this on my own algorithm, CDX, and it worked fine. It never
occurred to me, when designing it, to add any information to it. Oops. 

Oh well, I'm sure GCHQ, NSA, whoever, will cope.

-- 
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

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

From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: MIKE - alternative to SPEKE and PAK
Date: Sun, 04 Feb 2001 00:31:52 GMT


"Michael Scott" <[EMAIL PROTECTED]> wrote in message
news:iWLe6.100186$[EMAIL PROTECTED]...
>
> "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "Michael Scott" <[EMAIL PROTECTED]> writes:
> >
> > > "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > "Michael Scott" <[EMAIL PROTECTED]> writes:
> > > OK, so this might be better (must get that paper). Variables a,b and r
> are
> > > randomly selected
> > >
> > >  3. Carol: A=3^a mod p, Carol sends A to Steve
> > >  4. Steve: B=3^b.v^r. u=4^r. Steve sends B and u to Carol.
> > >  5. Carol calculates S=(B/u^x)^a. Steve calculates S=A^b
> >
> > In this case, Mallory (posing as Steve, but doesn't know v) gets Carol
to
> > talk to him instead of Steve:
> >
> > 3'. Carol: Sends A=3^a to Mallory
> > 4'. Mallory: B'=3^b, u=3.  Mallory sends B' and u to Carol.
> > 5'. Carol calculates S=(B'/u^x)^a=3^((b-x)*a)
> > 6'. Carol presumably sends Mallory some proof of S, e.g. H(S).
> > 7'. Mallory guesses values of the password x', and computes S'=A^(b-x')
> >     for each guess, and sees if S' is right, e.g. H(S) == H(S').
> >
> > So it looks like an active attacker can brute-force the password.
> > I believe this generalizes to u=3^c for arbitrary c.  I think the
> > computation of S cannot use a group operation to combine B and u^x
> > because that's what allows the attacker to strip out the "a" on the
> > other side, since the group operation commutes.  Thoughts?
> >
>
> Thanks to Tom, David and Phil for thier encouragement. I haven't given up
> yet....
> Hmmm. I think Carol needs to check that Steve has been behaving himself...
I
> think there are a number of ways of doing this.
> Its also not clear to me that r and b need to be distinct

Now I can see why they should be distinct. Steve needs to show that he knows
3^b, without revealing it.

3. Carol: A=3^a mod p
4. Steve: B=3^b.v^r mod p, u=4^r, w=H(3^b). Sends {B,u,w} to Carol.
5. Carol checks that H(B/u^x) =?=w, otherwise aborts. Then Carol calculates
S=(B/u^x)^a. Steve calculates S=A^b.


Mike Scott

>
> > Tom
> >
> > > --
> > > > Tom Wu                        * finger -l [EMAIL PROTECTED] for
> PGP
> > > key *
> > > >  E-mail: [EMAIL PROTECTED]       "Those who would give up their
> freedoms
> > > in
> > > >   Phone: (650) 723-1565              exchange for security deserve
> > > neither."
> > > >    http://www-cs-students.stanford.edu/~tjw/
> > > http://srp.stanford.edu/srp/
> > >
> > >
> >
> > --
> > Tom Wu                        * finger -l [EMAIL PROTECTED] for PGP
> key *
> >  E-mail: [EMAIL PROTECTED]       "Those who would give up their
freedoms
> in
> >   Phone: (650) 723-1565              exchange for security deserve
> neither."
> >    http://www-cs-students.stanford.edu/~tjw/
> http://srp.stanford.edu/srp/
>
>



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

From: Darren New <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are   
Date: Sun, 04 Feb 2001 01:00:08 GMT

Thomas J. Boschloo wrote:
> This really has some consequences.

The only real consequence of all this is that you can't make distribution of
some types of digital information illegal while other types remain legal.
The real problem is that it's too hard to catch pornographers/drug
manufacturers/witches, so you catch their customers instead.

> content protected media (aka software enforced licensing schemes) will
> make producers of such illegal material feel very secure.

Well, I guess the laws will change. Gunpowder was pretty shocking to armored
knights at the time, too.

> I also had an somewhat related (anti-echelon) thought about firearms
> (since you Americans seem so obsessed with that). What if there would be
> a technology that allowed every bullet to be traced by some homing
> signal.

Traced to what? Where it is? By whom? The government? They're the people we
americans distrust! :-)

> Would we use it to stop
> drive-by-shootings and terrorist actions in shopping malls?

There are easier ways to stop drive-by-shootings.

> What is your standing on Assassination Politics by Jim Bell? In it
> bad/corrupt politicians get killed by pseudonymiously 'predicting' the
> time of death of that politician. 

If it ever became real, it would be made illegal to gamble on the death of a
famous person, is all. Jim Bell seems to forget that when some legal
activity threatens politicians, politicians make it illegal.

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST).  Cryptokeys on demand.
                 Ignorance can be cured. Naivety cures itself.

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

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: The prospects for a theoretical breakthrough in the factoring problem
Date: 4 Feb 2001 00:51:06 GMT

[EMAIL PROTECTED] wrote:

> I know that this is a very difficult question because a breakthrough
> can without premonition – a sudden flash of genius is enough. But
> perhaps somebody here can make an advanced guess.

I don't have the standing or the knowledge to guess. I will point out an
article, however, which discusses just how far we seem to be from proving
anything about the hardness of factoring...

"News from the Isomorphism Front" 
E. Allender
http://external.nj.nec.com/homepages/fortnow/beatcs/column66.ps

-David

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

From: <[EMAIL PROTECTED]>
Subject: Re: RIJNDAEL is NOT patented
Date: Sat, 3 Feb 2001 20:30:19 -0500


On Sat, 3 Feb 2001, Tom St Denis wrote:

> 
> That's so full of it.  Rijndael is not patented (AFAIK) and is the new AES
> standard.
> 
        RIJNDAEL is NOT patented, and according to the authors, WILL NEVER
be patented. The name RIJNDAEL, however, is apparently copyrighted.
=============
My home page URL=http://www.afn.org/~afn21533/          Robert G. Durnal
Hosting RIJNDAEL, the AES winner, in CFB block          [EMAIL PROTECTED]
chaining mode with key hashing. Executable is         [EMAIL PROTECTED]
only 440 bytes. Download as tinyrijn.zip



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

From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: RIJNDAEL is NOT patented
Reply-To: [EMAIL PROTECTED]
Date: 3 Feb 2001 17:49:14 -0600

On Sat, 3 Feb 2001 20:30:19 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>On Sat, 3 Feb 2001, Tom St Denis wrote:
>> That's so full of it.  Rijndael is not patented (AFAIK) and is the new AES
>> standard.
>> 
>       RIJNDAEL is NOT patented, and according to the authors, WILL NEVER
>be patented. The name RIJNDAEL, however, is apparently copyrighted.

Err, names cannot be copyrighted. They can, however, be registered as
trade or service marks. 

As far as I know, the authors of Rijndael have not filed for a U.S. trademark
upon the name. It is unclear whether they could, now that the algorithm has
been accepted as the Advanced Encryption Standard and all rights have
vested with the NIST. For that matter, it's unclear whether it'd be worthwhile
to do so, given that everybody is going to call it AES now.

-- 
Eric Lee Green     Linux Subversives
[EMAIL PROTECTED]    http://www.badtux.org


====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
=======  Over 80,000 Newsgroups = 16 Different Servers! ======

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

From: B. Wooster <[EMAIL PROTECTED]>
Subject: Silly(?) RC4 question
Reply-To: [EMAIL PROTECTED]
Date: Sun, 04 Feb 2001 02:34:37 GMT

This may be a silly question, but here goes anyway.  I assume that a
variant of the RC4 algorithm that does everything *except* swap the
values in the S-table is worthless.  Am I correct?  Or is there any
value in it?

Thanks for any opinions.





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

From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: MIKE - alternative to SPEKE and PAK
Date: 03 Feb 2001 19:18:44 -0800

"Michael Scott" <[EMAIL PROTECTED]> writes:

> "Michael Scott" <[EMAIL PROTECTED]> wrote in message
> news:iWLe6.100186$[EMAIL PROTECTED]...
> >
> > "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > "Michael Scott" <[EMAIL PROTECTED]> writes:
> > >
> > > > "Thomas Wu" <[EMAIL PROTECTED]> wrote in message
> > > > news:[EMAIL PROTECTED]...
> > > > > "Michael Scott" <[EMAIL PROTECTED]> writes:
> > > > OK, so this might be better (must get that paper). Variables a,b and r
> > are
> > > > randomly selected
> > > >
> > > >  3. Carol: A=3^a mod p, Carol sends A to Steve
> > > >  4. Steve: B=3^b.v^r. u=4^r. Steve sends B and u to Carol.
> > > >  5. Carol calculates S=(B/u^x)^a. Steve calculates S=A^b
> > >
> > > In this case, Mallory (posing as Steve, but doesn't know v) gets Carol
> to
> > > talk to him instead of Steve:
> > >
> > > 3'. Carol: Sends A=3^a to Mallory
> > > 4'. Mallory: B'=3^b, u=3.  Mallory sends B' and u to Carol.
> > > 5'. Carol calculates S=(B'/u^x)^a=3^((b-x)*a)
> > > 6'. Carol presumably sends Mallory some proof of S, e.g. H(S).
> > > 7'. Mallory guesses values of the password x', and computes S'=A^(b-x')
> > >     for each guess, and sees if S' is right, e.g. H(S) == H(S').
> > >
> > > So it looks like an active attacker can brute-force the password.
> > > I believe this generalizes to u=3^c for arbitrary c.  I think the
> > > computation of S cannot use a group operation to combine B and u^x
> > > because that's what allows the attacker to strip out the "a" on the
> > > other side, since the group operation commutes.  Thoughts?
> > >
> >
> > Thanks to Tom, David and Phil for thier encouragement. I haven't given up
> > yet....
> > Hmmm. I think Carol needs to check that Steve has been behaving himself...
> I
> > think there are a number of ways of doing this.
> > Its also not clear to me that r and b need to be distinct
> 
> Now I can see why they should be distinct. Steve needs to show that he knows
> 3^b, without revealing it.
> 
> 3. Carol: A=3^a mod p
> 4. Steve: B=3^b.v^r mod p, u=4^r, w=H(3^b). Sends {B,u,w} to Carol.
> 5. Carol checks that H(B/u^x) =?=w, otherwise aborts. Then Carol calculates
> S=(B/u^x)^a. Steve calculates S=A^b.

Huh?  If a fake client Chris comes along, can't she do step 3, get Steve's
response in step 4, and just keep guessing x until the test in step 5
(H(B/u^x) == w) passes?  That would let her do an offline dictionary
attack after one failed exchange.  Did I miss something?

Tom
-- 
Tom Wu                        * finger -l [EMAIL PROTECTED] for PGP key *
 E-mail: [EMAIL PROTECTED]       "Those who would give up their freedoms in
  Phone: (650) 723-1565              exchange for security deserve neither."
   http://www-cs-students.stanford.edu/~tjw/   http://srp.stanford.edu/srp/

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

From: "David Finch" <[EMAIL PROTECTED]>
Subject: New Block Cipher
Date: Sun, 04 Feb 2001 02:38:51 GMT

This is different than last cipher I posted.

This time I made it non-VC++ specfic and gave a detailed description the
steps it takes to encrypt.

http://www.geocities.com/dtfinch/DAFI.html

Although my last one has not been broken yet, it wasn't well suited for many
applications.

This one uses the key to create the sboxes. To encrypt a block you just give
it a 64bit plaintext block and it returns a ciphertext block. The mode of
encryption is up to you. It would probably be best to xor the previous
ciphertext block with the current plaintext block before encrypting.

    -David Finch





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

From: "Police Suck" <[EMAIL PROTECTED]>
Subject: Crypto-quote
Date: Sun, 04 Feb 2001 03:36:50 GMT

GOQ RMNHEQ YKQ YZ QVRQZPHAQ ZWHPYZEQ. GOQF YEEMLRNHPO ZMGOHZD. GOQF
EQKGYHZNF BMZ'G RKQAQZG EKHLQ, YZB ZM YLMWZG MS YBBHGHMZYN SWZBHZD CHNN
HLRKMAQ GOQHK ZMZ-QSSQEGHAQZQPP. GOQF YKQ Y PEMWKDQ WRMZ GOQ NYZB.


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

From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Silly(?) RC4 question
Date: Sat, 3 Feb 2001 20:47:29 -0800


B. Wooster <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> This may be a silly question, but here goes anyway.  I assume that a
> variant of the RC4 algorithm that does everything *except* swap the
> values in the S-table is worthless.  Am I correct?  Or is there any
> value in it?
Rather little.  Without the swap, then the only values that change over time
are the i and j variables, and that gives you a maximum of 65536 outputs
before a repetition.

--
poncho





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

From: [EMAIL PROTECTED]
Subject: PGP Crack
Date: Sun, 04 Feb 2001 04:49:17 GMT

I was curious, does anyone have a good layman's explanation of the
recent PGP Crack that was discovered.

I mean was it intentionally placed there by Network Associates? How does
(or did) it work. I can't find too much information on it.

-Jeff


Sent via Deja.com
http://www.deja.com/

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

From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: Re: Crypto-quote
Date: Sun, 4 Feb 2001 00:07:29 -0500


"Police Suck" <[EMAIL PROTECTED]> wrote in message
news:m74f6.5926$[EMAIL PROTECTED]...
> THE POLICE ARE AN EXPENSIVE NUISANCE. THEY ACCOMPLISH NOTHING. THEY
> CERTAINLY DON'T PREVENT CRIME, AND NO AMOUNT OF ADDITIONAL FUNDING WILL
> IMPROVE THEIR NON-EFFECTIVENESS. THEY ARE SCOURGE UPON THE LAND

Get a speeding ticket eh?

Jeff



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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Encrypting Predictable Files
Date: 4 Feb 2001 05:23:36 GMT

[EMAIL PROTECTED] (Richard Heathfield) wrote in 
<[EMAIL PROTECTED]>:

>"SCOTT19U.ZIP_GUY" wrote:
>> 
>> [EMAIL PROTECTED] (Richard Heathfield) wrote in
>> <[EMAIL PROTECTED]>:
>> 
>> >"SCOTT19U.ZIP_GUY" wrote:
>> >>
>> >> Take any file decrypt with a key you get a valid file and when you
>> >> reencrypt with same key you get the original file back. Try that with
>> >> any any other so called "non-snake-oil" file and see what you get.
>> >
>> >You seem to be suggesting that P = E(E(P, K), K).
>> 
>>    No it is more like P = E(D(P, K), K)
>>    where P is any binary file. note also
>>    P = D(E(P, K), K)
>>    which is the normal situation. It just that
>>    encrypt methods like mine or Matts have no info added
>>    and you can interchange what you call the encryption
>>    direction.  In other words you could encrypt a file
>>    by using the normal decryption portion of the method
>>    and then recover the real message by using the normal
>>    encryption function. This is not allowed in most
>>    encryption/decrption software packages since they add
>>    information during encryption that makes it easier for
>>    groups like the NSA to break it. But it is easy to test
>>    your package to see if it adds information.
>>       Just try to decrypt a arbitrary file and see if you
>>    get it back when you encrypt it.
>
>I just tried this on my own algorithm, CDX, and it worked fine. It never
>occurred to me, when designing it, to add any information to it. Oops. 
>
>Oh well, I'm sure GCHQ, NSA, whoever, will cope.
>

  Did you really try this on your own method. I would be very
surprised if it works on all files. Did you try files of various
lengths. Since most "algorithms" will be fully reverseable for
some fixed block size. But if the file is not a nice number of
bytes they tend to fail. Is your method based on blocks longer
than 1 byte or is it a method that treats the file as a single
block.
 Having the method work for a given block size and then molding
into a working program that handles aribitrary lengths seems to
be a problem most give little serious thought to. If you have
then your a step ahead of most writter of software and I take
my hat off to you.

David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
        http://radiusnet.net/crypto/  then look for
  sub directory scott after pressing CRYPTO
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:

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

From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: PGP Crack
Date: Sun, 4 Feb 2001 18:48:33 +1300

You mean the ADK problem?

<[EMAIL PROTECTED]> wrote in message news:95in0c$8ld$[EMAIL PROTECTED]...
> I was curious, does anyone have a good layman's explanation of the
> recent PGP Crack that was discovered.
>
> I mean was it intentionally placed there by Network Associates? How does
> (or did) it work. I can't find too much information on it.
>
> -Jeff
>
>
> Sent via Deja.com
> http://www.deja.com/



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

From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Crypto-quote
Date: Sat, 03 Feb 2001 21:47:17 -0800


Jeff Moser wrote:
> 
> "Police Suck" <[EMAIL PROTECTED]> wrote in message
> news:m74f6.5926$[EMAIL PROTECTED]...
> > THE POLICE ARE AN EXPENSIVE NUISANCE. THEY ACCOMPLISH NOTHING. THEY
> > CERTAINLY DON'T PREVENT CRIME, AND NO AMOUNT OF ADDITIONAL FUNDING WILL
> > IMPROVE THEIR NON-EFFECTIVENESS. THEY ARE SCOURGE UPON THE LAND
> 
> Get a speeding ticket eh?
> 
> Jeff

BYLZHCYPGMMPNMCCQNNBMZQPHK

By the way - did you see any rhyme or reason to the substitution key? I
didn't see a way to assign ciphertext equivalents to plaintext B, J, K,
Q or Z without further ciphertext from Mr. Suck.

John A. Malley
[EMAIL PROTECTED]

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

From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Pseudo Random Number Generator
Date: Sat, 3 Feb 2001 21:46:17 -0800

On Sat, 3 Feb 2001, CR Lyttle wrote:
|XOR two "almost" random uncorrelated data streams, should result in 
|a more nearly "white" data output stream.

I sure hope so.  But are we relying on gut feelings here, or on
something we can prove?

|Encrypting the compressed video stream should make the data look even
|more random. Choosing a couple of action-adventure films with lots of
|explosions, etc., should make for a good result.

Heh.  Okay, if we must rely upon gut feelings, if nothing else.  Any
*Schwarzenegger* film ought to make for a better 'key' than a 'My Dinner
With Andre' sort of film.

|Lots of pixels changing in chaotic manner. In this case, a good result
|is one in which E[(X[i]-mX)(X[j]-mX)] = 0 if i != j. That means that
|given previous output you cannot predict what the next output will be.

This is the case for the algorithm I posted in sci.crypt back around
June 1st or May 30th, 2000.  And that was a very simple algorithm,
so long as you choose a nonzero key, 8 bytes long, you get a sequence
that doesn't repeat until after 2^42 iterations, which is a fair
result.

|> And what do you do if the user chose to use two identical DVD's?
|> (I know, you tell him not to, but what happens if he goes ahead
|> and does so?)  An identity function with very little appearance
|> of randomness.
|
|Big goof! If I were writing a program to do crypto, I would have
|that case abort with an error code. The correlation would be 1. The
|programmer would have to set a limit on rho, say +/-0.07 or some such.

But now we ought to conclude our algorithm with a series of "employee
training sessions" to keep them from doing that sort of thing!?  I
don't think we would want our national defense to be hanging in the
balance on how well some 'sociology major' CIA agent can figure out
which key to type in on their encryption routines.  (But vocabulary/
grammatical transformation coding is more practical, even if more easily
compromised and penetrated.)

|Exceed the limit and get prompted to choose another video.

Heh

|Also note that DVDs will have lots of areas that contain non-video
|information. The program will have to identify those and skip over
|them.

Well, compressing a DVD which is already compressed, should inflate
it in some obvious (?) sort of way.  And after that, you can encrypt
it, I guess.  As I have said in the past, and which others seem to
have said, the weak point in all these encryption systems is the human
element.  There's just not much a 'high' security echelon can do in
trying to straighten out an unreliable or incompetent lackey; all
the codes in the world here won't help.


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


** 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