Cryptography-Digest Digest #427, Volume #10 Mon, 18 Oct 99 14:13:04 EDT
Contents:
Re: Eric Young's libdes (Svend Olaf Mikkelsen)
Re: Testing of randomness (Jon Haugsand)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Mok-Kong Shen)
Re: Biometric Keys are Possible (Mok-Kong Shen)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Re: Biometric Keys are Possible
Re: The Quad. in RC6 ([EMAIL PROTECTED])
Re: The Quad. in RC6 (Tom St Denis)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (Larry Kilgallen)
Re: Biometric Keys are Possible (jerome)
Help! How can i decrypt text? ("dfg")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (John
Savard)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (wtshaw)
Re: Bruce Schneier Proves That Secure Cryptography is Impossible (wtshaw)
Re: Testing of randomness (wtshaw)
Re: Biometric Keys are Possible (Peter Pearson)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Svend Olaf Mikkelsen)
Subject: Re: Eric Young's libdes
Date: Mon, 18 Oct 1999 09:16:04 GMT
Jesper Gadeberg Jensen <[EMAIL PROTECTED]> wrote:
>Can anyone tell me how to compile Eric Young's libdes for DOS. I have
>come to the conclusion that I might be missing some critical part of
>Borland C++ (or maby my version is just to old)!
Synes jeg har set dette sp�rgsm�l f�r? Hvis det ikke f�rer til noget,
kunne du sp�rge i dk.edb.programmering.c
--
Hilsen
Svend Olaf
------------------------------
From: Jon Haugsand <[EMAIL PROTECTED]>
Subject: Re: Testing of randomness
Date: 18 Oct 1999 11:53:09 +0200
* [EMAIL PROTECTED]
> > I work in the GB range.
> >
> Good at testing randomness? Is this a random series: 45, 87, 3, 30.
Hardly in the GB range.
--
Jon Haugsand
Norwegian Computing Center, <http://www.nr.no/engelsk/>
<mailto:[EMAIL PROTECTED]> Pho: +47 22852608 / +47 22852500,
Fax: +47 22697660, Pb 114 Blindern, N-0314 OSLO, Norway
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Mon, 18 Oct 1999 12:38:01 +0200
Bruce Schneier wrote:
>
> On Sun, 17 Oct 1999 01:29:39 GMT, [EMAIL PROTECTED]
> (John Savard) wrote:
> >I think it *is* correct that users can't memorize _passwords_ which,
> >because they have digits or punctuation marks thrown in, have enough
> >entropy in them to be adequate in themselves.
> >
> >And there is a reason I underlined the word *passwords* in the
> >preceding sentence. Because it is the crucial point where I think
> >Bruce may have been mistaken. It is possible for the user of a
> >cryptographic system to memorize a pass phrase. It is possible to use
> >the same kind of tricks with a pass phrase as are used with short
> >passwords to increase entropy - insert an incongruous word, rather
> >than a non-alphabetic character, into the phrase. One can require two
> >or three pass phrases to be entered to produce the key.
> >
> >(Note that I've earlier advocated stripping punctuation from pass
> >phrases, since I think it's easier to memorize the words of a longer
> >pass phrase than to get the punctuation exactly right every time.)
> >
> >I could be wrong, but I believe it to be - with some effort - possible
> >for a user to memorize data, _in a suitable form_, from which a key of
> >sufficient (genuine) length can be derived. As there are many cases
> >where there is simply no reasonable alternative to a user-memorized
> >secret, I believe this is a vitally important point.
>
> I agree that it's possible, but I don't think it likely. It's hard
> enough getting users to remember four-digit PINs. You and I and
> everyone who reads this newsgroup can remember high-entropy
> passphrases (maybe a few), but the general populace cannot.
While people normaly seem to have difficulty to remember a eight or
more digit number, I suppose it is an exageration that they find
it hard to remember four digits ones. In my city telephone numbers
have at least six digits and plenty of people memorize quite a number
of the phone numbers of their friends well. Further, account numbers
of my bank has 10 digits and I have seen many people writing down
these without looking into their note books. If one memorizes six
(or even four) digits and, as Mr. Savard mentioned, insert these
into a pass phrase at some irregular positions, I am not sure that
cracking with a dictionary is that simple. Further, a meaningful
pass phrase need not be typed in as such, it could be, e.g. circularly
rotated a few characters.
M. K. Shen
========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Biometric Keys are Possible
Date: Mon, 18 Oct 1999 13:03:53 +0200
Francois Grieu wrote:
>
> This non-uniqueness is a practical issue in many applications,
> because it makes the output of a biometric device not directly
> usable as a conventional search, identification, or crypto key.
> For example, a Smart Card can easily make a binary comparison of
> a submitted PIN to an internaly stored PIN, and unlock some function
> if it matches. Comparing biometric characteristics requires
> a much more complex process.
Even if a biometric data were unique, i.e. always leading to a
unique constant, I conjecture that the mere fact that it is a constant
(that will and can never be changed in one's life and that is stored
probably in several data bases without guarantee of absolute and
permanent security) could render it of problematical value in at
least some cryptological applications. I should appreciate experts
refuting my conjecture.
M. K. Shen
------------------------------
Date: Mon, 18 Oct 1999 08:07:38 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Roger Schlafly wrote:
> Terry Ritter <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Modern "hardware" systems often consist of embedded processors and
> > "firmware" based in flash. The system itself can be designed to
> > choose from an array of acceptable ciphers, and also maintain a list
> > of a cipher *required* in a cipher stack, or *disallowed* due to new
> > information.
>
> Yes, hardware systems could do that. But I am sure that they
> would rather devote those resources to something more useful,
> in most cases.
Something "more useful" than averting the possibility that the entire
device becomes useless?
Like what?
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: 18 Oct 99 12:12:57 GMT
Bruce Schneier ([EMAIL PROTECTED]) wrote:
: I agree that it's possible, but I don't think it likely. It's hard
: enough getting users to remember four-digit PINs. You and I and
: everyone who reads this newsgroup can remember high-entropy
: passphrases (maybe a few), but the general populace cannot.
Well, that distinction was omitted in the article. Also, a four-digit PIN
hasn't been sugar-coated for ease of memorization.
But the question of how much entropy can be in a pass phrase, even one
memorized by a highly motivated user of PGP, is still a legitimate
question. I was wondering if someone who had done the math had an opinion,
because this is a very important user-interface issue.
Essentially, it sounded like secure cryptography on home computers had
suddenly become an oxymoron. Although I admit to sensationalizing the
title a bit...
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Biometric Keys are Possible
Date: 18 Oct 99 12:07:57 GMT
Francois Grieu ([EMAIL PROTECTED]) wrote:
: I doubt any biometric technique is able to produce a discrete
: number that is the same from device to device, with high probability
: and most individuals. That is, I believe two unconnect biometric
: devices will sometime produce different numbers for the
: same individual.
I agree: I'm only talking about one device. And even then, one device must
sometimes, for some attributes, produce different numbers for the same
individual.
What I'm talking about is a way to bypass that problem. Using Gray code, I
can ensure those "different numbers" differ by one or two bits. Using
check bits from an error-correcting code, stored with the User ID, I can
correct a small number of such errors to get a fixed bit string, at a
single workstation, for one individual.
John Savard
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The Quad. in RC6
Date: Mon, 18 Oct 1999 12:23:43 GMT
In article <7udh2s$eqn$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <7ucv3s$3r6$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > In article <7u7jin$o3t$[EMAIL PROTECTED]>,
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > > Ok to sumarize the quad in RC6 is
> > >
> > > F(x) = x(2x + 1)
> > >
> > > Which has been shown to be a function (multiplication of any
variable
> > by a
> > > odd number is a function mod 2^w).
> > >
> > > However have any weaknesses been found? What if you change it to
> > >
> > > F(x) = x(ax + b)
> > >
> > > Where (a, b) are round/key dependant integers (a being even and b
> > being odd
> > > of course)? Would that make it any harder to attack/model?
Would it
> > still
> > > be a function (as shown in RC6)?
> >
> > I see a couple of problems with this because there will be a limited
> > number of possible a's and b's that you can choose. The problem
stems
> > from the fact that multiplication by powers of two acts as a left
shift,
> > or right shift depending on endienity. In the case of the original
> > quad, x is shifted left by one bit. Now, for every bit we shift, we
> > lose a bit. In the case of a one bit shift, we lost the highest
bit.
> > If we multiply by 256, or shift by 8 bits, we lose 8 bits of
> > information. As far as I remember, the quad is primarily used to
> > generate 5 bits for the rotates that come next, with some additional
> > mixing included. Thus, you want to use as much information from the
> > data as possible, so by multiplying by larger values, you lose
> > information. Now, I'm not sure of the exact mathematics behind
this,
> > but the lost information may provide an attacker a means of attack.
> >
> > As for b, or the odd number, that will probably have to relate to
how
> > much information is lost by the multiply. Assuming we limit a to a
> > maxmimun value of 256, you will have to have at least 8 good odd
values
> > to obtain the desired effect of the quad. More than likely, you
will
> > have to predefine these. If an attacker can force certain values
for a,
> > he or she can then guess b.
> >
> > Anyway, that's what I came up with as a possibility as to why
x(ax+b) is
> > bad. If anyone can prove me wrong, or help refine what I said, I'd
> > appreciate it.
>
> Actually you had the right idea but your math is messed up. If for
example in
>
> f(x) = x(ax + b)
>
> a = even, b = odd then you will have amultiplication of x against an
odd.
> this is always going to be a permutation mod 2^w. And you talked
about a
> shift out, but again the multiplication is always odd. So if
you had
>
> 257x that would be the same as (x << 8) + x. No bits are lost there.
I was talking about losing bits of info when doing ax, not x(ax+b).
csybrandy
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Quad. in RC6
Date: Mon, 18 Oct 1999 12:32:41 GMT
In article <7uf3g8$ee1$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I was talking about losing bits of info when doing ax, not x(ax+b).
If I am not mistaken that's what provides the diffusion in this function.
I.e if you had a=8, b=5 you get
= x * ((x << 3) + 5)
= x(x<<3) + 5x
IF there were no shift then there would be no diffusion. Of course this
diffusion leans towards the upper bits and there are fixed points (as was
pointed out in private). I am looking at this as a sbox or linear transform.
Some other ideas were
f(x) = x(ax + b) + c
and
f(x) = x(ax + b) >>> c
Where [a, b, c] are round variant key words. a is even, b is odd and c is an
integer. Both would eliminate the f(xxxx0000) = xxxx0000 fixed points but
may cause new ones...
This function on it's own is not very secure, the former requires some
universial bit mangler (i.e the lower bits and higher bits have to mix with
equal prob). In the case of RC6 this is accomplished (?) via the
data-dependant rotations.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Larry Kilgallen)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Reply-To: [EMAIL PROTECTED]
Date: Mon, 18 Oct 1999 13:13:36 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bruce Schneier)
writes:
> On Sun, 17 Oct 1999 01:29:39 GMT, [EMAIL PROTECTED]
> (John Savard) wrote:
>>I could be wrong, but I believe it to be - with some effort - possible
>>for a user to memorize data, _in a suitable form_, from which a key of
>>sufficient (genuine) length can be derived. As there are many cases
>>where there is simply no reasonable alternative to a user-memorized
>>secret, I believe this is a vitally important point.
>
> I agree that it's possible, but I don't think it likely. It's hard
> enough getting users to remember four-digit PINs. You and I and
> everyone who reads this newsgroup can remember high-entropy
> passphrases (maybe a few), but the general populace cannot.
Certainly the general population "can" remember high-entropy passphrase
as well can those who have been granted admission to this newsgroup. It
would seem rather that they lack the motivation of people gathered here
for such an effort.
There seem to be two possible approaches:
1) Build systems that don't require remembering a
high-entropy passphrase
2) Mount a massive publicity campaign to explain
the importance of remembering high-entropy
passphrases to the masses
With luck, the second method might approach the effectiveness of the
War On Drugs (US joke).
Larry Kilgallen
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Biometric Keys are Possible
Reply-To: [EMAIL PROTECTED]
Date: Mon, 18 Oct 1999 13:58:56 GMT
On 17 Oct 99 14:24:52 GMT, [EMAIL PROTECTED] wrote:
>
>Pattern recognition can do certain things for you, but the problem I
>outlined is fundamental where the underlying measurement is analog. A
>technique such as that I outlined is necessary, and no amount of pattern
>recognition can avoid it, to produce a cryptographic key (however
>short) from hand geometry, for example.
Analog measure can be converted in a discret space in a robust way.
It isn't the problem.
>: By the way, employing biometric data involves
>: the risk of the data being copied and replayed in certain situations.
>
>Yes, that is certainly a valid point.
This is much more the problem, if i memorize the key i have to say it to
reveal it, it is a conscious process. it is unlikely that i would say my
key without being aware of it.
if the key is biometric, it is by definition on my body. So anyone who
can observe my body can learn my key too. And i won't be aware of it.
if the key is my fingerprints, my key is everywhere i put my hands,
my mouse, my keyboard, the door of my office etc...
------------------------------
From: "dfg" <[EMAIL PROTECTED]>
Subject: Help! How can i decrypt text?
Date: Mon, 18 Oct 1999 10:55:12 +0200
My task is to decrypt encrypted text and find the encryption key.
It's basic encryption character is only swaped with one other char.
example:
ABCDEF...
BEFGJK....
i need to find that key!
plz help
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Mon, 18 Oct 1999 14:42:33 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>On 16 Oct 99 15:19:12 GMT, in <[EMAIL PROTECTED]>, in sci.crypt
>[EMAIL PROTECTED] () wrote:
>>But the point - and it's a valid one - of the side other than yours on
>>this question is that sometimes we don't *know* all the shortcomings of a
>>cipher.
>Why would you claim that "the other side" says this happens
>"sometimes"?
>I claim that we *never* know "all the shortcomings of a cipher,"
>absent some sort of mathematically provable security in practice.
I should have been clearer.
We never know _that we know_ all the shortcomings of a cipher,
therefore, we should consider the possibility that, at least
sometimes, there will actually exist shortcomings (serious enough to
be relevant) in addition to those we know about.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Mon, 18 Oct 1999 09:59:50 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> While people normaly seem to have difficulty to remember a eight or
> more digit number, I suppose it is an exageration that they find
> it hard to remember four digits ones. In my city telephone numbers
> have at least six digits and plenty of people memorize quite a number
> of the phone numbers of their friends well. Further, account numbers
> of my bank has 10 digits and I have seen many people writing down
> these without looking into their note books. If one memorizes six
> (or even four) digits and, as Mr. Savard mentioned, insert these
> into a pass phrase at some irregular positions, I am not sure that
> cracking with a dictionary is that simple. Further, a meaningful
> pass phrase need not be typed in as such, it could be, e.g. circularly
> rotated a few characters.
>
Most everyone has a phone book, even us in the sticks. Pick five people
that you know; remember them in some order; use their last four digits one
after the other to get twenty digits; you can even insert the name of
their cat or dog ahead somehow in the string. If this sounds odd, it is
not near as odd a ways people can come up with to make passphases on their
own.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Bruce Schneier Proves That Secure Cryptography is Impossible
Date: Mon, 18 Oct 1999 10:03:17 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] () wrote:
>
> Essentially, it sounded like secure cryptography on home computers had
> suddenly become an oxymoron. Although I admit to sensationalizing the
> title a bit...
>
He should be careful when also selling books. Dumbing down cryptography
has so much of a federal flavor. I would prefer to thiung he just does
not understand, no disrespect to the young.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Testing of randomness
Date: Mon, 18 Oct 1999 10:14:10 -0600
In article <[EMAIL PROTECTED]>, Jon Haugsand
<[EMAIL PROTECTED]> wrote:
> * [EMAIL PROTECTED]
> > > I work in the GB range.
> > >
> > Good at testing randomness? Is this a random series: 45, 87, 3, 30.
>
> Hardly in the GB range.
>
Few have needs that might get there. My point is that it may simply not
matter in one sense. For the other extreme, see below:
Your search, well intentioned I'm sure, can fail to catch particular
patterns if they were never considered...sort of like proving an algorithm
has no novel break....well...exactly like that.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: Peter Pearson <[EMAIL PROTECTED]>
Subject: Re: Biometric Keys are Possible
Date: Mon, 18 Oct 1999 09:00:42 -0700
[EMAIL PROTECTED] wrote:
> What I'm talking about is a way to bypass that problem. Using Gray code, I
> can ensure those "different numbers" differ by one or two bits. Using
> check bits from an error-correcting code, stored with the User ID, I can
> correct a small number of such errors to get a fixed bit string, at a
> single workstation, for one individual.
John Savard has it right. In our demonstration system, the verifier's
database included the user's name, some error-correction information,
and a discrete-log problem to which the user's biometric held the
answer.
How much error-correction information you need is determined by
the reproducibility of the biometric readings and your tolerance
for false rejections. You want an error-correcting code that
can correct errors in as many as X bits, and you want statistics
indicating that the probability that two readings from the same
user will differ in more than X bits is less than your acceptable
false-rejection rate. Whether the readings are taken on the same
reader or different readers only affects the amount of error
correction required.
As John Savard observes, Gray codes are useful in reducing the
number of bits you have to be able to correct.
When the user presents himself for verification, the verifier
sends (over an unsecured line) the error-correction information
and a challenge for a proof-of-knowledge-of-a-discrete-log
protocol that the user should be able to answer
with the help of his biometric. The biometric
reader receives this information, reads the user's hand geometry
or iris patterns or whatever, and completes the
proof of knowledge. Secret information never appears outside
the biometric reader; and in particular, the verifier's database
need not contain secret information.
Naturally, given the distribution of biometric readings in the
general population and a user's error-correction information, an
attacker can narrow the search for that user's secret quantity.
The worse the biometric technology is, in terms of reproducibility,
the more error-correction information must be provided, and the
more the attacker's search is narrowed.
- Peter
------------------------------
** 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
******************************
