Cryptography-Digest Digest #378, Volume #9       Mon, 12 Apr 99 13:13:05 EDT

Contents:
  Re: True Randomness & The Law Of Large Numbers (R. Knauer)
  Re: More Diffie-Hellman musings... (Peter Gunn)
  Re: More Diffie-Hellman musings... (David P Jablon)
  Re: help in decrypting a message using the playfair cipher (Jim Gillogly)
  Re: Are LFSR's codebook rngs? ("Trevor Jackson, III")
  Re: More Diffie-Hellman musings... (David P Jablon)
  Re: Are LFSR's codebook rngs? ([EMAIL PROTECTED])
  Re: Can someone think this through, please.  (PGP) (John Savard)
  Re: True Randomness & The Law Of Large Numbers (R. Knauer)
  Re: Skipjack Decrypt Problems ([EMAIL PROTECTED])
  Re: Is public key crypto just Snake Oil?? (John Savard)
  Re: True Randomness & The Law Of Large Numbers ("Douglas A. Gwyn")
  LFSR polynomial testing ([EMAIL PROTECTED])

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

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 12 Apr 1999 14:21:14 GMT
Reply-To: [EMAIL PROTECTED]

On 12 Apr 99 09:29:26 -0400, [EMAIL PROTECTED] (John Briggs)
wrote:

>> It sure took long enough.

>Ok.

Better late than never, eh.

>> I assume that comes from the Standard Normal (z) Distribution.

>Nope.  I computed the probability of each total bias value explicitly.

Actually that is what I meant.

>If I were an expert, I might have assumed a normal distribution, figured
>out how many standard deviations out we were and looked up a probability.
>And I probably could have whipped out a couple of theorems to quantify
>how close this binomial distribution is to being normal.

According to Triola, the normal approximation is quite adequate for a
sample size of 30 and greater (IIRC).

>But I'm a computer jock.

Noble profession, one might say.

>For the test result.  The one whose distribution I just computed and
>specified.  Did you not follow the steps?

Yes, but you introduced that second distribution in an ad hoc manner.
I have never seen anything like that before. But then that doesn't
mean anything.

>Let me include again the text you apparently quoted without reading:

I read it. That doesn't mean I understood it.

>Let's try again, more slowly...

That's better...

Is this going to get published in a comic book version?

>The sum of all 20,000 bits is also a random variable with a distribution.

The sum of all 20,000 bits is the random walk variable Sn, the one
with abnormal properties.

>A formula whose value is 1 if the sum is inside a certain range and 0 if
>the sum is outside a certain range is also a random variable with a
>distribution.

I got that part. What I did not get is your motive for introducing it.

>The test result is just such a random variable.
>Distributions have parameters that describe them.

Not always. The infinitely large flat distribution, as well as any
other distribution that is not square integrable, does not have a
variance. But that is nitpicking.

>Given assumptions about the joint distribution of 20,000 bits
>one can compute the distribution of the sum.

That would be the distribution for the random walk.

>One can then compute the probability that the sum falls into a certain
>range.

Yes, just as one does with the random walk.

>Which part did you not understand?

The part where you complicated the issue by bringing in the
distribution for pass/fail. It appears contrived.

You did not have to go to all that trouble - the original distribution
which gave you the preliminary results was a parameterized
distribution since it was based on the random walk.

>No.  Trollish questions usually have obvious answers.  Like most folks,
>I tend to stay quiet when I don't know the answer.

>See.  That's a good trollish question.  It's insulting.  It has an
>obvious answer.  And it holds out the tantalizing hope of telling the
>poser something he doesn't know.

Your original accusation that my questions are trollish is a trollish
comment that deserves a trollish response.

Bob Knauer

"The contagious people of Washington have stood firm against
diversity during this long period of increment weather."
- Marion Barry, Mayor of  Washington DC


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

From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Re: More Diffie-Hellman musings...
Date: Mon, 12 Apr 1999 15:10:44 +0100

David P Jablon wrote:

> In article <[EMAIL PROTECTED]>,
> Peter Gunn  <[EMAIL PROTECTED]> wrote:
> > [...] So far, some helpful crypto folks
> > have
> > pointed [me] at Diffie's "Station To Station" (STS) protocol, which avoids the man
> >
> > in the middle by an exchange of public keys to authenticate both sides, EKE &
> > SPEKE which use encryption and work with low entropy secrets, and protocols
> > like SRP which avoids the encryption and hence (as far as the key exchange
> > itself
> > is concerned) avoids many export legalities. Its all really cool stuff [...]
>
> Export controls are not an issue with any of these protocols,
> when used purely for authentication.  Also, neither SPEKE, SRP,
> nor EKE when carefully implemented use any traditional
> symmetric encryption method, like DES.
>
> Bellovin & Merritt showed how XOR can be a suitable
> replacement for traditional symmetric encryption, when using a
> password-derived key, by avoiding any verifiable plaintext.
> SRP-3 uses addition, and SPEKE uses no symmetric function at all.

Im still digesting most of the available info... I still think its quite
amazing that you can have secure sessions with short secrets :-)

> > My 'enhanced' effort now looks like the following...
> >
> > x1 is a random number
> > x2 is a random number
> > A is the Client.
> > B is the Server.
> > H() is a one way crypto hash function (SHA or similar)
> > p a large safe prime
> > key is the key used for the symmetric block cipher
> > U is the userid (perhaps just the user's name?? probably ASCII, 8 or less chars)
> >
> > P is the password (probably ASCII, 8 or less chars)
> >
> > 1) A->B: y1=(2^x1)%p, H(U)
> > 2) B: key=H(P,(y1^x2)%p)
> > 3) B->A: y2=(2^x2)%p, H(U,key)
> > 4) A: key=H(P,(y2^x1)%p)
> >
> > What happens is...
> >
> > 1) The Client sends the server its public DH value y1=(2^x1)%p, plus
> > SHA(userid).
> > 2) The Server identifies the user by looking up a list keyed by SHA(userid),
> > and disconnects the Client if its not recognised. Otherwise, Server computes
> > key=SHA(password,(y1^x2)%p).
> > 3) The Server sends its DH public value y2=(2^x2)%p, and SHA(userid,key)
> > back to the Client.
> > 4) Client works out key=SHA(password,(y2^x1)%p), and checks that
> > SHA(userid,key) matches the value supplied by the server, breaking
> > the connection if it isnt.
> >
> > Then both Client & Server encrypt all traffic using the key value,
> > and a symmetric block cipher.
> >
> > A man in the middle could still do an offline attack on H(U) and possibly
> > work out the username, but this doesnt seem to help him get at the data
> > unless he can solve H(U,key) knowing the value of U, which doesnt
> > seem feasible... then he still has to work out P.
>
> Exercise for the reader:  After considering the MITM attack,
> look at what an attacker can do in Alice's shoes.

One pill makes you larger.... and one pill makes you small...

:-)

PG.

PS I presume you mean that the attacker can work out P
   after working out U because he knows the DH private key
   when being in the middle, because for short P he can
   easily solve H(U,H(P,<DH secret>)?? I think Ive fixed
   that in SNAKE :-)

PPS As always, please note that I'm *not* claiming to be an
  expert in any of this... just interested =^)



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

From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: More Diffie-Hellman musings...
Date: Mon, 12 Apr 1999 14:18:36 GMT

In article <7emdk4$9al$[EMAIL PROTECTED]>,
Lyal Collins <[EMAIL PROTECTED]> wrote:
> Why do you need DH when the hash of a shared secret and a counter serves the
> same purpose ?

Because an iterated hash alone is not strong.
UNIX crypt(3) originally used a 25-pass DES-like function, 
which at the time was slow, but is not anymore.
If you want long-term protection for network messages,
you have to use something stronger, like EKE, SPEKE, SRP-3,
or perhaps what Peter or others can come up with.

> Peter Gunn wrote in message <[EMAIL PROTECTED]>...  
>> Noone has commented on my proposal to avoid the man-in-the middle
>> by simply creating a key by hashing a secret shared between the
>> client & server with the DH value...

-- dpj

======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>

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

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: help in decrypting a message using the playfair cipher
Date: Mon, 12 Apr 1999 07:44:14 -0700

[EMAIL PROTECTED] wrote:
> I was wondering if anyone would be able to help me in decrypting a message
> which was encrypted using the Playfair Cipher. I have tried decrypting it for
> the past 2 weeks but have not even come close to doing so.

What's the message, and how does your teacher feel about you
getting help from Usenet on the assignment?

-- 
        Jim Gillogly
        Highday, 21 Astron S.R. 1999, 14:43
        12.19.6.1.16, 5 Cib 4 Pop, Ninth Lord of Night

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

Date: Mon, 12 Apr 1999 09:01:14 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Are LFSR's codebook rngs?

[EMAIL PROTECTED] wrote:
> 
> > It's known as the "initial fill", and depends on the system.
> > That can be considered part of the "key".
> >
> 
> Ok, next question, do they have the same paterns just rotated by x ammounts..
> 
> Say you start with 0
> 3, 1, 2, 0
> 
> Start with 3
> 1, 2, 0, 3
> 
> ??? Is that true?

All FSR generators have a PERIOD with which they repeat.  Thus there is
a cycle of values that forms a loop in the state space.  No matter where
you start on that loop you will end up where you started after PERIOD
steps.

Some FSR cycles have periods of one or two while others have periods of
2^WIDTH-1.  A long period is considered a Good Thing.

For more information read "Shift Register Sequences" by Golomb revised
in 1982.

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

From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: More Diffie-Hellman musings...
Date: Mon, 12 Apr 1999 14:00:35 GMT

In article <7elbq5$[EMAIL PROTECTED]>,
Harvey Rook <[EMAIL PROTECTED]> wrote:
> My comments within...
>
> Peter Gunn <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>> Noone has commented on my proposal to avoid the man-in-the middle
>> by simply creating a key by hashing a secret shared between the
>> client & server with the DH value...
>>
>> A->B: y1=(2^x1)%p
>> B->A: y2=(2^x2)%p
>> A: key=H(secret,(y2^x1)%p)
>> B: key=H(secret,(y1^x2)%p)
>
> Sharing a secret defeats the purpose of DH. You use DH, when there are many
> people on the network, and you managing all the secrets is pain. If you can
> share a secret, just use the secret as the password.

Harvey, you've missed the point, which was explained in
prior posts, that you want to avoid the man-in-the-middle
attack on low entropy secrets.  What you suggest is clearly
broken.  As Peter noted in earlier posts, protocols like SPEKE,
EKE, and SRP-3 fix this.

> To the best of my knowledge, you can only defeat the man in the middle by
> using digital signatures. [...]

To learn about the other ways, visit www.IntegritySciences.com.

>  [...] You need to have a trusted central signing
> authority if you want to immediately trust a stranger. You can use the a
> user generated signature only if A and B are willing to build a
> relationship, and learn to trust each other over a period of time.

You need more than that to immediately trust a stranger.
You also need to know what you should trust him for, and why.

DH and public-key crypto in general have many great uses, beyond 
just authentication between strangers.  The methods we've been 
talking about let you safely verify a small secret with another party,
regardless of whether or not you can trust that party.
Central signing authorities don't solve this problem.

-- dpj

======================================================
David P. Jablon
Integrity Sciences, Inc.
[EMAIL PROTECTED]
<http://www.IntegritySciences.com>



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

From: [EMAIL PROTECTED]
Subject: Re: Are LFSR's codebook rngs?
Date: Mon, 12 Apr 1999 13:57:44 GMT


> All FSR generators have a PERIOD with which they repeat.  Thus there is
> a cycle of values that forms a loop in the state space.  No matter where
> you start on that loop you will end up where you started after PERIOD
> steps.
>
> Some FSR cycles have periods of one or two while others have periods of
> 2^WIDTH-1.  A long period is considered a Good Thing.
>
> For more information read "Shift Register Sequences" by Golomb revised
> in 1982.
>

Ok, so I am right?  It will produce the same sequence just shifted....

BTW, are there any good online sources for LFSR's?  I really don't want to
buy a book to learn about it...

Tom

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Can someone think this through, please.  (PGP)
Date: Mon, 12 Apr 1999 15:31:42 GMT

Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote, in part:

>Then does it follow that if you use the
>same first byte from the original message that you get the same output
>from this first byte?  And if so, then once you have determined the
>first original byte that you can follow the same procedure and determine
>the second original byte and so on until the full original message is
>determined?  If not why not?

You can't really take a 200-digit number to a power modulo a 200-digit
prime one byte at a time in that sense: you need to do arithmetic on the
whole number, not just one byte of it.

John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html

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

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 12 Apr 1999 14:34:14 GMT
Reply-To: [EMAIL PROTECTED]

On 12 Apr 1999 08:56:32 -0500, [EMAIL PROTECTED] (Herman
Rubin) wrote:

>There are many things known which can affect the distribution
>of spin.

How about for photons?

>For them to be equiprobable, these need to be absent,
>and furthermore, something to make them exactly equiprobable
>has to occur.

What does it mean to say "something to make them exactly
equiprobable"? Why does something need to be a cause of quantum
equiprobability, other than symmetry?

>The same applies here.  There are physical forces which affect
>this; the effect may be far less than the accuracy of measurement.

If the particle is a photon, what might those forces be?

Bob Knauer

"The contagious people of Washington have stood firm against
diversity during this long period of increment weather."
- Marion Barry, Mayor of  Washington DC


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

From: [EMAIL PROTECTED]
Subject: Re: Skipjack Decrypt Problems
Date: Mon, 12 Apr 1999 15:43:32 GMT



  Thanks, someone was kind enough to let me see their code and I found the
errors in my inverse A&B rules and F table use. Thanks for the quick reply!




In article <7es64v$26v$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
>
>
>   Following the Skipjack algorithm specifications downloaded from NIST I've
> succeeded in correctly encrypting, but the code I've written does not decrypt.
> I believe my problem is in my interpretation of the inverse Rule A and inverse
> Rule B, but could be elsewhere.
>
>   I'd appreciate it if someone could let me know where I could download a 'C'
> implementation of Skipjack or could take a look at my decryption functions. My
> C code for decrypting Skipjack can be found at:
>
>   www.geocities.com/ResearchTriangle/Facility/4150/skipjack.txt
>
>   Thanks.
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
>

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is public key crypto just Snake Oil??
Date: Mon, 12 Apr 1999 15:38:19 GMT

Peter Gunn <[EMAIL PROTECTED]> wrote, in part:

>I must be missing something here?? What is it??

It is true that the man-in-the-middle attack does mean that public-key
cryptography can't really be used to establish secure communications over
*just any* connection.

However, it is still useful in some situations.

1) A company could put a hash of its public key on its billboards or TV
commercials.

In general, there are channels of communication such that it's hard to
tamper with them to insert false messages, but easy to eavesdrop.

2) One might trust a certificate authority to issue accurate public-key
certificates...

without wanting to give them a copy of your private (or conventional) keys.

After all, issuing bogus certificates involves a risk of getting caught,
where eavesdropping does not.


Thus the man-in-the-middle attack does not mean public-key cryptography is
*useless*, but it _does_ mean it is no panacea, which people keep
forgetting.

John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html

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

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Mon, 12 Apr 1999 16:22:57 GMT

Terry Ritter wrote:
> But if we see amplified zener noise producing the characteristic flat
> frequency spectrum we almost have to attribute that to shot noise or
> otherwise named impulsive noise of a similar form.  It's larger than
> Johnson or thermal noise, and it's not "transistor noise" which is
> 1/f; it is sometimes called "avalanche noise."

Okay, I'll take your word for the magnitude of the effect in your
set-up.  I did look at your Web page on this, and it is interesting.

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

From: [EMAIL PROTECTED]
Subject: LFSR polynomial testing
Date: Mon, 12 Apr 1999 16:50:17 GMT

I found a program on the net for testing LFSR polynomials, it isn't a really
helpful program (works backwords....), anyways, I was wondering if anyone had
a program to test for valid LFSR polynomials (LFSRs of any bit length)?  In C
would be the best, or MS-DOS .EXE format.

Thanks in advance.

BTW, is the AC definition of LFSRs really that off?  I read the section a
couple of times, and it seems reasonable to me...

Tom

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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


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