Cryptography-Digest Digest #41, Volume #13 Mon, 30 Oct 00 01:13:00 EST
Contents:
Re: CHAP security hole question (David P Jablon)
Re: Padding scheme? (SCOTT19U.ZIP_GUY)
Re: Algorithm/code to encrypt to readable text (SCOTT19U.ZIP_GUY)
Re: CHAP security hole question (David P Jablon)
Re: Psuedo-random number generator ("slak-")
Re: Psuedo-random number generator ("slak-")
Re: ring homomorphic signature and encryption (Matthew Skala)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: CHAP security hole question
Date: Mon, 30 Oct 2000 04:48:13 GMT
Continuing a perhaps futile dialogue on CHAP vs. strong password
authentication, with a surprise ending where I almost lose it
in a most intemperate response.
In article <8tcv5s$soj$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
>>> [...] It also seems to me that
>>> http://www.IntegritySciences.com/password.html gets the notion of
>>> challenge/response protocols such as CHAP wrong; the authenticatee in a
>>> CHAP exchange does not learn the secret if it was not already known.
> In article <[EMAIL PROTECTED]>,
> David P Jablon <[EMAIL PROTECTED]> wrote:
>> No. You've misunderstood. That page starts out with a breezy discussion
>> that does indeed gloss over the difference between a hashed password and
>> a clear-text password. However, if you look at the middle of the page
>> you'll find a crucial conservative assumption -- that the password is small.
>> Under this assumption, a hashed password is essentially equivalent to
>> the password. And therefore, so the argument goes, CHAP is crap.
>>
>> Here's how a malicious authenticatee learns the password in CHAP:
>> He sends a random value R, and receives Hash(password, R).
>> In one failed run of the protocol he can verify an unlimited number
>> of guesses for the password off-line, by comparing the response to
>> Hash(guess_1, R), Hash(guess_2, R), etc., until guess_i == password.
[Vernon]
> Please read RFC 1994 or RFC 1334, and see that is wrong. CHAP works by
> - authenticator sends challenge
> - authenticatee responds with hash of the challenge and secret
> - authenticator says ok or not
[David]
Forgive my misunderstanding of your term "authenticatee", but neither of those
documents defines it. In RFC 1994, the challenger is the "authenticator" and the
hasher is the "peer". It doesn't take a genius to see that replacing "authenticatee"
with "authenticator" in the attack described above is the only interpretation that
makes sense.
> A reasonable CHAP authenticator implementation does itself not know the
> secret when it sends the challenge. Sending the challenge before knowing
> the secret is good for security, improves code modularity, and in some
> cases can significantly speed up the creation of the PPP connection.
All of which is quite irrelevant to the attacks being described.
> The authenticatee obviously cannot learn anything more than the boolean
> ok/not-ok answer that it does not already know. Thus the claim that a
> bad guy can send a random value R and so forth is obvious nnsense.
Wrong. A bad guy can pose as the authenticator, obtain a hashed
response, and then start guessing the password offline.
Aaron Spangler had a web site up for quite a long time doing exactly that,
grabbing NTLM hash responses of NT passwords from people browsing by.
> It is possible for a third party to snoop on a successful CHAP exchange
> between an authenticator and an authenticatee, both of whom know the
> secret, and to compute the secret that was used at that time. ...
Yes, that too. Now you're starting to get it.
>... However,
> that does not imply that the third party can now pass a challenge
> by the athenticator. If the authenticator is using a varying, hard
> to predict secret, such as S/Key or a smart card, the bad guy has only
> one of a series of a useless series of secrets.
Fair enough. Simple replay is just one attack that might not work, and
smartcards and OTP systems do have their place. But you seem to be
backpedalling now.
> Yes, it is common for a constant poor password to be used for the CHAP
> secret, and so a third party can discover the password by watching a
> succssful session and doing a lot of computing, possibly vastly reduced
> with a dictioncary. However, given what CHAP (not MS-CHAP) is protecting
> in PPP, it would be silly to worry about such dangers.
Really now? That philosophy seems at least socially irresponsible.
All passwords should be considered highly sensitive data.
What if someone uses or re-uses a "lowly" PPP password for something
important, either by accident or perhaps simply due to ignorance of
the threats?
> Moreover, because CHAP and PAP are used between computers, and because
> smart cards are now common, common, freely redistributable PPP
> implementations make provisions for smart card and similar sources of
> secrets.
There is a valid point about using CHAP as a safe protocol between two computers,
which presumably can remember large secrets, yet it ignores the
fact that people often set such secrets based on a password. EKE & friends
provide a nice secure way to at least configure or bootstrap such keys.
But I just don't buy the argument that everyone who matters has a smart card,
with readers on all their workstations.
>[...]
> http://www.IntegritySciences.com/password.html starts out with that
> misunderstanding or false generalization of "network password protocols"
> that Mr. Jablon repeated above.
Anyone else out there with similar feelings? Only *specific* criticism is
appreciated. I haven't yet seen you cite a single false or misleading
statement, other than that "authenticatee" confusion from an earlier post
in this dialogue.
> http://www.IntegritySciences.com reeks of sales "breezy discussions."
> If it is not 98% pure snake oil, you couldn't prove it by me. ...
So your nose objects to the style of our web site. I'll take it under
advisement. It is a difficult job to communicate new cryptographic
concepts in layman terms in an interesting and exciting way.
But I feel compelled to point out that the *brain* is the only reliable sense
organ for detecting snake oil. So if you don't trust yours to the task,
ask around.
>... The
> claims that all other authentication schemes are obsolete, easily
> broken, and should be replaced by IntegritySciences Technology is only
> the first that blows the fuses in my Technology meter**. By looking
> hard, I did find statements that might have technical merit, such as
> what might be a reference to what I've tried to describe above of a
> third party snooping on a sucessful CHAP handshake, but I could be as
> mistaken about that as are the people who find all possible knowledge
> encrypted in ancient poetic texts.
While you're replacing that short fuse, take some time to look over
the large body of work listed at www.IntegritySciences.com/links.html,
as I originally posted. We're neither the first nor the last to develop
strong password systems. So if you dispute our claim that this work
as a whole renders the listed pre-1990 password systems obsolete,
you should pick one out and explain why.
[David asked politely]
>> Also, out of courtesy, please "Cc" me directly too, when you choose
>> to post your comments to the world at large.
[Vernon objected with]
> I'm sorry, but I follow the decades old netnews conventions and stick
> to either email or netnews, and not both. Discussions that are public
> should be public. Most people with a few years of experience with netnews
> curse the abmonination of newsreaders that send so called courtesy copies.
>
> To save me the work of adjusting my email filters, please follow those
> decades old netnews conventions and *stop* sending me "courtesy" copies.
>
> Vernon Schryver [EMAIL PROTECTED]
>
> ** Whenever you hear a form of the word "Technology," replace it with
> an appropriate synonym for post-digestive male bovine grass and grain,
> and notice that the speaker's intended meaning is far more clear, albeit
> usually more clear than the speaker intended.
Ohh, now I get it. Bovine excrement. You're calling my work "bullshit".
That's very clever for an .... Oops, damn it. I almost dropped my
Sales Person hat. What I meant to say is:
"Thank you very much for your feedback."
======================================================
David P. Jablon
[EMAIL PROTECTED]
www.IntegritySciences.com
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Padding scheme?
Date: 30 Oct 2000 04:47:07 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>I'm not certain if this padding scheme is new. If it's not, don't sue
>me :)
>
>messagesize and blocksize are measured in bytes.
>
>x = (messagesize + 1) mod blocksize
>if( x == 0 )
> y = 0
>else
> y = blocksize-x
>append y Truly Random bytes to the message
>append a final byte that has the lower log2(blocksize) bits set to y,
>and the upper bitlength(byte)-log2(blocksize) bits filled in from your
>Truly Random bitsource.
>
>To remove the padding, read the message up to the last byte, use a mask
>to extract y, and discard the y previous bytes.
>
>Note that the scheme requires that blocksize be fewer than
>2**bitlength(byte) bytes, and works best if blocksize is a power of 2.
>
>Does anybody see any weakness in this scheme?
>
The main objection I see is the same when people bitch about the
"random bits" in a OTP. The weaknes is you have to count on having such
bits. I have nothing agains using random bits. But I prefer to have a sound
method with out the use of the "random god" and then add random later.
But I would prefer to use the random number as a number use to rotate
the source file and then DSC to mate it in. Then optimal end treatment
such as Matts or mine that works on any file to match the block size
of the encryption used. That is what I would so if for some reason I
want to padd out to match the encrypted block size.
The other error I feel that is there is when you start doing this
for real the field you use to contain the data must be able to account
for all bit patterns you still have to play same games with this so that
every combination of bits is possible. Even if you try to add a
constant to a file the way I did there are optimal end considerations
that come out in the details.
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Algorithm/code to encrypt to readable text
Date: 30 Oct 2000 04:49:08 GMT
[EMAIL PROTECTED] (G) wrote in <8titg9$1ok$[EMAIL PROTECTED]>:
>Hello,
>
>I'm trying to figure out how to do the following in VB:
>
>serial = 123456789
>date = 12/29/00
>
>ciphertext = abcdef123
>
>where the serial serves as a key and the date as plaintext. It's important
>that the ciphertext consist of typical letters and numbers. The only code
>I've found for VB is xor functions which generate non-standard characters,
>in addition to letters and numbers. Can anyone point me to some algorithms
>or code examples?
>
>Thanks
>
>
>
I have code in C that would expand a file to the character
set of your choice in a bijective way. But it may me difficult
to but it in VB
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: [EMAIL PROTECTED] (David P Jablon)
Subject: Re: CHAP security hole question
Date: Mon, 30 Oct 2000 05:26:25 GMT
Vernon,
You've made more disparaging remarks about the content at
www.IntegritySciences.com, having previously called it
"bovine excrement". I asked you politely to state the
basis for your assertions, and now, you continue without basis to
complain about our presentation of this new technology.
Strangely, you even had the gall to admit that you didn't read enough
to understand how these protocols work or even understand the nature
of the attacks that they prevent.
Sure, I'm tempted to continue our debate in an Aykroyd/Curtin style
("Jane, you ignorant slut ...") but I'm losing the good humor to
pull it off.
I'm simply requesting that you apologize.
If you can't, then I urge you to PLEASE READ THE PAPERS in the field.
If you cannot understand them, then please ask others for their help.
Vociferous uninformed opinions are worse than useless.
I can only think that you are perhaps a victim of too many other
disappointments in new technology, so that you can't imagine that
what we describe could possibly live up to our claims.
For now, I'll simply point out where you are way off-base.
In article <8tdqkl$9d9$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
> What I don't like is the salesmanship on those web pages, the gross and
> misleading eaggeration and the overly broad and false generalizations.
The tone of our site was designed to generate enthusiasm for this technology,
even though it seems to have done the reverse in your case. Too bad.
But as a first prioirity, I have strived to insure that the content is
technically accurate, and there should be nothing even close to a false
claim here. If you were merely stating that our salesmanship is bad,
maybe I'd just spend some more time and money to fix it, but you have
gone much further than that.
In your most recent post you provide this example:
> E.g. on http://www.IntegritySciences.com/password.html the obviously false
>
> With obsolete network password protocols, whoever goes first
> gives away the password.
If this is so "obviously false", where is your counter argument?
I challenge you: Pick some of the listed "obsolete" protocols and defend them.
Tell me why it's just fine to give the password away in the process of proving
it, or show me why it can't happen.
Before you rush into an answer, note that a typical password can
be "given away" in many ways. And before you suggest that there's no
problem as long as you give it to the "right" party, think about how
this might not happen, over a network.
The point is: Why send any information about it when you can just
prove it giving nothing away? This "zero-knowledge" aspect is a central
benefit of the new methods, and why we brand *a lot of* other password
methods (but not "all", as you mis-stated) as "obsolete".
And *please* take your time. It took me years to come to appreciate the
nuances of this field, to discover (and rediscover) solutions, and to
provide ways to explain this material to at least try to make it accessible.
I wouldn't expect *anyone* to be able to come up to speed in the subject
in just a day or two.
So, because you just learned about it, I'm inclined to dismiss your immediate
visceral reaction as some kind of anomaly. So think about it.
If then, you still feel the claims are exaggerated, then show me exactly what
you don't like. But the burden here is on you.
Your further comments are equally unconvincing:
> Passwords are a problem, but "rapidly becoming a weak link in the crypto
> chain" is overstated. Passwords can't be the weak link until there real
> encryption is common. [?] ...
Funny. Even though you are responding to Tom Wu's statement,
I think the statements on our site that support this view are among the
least controversial on the site, being almost self-evident.
People aren't getting much better at remembering or computing things,
and computers obviously are. Furthermore, strong encryption of the sort
that requires large keys is becoming very common.
> ... It's decades late to be warning about the evils of
> weak paswords. ...
Again, passwords are being used and abused at least as much today as
ever before. And our position is clearly *not* to warn about the "evils" of
passwords, but rather the problems with bad password *systems*.
And if you think it's simply "too late" for our message to make a difference,
what in the heck *are* you so upset about? Better late than never.
>... Yes, what was once a good, strong password is now almost
> as weak as your mother's maiden name, and what is now a good strong
> password is hard for humans to remember. However, the best I can see
> through the smoke at those web pages is that Integrity Sciences' solution
> is one among several--never mind the worst that the pages suggest to me.
Look a little harder sir. The only smoke here is emanating from your own
smoldering head. In that regard, I suggest that you keep your "worst thoughts"
to yourself until you cool down.
Integrity Sciences has presented a *full disclosure* of how our technology
works. There is absolutely nothing obfuscated here. It is fully described
and peer-reviewed in published papers. We've made open source code available.
And we go further than almost any other company to provide links to the
largest body of supporting and related educational material in this field,
even of our competition, from all over the Internet and elsewhere.
Smoke? Give me a damn break.
But even if you still find our web site inadequate, as you apparently do,
don't let it hold you back. Go ahead and learn for yourself from your
own resources.
> It is not always possible or even desirable to verify passwords on line
> for any of the many meanings "on line," unless you happen to be selling
> an on line key verifying service (e.g. Verisign) or a a new protocol that
> makes all previous protocols obsolete.
It seems obvious that the continued use (and abuse) of passwords
in both local and network settings will continue for a very long time.
Our point is simple. When used over a network, one can do much better
than the "status quo".
The fact that Verisign, Entrust, Lucent and many others are taking an
interest in this field, both academically and commercially, just might say
that there's *something* of value here.
And if by chance there is a new protocol that makes earlier protocols
obsolete, and it solves security problems, and people want to actually
pay to use it, where is the harm? Are you so worried that my little company
is going to hold the industry hostage for patent fees, and force the people
of the world to use passwords against their will? Get real.
Finally, about your last "criticism" ...
> http://www.IntegritySciences.com/obsolete.html says meakly: [<- meek?]
>
> All of these [legacy] password methods are now obsolete because of the
> development of practical zero-knowledge password proofs.
Vernon, you have publicly asserted without basis that our web site
is misleading, exaggerated, snake oil, and bullshit, and you have done
this while at the same time admitting that you haven't a clue about
how our technology works or even a clear notion of what it does.
And now, finally, in this second cited example, which I can only assume
is intended to back up these assertions, the worst that you can say
about our statement is that it's "meek"?
There is just no pleasing you today.
======================================================
David P. Jablon
[EMAIL PROTECTED]
www.IntegritySciences.com
------------------------------
From: "slak-" <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sun, 29 Oct 2000 22:40:52 -0700
I must say, that was the most well-thought out personal attack /
psychological attack I've seen in a long time.
Brian Wong <[EMAIL PROTECTED]> wrote in message
news:8tiiel$s5k$[EMAIL PROTECTED]...
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:8tieh2$be5$[EMAIL PROTECTED]...
> > In article <[EMAIL PROTECTED]>,
> > Peter Maxwell <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > can you provide a link to a paper or page written by a respected and
> > well
> > > known member of the scientific communicty with adequite proof that
> > quantum
> > > phenomena are unpredictable ?
> > >
> > > i am currently an undergraduate student in physics and would like to
> > hear an
> > > alternate perspective on quantum phenomena, ie that it is not
> > unpredicatable.
> >
> > Well if you can't observe something and it's unpredictable then it's
> > random. We can't see atoms and so on since they are too small, and
> > well they behave somewhat chaotic, so as it stands atomic decay is
> > random for now.
> >
> > Tom
>
> This is so blatantly false that I cannot believe that you would present
that
> as fact. Your statement is either indicative of your gross ignorance of
even
> the rudiments of modern physics or your pathological need to participate
in
> a discussion that you add nothing to. STMs can routinely resolve surface
> features the size of individual atoms. The decay of an individual atom is
a
> random process; this is a neccesary consequence of quantum mechanics.
There
> are no "tiny clocks" or other such timers hidden inside radioactive atoms
> that tick towards a deterministic decay.
>
> Hidden variable theories are incompatible with the idea of quantum
mechanics
> as local. Many-worlds is an alternative interpretation of QM that moves
the
> indeterminism from the level of atoms to the idea of observations as
> splitting the universe into divergent paths, each proceding along strictly
> classical paths until the next such splitting. There are certain
> philosophical objections to this theory, as well as the very real one of
the
> lack of its ability to explain why the Copenhagen interpretation of QM is
> able to make probabilistic assertions about the behavior of quantum
> mechanical ensambles (although Everett does have a nice argument along the
> lines that the set of observers who do not see events consistent with such
a
> probability distribution must be measure 0, that unfortunately relies on
an
> additional assumption beyond those shared by many-worlds and Copenhagen).
>
> Brian
>
>
------------------------------
From: "slak-" <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sun, 29 Oct 2000 22:58:15 -0700
My sound blaster example was just an idea of something already present in
most systems. A more logical idea would be a cheap hardware addition to
motherboards, for instance, that would pickup high frequency radio waves.
If they were high frequency AM waves ( I believe ) they would be affected in
some way by the sun. It sounds logical to me, however I'm not a physics
guru like the other million people that posted above :)
It's just an idea, a meager posibilit, and a posibly cheap solution.
Eric Lee Green <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> slak- wrote:
> > Would it not be feesable to use your sound blaster to scan a number of
> > radio-frequencies and do a series of calculations based on the results
to
> > generate a seed?
>
> This assumes that radio "noise" is random. It isn't necessarily so. In
> addition, the Sound Blaster does not scan "radio frequencies". It detects
> audio frequency noise, which is much lower frequency than "radio
frequencies".
> Inside a computer, such noise is usually inductive currents generated by
the
> 60hz hum of the power supply (or slightly higher hum of its switching
> components), and thus is not really "noise", it is actually quite
predictable.
>
> This is not to say that this hum is not useful. For example, the bit skew
> between this hum and some other (non-power-supply-dependent) data source
may
> be useful as a source of entropy. But as a source in and of itself, it's
> useless.
>
> --
> Eric Lee Green [EMAIL PROTECTED]
> Software Engineer "The BRU Guys"
> Enhanced Software Technologies, Inc. http://www.estinc.com/
> (602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: [EMAIL PROTECTED] (Matthew Skala)
Subject: Re: ring homomorphic signature and encryption
Date: 29 Oct 2000 21:41:15 -0800
In article <8tdjc3$9uj$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
>homomorphism). I am interested in a signature scheme which is a
>homomorphism for both * and + over Z_N^*.
Homomorphism from what to what? From the ring you mention onto
itself (i.e. an automorphism)? From that ring onto a subring of
itself? From that ring to some completely different ring?
What immediately occurs to me is that there may not be very many
homomorphisms of the type you want, at all; thus it may be difficult to
hide a secret by selecting one of them. With a cryptosystem that always
produces a group homomorphism, there are a lot of those to choose from and
so the attacker can't easily determine which one was selected.
Chapter 15 of _Contemporary Abstract Algebra_ by Gallian, one of the
standard textbooks, includes this reference:
J.A. Gallian and J. Van Buskirk, "The Number of Homomorphisms from Z_m
into Z_n", American Mathematical Monthly 91 (1984): 196-197.
You might want to look that up.
--
Matthew Skala
[EMAIL PROTECTED] :CVECAT DELENDA EST
http://www.islandnet.com/~mskala/
------------------------------
** 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
******************************
