Cryptography-Digest Digest #400, Volume #10 Tue, 12 Oct 99 11:13:04 EDT
Contents:
Re: where to put the trust (Tom St Denis)
Re: where to put the trust (Tom St Denis)
Eric Young's libdes compilation (Jesper Gadeberg Jensen)
Re: where to put the trust ("Trevor Jackson, III")
Re: RSA Algorithm (Bo D�mstedt)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
(DJohn37050)
hmac for files
Re: FBI issues warrant for Alice & Bob (Gurripato)
Re: where to put the trust (Terry Ritter)
smart cards taking external RNG seeds (David A Molnar)
Re: where to put the trust (Patrick Juola)
Re: classifying algorithms (John Myre)
Scrambling identifiers (Markus Peuhkuri)
Re: where to put the trust (Patrick Juola)
Re: 512-bit key broken in microseconds?! bogus ! (Stefek Zaba)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Date: Tue, 12 Oct 1999 11:18:26 GMT
In article <rmAM3.777$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> Again, Its silly to blindly believe an expert. I never said I always put my
> trust in doctors or anyone for that matter. Most people don't get exposed
> to doctor's guesses or trial and error procedures, on the other hand so
> called expert cryptographers do exactly this. They devise a method study
> it, refine it then release it. People use it, test it, and in many cases
> its not the creator of the method who find the weakness. Also if you trust
> the 'experts' to make good ciphers, and I created a strong cipher, that
> wouldn't make an expert would it? This goes for any field of study, you
> just can't accept someone's idea because they have been right in the past.
> We make mistakes all the time.
I think you need to be more objective. People like Charlisie Adams
(spelling?) do not just throw ciphers together. The CAST design procedure
has been designed and studied for quite some time.
It's only thru trial and error that most experts learn anything, including
medicine.
I think the experts in cryptography (the press guru ones anyways) are self
evident... Scheneir, Rivest, Rijnmen, Daemon, Vaudenay, etc... However I
also believe if you have a math degree, some comp-sci, are objective you
could be a good cryptography guru as well.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Date: Tue, 12 Oct 1999 11:22:13 GMT
In article <[EMAIL PROTECTED]>,
Michael =?iso-8859-1?Q?Str=F6der?= <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > So what do we do?
> >
> > Well we trust experts.
> > [..]
> > Do they do good jobs? 99.99% of the time yes.
>
> The question is: Why are they doing good jobs in 99.9% of the cases?
> (I doubt that number is right but let's abstract of this.)
>
> Well, the jobs of doctors, bridge constructing engineers etc. are
> embedded in a legal system. They will be punished by law if things are
> going wrong. Actually there are some legal systems for applied
> cryptography (e.g. SigG in Germany) but the legal systems are still not
> full-featured to cover all aspects.
While I trust (for example) my doctors opinion, am I to take anything he says
as the pure simple truth. I don't think so.
If for example I have blurry vision, headaches and nausea and he tells it's a
head cold, I will want a second opinion, possibly even a CAT scan. [this is
just an example, in case you don't know, these are symptoms for circulation
problems in the head].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jesper Gadeberg Jensen <[EMAIL PROTECTED]>
Subject: Eric Young's libdes compilation
Date: Tue, 12 Oct 1999 11:43:14 GMT
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 (or maby my version is just to old)!
When I run the following: "make -f makefile.bc" I get (besides a lot of
other warnings):
...
Borland C++ 4.52 Copyright (c) 1987, 1994 Borland International
ofb64ede.c:
Warning des_locl.h 184: Redefinition of 'random' is not identical
bcc -c -ml -d -3 -O2 -DMSDOS supp.c
Borland C++ 4.52 Copyright (c) 1987, 1994 Borland International
supp.c:
Warning des_locl.h 184: Redefinition of 'random' is not identical
del libdes.lib
File not found
makersp "+%s &\n" MAKE0000.@@@ >libdes.rsp
Bad command or file name
tlib /0 /C libdes.lib @libdes.rsp,nul
TLIB 4.00 Copyright (c) 1987, 1994 Borland International
DOS-reported error: No such file or directory
opening 'libdes.rsp'
** error 1 ** deleting libdes.lib
C:\BC45\BIN\DES>
Can you help? If anyone has libdes compiled for DOS/Windows, I would
really appreciate if you could send me a copy by E-mail!
-Jesper
------------------------------
Date: Tue, 12 Oct 1999 07:37:44 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: where to put the trust
Michael Str�der wrote:
> Tom St Denis wrote:
> >
> > So what do we do?
> >
> > Well we trust experts.
> > [..]
> > Do they do good jobs? 99.99% of the time yes.
>
> The question is: Why are they doing good jobs in 99.9% of the cases?
> (I doubt that number is right but let's abstract of this.)
>
> Well, the jobs of doctors, bridge constructing engineers etc. are
> embedded in a legal system. They will be punished by law if things are
> going wrong. Actually there are some legal systems for applied
> cryptography (e.g. SigG in Germany) but the legal systems are still not
> full-featured to cover all aspects.
One of the most important differences is that you usually tell when a
doctor or engineer fails. You may not be able to tell when a cipher
designer fails because the people who profit by the failure profit by
keeping it secret.
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: RSA Algorithm
Reply-To: [EMAIL PROTECTED]
Date: Tue, 12 Oct 1999 13:38:56 GMT
Gary Partis wrote:
>Hi,
>
>We have implemented a sub-set of RSA (the EXP bit) in Z80 and even after
>extensive optimisation (and dedicated hardware to handle big numbers), it
>is still slow.... :-(
[...]
>Does any one know of an algorithm which overcomes this performance issue...
[...]
An alternative way would be to distribute keys using a key
server. Note that this approach has diminutive drawbacks,
compared to using public key cryptography.
...
Then there was some comments on the 128 bit RSA security:
Walter Hofmann, Regionales Rechenzentrum Erlangen, Germany
>I cannot see how 128 bits can provide any security, though.
Peter Pearson wrote:
>A 128-bit modulus is not secure, since 128-bit composite
>numbers can be easily factored.
Doug Stell, Motorola, wrote:
>As stated by others, 128-bit RSA keys are quite insecure and nearly
>useless. The 512-bit challenge was recently cracked and one should
>certainly use something larger than this. The absolute minimum today
>is probably 768 or 1024 bits.
Bill Unruh, ITServices, University of British Columbia wrote:
>Note that your use of only a 128 bit key makes your use woefully
>insecure.
Warning! Some very well informed researchers do not think that
RSA with a long modulus can provide any real security against
an resourceful opponent!
Bo D�mstedt
Chief Cryptographer
Protego Information AB
IDEON,Lund,Sweden
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 12 Oct 1999 11:50:52 GMT
Yes, sometimes the value of the message is so high that it is appropriate to
use encrytion with multiple algorithms, just in case one would break. I do not
see how the previous statement could be controversial to anyone.
I again like Brian's point. For small systems we may need to choose one
algorithm to do a particular job, but for large systems, it is much better to
go for algorithm independence, etc.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] ()
Subject: hmac for files
Date: 12 Oct 1999 12:56:39 GMT
I'm working on a program that produces an HMAC for files. It is much
like the "md5sum" but it also uses hmac. This is intended to securely check
if some files in a filesystem have changed. The program can be
found at http://hq.hellug.gr/~mcrypt/shash/.
Since I hadn't find much information on this except some rfcs, I'd
like some comments on the procedure I use.
1) If used in hmac mode, the program, asks for a password to be supplied.
2) The password is being hashed using sha-1 , thus we get a
16 byte key. (I use hashing to make brute force attack for small keys slower)
3) Four random bytes (from /dev/urandom) are appended to the key, as salt.
(to make brute force much slower)
4) Then this key is supplied to the algorithm-HMAC, as described in rfc2104.
5) The program outputs something like:
salt digest file
b84a3a1e d190829fb4370a7d264aaf480f58ea5c /etc/passwd
Do you think that this is secure enough for the purpose this program?
--
Nikos Mavroyanopoulos
mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]=NOSPAM (Gurripato)
Subject: Re: FBI issues warrant for Alice & Bob
Date: Tue, 12 Oct 1999 11:08:40 GMT
On Sun, 10 Oct 1999 03:11:47 GMT, [EMAIL PROTECTED] (Tom) wrote:
>>
>Well that certainly sounds paranoid. On the other
>hand, there is some truth to it, if you substitute
>"liberal/socialist" for "communist". Probably not
>worth a memo, though.
>
Not quite. In Spanish, the word "memo" is synonimous to dumb,
stupid, fool. So it is not so off-mark ;-)
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: where to put the trust
Date: Tue, 12 Oct 1999 13:08:01 GMT
On Mon, 11 Oct 1999 23:01:32 GMT, in <7ttq86$kda$[EMAIL PROTECTED]>, in
sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>I have been getting alot of flak about 'how do you KNOW that 'place cipher
>here' is actually this strong'. I admit there is no honest PROOF to it. No
>cipher is unconditionally strong, none, zippo, zilch. If you use an OTP
>wrong it can become weak. (Yes even the infamous Scottu19 has not been
>proven to be strong).
>
>So what do we do?
>
>Well we trust experts.
>
>Let's take a survey... If you do any of the follwing post a short reply...
>
>drive a car, goto the doctors, eat fast-food, use a computer, drive on
>bridges, live in an apartment, work in an office, gone to school ...
>
>You have probably relied on an experience expert. Do we trust them? Hell
>yes. Do they do good jobs? 99.99% of the time yes.
>
>So does this apply to cryptography? Yes I think so.
And I think you are fooling yourself.
Cryptography is different from the areas in which we trust expertise
because in cryptography there is no way for anyone to know whether any
particular approach is successful.
Would you really trust a doctor who could not know whether the
patients, having been treated, were alive or dead? Would you trust a
computer if you knew there was no way to check the results? Would you
drive on bridges if you did not know that bridges generally stay up?
Bridges generally stay up precisely because engineers can unarguably
distinguish between a bridge which falls and one that does not.
Without this, there is no way to measure prediction, and no way to
develop the knowledge to make predictions correspond to reality.
There are many predictions in cryptography, but no similarly apparent
result. There simply is no way to know when cryptography keeps things
secret from opponents who are themselves secret. There is thus no way
to judge risk, and similarly no way to judge expertise. In a very
essential way, there can be no real experts on cryptographic strength.
>So although (for example) Twofish has not been proven to be strong, it has
>been designed by people in the know, and I would trust it, just like I trust
>my doctor to give a good evaluation of my health.
And that is the same sort of argument that led Germany and Japan to
assume their codes were secure in WWII. They were both wrong.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: smart cards taking external RNG seeds
Date: 12 Oct 1999 12:01:14 GMT
Hi,
Does anyone know of smartcards which either
* use an external source (like the card reader) for random number
generation
or * have an on-card PRNG, but can be re-seeded easily
I am looking on my own, of course, but wanted to ask here as well.
Thanks much,
-David Molnar
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: where to put the trust
Date: 12 Oct 1999 09:55:37 -0400
In article <wovM3.96$[EMAIL PROTECTED]>,
Adam Durana <[EMAIL PROTECTED]> wrote:
>It is silly to blindly believe an expert. Comparing doctors to 'the
>experts' is a bad comparison at best. Doctors provide you with proof and
>explainations for thier diaginosis.
They do not. I don't think I've ever seen a doctor provide "proof",
nor can I imagine what any doctor could provide as a "proof" with
the possible exception of a pathologist -- at which point, it's
too late.
I walk into a doctor with a collection of symptoms, and the doctor
will make his best guess as to what I have, based on his observations,
my descriptions, and some test results (which are rarely conclusive,
but often informative). Then he will prescribe a course of treatment
which has been shown to be effective most of the time, assuming of
course that I don't have any particular difficulties with the treatment --
"Oh, didn't I tell you, I'm a penicillin-allergic."
They can easily provide you with explanations. So can cryptographers.
Doctors cannot provide you with proof, but they've usually got an
extensive literature and experience to back up their opinions.
So have cryptographers. Doctors can also make mistakes and misdiagnosis
or mis-read clinical signs. They can even be flat out wrong, without
making any particular mistake. So can cryptographers.
Why are you holding cryptographers to a higher standard than medical
doctors? Is your information more important than your life?
-kitten
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: classifying algorithms
Date: Tue, 12 Oct 1999 08:02:01 -0600
Joseph Ashwood wrote:
>
> My own (potentially) pitiful attempt.
>
> About Stream vs Block Ciphers.
> I have always found that the most conventiant way of thinking of the
> difference is that a block cipher is expressed as:
> f(k,d), where k is a key, and d the current block of data to be enciphered.
> where a stream cipher is a function as:
> f(k,d,p), where k and d are as before, but p is the prior data that has been
> through the cipher
>
> I've only seen one potential reason to think otherwise, and that's the
> observation that if the "stream" cipher simply ignores p it is effectively a
> block cipher. Now whether this is the case or that there should be an
> additional restraint that the stream function can not ignore the prior input
> is open for debate.
> Joe
In particular a stream cipher could depend on p merely to use
its length, as for any key-stream generator (e.g. RC4).
By your definition, most block cipher modes (OFB, CFB, CBC) are
actually stream ciphers; only ECB is really still a block cipher.
Does this seem reasonable?
John M.
------------------------------
From: Markus Peuhkuri <[EMAIL PROTECTED]>
Subject: Scrambling identifiers
Date: 12 Oct 1999 16:53:45 +0300
I have following problem. Any help or pointers to references
are welcome. I've read the FAQ and 4500 past messages (OK,
only subjects from most) but found no direct answer for this.
I have number of identifiers, which are organized as (group,
entity) so there are number (thousands) of groups and each
group will have (possibly) different number (say few hundred
to tens of thousands) members. There are possibly "holes" in
entity identifier sequences.
I like to have the identifiers scrambled so that the group
identifier (gid) is intact but the entity identifier is
scrambled (eid). There may be be some secret information
which is used in computation.
The purpose is that the attacker cannot find out original
entity identifier even if she knows:
* all (gid, entity), (gid, eid) pairs for maybe multiple
groups (not the protected entity group)
* some of (gid, entity), (gid, eid) pairs for the attacked
entity's group
So, the obvious try would be H(secret || gid || entity) and
taking suitable numbers of bits from the result. There could
be some collisions (two entities map to single eid) but I can
live with that given enough low probability. The hash
function would be some of well-known enough-safe algorithms
(like MD5, SHA).
Any obvious errors above?
However, as I might have very tight budget on processor
cycles, the "hard" algorithms may be too slow. (I haven't yet
evaluated: pointers to performance figures?). So, I like to
have a faster algorithm.
It is well shown in literature that LCGs are not safe to
produce cryptographic safe random numbers, but can they be
used in this case:
1 initialize LCG with gid, entity
2 run LCG with secret factors
3 get part of result
Of course, there are possibly not many good possible secret
factors for LCG, so some more states may be needed. Any
suggestions if LCGs are at all feasible for this?
Any other choices to scramble?
--
Markus Peuhkuri ! [EMAIL PROTECTED] ! http://www.iki.fi/puhuri/
========================================================================
Arithmetic is being able to count up to twenty without taking off your
shoes. -- Mickey Mouse
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: where to put the trust
Date: 12 Oct 1999 10:01:49 -0400
In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
>And I think you are fooling yourself.
>
>Cryptography is different from the areas in which we trust expertise
>because in cryptography there is no way for anyone to know whether any
>particular approach is successful.
>
>Would you really trust a doctor who could not know whether the
>patients, having been treated, were alive or dead?
That's most of the doctors, actually. Once you leave the office, very
few of them will follow you around to confirm that you stayed alive.
Similarly, very few bridge designers hang around their work watching
it for years lest it should suddenly fall over.
>Bridges generally stay up precisely because engineers can unarguably
>distinguish between a bridge which falls and one that does not.
... Yeah. *After it has happened*, assuming there was anyone around
to witness the fall. And even then, you need a team of experts to
examine the wreckage to figure out if it was a design flaw, a construction
flaw, or actual sabotage/demolition.
Just like cryptography.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: 512-bit key broken in microseconds?! bogus !
Date: Tue, 12 Oct 1999 14:12:49 GMT
In sci.crypt, Francois Grieu ([EMAIL PROTECTED]) wrote:
> The sunday-times article is a mess. As far as I understand it's
> a mixup of three things:
Yup - I'd also toss in the French banking smartcard crack as an element
of the zeitgeist leading to this story. As to Francois' third element,
> - A self-proclaimed "European Institute of Quantum Computing" has
> opened a web site at <http://www.eiqc.org>. It is an obvious joke.
> No member is listed, except "Dr Brian Oakley, EIQC Life President".
> There is a "Brian Oakley" page at <http://quantum.phy.okstate.edu/>
> greeting you with an anoying butthead sound; the guy is picturing
> himself as a student at the "Oklahoma State University in Physics",
> "interested in computer games, including Command & Conquer, Quake,
> and the upcoming Red Alert and X-Wing vs. Tie Fighter."
> I failed to find any scientific publication by Brian Oakley,
> or even on quantum physic from the Oklahoma State University.
no, it's not *that* Brian Oakley. The relevant Brian Oakley is a (let's
keep the right right side of British libel laws here :-) distinguished but
colourful figure on the British computing scene; most widely known for running
the Alvey research programme in the 1980s - this was a govt-sponsored joint
university and industry research effort, kicked off partly in response to
the Japanese Fifth Generation Computing Programme ("the second coming of AI"
:-) which in fact did rather a lot of good in getting academia and industry
more closely entangled [quantum-related pun intended. Sorry]. Latterly,
he's been President of the BCS (British Computer Society - like the ACM
but with cream teas :-) and has been visible in various science-policy-advisory
roles - unsurprising given his background. Not usually the last person in
a group to voice an opinion, he seems now to have become an enthusiast of
quantum computing, and may have thought sharing this enthusiasm with a
Times journalist needing good copy would be a great way of proselytising
the quantum cause. How grateful the quantum research community is for
being thus thrust into the limelight - or for the offer of a new non-profit
"forum for the collection, dissemination and discussion of information" on
QC - I leave as implied by the unidirectionality of weblinks between the
www.eiqc.org sites and those it references, and the continuing nullity of
the set of members listed on that website. A patently unscholarly metric, I'm
afraid.
Dang, there goes my chance of being elected as a BCS Fellow!
Cheers, Stefek
------------------------------
** 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
******************************
