Cryptography-Digest Digest #433, Volume #10 Wed, 20 Oct 99 01:13:04 EDT
Contents:
Re: detecting backdoor in prime generator (Anton Stiglic)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" ("Trevor
Jackson, III")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Tim Tyler)
Re: detecting backdoor in prime generator (Anton Stiglic)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Johnny Bravo)
Re: RSA Hardware (Paul Koning)
Interested in quality Certificate Authority software that your company can actually
afford? ([EMAIL PROTECTED])
detecting correlated pairs? ([EMAIL PROTECTED])
Re: plaintext/cyphertext question ([EMAIL PROTECTED])
Re: Strengthening passwords against dictionary attacks (Thomas Wu)
Re: HELP on Kerberos and SSH (Thomas Wu)
Re: Looking for Stegano programs ([ Dr. Jeff ])
Re: RSA key size and encryption (Tom St Denis)
----------------------------------------------------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: detecting backdoor in prime generator
Date: Tue, 19 Oct 1999 14:13:17 -0400
Tom St Denis wrote:
> What theoretic? You make up a random number and test it for
> primailty. If you are suggesting that one scheme may let composites
> thru you can always use two algorithms. The chances of both of them
> letting it thru is squared (if you maintain an equal probable
> proportion between the two algorithms. I.e one scheme may need k runs
> to get 2^-k proof and the other 2^-4k ..etc)
I'm not talking about a prime number generator, I'm talking about an
RSA modulus generator with a back door.
------------------------------
Date: Tue, 19 Oct 1999 14:33:01 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks"
James Felling wrote:
> "Trevor Jackson, III" wrote:
>
> > Bruce Schneier wrote:
> >
> > > On Sat, 16 Oct 1999 23:21:25 -0400, "Trevor Jackson, III"
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > >David Wagner wrote:
> > > >
> > > >> In article <[EMAIL PROTECTED]>,
> > > >> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > > >> > I doubt it takes more than 100 lines of code on average to implement
> > > >> > the AES finalist algorithms.
> > > >>
> > > >> In software, it's easy; in hardware, it's a huge added cost.
> > > >
> > > >Huge compared to what? A single-chip implementation of just the cipher
> > > >might sustain a 100% or so increase in cost. But an appliance will see
> > > >only a few percent increase in cost.
> > >
> > > I have had clients that could not afford the hardware cost of DES, let
> > > alone two or three AES algorithms. The cost is either in a more
> > > expensive chip or less performance on the same chip. The cost is
> > > real, and there are many applications where it is very important.
> >
> > Stipulated.
> >
> > But you are making the assumption that every vendor must implement every
> > "winning" algorithm. I believe this assumption to be invalid.
>
> If there are 3 algorithims in the "AES Standard", then to be 100% AES
> Compliant, and get the legal right to say "This unit is AES Compliant" you must
> implement all algorthims on that box, otherwise your AES Compliant box might
> not talk to my AES Compliant box, which is exactly what a standard is supposed
> to prevent.
Not quite. Standards can be used to this effect, but this one is not aimed in that
direction. As I understand it the purpose of the contest is to qualify algorithms
for purchase by the Federal Government. They are concerned that security products
use ciphers of adequate strength. Thus AES compliant means "uses ciphers
certified by NIST to be strong enough" for the indicated purposes. AFAIK AES is
not aimed at certification for classified systems.
Thus multiple ciphers do not invalidate the standard. The standard is just a
threshold over which multiple ciphers may pass.
In fact multiple ciphers would not invalidate "AES compliance". There's no such
thing as "AES compliance" for products, and certainly no magic to "AES
compliance". CIPHERS would be AES compliant. PRODUCTS would implement particular
ciphers.
>
>
> If there is one AES winner, and 2 runners up then I could say this box is AES
> compliant and also supports Algorithims X, and Y the runners up, and if a
> weakness is found in the AES will have these also very good algorithims to fall
> back on. But, this should NOT be
> mandated in the standard. The standard should be as simple and minimal as
> possible, and entail the minimum load upon the user/maintainer/manufacturer.
You might complain about the same issue for EtherNet. Are TCP/IP, IPX/SPX, and ATM
"Ethernet compliant"?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Reply-To: [EMAIL PROTECTED]
Date: Tue, 19 Oct 1999 19:08:17 GMT
Bruce Schneier <[EMAIL PROTECTED]> wrote:
: If we, as the world's non-military cryptographers, cannot choose an
: algorithm, why should we expect others to?
There is no such thing as a non-military cryptographer:
Business is war (Japaneese proverb).
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Imagination is the only weapon in the war against reality.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: detecting backdoor in prime generator
Date: Tue, 19 Oct 1999 15:16:02 -0400
Thanks to Bob for a ref to an article that does talk about
what I was talking about:
R.S. Lehman, early 70's in Math. Comp.
Discussed Riesel's book (1st ed. 1985 p. 156)
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Tue, 19 Oct 1999 16:02:34 GMT
On Tue, 19 Oct 1999 16:26:53 GMT, [EMAIL PROTECTED] wrote:
>Plain English is close to 1 bit entropy per character. I have published
>a list of 4096 common and short English words (see
>www.tecapro.com/makepass.html); if you randomly choose words from that
>list you get a little over 2 bits of entropy per character and can
>build shorter pass phrases.
Or to be precise, you get 12 bits per word. Unless you end up with a valid
english sentence, in which case you should select another passphrase.
>A related problem is: how do you produce a normal English phrase?
>Picking one out of a book won't do because there are not 2^128 phrases
>printed.
It certainly would do. Even though there might not be 2^128 printed phrases,
your attacker would have to use a dictionary of every book ever printed to begin
a dictionary attack against you. The limitation here would be the storage
requirement and the trouble of scanning every book ever printed into the
database to begin with, and there is nothing that says that you can't change a
word. What if your phrase was one of those book phrases with a random word at
the beginning, or in the middle, or at the end. With a few minor changes, you
can easily end up with 2^128 possible phrases. Even something as simple as a
deliberate misspelling of a single word would render the entire dictionary
useless.
Johnny Bravo
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: RSA Hardware
Date: Tue, 19 Oct 1999 16:56:54 -0400
[EMAIL PROTECTED] wrote:
>
> Could anyone please recomend any RSA Hardware related sites, or offer
> advice on implemtation of RSA in hardware.
Do you mean: hardware that implements the RSA public key
encryption/signature algorithms?
If so, there are a number of chip vendors you might want
to look at, for example IRE, Hi/fn, and Crysalis.
paul
------------------------------
From: [EMAIL PROTECTED]
Subject: Interested in quality Certificate Authority software that your company can
actually afford?
Date: Tue, 19 Oct 1999 22:41:21 GMT
What is this message?
=====================
We, the development team of Echo6, want to measure the temperature
of the worldwide market to see if there is any potential in the
product that we have almost finished developing.
What is Echo6?
==============
Echo6 is a highly-flexible certificate management system for use in
all kinds of organisations that want to secure their IT infrastructure
with X.509 digital certificates (used with S/MIME secured email
(say Outlook), SSL client and server authentication (say Internet
Explorer), and with all kinds of other stuff like electronic banking,
NT domain login in Windows 2000 etc). Echo6 provides the administrator
with equivalent and sometimes much more advanced functionality than
competitive products which currently dominate the high-end market
(UniCERT, Entrust). And, best of all... we offer the same package
with a 5-10 times lower price tag.
We can provide you with a software infrastructure to enable you to do
the following:
- generate standard X.509 certificates for your own people, your
customers or anyone else
- create and maintain sophisticated CA hierarchies
- manage all kinds of certificates
- modify certificate generation policies to suit your needs
- secure your private keys with PKCS#11 modules
(smartcards, hardware security adapters)
- use 3rd party plugins or write your own to extend the
functionality of our certificate management system
... and since our software is perfectly standards-compatible, you
can use all kinds of other software, even Microsoft's, with
certificates generated by Echo6. If you so desire, our technicians
and system integrators can come to rescue as well.
And we have a couple of other advantages too:
- you can buy the sources. If you're a skepticist, you can make
sure that the product works as advertised. No hidden backdoors.
- and yes, we support (and recommend) RSA key lengths of more
than 512 bits. We're from outside of the USA; there are no
artificial limits on the size of the keys that our software
works with.
We believe in stating our terms upfront, therefore our price is fixed.
No strings attached, no hidden limitations, no need for additional
licenses. What you see on the invoice is what you get delivered.
(Unlike most of what we've seen on the CA market these days)
Hey, that's impossible!
=======================
If you think so, go on and buy Entrust for a couple of hundreds of
thousands of bucks. Be sure to send us a postcard though.
We've been there and we've done that; we know our market and we know
our technology.
A lower price doesn't mean our software is cheap - it is not.
But it IS affordable.
Oh, what about support?
=======================
Telephone and email support will be included in the initial cost of
the product; we do however need distributors and system integrators
who are prepared to pay personal visits to our customers and offer
them help with system integration. If know a company that would be
able to provide these services in your area, please email us at
mailto:[EMAIL PROTECTED].
Until a network of capable system integrators is established,
we will fly a person to you if you need us to solve any problems.
What is the current state of Echo6?
===================================
Currently, it is in the final phases of development; internal
testing has begun as well.
Where is the website?
=====================
Sorry! It is still being built. Until enough of the web creation
process is completed to make the resulting website available to the
general public, we recommend that you send all questions and inquiries
freely to:
mailto:[EMAIL PROTECTED]
Actually, I (the writer of this ad) personally invite you to send us
your opinion about what we are doing; we've been working on this
project for a while now and we could very much use some positive
feedback.
Thank you!
- The Echo6 development team
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: detecting correlated pairs?
Date: Tue, 19 Oct 1999 23:26:24 GMT
I'm testing weak pseudorandom functions with a couple thousand output
digits. I'd like to know whether some pair of digits is strongly
correlated.
Is there a way to do this that doesn't involve checking each of the
n(n-1)/2 pairs of digits individually?
- Bob Jenkins
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: plaintext/cyphertext question
Date: Tue, 19 Oct 1999 23:56:17 GMT
In article <7ugj7r$ern$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Obviously if there were no ciphertext that corresponds with #4 then
you
> have no relation to use in a iterative attack. however if #4
contained
> keys for a future session, or important information I would worry.
>
> Tom
Thanks Tom, appreciated. This agrees with my hypothesis. I realize it
a grossly amateur question, but I needed to know. Thanks very muchly.
Michael
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Strengthening passwords against dictionary attacks
Date: 19 Oct 1999 17:15:52 -0700
[EMAIL PROTECTED] writes:
> In article <[EMAIL PROTECTED]>,
> Thomas Wu <[EMAIL PROTECTED]> wrote:
> > Tom St Denis <[EMAIL PROTECTED]> writes:
> > >
> ...
> > > Simple as that.
> >
> > This is vulnerable to dictionary attack [attacker gets R and a,
> > and tries passwords P until a == HASH(R + P)]. Any login system
> > should work like SRP, SPEKE, or EKE to prevent a dictionary attack.
> > --
> > Tom Wu * finger -l [EMAIL PROTECTED] for
>
> ...
>
> SPEKE at least won't work for a non-interactive scenario. For
> example, I am logging into a stand alone NT box. SPEKE requires
> two active participants per the paper 'Strong Password-Only
I'm not sure I understand the objection. Protocols like SRP/SPEKE
require a server to perform the necessary computations, but the server
can be a machine. If the protocol is verifier-based (e.g. SRP), then
the quantity the server stores is not plaintext-equivalent to the
password. First secure the network protocol, then protect the server.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: HELP on Kerberos and SSH
Date: 19 Oct 1999 17:24:58 -0700
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
>
> Not so short version:
> Regardless of any protocol analysis, I personally don't think Kerberos 5
> needs to be considered useful in many situations. The encryption used is no
> longer considered strong enough for high security. This necessitates the
> changing of the user's password on a day by day basis, a precaution that
> most people would not enjoy. Otherwise the current password can be
> discovered (using a fairly inexpensive machine, ~$150-200K US) within a few
> days. The packet format is known, and large portions of the internal data
> are in fact known, which gives a very high probability of a break being
> detectable.
As I've said before, Kerberos V5 must augment its preauthentication
method with a strong password scheme like SRP/SPEKE/EKE/whatever before
it can be considered secure. Otherwise, the brute force attack works
for active and passive attackers, and forward secrecy is lost.
> Once the break has been found (using brute force in this case), the user's
> password is known, and not only is the network attacked broken, but
> potentially a large number of other locations as well. Even if the attack is
> limited to one network, the information taht is available on a workstation
> (the most likely location for the use of distributed authentication), the
> password can be changed, giving free access using the original operating
> system, and presenting the data in exactly the way used by the target,
> including often all of the configuration information used on a day by day
> basis by the victim.
>
> The coming availability of a large number of networks based on Kerberos
> serves only to increase the amount that can be gained by building a machine
> like the EFF DES challenge machine. This decreases the risk, due to the fact
> that if a company (the assumed target) finds out that such a device is being
> built, Kerberos usage may be discontinued, but the availability of other,
> potentially profitable targets will make even a machine that has served it's
> original pupose (the elimination of all security on the target network, and
> hence the compromise of all the data) remain profitable, by performing
> similiar tasks on other networks.
>
> Of particular interest to many people should be the use of such a weak
> protocol on a banking/credit network. If a password on one of these networks
> is discovered, the impact could be in the hundreds of millions of dollars
> (US), and destroy/vandalize the information about millions of americans,
> maybe even undetected, and certainly it's possible for it to be done
> unlocatable.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] ([ Dr. Jeff ])
Crossposted-To: alt.2600
Subject: Re: Looking for Stegano programs
Date: 19 Oct 1999 21:11:16 -0500
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Curious Ascender) wrote:
>
>I'm trying to locate a few stegnographic programs.
Well you won't find them here in alt.2600. Ah, but at least you
cross-posted to sci.crypt where you should've posted...
--
Dr. Jeff is not common so don't expect common courtesy from him.
If you don't like me, bite me. Be warned, however, I may bite back!
((N)) ((I)) ((T)) ((A)) ((L)) ((L)) ((I)) ((C)) ((A))
((F)) ((A)) ((N))
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA key size and encryption
Date: Wed, 20 Oct 1999 02:55:10 GMT
In article <[EMAIL PROTECTED]>,
Sebastien LUCAS <[EMAIL PROTECTED]> wrote:
>
> --------------D0F498A36EB57D67360A1BE8
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> If I have a 512bits RSA key. I want to crypt 8 bytes. What is the
> length of my crypted data?
If your modulus is n bits, then you can generally encode anything upto
n-1 bits in length. I would suggest having AT LEAST half of that as a
random value. So if you had a 512 bit modulus you could encode 511
bits, about 256 bits of which should be random junk. Obviously if you
are sending [for example] 128 bit keys for a symmetric cipher you will
have 511-128=383 random bits.
The length of your ciphertext/plaintext is ALWAYS the same size as the
modulus, otherwise you encounter the halting problem and that's no good
(at least I think that's the right problem...)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
