Cryptography-Digest Digest #43, Volume #13 Mon, 30 Oct 00 06:13:01 EST
Contents:
Re: CHAP security hole question (Vernon Schryver)
Re: Psuedo-random number generator (Tim Tyler)
Re: .java.policy (i figured it out) (Tim Tyler)
Searching for a good PRNG (=?iso-8859-1?Q?Tom=E1s?= Perlines Hormann)
Re: DATA PADDING FOR ENCRYPTION (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: CHAP security hole question
Date: 30 Oct 2000 00:54:48 -0700
In article <[EMAIL PROTECTED]>,
David P Jablon <[EMAIL PROTECTED]> wrote:
> ...
>>> 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.
>> 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
>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.
> ...
>Wrong. A bad guy can pose as the authenticator, obtain a hashed
>response, and then start guessing the password offline.
Ok, I misunderstood the scenario. If the bad guy can pose as the
authenticator, then it is possible do a dictionary attack. However, how
does a bad guy pose as the CHAP authenticator? That generally requires
that the bad guy get a good guy to originate the connection to the bad
guy. That is far from impossible, such as with POTS glare, but it is a
lot harder today with such as ISDN, DSL, and PPP/Ethernet (cable modems)
than it once was. Given the most common situations in which CHAP is used,
in which at least one of the authenticators is intentionally built to be
unable to originate phone calls or any kind of PPP connection, it is
generally literally impossible for the bad guy to pose as th authenticator
that goes first. (Because of the "oracle" problem with CHAP, it is common
to have the "server" PPP peer never go first.)
>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.
NTLM is not the same different protocol as CHAP. In other words, there
are well known reasons why I keep distinguishing CHAP from MS-CHAP. For
that matter, there are reasons why MS-CHAPv2 differs from MS-CHAPv1.
> ...
> But you seem to be
>backpedalling now.
No, as I said from the almost the first, CHAP does have weaknesses. It's
simply that contrary to the claims on the Integrity Sciences web pages,
CHAP has not been made significantly or even noticeably obsolete by what
Integrity Sciences is selling.
That's partly because a PPP implementation that requires a human to
participate in the authentication dance between the computers is lame.
One reason for that lameness is that good PPP implementations occasionally
re-authenticate, and you usually can't ask users to repeat their password
in the middle of sessions (and for obvious reasons you'd probably rather
not save the human's password for re-use). For another, good PPP
implementations can do symmetric demand dialing in which the phone (or
other serial) link is brought up only while there is traffic. Yes, of
course, you don't always want symmetric demand dialing, sometime because
the link is static (e.g. SONET) and sometimes because it is very transient
(e.g. dial-up to consumer ISP account). More commonly, there are business
reasons for ISP's to refuse (few consumers can handle configuring their
systems to receive modem calls and fewer want them). Note also that an
extremely large router vendor has said in private that it does not support
originating phone calls in some products to counter weaknesses in CHAP
that I've mentioned repeatedly and that are unrelated to weaknesses that
Mr. Jablon claims to fix with his products.
>> 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.
No, the value of any password depends on the value of what it protects.
Some passwords are extremely valuable and others are practically worthless.
The monetary value protected by a CHAP secret is generally (but not always)
about $20/month. As I've said from the start, CHAP (as opposed to MS-CHAP)
protects the ability to send IP packets. Thus, what CHAP protects is
generally (but not always) access to the same computer which is wide open
to 300,000,000 people via connections 10X or 1000X times faster than the
CHAP protected IP/PPP connection.
>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?
What if they publish a password used in what Mr. Jablon is selling? What
if they use trivially guessable passwords, such as the name of the account?
What happens if your bank forgets to close its vault at night and gets
robbed? As the doctor says, "Don't do that."
And for the umpteenth time, a well known and published weakness of MS-CHAP
is that it's secret is related to an account instead of merely a stream
of untrusted IP packets. And yes, people often misconfigure UNIX boxes
to use the same names and passwords for user accounts as for PPP. They
also too commonly use passwords that are cannot be protected by anything
including EKE, such the account name. Again, don't do that.
>> 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.
I don't recall claiming that EKE is worthless, but pointing out that
http://www.IntegritySciences.com goes over the top, specifically in
claiming that CHAP and every other authentication scheme is made obsolete
by what Mr. Jablon is selling.
>But I just don't buy the argument that everyone who matters has a smart card,
>with readers on all their workstations.
Currently, few do, and I think and hope that will change. Even after it
has changed, other things will continue to be needed in other applications,
probably including EKE.
> ... It is a difficult job to communicate new cryptographic
>concepts in layman terms in an interesting and exciting way.
I'm among those who think that misleading statements are never a good way
to communicate. It's not that every statement on Mr. Jablon's pages are
false, but that the discussions of real weaknesses are exaggerated and
painted as proof that the protocols are "obsolete" and "inferior:"
] Here is a sample of inferior methods for handling passwords over
] a network. As a group, they encompass most methods in use today,
] on both the Internet and intra-nets.
For example, implementations problems such as the possibly small entropy
in SecurID secrets are supposed to show that the notion of smart cards is
obsolete. Contrary to Mr. Jablon's claim, smartcards are not yet obsolete.
> ...
>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.
Links to other pages as proofs of accuracy are analogous to name dropping
My complaint is not with the links I didn't follow, but with the
http://www.IntegritySciences.com/ pages
> 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.
RFC 1994 CHAP has been explicitly mentioned by Mr. Jablon and on
http://www.IntegritySciences.com/obsolete.html as obsolete, but it has
clearly not been rendered obsolete by what Mr. Jablon is selling for the
purposes for which CHAP is suited, authenticating a pair of PPP peers.
> > ** 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:
On the contrary, I intended to and think I earlier and clearly said that
the http://www.IntegritySciences.com/ pages are filled with exaggerations
and false claims, or what Mr. Jablon called "breezy discussions" and
communicating "concepts in layman terms in an interesting and exciting
way." Those are great alternatives to the T-word.
My comment about the T-word was a repetition of a point I've been repeating
for more than 10 years. Salescritters (i.e. bad salespeople), bad
politicians, Dilbert's bosses, bad trade journalists, and others have made
"technology" a synonym for "bullshit."
I looked for but failed to find the T-word Integrity Sciences web pages.
Perhaps sales people are moving away from it, as they have deserted
"information super highway,"
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Oct 2000 09:47:14 GMT
Brian Wong <[EMAIL PROTECTED]> wrote:
: "Tom St Denis" <[EMAIL PROTECTED]> wrote:
: You are totally incorrect and this is not off-topic since you continue to
: disperse this nonsense that could mislead other readers.
To me it appears that you're the one "dispersing nonsense" with your
"hidden variable theories are incompatible with the idea of quantum
mechanics as local" and your bizarre notion that the MWI is incompatible
with observations - and is thus inferior to the CI.
Note also that just because someone posts some nonsense on usenet
that does not make correcting that nonsense on-topic.
Ob cryptography: How widespread is the practice of key-stretching?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Free gift.
------------------------------
Crossposted-To: comp.lang.java.programmer
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: .java.policy (i figured it out)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Oct 2000 10:01:38 GMT
In two places, William A. McKee <[EMAIL PROTECTED]> wrote:
: I can see why news:sci.crypt complains that Java is not
: secure since a substituted unsigned .jar files could be run "in the sandbox"
: if an attacker hacks out the security exceptions.
It's not clear to me from what you have written what you're talking about.
Java's security model is not designed to prevent unsigned jar files from
running in the sandbox - if an attacker can place himself upstream of the
client (excepting SSL'd communications).
Nor is it clear which security exceptions you're talking about.
These are ones that a MITM can gain access to?
: Also there is the problem of securely getting the public.keystore file to
: the client without being intercepted by the MITM. It would be possible to
: substitute the intended certificate with a phony one then the attacker is
: free to substitute his signed .jar files for the authentic ones.
: Furthermore, the .java.policy can be hacked by the MITM to change the
: permissions granted to the applet, thus, giving him complete access to the
: client machine.
When do you anticipate such files being sent over the network?
You might also like to try this in comp.lang.java.security, BTW.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: =?iso-8859-1?Q?Tom=E1s?= Perlines Hormann <[EMAIL PROTECTED]>
Subject: Searching for a good PRNG
Date: Mon, 30 Oct 2000 11:24:44 +0100
Hi!
I am searching for a good PRNG in software, preferrable for FREE. I know
that there is a big discussion going on about where to get possibly good
PRN out of a computer (mouse, thermal noise, etc.)
My only requirement is to not have the user worrying too much with such
stuff. The generation of PRN should be transparent to anybody.
Does anybody know a good URL???
TIA...
--
Quick answering: mailto:[EMAIL PROTECTED]
Check it out: http://www.weh.rwth-aachen.de/~tomas
Do it Now!
:o) Tom�s Perlines (o:
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Reply-To: [EMAIL PROTECTED]
Date: Mon, 30 Oct 2000 10:59:40 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Bryan Olson <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote:
:> :> Bryan Olson wrote:
:> :> : Tim Tyler wrote:
:> The problems of padding scheme of appending a 1 and padding with 0s to
:> the end of the block is the topic under discussion I believe.
: Specifically, you suggested that known plaintext it adds,
: and thus the ability to reject most individual keys (out of
: 2^128 of them) was some kind of security problem [...]
That's a fair assessment.
: | It is true that some people are prepared to trust security
: | based on the percieved difficulty of performing certain
: | mathematical operations, rather than security based on an
: | information theoretical lack of ability to determine
: | whether keys are correct.
: One who cannot trust computational security might reasonably
: use the OTP.
If they can handle the large keys involved.
: But presenting this as a justification for bijective padding is
: nonsense.
It's not nonsense. Failing to add known plaintext might help when the
attacker would not otherwise have a unique halting criterion.
All he has to do is to guess keys ar random to stand an increased
chance of success with his improved halting criterion.
This isn't difficult to understand. What is your problem with it?
: The same 128-bit key is not going to provide ideal secrecy for
: realistic message spaces.
There you go with your "message spaces" again. If each message has its
own key, message spaces are of little relevance. An attacker can
attack indivdual messages. It does not matter what the message space is -
if the parties communicating with one another send *any* short messages,
then an attacker's ability to decode these messages will be likely to be
improved if he can get a better halting criterion for them.
:> :> Using an OTP may require significantly more key material.
:> :> Note that the redundancy you mentioned arises with messages
:> :> longer than the unicity distance.
:>
:> : Wrong. It arises when the sum of the redundancy in
:> : all the messages sent under the key exceeds the key
:> : entropy.
:>
:> I was (rather obviously) dealing with the case of one
:> key per message.
: Then don't phrase it as a response to "the redundancy you
: mentioned" when I was talking about multiple small messages
: covering the key equivocation.
You wrote:
``can you imagine someone so clueless as to expect his message
space won't have enough redundancy to cover a couple hundred (or
several thousand) bits of key equivocation?''
"Multiple small messages" were not mentioned, AFAICS.
Regardless of what you thought you were talking about, my point still
stands - short messages may not contain enough entropy to allow a unique
halting criterion. If you pad them out with lots of zero bits, that may
make the difference between having a single unique possible message, and
having many such possible messages.
: Very short messages happens frequently; for example an
: encrypted telnet session often sends individual key-strokes.
: Do you know someone sending very-small messages with a new
: small key every time?
I believe you can send messages of any size with PGP.
You don't have to /repeatedly/ send small messages - just sending one
is enough.
A "small" key is not required - or a very good idea for obvious reasons.
[snip clarifying ``what you think "the standard padding schemes" refers
:> :> :> What about the man who forwards an encrypted message he has
:> :> :> intercepted back to his HQ for decipherment?
:>
:> :> The attacker that intercepts his message may be unable to
:> :> distinguish a correct decrypt from a random stream (without
:> :> lots of work).
:>
:> : Huh? If he's forwarding intercepted messages, then there's
:> : a small pool of possible plaintexts.
:>
:> Which may not be known to the attacker. He may not even
:> know the cipher it is encrypted under. His task might be to
:> strip off the outer layer of encryption and then pass the
:> message to his supervisor to deal with the (classified)
:> inner algorithm.
: "Intercepted" means it came from an adversary. We're not
: talking about how the user might get lucky and not be
: attacked by that adversary. [...]
I was not talking about that either. I was saying that some attackers
might not have the information necessary to mount the attack you
suggested. Consequently, defending against their (weaker) attacks
may still be worthwhile.
:> If he can recognise a correct decrypt by the zero padding,
:> he may succeed. If the padding is not present, his job is impossible.
:>
:> :> Consequently adding up to 127 zero bits to the file might make
:> :> finding a termination criteria much easier for him.
:>
:> : As John Myre wrote
:> : Nobody with any sense cares, and you know why.
:>
:> It was false then, and is false now.
: How about I give you message encrypted with a 128-bit key,
: but with over 128 zero bits at the end of the plaintext. It
: will have, as you defined the term, an "effective key space"
: of just one key. The termination criteria will be trivial.
: Want to try to recover the message?
I'm no great cryptanalyst - that would probably be a waste of my time.
That such problems can be hard does not mean that adding known plaintext
to a message has no security implicactions, though.
Even I would stand a better chance of identifiying the message with the
known plaintext added (even if I just guessed keys at random) - since
without that known plaintext, my chance of getting the correct message
(and knowing that I have it) is zero.
:> : And yet your examples fail.
:>
:> No they do not - you just fail to grasp them.
:>
:> : You thought small messages can't cover the unicity distance; [...]
:>
:> Which is true, under some circumstances.
: Which you omitted from the example [...]
I would have though it obvious from my statement that you could
identify keys with messages longer than the unicity distance.
Even if you failed to understand me then, I have made it blindingly
clear what I was referring to in the interim.
: [...] and are false in the real-world cases that occur every day.
Nope. People can and do send short messages, and change key before they
exceed the unicity distance. Deal with it.
*Even* in cases where the unicity distance is massively exceeded, adding
specific known plaintext is something to avoid - since it may be
able to provide a halting criterion that is either more concrete, or
faster to evaluate than other types of statistic about the plaintext.
Alternatively, the halting criterion may be simpler, allowing a
brute-force parallel machine to be built using a smaller area of
silicon.
:> : You thought intercepted encrypted messages won't have useful
:> : redundancy. Did it occur to you that the attacker could have
:> : intercepted the same messages, or that the original sender is
:> : a likely attacker?
:>
:> Did it occur to you that there might be other attackers not in this
:> category?
:>
:> Obviously not.
: Actually it did. I think we should design for the dangerous
: cases, not the ones where we get lucky.
So (in this case) because some attacker might have complete known
plaintexts, don't bother trying to reduce known plaintext??
Please. With known plaintext attakers can guess message keys,
confirm correct keys, etc. Without any known plaintext, they
can be stumped.
: Resist adaptive-chosen-plaintext; don't bother adding nuisance value
: against ciphertext-only. [...]
Despite the fact that adaptive chosen plaintext attacks are relatively
rare in practice?
I think one should defend against known-plaintext as well as is
conveniently possible. Especially if the "defense" is the
relatively inexpensive one of avoiding padding one's message out
with zeros.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Organic: Church music.
------------------------------
** 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
******************************
