Cryptography-Digest Digest #457, Volume #9 Sat, 24 Apr 99 08:13:06 EDT
Contents:
Re: choosing g in DH ("Roger Schlafly")
Re: May be wrong place to ask this... (xstpvmi)
Re: Block Cipher Question (wtshaw)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(wtshaw)
Re: How good is /dev/random... (xstpvmi)
Re: Thought question: why do public ciphers use only simple ops like shift and XOR?
(wtshaw)
Re: Adequacy of FIPS-140 (wtshaw)
Re: encrypted and AUTHENTICATED tunnels ("Steve Sampson")
Re: choosing g in DH ("Michael Scott")
Re: Paper on (in)security of passwords (Jonathan Thornburg)
Re: choosing g in DH ("Michael Scott")
----------------------------------------------------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: choosing g in DH
Date: Fri, 23 Apr 1999 20:40:07 -0700
Bob Deblier wrote in message <[EMAIL PROTECTED]>...
>Any pointers on where I can find more information on that?
One problem is that if the order of g is not prime, then g^k
might be in some small subgroup. Someone might enumerate
all elements of that small subgroups.
If the generator g has prime order, then every power of g has
that same prime order, or is 1 (and 1 can be easily checked).
Even if g has prime order, there are still some pitfalls.
Eg, see the article by Lim and Lee in Crypto '97.
http://crypt.future.co.kr/~chlim/english_pub.html
------------------------------
From: [EMAIL PROTECTED] (xstpvmi)
Subject: Re: May be wrong place to ask this...
Date: Sat, 24 Apr 1999 05:59:24 GMT
On Fri, 23 Apr 1999 21:23:41 -0700, Bob Novell <[EMAIL PROTECTED]> wrote:
> I located a site with links to some of the source from the Applied
> Cryptography book, but many are tar.gz and c.gz files.
>
> Being a DOS/Windows user, I don't know how to unarchive these files.
Winzip can handle .gz files. If you need a DOS program to do so then you
can download gzip.exe from the DJGPP collection at www.delorie.com.
There are probably numerous other programs for DOS/Windows as well.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Block Cipher Question
Date: Sat, 24 Apr 1999 01:50:26 -0600
In article <7fpus4$s0f$[EMAIL PROTECTED]>, SCOTT19U.ZIP_GUY
<[EMAIL PROTECTED]> wrote:
>
> Whay are you rantng about a 16bit key size. In scott16u I use
> only a subset to the possible 16 bit S-tables namely the single
> cycle S-table. And the key in it is over 100,000 bits so you
> are not reading what I write.
You are not the only one writing. And, you make my case.
16 bits? An earlier poster did that; the fact that bits alone are
mentioned should clue you that I did not insert that specific example.
>
> > The myth that keys cannot be longer than block size has been punctured for
> > quite a long time now; you can credit or blame me, your option, for
> > exposing the truth some time ago.
>
>
> If anything it was me that exposed this truth to you. It has been
> known for centures.
>
Centuries, OK for a limited few perhaps, most likely, not very long for
most. Many, as victims of propaganda, do not understand this basic, and I
brought it up now because of a posters belief in the absurdity that small
block size means automatic poor security. In crypto, there has been a
cultivated string of myths that need to be undone, and the ones most
cultivating them have been those who would most likely benefit by their
spread.
--
Life's battles do not always go to the stronger of faster man...
But, sooner or later always go to the fellow who thinks he can.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Sat, 24 Apr 1999 01:36:38 -0600
In article <7fq06b$t83$[EMAIL PROTECTED]>, SCOTT19U.ZIP_GUY
<[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (wtshaw) wrote:
> > In article <7fnujg$2tj$[EMAIL PROTECTED]>, SCOTT19U.ZIP_GUY
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > Your feelings are correct except for one small point. The AES contest
> > > is not about having secure encryption. The NSA would never allow a good
> > > common method to be blessed by the government for general use.
> > > So that is why you will never see a blessed super cipher method made
> > > of completely different methods. Unless each method added information
> > > at each pass so that they could be broken independitly.
> > >
> > We can expect that there are tactics and strategies on file for finding a
> > way for the government to get itself out of the corner that it has painted
> > itself into. Whether any of them will work or is going to be acceptable
> > is up for grabs.
> >
> > As seen in many cases before, our government is adept at doing
> > inconsistent things, even, alas, contradicting itself in statements of
> > mission and policy. As in any level of organization, individual to
> > government, the devil is in the details, that is which values are given
> > more weight at the time. In time of war....well, we will see...rather not
> > have to have any war that might be abused for ulterior motives aside from
> > those well recognized.
>
> These inconsistent things are done for a reason. One branch of the
> government can promise you something in exchange for something but
> when you keep your promise then another branch can punish you for the
> very same action. That way those in power can really do what the hell
> they want because there are so many laws rules and organiszations
> they are routinely selectively applied. As an example is the tax
> structure. It cost a lot of money to collect and process the taxs
> any comgress man knows a simple flat tax would save the government
> money and be best for the population as a whole and it could make
> the size of government smaller. But this will never happen it is
> designed to keep citizens in fear instead of helping them. Also
> as a recent stufy showed for a family of 4 with a simple tax set
> up the mahority of CPA's could not do the tax forms correctly.
> The govenment likes this. If you vote wrong or whatevery you can
> be charged with falsefying your income taxes. This tool is to
> powerful for government to throw away. The governments main
> concern is to keep the status quo and to control. Not to help
> people.
I agree with you about most of what you have said above, but it may be
more true of some in government than others. We could add lots of other
examples, at various levels of government. The best thing to be is open
and honest, something government does not particularly like to do as it
limits arbitrary power.
>
> Next silly thing your going to tell me is that if the Pres
> comitted perjury he would be punished in court like any other
> man.
Lots of wrong statements make it into the record by default.
Inconsistencies are overlooked because they are so common, and the
workloads demand getting on to something else. And, perjury is often
expected to have occured at some point; otherwise, anyone protesting
charges were untrue could be charged with perjury if there was a
conviction.
In Clinton's case, due process was carried out, be it a special form.
> I still think the shootings in Colorado are more the result
> of the mixed signals we send our kids. We teach them about
> truth and justice and fair play. But then the first taste of
> justice is a dishonest traffic ticket.
We have many good rules about how school should be. The school
authorities do not follow them too closely all too often. When problems
are not addressed, the odds that trouble will occur just increase. What
should be done is an open question, every contemplated action has its down
side; formal demands for guaranteeing a good education environment are all
too often treated as mere guidelines. It is the same story as it was with
the courts, time constraints are real in the schools; but, that is no
excuse for not doing more to address real problems that affect each
individual, and individuals do reach breaking points.
--
Life's battles do not always go to the stronger of faster man...
But, sooner or later always go to the fellow who thinks he can.
------------------------------
From: [EMAIL PROTECTED] (xstpvmi)
Subject: Re: How good is /dev/random...
Date: Sat, 24 Apr 1999 05:57:14 GMT
On 23 Apr 1999 23:22:15 GMT, Stephen Robert Norris <[EMAIL PROTECTED]> wrote:
> Has anyone done any analysis on how "good" the randomness from /dev/random
> is in Linux?
Portion of the comments in random.c:
* Ideas for constructing this random number generator were derived
* from Pretty Good Privacy's random number generator, and from private
* discussions with Phil Karn. Colin Plumb provided a faster random
* number generator, which speed up the mixing function of the entropy
* pool, taken from PGPfone. Dale Worley has also contributed many
* useful ideas and suggestions to improve this driver.
Good sources are used for the entropy pool and SHA is used on the pool
to produce the random output. Assuming the author (apparently Theodore
Ts'o) didn't screw up somewhere then it should produce good output for
cryptographic applications.
I haven't seen any detailed analysis of it though. Let us know if you
find something.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift
and XOR?
Date: Sat, 24 Apr 1999 01:15:17 -0600
In article <7fp131$dg1$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bryan G. Olson;
CMSC (G)) wrote:
> Terry Ritter ([EMAIL PROTECTED]) wrote:
>
> [...]
> : And in this way we can have hundreds or thousands of different
> : ciphers, with more on the way all the time. That means that we can
> : divide the worth of our information into many different ciphers, so
> : that if any one fails, only a fraction of messages are exposed.
>
> Absurdly naive. In any real project or real enterprise, the
> same information is carried by many, many messages. The degree
> of protection of any piece of intelligence is that of the
> weakest of the systems carrying it.
>From a herd point of view, you may be right, but specific information
between individuals is not apt to pass but once or few times at the most.
To fully follow the dialog, all parts of the conversation should be
recovered. Even when encrypted, however, the use allegory and novel in
text, security measures in themselves, should be used.
>
> : It
> : also means that *any* Opponent must keep up with new ciphers and
> : analyze and possibly break each, then design a program, or build new
> : hardware to exploit it. We can make good new ciphers cheaper than
> : they can possibly be broken. The result is that our Opponents must
> : invest far more to get far less, and this advantage does not depend
> : upon the delusion of strength which is all that cryptanalysis can
> : provide.
>
> Nonsense. The attacker just waits for the information he wants
> to be transmitted under a system he can break.
>
If certain information is so common, it may not be worth encrypting in the
first place. The idea of putting all eggs in one basket, or very few, is
not supportable; But, one should only use promising baskets in any event.
Keep 'em busy with ciphers that they have not even considered before.
--
Life's battles do not always go to the stronger of faster man...
But, sooner or later always go to the fellow who thinks he can.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Adequacy of FIPS-140
Date: Sat, 24 Apr 1999 02:03:44 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> Perhaps you can offer an analysis of why hashing and strong mixing
> will not lead to a satisfactory flattening of the distribution.
>
Looking for satisfactory flattening is the wrong goal. Looking for any
distribution that does not correlate with expected plaintext or give clues
for useful for attack is the meaningful goal. Better yet, send 'em on a
wild goose chase with a distribution that leads them into the swamp.
The quest for absolute randomness in generators or ciphertext may be
little more than a snipe hunt if no real gains in strength are realized.
Any predetermined goal of distribution is prejudiced, even flat to some
standard, and we cannot even agree to what constitutes being flat.
--
Life's battles do not always go to the stronger of faster man...
But, sooner or later always go to the fellow who thinks he can.
------------------------------
From: "Steve Sampson" <[EMAIL PROTECTED]>
Subject: Re: encrypted and AUTHENTICATED tunnels
Date: Sat, 24 Apr 1999 05:36:13 -0500
Yes.
The rest of your post shows that you are wasting your time
on politics. Take your blinders off.
Look at SSH and IPSEC. You'll find enough info to perform
the function. You can run PPP over SSH for example.
Phil Howard wrote in message ...
>Is there any free and unencumbered software that implements encrypted
>and AUTHENTICATED tunnels? This would require an unshared authentication
>key pair in each direction. Otherwise, a cracker with the tunnel code
>and the opportunity to hijack the routing of one end of a VPN, could get
>into a VPN easily and penetrate all those insecure applications that
>assume they are running on a secured LAN.
>
>Unfortunately, it is rather pointless for me to try to implement such a
>thing myself, given the country I live in.
>
>* strong encryption
>* strong unshared authentication
>* no patent encumberances
>* GPL or similar licensing
>
>--
>Phil Howard KA9WGN
>[EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: choosing g in DH
Date: Sat, 24 Apr 1999 11:10:42 +0100
Phil Howard <[EMAIL PROTECTED]> wrote in message
news:%CaU2.523$[EMAIL PROTECTED]...
> | > That makes no sense. If you know a generator g in which you can
> | > compute discrete logs, then you can compute discrete logs in any
> | > base. Here's how:
> | > ...snip
> |
> | Ah but it does make sense. The suggested use of a prime order generator
is
> | to avert certain active attacks on the DH algorithm, not to make the
> | discrete log problem more difficult..
>
> So now where I can I find references on how to choose g to have prime
order?
>
That's easy. As has already been pointed out choose p a safe prime (p-1)/2
also prime, and then g=3, g=4 or g=x^2 where x is anything.
The use of a prime order generator rather than a primitive root was first
suggested I believe by Oorschot & ???? in a paper "On the use of small
exponents with Diffie-Hellman", or somesuch - sorry I don't have it to hand.
Note that if a primitive root is used (as is still sugested in some
textbooks), then the m least significant bits of the discrete logarithm can
be easily found where (p-1)=q.2^m, where q is odd. So even if p=3 mod 4, one
bit is revealed, actually a 0 or 1 depending on whether y=x^w mod p is a
quadratic residue or not.
Mike Scott
> --
> Phil Howard KA9WGN
> [EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Paper on (in)security of passwords
Date: 24 Apr 1999 12:35:55 +0200
In article <7fo9j1$a4c$[EMAIL PROTECTED]>,
Florian Erhard <[EMAIL PROTECTED]> wrote:
>I'm looking for a evaluation of the security of password
>used in universities or companies. I rember I once read
>soemthing about x% consisting of names and y% consisting of
>birtdates and so on. An url or a bibliography-entry would
>help! Thank you,
Here's a slightly-edited article I posted on this same topic back in
1993. Alas, I doubt that typical computer users choose any better
passwords today. And it's painfully obvious that brute-force password
searching/cracking has gotten a *lot* easier... (sigh)
Again, I emphasize that the CPU-time estimates here are for early-1990s
hardware, today you can do a lot better.
Summary:
Unfortunately, passwords are far less secure in practice than simple
"length^alphabet_size" arguments would indicate, because real-life
passwords aren't even close to random.
At the end of this article I give 5 references which IMHO *anyone*
interested in Unix security should read (presuming that Garfinkel
and Spafford is already in <books.h> and /etc/motd combined :-) ...).
Of these references, [125] describe the statistical characteristics
of actual real-world Unix passwords (gathered with due concern for
security and privacy risks, discussed in the papers), while [34] are
"war stories" which give a few insights about some of the less friendly
people who inhabit the internet. References [125] also describe several
large-scale (> 1 workstation cpu-year) password-cracking studies.
Two quotes that are particularly relevant to this thread:
Reference [1] was based on a set of ~15000 /etc/passwd lines the
author gathered.
"All in all, after nearly 12 CPU months of rather exhaustive testing
approximately 25% of the
passwords had been guessed. So that you do not develop a false sense
of security too early, I add that 21% (nearly 3,000 passwords) were
guessed in the first week, and that in the first 15 minutes of testing,
368 passwords (or 2.7%) had been cracked using what experience has
shown would be the most fruitful line of attack (i.e., using the user
or account names as passwords). These statistics are frightening,
and well they should be. On an average system with 50 accounts in
the /etc/passwd file, one could expect the first account to be cracked
in under 2 minutes [of cracker cpu time], with 5-15 accounts being
cracked by the end of the first day."
Reference [5] was based on installing special versions of passwd
and yppasswd on a variety of machines over a 6 month periods,
which logged the newly set passwords (RSA encrypted for security).
"Of the 13787 unique password entries examined, the average length
was 6.80 characters. The lengths of passwords are given in table 1.
Table 1: Password lengths
Length Quantity
------------------------
1 55
2 87
3 212
4 449
5 1260
6 3035
7 2917
8 5772
Table 2: Character distributions
Characters Count Percentage
==================================================
Lower-case only 3988 28.9%
Mixed case 5259 38.1%
Some upper-case 5641 40.9%
Digits 4372 31.7%
Meta-characters 24 0.2%
Control characters 188 1.4%
Space and/or tab 566 4.1%
.,; 837 6.1%
-_=+ 222 1.6%
!#$%^&*() 654 4.7%
Other non-alphanumeric 229 1.7%
In conclusion: (mine, not the above-cited authors)...
On almost all Unix systems not in a ultra-high-security environment,
~10% of the accounts have trivial passwords (guessable in under 10
tries using /etc/passwd information only), and another 20% of the
accounts could be cracked within a few minutes of CPU time.
References:
1 "Foiling the Cracker: A Survey of, and
Improvements to, Password Security"
Daniel V Klein
p.5-14 in Usenix Security II proceedings
2 "How Crackers Crack Passwords, or,
What Passwords to Avoid"
Ana Maria De Alvar\`{e}
p.103-112 in Usenix Security II proceedings
3 "Security Breaches: Five Recent Incidents
at Columbia University"
Fuat Baran, Howard Kaye, and Margarita Saurez
p.151-171 in Usenix Security II proceedings
4 "There Be Dragons"
Steven M Bellovin
p.1-16 in Usenix Security III proceedings
5 "Observing Reusable Password Choices"
Eugene H Spafford
p.299-312 in Usenix Security III proceedings
The full references for the two proceedings are:
Usenix Unix Security II Workshop Proceedings
27-28 August 1990
Portland Oregon USA
and
Usenix Unix Security III Workshop Proceedings
14-16 September 1992
Baltimore Maryland USA
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
Universit�t Wien / Institut f�r Theoretische Physik
"It's every man for himself, said the elephant as he danced on the
anthill!" -- T. C. "Tommy" Douglas's description
of the central ethos of American society
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: choosing g in DH
Date: Sat, 24 Apr 1999 11:20:42 +0100
Phil Howard <[EMAIL PROTECTED]> wrote in message
news:%CaU2.523$[EMAIL PROTECTED]...
> So now where I can I find references on how to choose g to have prime
order?
>
I found it. Van Oorschot & Wiener "On Diffie-Hellman key agreement with
short exponents", EuroCrypt '96, pp 332-343
Mike Scott
> --
> Phil Howard KA9WGN
> [EMAIL PROTECTED] [EMAIL PROTECTED]
------------------------------
** 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
******************************
