Cryptography-Digest Digest #392, Volume #9 Wed, 14 Apr 99 19:13:03 EDT
Contents:
Re: PGP 6 is JUNK (Paul Koning)
Re: Security problems: Europe (Jim Dunnett)
Re: SNAKE#8 (Peter Gunn)
Re: Is public key crypto just Snake Oil?? (David P Jablon)
Re: Comments to DOJ re NICS (Paul Rubin)
Re: True Randomness & The Law Of Large Numbers ("Franzen")
Re: AES Round 1 deadline: 15th April 1999 (John Savard)
Re: PGP 6 is JUNK (Paul Rubin)
Re: discreate logarithm problem ([EMAIL PROTECTED])
Re: Where can I find PGP for Win98? (Tom McCune)
Large Key Length XOR and Scramble Question ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: PGP 6 is JUNK
Date: Wed, 14 Apr 1999 14:22:07 -0400
Charles Booher wrote:
> ...
> I am also somewhat familiar with earlier versions of PGP, but you will need
> to bear with my ignorance on a few topics.
>
> 1. What is the mathematical representation of discrete numbers in PGP 2.6.2
> ??
>
> How does the prime testing algorithm work.
>
> I am not capable, because I do not have the time, of showing what total
> garbage PGP has been from word get go.
I wouldn't have thought it possible for someone to outdo DScott, but
here is someone who clearly succeeded.
Fancy that, he doesn't know elementary things like primality tests.
He's unable to read documentation to find out how numbers are
represented
(something so simple you don't even need to read the code). He rants
and
raves with no connection to reality. And yet he expects people to
believe
that his software is better than PGP.
Sober up, bozo.
paul
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: Security problems: Europe
Date: Wed, 14 Apr 1999 18:33:21 GMT
Reply-To: Jim Dunnett
On Tue, 13 Apr 1999 22:19:06 GMT, [EMAIL PROTECTED] (Doug
Stell) wrote:
>On 11 Apr 99 16:09:55 GMT, [EMAIL PROTECTED] wrote:
>
>From my experience, I find it hard to believe that the NSA or CIA are
>involved in wide-spread industrial espionage. These agencies generally
>concern themselves with national security are are black holes as far
>as American industry is concerned.
You're naive! Part of their mission is 'the economic
well-being of the United States' as well as national
security.
They ALL do it. The DGSE indulges in economic COMINT,
as no doubt does Germany's BSD.
--
Regards, Jim. | Perhaps if the English were given more reason
olympus%jimdee.prestel.co.uk | to be proud of themselves, they may see that
dynastic%cwcom.net | it isn't so bad to be joined by land to a
nordland%aol.com | neighbour they do not control.
marula%zdnetmail.com | - Simon Heffer on Scottish Independence.
Pgp key: pgpkeys.mit.edu:11371
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Re: SNAKE#8
Date: Wed, 14 Apr 1999 21:24:43 +0100
David P Jablon wrote:
> In article <[EMAIL PROTECTED]>,
> Peter Gunn <[EMAIL PROTECTED]> wrote:
> > [...]
> > So, new approach... attempt to include the password data in the DH public
> > key exchange, but avoiding symmetric encryption (in other words, try to
> > avoid copying EKE exactly :-)
>
> It looks like your "new approach" does copy EKE exactly.
> And if you're trying to refine EKE in some way, you may want
> to try to find a better name.
Many apologies to whoever owns this... wasnt intentional :-)
>
>
> > So, here it is SNAKE#8...
> [... definitions trimmed ...]
>
> f(N,P) = (N-P)%p
> >
> > 1) A->B: y1=(P+((g^x1)%p))%p, U
> > 2) B->A: y2=(P+((g^x2)%p))%p, s1
> > B: key=H((f(y1,P)^x2)%p)
> > A: key=H((f(y2,P)^x1)%p)
> > 3) A->B: E[key](s1), s2
> > 4) B->A: E[key](s2)
>
> Here's one abstract description of EKE:
>
> A->B: y1 = SymmetricEncrypt(P, (g^x1)%p), U
> B->A: y2 = SymmetricEncrypt(P, (g^x2)%p), s1
> B: key = H(SymmetricDecrypt(P, y1)^x2)
> A: key = H(SymmetricDecrypt(P, y2)^x1)
> A->B: E[key](s1), s2
> B->A: E[key](s2)
>
> The methods are identical when:
> SymmetricEncrypt(P, m) = (m+P)%p
> and SymmetricDecrypt(P, m) = (m-P)%p
>
> If your goal is to circumvent the EKE patent,
> you'll have to work harder. Their claims are even
> more abstract, and less restrictive, than what's shown here.
Errr... yes and no... I'm not intending on ripping anyone off,
and Im glad I've stiumbled across something that would have worked
even if it belongs to someone else and it was just dragged out of
my subconcious (Ive read a couple of papers but I couldnt
repeat them deliberately without having them infornt of me :-)
This is also quite scary as I didnt realise it was possible to
patent something as basic as addition/subtraction as a
symmetric encryption system. :-(
So, is it true that any function which which performs
a reversable operation using P on the DH public values
is outlawed??
Thanks pointing this out anyway, I probably need to spend
more time looking at whats not allowed... especially
outside of SPEKE and SRP... which Ive been looking at quite
a lot. Nice web site BTW, I keep meaning to set one up :-)
What about the following idea then? it looks
a bit too obvious to me... (SNAKE#9 ??)
Client: sends g^A
Server: sends g^B
Client: works out key = g^BAP using g^B, A, and P
Server: works out key = g^ABP using g^A, B, and P
1) A->B: y1=(g^x1)%p, U
2) B->A: y2=(g^x2)%p, s1
B: key=H((((y1^x2)%p)^P)%p)
A: key=H((((y2^x1)%p)^P)%p)
3) A->B: E[key](s1), s2
4) B->A: E[key](s2)
I suppose this idea could be extended so that
A sends g^AP, B sends g^BP, and they both work out
g^ABPPP ... but would this offer any advantage??
As usual all comments are appreciated :-)
ttfn
PG.
PS Any archives of the old sci.crypt postings for
SPEKE and SRP??
------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: Is public key crypto just Snake Oil??
Date: Wed, 14 Apr 1999 20:38:16 GMT
In article <[EMAIL PROTECTED]>,
Doug Stell <[EMAIL PROTECTED]> wrote:
>On Mon, 12 Apr 1999 11:42:53 +0100, Peter Gunn
><[EMAIL PROTECTED]> wrote:
>
>> Is public key crypto just Snake Oil??
>
>Certainly not. It is a very mature field and is in wide-spread use. It
>probably even protects our lives and liberty every day. Some of it is
>far better than anything we can discuss in this forum, contrary to
>what Wired readers have been led to believe.
>
>>Ive now come to the conclusion that it definately is possible to have
>>secure point to point network connections based only on a short
>>low entropy shared secret, as per EKE, SPEKE, SRP, (and maybe
>>even SNAKE ;-)
>
>Passwords are generally bad, because they have to be low entropy
>values that us weak-minded humans (compared to a computer) can
>remember. A shared secret is even worse. Worse of all, is a plaintext
>password sent over the wire for all to read.
>
>Passwords should be kept as closely limited to the human as possible,
>such as unlocking an encrypted private key on one's local platform.
>Beyond that, it's best to banish passwords from your thinking.
Doug, in your attempt to educate sci.crypto neophytes,
you've climbed to the opposite side of this mountainous argument.
Both slopes are slippery, and in your advice,
I think you've spilled some oil yourself.
Knowledge-based authentication will always be important.
The better debate is on how to protect that knowledge,
while using it to strengthen the system.
All password are shared secrets. You've just advocated
that the password-verifier must always be kept close at hand.
This advice can be either useful, or extremely foolish.
Take traditional "two factor" authentication, as in a PIN
used in combination with a mag-stripe card, smart-card,
or a palm-computing device. Ideally, you don't want the token
factor to contain the knowledge factor, otherwise when you
lose it, the knowledge factor is lost, or at risk.
And looking at ordinary PC-based password systems,
it's nice to avoid having password-derived data stored
permanently on the local disk, when the password is used
for remote authentication.
In many cases, it's better to have the PIN be a completely
independent factor, which is verified by a remote system
elsewhere on the net. SPEKE and related methods provide
the strongest form of remote PIN verification, which
doesn't rely on other factors.
>>But the problem of the man-in-the-middle that I came across when
>>investigating the Diffie-Hellman key exchange has started me thinking
>>(or maybe the beer is wearing off? heehee :-)
>
>We all know that plain, unauthenticated Diffie-Hellman is open to the
>MIM attack. However, there are lots of ways to solve that problem,
>mainly via authenticated keys. Public-key bearing certificates, signed
>by a mutually trusted authority, is the classical model. A published
>and trusted list is a simplified version of that model. PGP's web of
>trust is another model.
Password-authenticated DH is another solution, which Peter's
been exploring. Each solution has it's benefits and limitations,
and in our modern age, we have the power to combine them
intelligently. The days of the "either-or" argument are past.
>>If this is the case, wouldnt it be simpler to have a traditional
>>username/password account with the trusted authority, and
>>send them the hash for a document you want to sign, and
>>have them return a signature of the hash encrypted using
>>some 'private key' unknown even to you. Similarly, people
>>could verify the signatures by simply sending off the signature
>>and your username, and receive the hash for the document
>>which they could then check.
>>
>>So, as far as I can see, you dont need public key crypto
>>to do this?? Just plain old symmetric encryption will do,
>>us humans just need to remember a short username &
>>password, and signatures are nice and short.
>
>This is a very old concept, from the days when we had only symmetric
>encryption. It has been overtaken by events (OBE) with the advent of
>public key cryptography. The biggest problem with these, for signature
>or encryption, schemes is that they require on on-line third party.
>Public key removes that requirement.
I always thought that the "elimination of the always-on-line
authority" benefit was a little oversold. Fortunately, PK
crypto techniques are fundamentally useful in lots of ways.
>>I must be missing something here?? What is it??
>
>No and Yes. You are simply going through evolutionary process that the
>discipline as a whole has gone through in the past 25 years.
>Cryptography is a huge and complex field. What you are missing is the
>knowledge base that comes through experience and study. When you get
>up to speed, you will realize that SNAKE is the snake oil.
Hopefully, we're all participating in this ongoing process :-)
>From earlier posts, we know "SNAKE" doesn't work.
Yet the goal of strong remote password authentication is worthy,
and the benefits of EKE-style methods neatly complement
the limitations of other (ahem) less evolved public key systems.
-- dpj
------------------------------
Crossposted-To: talk.politics.guns
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Comments to DOJ re NICS
Date: Wed, 14 Apr 1999 19:55:48 GMT
In article <[EMAIL PROTECTED]>,
Eric Williams <[EMAIL PROTECTED]> wrote:
>> Depending on having a phone available doesn't sound so wise in this
>> situation.
>
>I think I've heard of a recent invention called a "cellular phone". It
>might have applications in this situation.
See above. Cellular phones work in most urban areas. Gun dealers
are not necessarily in urban areas. The cell phone systems with
the most coverage are analog and are terrible for sending data.
I guess a satellite phone might work better but it starts getting
ridiculous.
>> Of course it would. You just backdate the transfer to the day the key
>> was good.
>
>But if DOJ kept records of what signatures were issued to what FLL and
>when (as my proposal included), that scan wouldn't work.
In that case there is no need for a secret key. Just remember the
hash of the whole application. You're no longer verifying anything,
but just looking it up.
------------------------------
From: "Franzen" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Wed, 14 Apr 1999 16:07:27 -0500
On Wed, 14 Apr 1999 00:07:27 -0500, in sci.crypt "Franzen"
<[EMAIL PROTECTED]> wrote:
>>My chi-square table predicts 98% of the times I flip one million fair
>>coins I will get 500,007 to 501,284 (and its inverse, 498,716 to
>>499,993) heads.
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary replied Wed, April 14, 1999 at 1:39 AM:
>I'm not happy with using a chi-square table to approximate a binomial
>distribution. We could do better with the normal distribution, but
>then we would have to convert to standard form, which would confuse
>me. Being a simple man, I prefer to use the binomial directly, even
>if that must inevitably be harder. And it looks to me like we get:
>
>* less than (or equal to) 498712 about 0.5 percent of the time, and
>
>* more than 501,288 about 0.5 percent of the time.
>
>So we get between 498,712 and 501,288 about 99 percent of the time.
I am happier after looking at these numbers. Thank you very much for
your factual contribution.
Are you not able to see how accurate chi-square is. As you seem to
indicate above, the pure binomial distribution is difficult to apply.
What I woke up to from these numbers is what happens when I fold
my binomial distribution in half at the zero point (500,000 heads)
and accumulate the probabilities. The result is an amazingly
accurate chi-square representation.
---
>... like it or not, the single most probable outcome *is* 500,000
>nevertheless. The probability of getting that particular value is
>of course very low (0.0008 or so). As you say, getting this exact
>value would be unexpected and improbable. But the value 500000 is
>what we call "the expectation." It also is the most-probable value.
>
>Even that low 0.0008 probability will decrease in either direction as
>we move away from 500,000. For example, the probability of getting
>exactly 500,200 is down to 0.0007, and the same can be said of
>499,800, so getting these values is even more unexpected and more
>improbable than getting 500,000. The distribution is symmetric and
>values even more distant from 500,000 become even more unexpected and
>improbable.
I plead guilty to imprecision in my former explantion. I was looking
through my chi-square filter.
For example, assume the individual probability for 500,001 heads is
0.00079 (a single increment less than 0.00080). For chi-square
purposes, 499,999 is the same event as 500,001. Therefore, they
(499,999 and 500,001) combine into a total 0.00158 probability for
a single equivalent chi-square event result.
Let us "do" a simple experiment to maybe illustrate the difference
between EV and what I ordinarily expect about the number of heads
before and after one million fair flips:
I chose 499,665 and 500,335 as my ideal measuring points. You chose
500,000. We then let the computer do 2,000 sequences of one million
coin flips each (while we drink our favorite libation).
About 1,000 of these sequences will result in 499,665 to 500,335 heads.
We will use only those results whose head count is in this range to
control for bias (this is a real use of bias as a concept).
Let us say the first actual head count is 500,168. You get a score of
168 and I get 167. Say the second actual head count is 499,700. You
get a score of 300 and I get 35.
We are measuring the distance from what each of us "expects." As in
golf, low score wins. I leave it up to you to decide who wins.
---
Douglas McLean
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES Round 1 deadline: 15th April 1999
Date: Wed, 14 Apr 1999 21:09:04 GMT
David Crick <[EMAIL PROTECTED]> wrote, in part:
>Just a reminder (as if one's needed) that the deadline for comments
>on Round 1 of AES is 15th April 1999.
Like the Bulwer-Lytton Contest, they chose a day easy for Americans to
remember...
John Savard (teneerf is spelled backwards)
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: PGP 6 is JUNK
Date: Wed, 14 Apr 1999 21:28:15 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
>I wouldn't have thought it possible for someone to outdo DScott, but
>here is someone who clearly succeeded.
The odd thing is, I remember Charles as someone who knew what he was
doing. I called the phone# in the previous article to ask what
was going on and I got an answering machine.
Could someone be forging posts in Charles's name in order to hassle him?
That would explain why the phone number was also posted.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: discreate logarithm problem
Date: Wed, 14 Apr 1999 21:57:24 GMT
Here is my solution.
How about you answer the original question, so I and the poster can learn
something. Obviously I need to learn more about the DL problem.
Sorry for the confusion.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Tom McCune)
Subject: Re: Where can I find PGP for Win98?
Date: Wed, 14 Apr 1999 21:57:47 GMT
=====BEGIN PGP SIGNED MESSAGE=====
In article <7f29ek$emb$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jennifer Lu)
wrote:
>As titled.
>Thanks.
For links, take a look at:
http://www.borg.com/~tmccune/PGP.htm
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
Comment: http://www.Tom.McCune.net - Default: RSA 2047 0x90321F49
iQEVAwUBNxUPUWR4bNCQMh9JAQGCqgf+OevjzwB1BUkJoGL1DmntOVJrHrrz5rQL
fRXHw9Sxf3nqPeYG8JuoDAx/6uYZOP/pPS7vyjUY7u6DM9MCJcz+nAQ76QdkGAjN
I1gPAyp+OFkejf6SvvKm8Mze5V9X6/HkOOX0H6MIBvKiWrGSrlUatLRluN6pMQjv
4ODVvA5yV+h3ZIh5b7oecl4kSAS7PepX6ZA6P8Em2FHlfj0TUoZhrnJavNF81I39
zCLq6Dan66boIZHCIl9sFTe/4TObuxiUdsJgkVbPi3+NK2kizdfZEm5Zov4j2Bpi
xsPIdT/5HeDyTBiRGkEd2Xe3BzMFc8CEfWBEJI9B5scGULotXlsg6w==
=gjtw
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Large Key Length XOR and Scramble Question
Date: Wed, 14 Apr 1999 22:22:09 GMT
Hello again...
What about the following scenario:
- 1 GByte of raw data to be encrypted
- 4Kbit XOR key
- 4Kbit * 4 = 16Kbit Scramble key
- All 20Kbits of key are randomly generated
- Random scrambling of every 16-bit word of raw data after XOR
4Kbits of raw data are XORed with the 4Kbit XOR key to produce a block of
4Kbit XORed data. All 256 16-bit blocks of the 4Kbit XORed data are
scrambled according to the 16Kbit Scramble key. This process is repeated
until the entire 1 GByte of data is encrypted.
The question is: Is this at all secure? Would someone be able to break this
as easily as a simple XOR? How does it compare to 56-bit or 112-bit DES?
Thanks.
Randy
============= 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
******************************
