Cryptography-Digest Digest #87, Volume #12       Thu, 22 Jun 00 15:13:00 EDT

Contents:
  Re: Try it. (John)
  Re: Missing Info in the crypto-gram of MR BS (Jack)
  Re: MD5 Expansion (Simon Johnson)
  Re: Forgot ZIP File password. (pwrecover)
  Re: CRC-64 and 128 - Generator Polynomials? (Mike Rosing)
  Re: obfuscating the RSA private key (Mike Rosing)
  FOR MY NONFANS AND FANS (SCOTT19U.ZIP_GUY)
  Re: MD5 Expansion ("Joseph Ashwood")
  Re: Encryption on missing hard-drives (David A Molnar)
  Re: Try it. (James Pate Williams, Jr.)
  Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
  Re: Try it. (James Pate Williams, Jr.)
  Re: Try it. (John)
  Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
  Re: Variability of chaining modes of block ciphers (Mok-Kong Shen)
  Re: Try it. (None)
  Re: Try it. (John)
  Re: Try it. (John)
  breaking encryption - help! (Steve Basford)
  Re: Try it. ("Joseph Ashwood")

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

Subject: Re: Try it.
From: John <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2000 10:23:05 -0700

[EMAIL PROTECTED] (Mark Wooding) wrote:
>None <[EMAIL PROTECTED]> wrote:
>
>> I can only describe the encryption system in question as
follows:
>>
>> 1. It uses Random #s
>> 2. The outputs of the system pass the statistical tests on the
>> theorietical and empirical level.
>
>Dilbert: `Our product is beige.  It uses electricity.'
>Marketroid: `Woah!  Brain overload!'
>
>Oh, by the way, those are nowhere *near* being sufficient
conditions for
>security.  (Using random numbers and passing statistical tests,
I mean.
>Beigeness and use of electricity aren't actually necessary.
Some crypto
>boxes are blue, for example. ;-) )
>

Yeah, OK. The only thing I've seen here is, "Give us the source,
and we'll let you know if it's secure."  Without the source, all
you can do is brute force it.

>> Encryption is the oddest field. No other area in software is
filled
>> with so much hype.  I don't think I'm as stupid as some think
I am.
>
>Actually, from where I'm sitting, I think it's remarkably free
of hype.
>There's a load of dross, but you just ignore that.  Compare the
amount
>of hype about things like XML and Java.
>

True, but there is still a lot of hype.

>> I mean, if you pick a pass phrase and plaintext and can't
figure out
>> if the cyphertext is whole without the source code, oh well,
I don't
>> think I'll get qnywhere.
>
>Nope.  You've lost me.  I only understand English, French,
German and
>Latin.
>

Maude Merde Du Cu!

I take it you don't bother with pass-phrases, cyphertext, etc.

>-- [mdw]
>
>


Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com


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

From: [EMAIL PROTECTED] (Jack)
Subject: Re: Missing Info in the crypto-gram of MR BS
Date: 22 Jun 2000 17:18:51 GMT

[EMAIL PROTECTED] (Andrew Bortz) wrote in 
<[EMAIL PROTECTED]>:


>
>At some level there will be identifying information that an automated 
>program can use to distinguish a correct decryption from an incorrect 
>one. And most compression algorithms are defined at a file format level, 
>leaving the implementation up to the programmer. With algorithms that 
>rely on searching, there will always be more than one way to compress a 
>file.
>
>Andrew
>

 I think way are playing with different rules. I am assuming the
attacker has both the encryption program and the compression 
decompression programs. Also I am assumming that if you compress
a file B then you always get the same compressed file for compressed (B)
if you don't then you are adding noise and that is an entirely different
can of worms and in my way of thinking would be part of an add on of
encryption where one has to worry about how random.


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

Subject: Re: MD5 Expansion
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2000 10:27:02 -0700

"Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
>
>Simon Johnson <[EMAIL PROTECTED]> wrote
in message
>news:[EMAIL PROTECTED]...
>> Good point.......
>> I'll revise my suggestion:
>>
>> Divide the message into two parts,a,b. do this by taking the
>> first character and appending it to a, the second character
and
>> appending it to b, the third character and append this to a,
the
>> forth character and append it to b. And so on and so
fourth.....
>>
>> Then:
>>
>> Output = h(a) & h(b)
>>
>> This should now be secure enough, with a 128-bit birthday
attack.
>Not particularly.  Suppose you know M != M' such that h(M) == h
(M').  If h
>has a 128 bit output, this takes no more than O(2**64) work
>
>Then, consider the function f(X) that takes a message X, and
replaces each
>character with two of that same character.  For example,
>  f( "I am a message" ) = "II  aamm  aa  mmeessssaaggee".
>It is clear that f(M) != f(M')
>
>Then, if you apply your hashing mechanism to f(M), f(M'), then
you'll find
>the a=b=M, a'=b'=M', and so Output==Output', giving you a
collison.
>more than O(2**64) work.

>For more fun, you can consider f's which interleave M and M',
which gives
>you more colisions.

I can't see how this is correct.....
Lets see where i'm wrong,

1.) treat A & B as two seperate messages...

2.) We want to find A' such that H(A')=H(a)

3.) We also want to find B' such that H(B') = H(B)

For MD5 this attack has O(2^64). Since we to find A' and B' we
mutliply the complexities:

2^64 x 2^64 = O(2^128)

Secondly, it M != (A or B) since A or B is a subset of M.
>--
>poncho



Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com


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

From: pwrecover <[EMAIL PROTECTED]>
Subject: Re: Forgot ZIP File password.
Date: Thu, 22 Jun 2000 17:22:01 GMT
Reply-To: [EMAIL PROTECTED]

In article <[EMAIL PROTECTED]>,
  Pranshu Singhal <[EMAIL PROTECTED]> wrote:
> I encrypted a Win ZIP file and now after many weeks I am unable to
recall
> the
> password. I have tried many options which I thought possible but to no
use.
>
> What do I do??? Please Help...
>
> Pranshu.
>
> Adieu,
>
> Pranshu Singhal
>
>

Password Crackers, Inc. has a service that can recover your .zip
password for you.  There is no charge unless they are successful.  You
can get more information at their site at http://www.pwcrack.com/


Sent via Deja.com http://www.deja.com/
Before you buy.

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

From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: CRC-64 and 128 - Generator Polynomials?
Date: Thu, 22 Jun 2000 12:23:11 -0500

Mack wrote:
> I am looking for some good CRC polynomials for 64, 128, 192, 256 and
> higher bits.  Does anyone have a list of primitive polynomials of those degrees
> mod 2?

You can easily create lists of primitive polynomials.  It wouldn't take long
to modify lots of available code to generate several 1000 per minute.

Patience, persistence, truth,
Dr. mike

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

From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: obfuscating the RSA private key
Date: Thu, 22 Jun 2000 12:48:50 -0500

Dave Ahn wrote:
> Our group has client-server programs that are open sourced for peer review.
> We distribute these programs in source and precompiled binary form.  Users
> download the client binary and use it to connect to servers over the
> Internet.
> 
> We wish to ensure that the users of the client software are using the
> official precompiled binary as opposed to a custom-compiled version based
> on the public source code.  We do not trust the client users.  But we do
> trust the server administrator.  We also trust the network connection
> between the client and the server (i.e. ignore eavesdropping or man-in-middle
> attacks).
[...]

> Does this clarify my original questions a bit?

Yup.  I think you're attacking the problem from the wrong direction.  As pointed
out by other replies, you can't stop a determined hacker.  However, you can
make their life really miserable.  

Since you trust the sever, use a zero-knowledge-proof on a running basis to
check the client.  For example, every 10 or 100 messages (or whatever seems
reasonable) the sever asks the client "what's the <random address> byte of code?"
This is really simple to reply.  You can even use encryption to make it look
like you're doing something else :-)  

It's still easy to hack, but the hacker now needs to fully understand all your
code and have a copy of the original binaries to use as the look up table. 
It's also pretty quick so honest users don't notice anything in loss of performance.

A hacked copy will probably run slower and take more space, so you can use
averaging too to help determine if there's a hacker out there sophisticated
enough to get by your code.  You keep the sophisticated math on the server,
so the client doesn't even know they are being closely watched.  

Expand on this so the questions are more diverse, and make the hackers have to
comprehend every aspect of the system check.  For example: how big are you,
how big is library xxx, how many questions have I asked so far, etc.  

As I said, you can't stop them, but if they have to think about things instead
of responding "instantly" you can catch most of them.

Patience, persistence, truth,
Dr. mike

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: FOR MY NONFANS AND FANS
Date: 22 Jun 2000 17:55:48 GMT

  I have a new machine with new software. The old NEWSREADER I used
was not found by my on the NET so I had to find something else, In
doing so I have had trouble getting a fixed identity. So for my
NON FANS I have finally I hope figured it out and this will make
it easier to filter my email. This way MR BS and his close friends
donot have to trouble there brains with ideas foriegn to there
narrow views on compression and encryption. God forbide that they
have to think a bit. I hope this setup I am current trying to use
will ease any computational burden on there central processors.

Note the folling sigfile will change from time to time.


David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS **no JavaScript allowed**
        http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
        http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed ** JavaScript OK**
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
   "The road to tyranny, we must never forget, begins with the destruction 
of the truth." 

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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: MD5 Expansion
Date: Thu, 22 Jun 2000 10:45:43 -0700

All you're doing is dividing the message up differently. The weakness is
against the same method of attack, it's just a little less clear how to do
it, and now the attacker has to carefully choose which location to attack.
                Joe
"Simon Johnson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Good point.......
> I'll revise my suggestion:
>
> Divide the message into two parts,a,b. do this by taking the
> first character and appending it to a, the second character and
> appending it to b, the third character and append this to a, the
> forth character and append it to b. And so on and so fourth.....
>
> Then:
>
> Output = h(a) & h(b)
>
> This should now be secure enough, with a 128-bit birthday attack.
>
> Got questions?  Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>



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

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Encryption on missing hard-drives
Date: 22 Jun 2000 17:48:40 GMT

Guy Macon <[EMAIL PROTECTED]> wrote:
> You are missing the cultural differences.  These aren't employees of a
> high tech firm.  Thjese are scientists with a core belief that keeping
> secrets is silly, futile, moronic, and a big game that they win whenever
> they circumvent the military security procedures.

Where did this come from? Do you know that the members of NEST hold this
belief, are you extrapolating from your experience with other Los Alamos
scientists,are you extrapolating from other scientists you know, or what?


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

From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: Try it.
Date: Thu, 22 Jun 2000 18:17:18 GMT

On Thu, 22 Jun 2000 08:37:41 -0700, None
<[EMAIL PROTECTED]> wrote:

>John, sounds like a commie to me.  Seems that he/she has
>something against people making money. :-)
>
>I agree. If they put out the source code to the public, you
>wouldn't need an NDA at all!  If it was public, how could
>companies make money?  I mean, it's like saying you'll put the
>source code for Windows in the public arena and also sell it as
>well. Sounds kind of ass backwards to me.
>
>Got questions?  Get answers over the phone at Keen.com.
>Up to 100 minutes free!
>http://www.keen.com
>

Microsoft offered the Justice Department a settlement that would make
Windows open source, but the Justice Department in their "infinite
wisdom" declined the offer. Open source does not mean non-profit.

==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate


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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Thu, 22 Jun 2000 20:20:44 +0200



Mark Wooding wrote:

> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > That's why I favour use of chaining.
>
> So do I.  It's just that varying your method seems silly.  Pick one, say
> CBC with ciphertext stealing, and use a good cipher.

It is because there are many of them, i.e. there exists variability,
that you are able to 'pick' one. Otherwise there is no 'picking'.

M. K. Shen


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

From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: Try it.
Date: Thu, 22 Jun 2000 18:26:40 GMT

On 22 Jun 2000 15:36:19 GMT, [EMAIL PROTECTED] (Mark Wooding) wrote:

>John <[EMAIL PROTECTED]> wrote:
>
>However, I think we
>tend to prefer descriptions in mathematical English here, rather than
>raw source code.
>
>-- [mdw]

I disagree with the statement above. Anyone can tell you in plain
English an algorithm that they have implemented, but the source code
might reveal that they have incorrently implemented the algorithm.
Ever hear of a formal technical review of source code, it is a
standard software engineering procedure.

==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate


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

Subject: Re: Try it.
From: John <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2000 11:12:57 -0700

I never heard of the Open-Source offer. Can you site me a news
article, or something?  I assume MS was only talking about
Internet Explorer. OK, I did hear about something for Developers
where MS would make source for IE available.

They would lose there IE market, but there was nothing about the
Windows platform as far as I know.


Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com


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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Thu, 22 Jun 2000 20:24:26 +0200



Mark Wooding wrote:

> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > It is indeed strange that you have seen very few recent ciphers which
> > hav fixed-length key sizes. The most recent ciphers of significance
> > are certainly the AES candidates. How many of these allow you to vary
> > the key size from 128 by steps of, say, 8 all the way to 256? (Note we
> > were discussing about 'slightly larger keys', not giant jumps.)
>
> Off the top, RC6, Twofish, Serpent, and CAST256.  I think (but don't
> quote me) that MARS and HPC also qualify here, and possibly other things
> like DFC and Frog.  Rijndael's key can be increased in steps of 32 bits.
>
> I'm not actually sure what a `slightly larger key' buys you anyway.  If
> you think that n bits isn't enough, n + 3 bits isn't likely to make you
> much happier.  Use 4 n instead.

You apparently forgot how the issue 'slightly larger key' came in the first
place. It was because you touched that point that we began to discuss
on that. Let me quote you:

     Why is this better than using a good cipher with a slightly longer key
     in a standard chaining mode?

M. K. Shen


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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Variability of chaining modes of block ciphers
Date: Thu, 22 Jun 2000 20:27:17 +0200



"David A. Wagner" wrote:

> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen  <[EMAIL PROTECTED]> wrote:
> > The most recent ciphers of significance are
> > certainly the AES candidates. How many of these allow you to vary the
> > key size from 128 by steps of, say, 8 all the way to 256?
>
> Quite frankly, who cares?
> If 152-bit keys are good enough for you, then 192-bit or 256-bit keys
> should also be perfectly sufficient.

Of course it is preferable to use larger keys, if one can afford to do
that. But the issue of slightly larger keys arose in a special context
of discussion with Mark Wooding. See my response to him.

M. K. Shen



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

Subject: Re: Try it.
From: None <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2000 11:17:03 -0700

I don't see what that has to do with our encryption talk.

Nobody has convinced me that you need source to prove an
encryption system secure. Aren't there other methods to show
security?

http://www.aasp.net/~speechfb

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com


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

Subject: Re: Try it.
From: John <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2000 11:21:51 -0700

Hmmm...Tell that to Microsoft!

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com


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

Subject: Re: Try it.
From: John <[EMAIL PROTECTED]>
Date: Thu, 22 Jun 2000 11:24:30 -0700

None <[EMAIL PROTECTED]> wrote:
>I don't see what that has to do with our encryption talk.
>
>Nobody has convinced me that you need source to prove an
>encryption system secure. Aren't there other methods to show
>security?
>

There are, but the source code is the easiest way. Maybe people
don't want to do a lot of hard work. :-) Without source, one
only has the data. Analysis of data CAN help you know a little
about the encryption system.

>http://www.aasp.net/~speechfb
>
>Got questions?  Get answers over the phone at Keen.com.
>Up to 100 minutes free!
>http://www.keen.com
>
>


Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com


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

From: Steve Basford <[EMAIL PROTECTED]>
Subject: breaking encryption - help!
Date: Thu, 22 Jun 2000 19:39:10 +0100

Sorry, firstly, if this is the wrong group to ask this but I wonder if anyone
can help me with this little problem.

I use a free proxy server at work, that contains a list of url's that are
banned.  As the administrator I can add to this list from within the
proxy server, however I want to code a little util to read the banned.cfg
file and output, in plain text, a list of the banned url's for my records.

Here's the problem... the banned.cfg file is encrypted, I'd take a guess
at a very simple encryption, such as xor, but I'd tried that and so I must
be missing something.

Here's a sample part of the banned.CFG file (plus my comments)....


0F  : length of url (15)
00 00 00  : spacer
2F 83 92 A3 DC 37 A1 3A 0A FA 29 83 A6 41 D7 : www.aaaaa.co.uk
01 : index

as you can see the codes 2F,83,92 are in fact the "www" part of the text, now
if using just xor, that would be the same value.

Anyone any ideas how I can decode this?  

BTW I know the www.aaaaa.co.uk is correct because I enter this banned url from
within the proxy program.

thanx....



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

From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Try it.
Date: Thu, 22 Jun 2000 11:47:58 -0700

The methods of proving an encryption scheme secure are not yet known, the
methods of establishing it secure to the best of our knowledge is generally
done only successfully when the algorithm has been examined publically for a
period of years. No meer NDA will ever accomplish this.

The methods of determining if source code is secure against
non-cryptographic attacks are better understood, it consists of going over
the source code making sure that every possible occurance is accounted for,
making sure that no data will be leaked, no buffer overflows can occur, that
keys are properly wiped from memory, making sure keys are locked in memory
instead of being free to be swapped to disk, etc, etc. For this an NDA is
usually required.
                        Joe



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


** 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 (and sci.crypt) via:

    Internet: [EMAIL PROTECTED]

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

Reply via email to