Cryptography-Digest Digest #278, Volume #9 Wed, 24 Mar 99 14:13:04 EST
Contents:
Re: Live from the Second AES Conference (Jim Gillogly)
Re: RSA key distribution ("Sam Simpson")
Re: CD Cipher (R. Knauer)
Re: Random Walk ("karl malbrain")
Re: Live from the Second AES Conference (Alan Braggins)
Re: DIE HARD and Crypto Grade RNGs. (Mok-Kong Shen)
Re: Certicom Benchmark (Medical Electronics Lab)
Re: RSA key distribution (Michael Sierchio)
Re: Maurer's Universal Statistical Test C (was Re: idea for random numbers (Medical
Electronics Lab)
Re: RSA key distribution ([EMAIL PROTECTED])
Re: Test Vectors (iLLusIOn)
Re: DIE HARD and Crypto Grade RNGs. (Patrick Juola)
Re: QDD v0.1 : Quantum Computer Emulation C++ Library (Darren New)
Re: RSA key distribution (DJohn37050)
Re: Test Vectors (Medical Electronics Lab)
Re: Random Walk ("Trevor Jackson, III")
Re: Symmetric vs. public/private (Bo D�mstedt)
Re: Message Digest (Francois Grieu)
Re: Live from the Second AES Conference (DJohn37050)
Re: compare RSA and D-Hellman (DJohn37050)
----------------------------------------------------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Live from the Second AES Conference
Date: Wed, 24 Mar 1999 09:15:06 -0800
Thanks very much for the reports from the AES conference.
Your views and notes are invaluable, as they were from the
first conference. Well done!
[EMAIL PROTECTED] wrote:
> rounds. It is interesting to observe how cultural characteristics
> have an impact in this international process. The designers of the
> Asian candidates (E2 and Crypton) are really far too modest and
> this, I think, hurts their chances. American designers, of course,
> are the most crass, and I think this is a winning strategy.
Ouch!
> The standard answer is that mixing ciphers is a bad idea because the
> resulting cipher could be weaker than each individual one, that
> the resulting cipher would be a completely new cipher which would
> require fresh analysis which is the only way to gain trust, etc.
I don't know whose standard answer this is, but it has to be
totally bogus for immediately obvious reasons: if A.B is
E2.RC6 and it's weaker than either of them, then you
can mount an effective attack on E2 by encrypting it with
RC6, and vice versa. This can be done by the cryptanalyst
in possession of A-ciphertext, and doesn't need to have been
done by the sender.
Whoever gives this "standard answer" isn't thinking it through.
--
Jim Gillogly
2 Astron S.R. 1999, 16:56
12.19.6.0.17, 12 Caban 10 Cumku, Eighth Lord of Night
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: RSA key distribution
Date: Wed, 24 Mar 1999 17:16:31 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
[EMAIL PROTECTED] wrote in message
<7db0vg$8fe$[EMAIL PROTECTED]>...
>In article <7da5mu$rca$[EMAIL PROTECTED]>,
> "Roger Schlafly" <[EMAIL PROTECTED]> wrote:
>>
>> [EMAIL PROTECTED] wrote in message
<7d89rr$u8u$[EMAIL PROTECTED]>...
>> >In article
<01be7519$3e375b40$[EMAIL PROTECTED]>,
>> > "dino" <[EMAIL PROTECTED]> wrote:
>> >> Hi everyone
>> >> my customer asked me to assure him about uniform
distribution of RSA
>> keys.
>> >> Can anyone help me?
>> >
>> >Sure. What would you like to know?
>> >
>> >email me.
>>
>> I am sure that "bobs" can help you, but his views on this
subject are
>> somewhat controversial. He helped the ANSI X9.31 committee
adopt
>> a complicated construction for RSA keys, even though many
experts
>> believe that the construction adds nothing of any value over a
simple
>> random choice method.
<SNIP>
>(3) Please name the "many" experts you cite. The experts (those
who know
>factoring algorithms) are all in agreement that strong primes
are NOT
>necessary. This includes me, Peter Montgomery, A. Lenstra, H.
Lenstra,
>C. Pomerance, H. Cohen, S. Wagstaff Jr., and H. Williams.
All very interesting, but this was precisely the point of the
previous post: "even though many experts believe that the
construction adds nothing of any value over a simple random
choice method."
So you both agree on this point, right?
- --
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components. PGP Keys available at the
same site.
If you're wondering why I don't reply to Sternlight, it's because
he's kill filed. See http://www.openpgp.net/FUD for why!
=====BEGIN PGP SIGNATURE=====
Version: 6.0.2ckt http://members.tripod.com/IRFaiad/
iQA/AwUBNvkd5O0ty8FDP9tPEQJclwCgs5800nhLgyITDr1A+WMszhOq7RUAn0yC
lysMZRi2nNAidZxGx5X0WZ6R
=GRjf
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: CD Cipher
Date: Fri, 12 Mar 1999 20:37:20 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 12 Mar 1999 20:14:06 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>I remember discussing something like this a while back, in posts entitled
>"My Large-Key Brainstorm", so, naturally, I'm biased in favor of the idea.
Well... don't keep us in such suspense. What is it?
Bob Knauer
"My choice early in life was either to be a piano-player in a whorehouse
or a politician. And to tell the truth there's hardly any difference."
-- Harry Truman
------------------------------
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Random Walk
Date: Wed, 24 Mar 1999 09:36:02 -0800
R. Knauer <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The reason is that obscurity can also pass for
> unpredictability, and we know that is not a good way to build
> cryptosystems.
> >MeThinks you've gone quite over the edge on this one -- the very NATURE
of
> >the OTP is one of OBSCURING the plaintext under <<white>> noise XOR with
the
> >KEYSTREAM (or other LINEAR function).
>
> Something far more fundamental than mere obscuring happens with the
> OTP cipher. If you and your correspondent lose the key for a given
> ciphertext, the message is lost forever. No matter how hard you try to
> "find" the message, you will fail.
>
Dictonary definition of OBSCURE:
5. Not clear, full, or distinct; clouded; imperfect; as, an obscure view of
remote objects. Obscure rays (Opt.), those rays which are not luminous or
visible, and which in the spectrum are beyond the limits of the visible
portion. Syn. -- Dark; dim; darksome; dusky; shadowy; misty; abstruse;
intricate; difficult; mysterious; retired; unnoticed; unknown; humble; mean;
indistinct.
Please note the tie into previous posts re: UNCERTAINTY PRINCIPLE. Obscure
is a measure for BEYOND THE LIMITS OF RETRIEVAL. After you burn a negative
with too much light, you can't go back to retrieve the previous image taken
there. Note also the reference to dropping into the RADIO spectrum to
<<bring-to-light>> an obscured images, as is done with Defense Early Warning
System (DEWS), etc.
So, indeed, as a person of all persons, I submit that you've stepped beyond
the pale and are making words fit your circumstances. Karl M
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Subject: Re: Live from the Second AES Conference
Date: 24 Mar 1999 16:14:17 +0000
[EMAIL PROTECTED] writes:
> it appears that the very fastest code is self-modifying - this may
> look "unpure" to some but I think that it is a valid optimization
> technique).
[...]
> improvement. As expected the answer is no, because one of the
> easiest things to read from a card is the "signature" of the
> instructions being executed.
Any ideas whether self-modifying code would make reading instruction
signatures easier or more difficult?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Fri, 12 Mar 1999 18:22:26 +0100
Patrick Juola wrote:
>
> >
> >I suppose that computational cost is a relevant practical issue.
>
> But one the other hand, if you assume a large amount of time available,
> for example, in an off-line attack, then it doesn't make sense to
> be worried about the efficiency of the generator and the size of
> the generator is a reasonable measure of complexity.
I don't quite understand what you said in the current context.
I was questioning why the efficiency of a program plays no part
in the Kolmogorov complexity (if one thinks that complexity is
essentially related to computational effort at all).
M. K. Shen
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Certicom Benchmark
Date: Fri, 12 Mar 1999 16:55:09 -0600
Michael Scott wrote:
> Key generation 1024-bit DH - 91.67ms (14ms)
> Shared secret 1024-bit DH - 108.33ms (17ms)
> Key generation 2048-bit DH - 611.67ms (65ms)
> Shared secret 2048-bit DH - 728.33ms (80ms)
>
> As you can see the differences are highly significant. It is suggested in
> the text that standard DH benefits from the use of the Pentium Pro
> co-processor. It doesn't, and I didn't use it.
What we have to do is compare the same machines with similar
code. All the comparisons should show ECDH to be faster simply
because the field size is smaller.
>
> When I commented on these benchmarks before, I was surprised that even
> someone as knowledgable as our own patient, persistent and truthful Dr, mike
> was apparently happy to take them at face value. But to do so would in my
> opinion be a mistake.
I agree. Let's to a real test, on the same machine run the two
codes side by side. Anything else won't mean much.
> For a well-balanced comparison see Michael Weiner's article "Performance
> comparison of Public Key Cryptosystems" in RSA labs Cryptobytes, Vol. 4, No.
> 1, 1998 from www.rsa.com
> After a thoughtful analysis he gives some results (also from a Pentium
> 200MHz) which indicate that certain EC methods are about 50% faster when
> comparing DSA (1024-bits) with ECDSA (168 bits). He states that DH and ECDH
> are comparable speed-wise - which flatly contradicts Certicom's claims. He
> also makes the interesting observation that software implementations of
> Elliptic curves over GF(2^m) appear to be slower than those over GF(p), but
> accepts that reports differ on this.
I find it hard to believe, but I've been wrong before. GF(2^m) is
so much simpler than GF(p) in terms of basic operations that it ought
to be faster.
I'll be happy to help you set up a test between the two on your machine.
Send me e-mail at [EMAIL PROTECTED] and we can put some code
together that will do a nice test for posting up here.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: RSA key distribution
Date: Wed, 24 Mar 1999 08:36:23 -0800
Reply-To: [EMAIL PROTECTED]
Roger Schlafly wrote:
> ...He helped the ANSI X9.31 committee adopt
> a complicated construction for RSA keys, even though many experts
> believe that the construction adds nothing of any value over a simple
> random choice method.
"many experts believe" requires some qualification. References?
Definition of "many" and "expert?"
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Maurer's Universal Statistical Test C (was Re: idea for random numbers
Date: Wed, 24 Mar 1999 12:12:14 -0600
[EMAIL PROTECTED] wrote:
> About 60 or 70 percent of NSA were smoking pot -- a lot of them while on
> duty. It's very relaxing, particularly when you're bored with the
> Russian or East German traffic that is coming through.
> http://jya.com/nsa-40k.htm
I hope it's sinse!
BTW, thanks for the code, I'll put it to work.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA key distribution
Date: Wed, 24 Mar 1999 15:39:30 GMT
In article <7da5mu$rca$[EMAIL PROTECTED]>,
"Roger Schlafly" <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote in message <7d89rr$u8u$[EMAIL PROTECTED]>...
> >In article <01be7519$3e375b40$[EMAIL PROTECTED]>,
> > "dino" <[EMAIL PROTECTED]> wrote:
> >> Hi everyone
> >> my customer asked me to assure him about uniform distribution of RSA
> keys.
> >> Can anyone help me?
> >
> >Sure. What would you like to know?
> >
> >email me.
>
> I am sure that "bobs" can help you, but his views on this subject are
> somewhat controversial. He helped the ANSI X9.31 committee adopt
> a complicated construction for RSA keys, even though many experts
> believe that the construction adds nothing of any value over a simple
> random choice method.
You know nothing about my views yet presume to state that they are
controversial.
You were not present at the ANSI meetings so how do you know what went on?
Your claims about what occurred are highly unprofessional because you were not
there.
You state that the method is complicated, yet this too is false.
ANSI X9 does crypto standards for the banking community. Bankers are
excessively paranoid. (with multi-billion dollar IMF transactions, I don't
blame them. They are very worried about liability).
(1) The method I suggested was *forced* upon me because the banking
industry insisted that RSA keys be made from strong primes. In fact, I
argued long and hard for merely using random primes, but the political
climate was such that such a proposal was doomed to failure. My views are
exactly opposite to what you think they are. I do NOT advocate strong primes.
The banking industry demanded strong primes, so I gave them a simple and
fast technique for generating them. If you had been present at the meetings,
you would know this.
(2) The method is anything but complicated. It simply requires that N=pq
have p+/- 1 and q+/-1 with at least one prime factor >= 100 bits.
This is done by randomly selecting 4 100+ bit primes which are those factors.
One then randomly chooses a starting point to look for p,q and uses the CRT to
construct an arithmetic progression such that every number in the progression
has p,q +/-1 divisible by the 100 bit primes. One sieves out the candidates in
the progression which are divisible by small primes, then progressively tests
the numbers which survive the sieve for primality. The method is VERY fast.
(3) Please name the "many" experts you cite. The experts (those who know
factoring algorithms) are all in agreement that strong primes are NOT
necessary. This includes me, Peter Montgomery, A. Lenstra, H. Lenstra,
C. Pomerance, H. Cohen, S. Wagstaff Jr., and H. Williams. And while
requiring strong primes may not be a mathematical necessity, it makes the
user community more at ease with the standard. This last fact, in and of
itself, gives value to the technique.
(4) Having a slightly sub-optimal standard now is better than waiting several
years to try to force an optimal one. ANSI standards are voted upon by the
banking industry. It is they who decide what is acceptable for them to use.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: 24 Mar 1999 17:50:24 -0000
From: iLLusIOn <Use-Author-Address-Header@[127.1]>
Subject: Re: Test Vectors
=====BEGIN PGP SIGNED MESSAGE=====
I wanted to create a webpage like that some time ago also, so if you need
help with the html pages or organization send me an email :-)
//iLLusIOn
>Good idea, i might start work on a page for the less mathamaticly minded
>people like my self who want implementation rather than theory.
>
>cheers
>Tim
~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Wed Mar 24 17:50:18 1999 GMT
From: [EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: 2.6.2
iQEVAwUBNvkl305NDhYLYPHNAQFu0Qf+OQ4PFoGFA6A8R9Hh3dj1EiK8YyQPH/EZ
3nven/V3uRxVG4qKuCofiwPP7D1JBgAjPg2raAud5z8a8pSVacdZHILyQevMGt57
BOQmIJ9hBmIUjxwSaT+gpoOxxFO/La0TTKYLEG2Ee7Y8YtT6HOpbzmXsI7BSXy0J
B8duVMzoqTt3LhDyQJj0HUSSBzQk2/nftbAqSyD50G3nafLOuAppe1NxaFIIU6HQ
NMuKLOkV9rpqzN5n5mGm/mdszNUycB6qQPbpIQG8Htfli1et9Ww2rtb+9k4/lL+4
WESE+dYAAzpL/vTGX0V48F77XxsBL46n1scV41kKJ23FnddBdTRpbA==
=5R3c
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 12 Mar 1999 14:09:29 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>>
>> >
>> >I suppose that computational cost is a relevant practical issue.
>>
>> But one the other hand, if you assume a large amount of time available,
>> for example, in an off-line attack, then it doesn't make sense to
>> be worried about the efficiency of the generator and the size of
>> the generator is a reasonable measure of complexity.
>
>I don't quite understand what you said in the current context.
>I was questioning why the efficiency of a program plays no part
>in the Kolmogorov complexity (if one thinks that complexity is
>essentially related to computational effort at all).
Because that's the way that Kolmogorov complexity is defined;
optimization for program size. This particular definition works
out to have some useful mathematical properties, too, which is why
Kolmogorov's papers didn't sink without a trace.
Whether or not K-complexity is *relevant* to any particular application --
in particular because it explicitly ignores any timing implications --
depends of course on the application.
If you want to define the complexity of a sequence as the minimum amount
of *time* it takes to output the sequence, defined over all possible
programs, that's simply a different complexity measure. And, in
practical terms, pretty useless -- the minimum time is just proportional
to the length of the string and obtained by a sequence of write()
calls.
If you want to define the complexity of a sequence as some joint
function of minimum time and minimum machinery, you have all the problems
of a joint optimization, but there may be a meaningful metric there.
And, of course, if you want to define the complexity of something
other than a sequence, K-complexity is inappropriate and you'll need
a completely different approach.
But your question verges on the meaningless -- why does a triangle
have only three sides?
-kitten
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: QDD v0.1 : Quantum Computer Emulation C++ Library
Date: Wed, 24 Mar 1999 17:35:41 GMT
> I'm pleased to announce the first release of QDD, a C++
> Library for Quantum Computer Emulation.
Now the question is whether this can be used to allow a classical
computer to generate True Random Numbers (TM). ;-)
--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
"For efficient programs, practice featurecide regularly."
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA key distribution
Date: 24 Mar 1999 18:52:06 GMT
I was also at the ANSI X9F1 meeting where it was decided that the X9.31
standard would require strong primes. There is at least one cryptographer
talking about "safe" primes for use in RSA which have even more criteria than
strong primes. I think the organizations that voted YES thought that as the
performance cost was low (less than 5%) it MIGHT have a positive effect on
security. That is, it was a conservative decision to make. My take is that it
is the user's right to make such a decision. P.S. On this vote I voted
ABSTAIN.
Don Johnson
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Test Vectors
Date: Wed, 24 Mar 1999 12:40:55 -0600
Tim Fowle wrote:
>
> Good idea, i might start work on a page for the less mathamaticly minded
> people like my self who want implementation rather than theory.
Let me know and I'll toss in some test vectors
for Gf(2^n) math too. So far only a few people
have asked so it's pretty easy to just send
something
directly, but having a web site of test vectors
for lots of different things makes good sense.
Patience, persistence, truth,
Dr. mike
([EMAIL PROTECTED] too)
------------------------------
Date: Wed, 24 Mar 1999 13:52:33 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Walk
karl malbrain wrote:
>
> R. Knauer <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > The reason is that obscurity can also pass for
> > unpredictability, and we know that is not a good way to build
> > cryptosystems.
>
> > >MeThinks you've gone quite over the edge on this one -- the very NATURE
> of
> > >the OTP is one of OBSCURING the plaintext under <<white>> noise XOR with
> the
> > >KEYSTREAM (or other LINEAR function).
> >
> > Something far more fundamental than mere obscuring happens with the
> > OTP cipher. If you and your correspondent lose the key for a given
> > ciphertext, the message is lost forever. No matter how hard you try to
> > "find" the message, you will fail.
> >
>
> Dictonary definition of OBSCURE:
>
> 5. Not clear, full, or distinct; clouded; imperfect; as, an obscure view of
> remote objects. Obscure rays (Opt.), those rays which are not luminous or
> visible, and which in the spectrum are beyond the limits of the visible
> portion. Syn. -- Dark; dim; darksome; dusky; shadowy; misty; abstruse;
> intricate; difficult; mysterious; retired; unnoticed; unknown; humble; mean;
> indistinct.
Since the term "cryptic" is missing from the above list of synonyms,
should we conclude that obscurity is not useful for cryptological
purposes?
>
> Please note the tie into previous posts re: UNCERTAINTY PRINCIPLE. Obscure
> is a measure for BEYOND THE LIMITS OF RETRIEVAL. After you burn a negative
> with too much light, you can't go back to retrieve the previous image taken
> there. Note also the reference to dropping into the RADIO spectrum to
> <<bring-to-light>> an obscured images, as is done with Defense Early Warning
> System (DEWS), etc.
>
> So, indeed, as a person of all persons, I submit that you've stepped beyond
> the pale and are making words fit your circumstances. Karl M
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: Symmetric vs. public/private
Reply-To: [EMAIL PROTECTED]
Date: Wed, 24 Mar 1999 18:56:44 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
>What do you mean by "securely"? Do you mean with authentication,
>privacy or both?
>
>Of course if "securely" means something different in the case
>of public key distribution from what it means in the case of
>secret key distribution, then the "doesn't matter" claim is
>nonsense.
>
>--Bryan
First, the Reader should note that Bryan Olson has been
informed, in detail, about this issue already. His question is
thus rhetoric in the sense that "securely" _do_ mean different
things in the context of "Public Key" vs "Secret Key" key
distribution protocols.
For the "Secret Key" key distribution protocol "secure" means
that the key is both authentic and secret. A "Public Key"
can, obviously, be transferred by non-secret means.
In a public key network, the Key Signing Authority first
generates its own secret/public key pair. So do the network
nodes. The public key, of a network node, must be signed
by the Key Signing Authority, in order to be accepted as valid
by the other nodes in the network.
When transferring a public key, of a node, to the
Key Signing Authority for signing, it is essential that
a) It is possible, for Key Signing Authority, to prove
that the key originates from the node in question,
b) It is possible, for Key Signing Authority, to prove
that the node is allowed to be a member of the network.
The node may encrypt his public key by the public key
of the Key Signing Authority... :
It is then essential that
a) The node can prove that the public key obtained,
from the Key Signing Authority, is indeed the correct one.
b) The Key Signing Authority can prove that the encrypted
key originates from the node in question, and
c) It is possible, for Key Signing Authority, to prove
that the node is allowed to be a member of the network.
Note that, in almost all literature (see 1 and 2!!), the above
essential problems is ignored by a statement like "The key is
first encrypted by the published /signing/ key" -- the key word
here is "published". Do such things exist?
In practice, the above problems (ab,abc) is solved by
transferring the public keys securely, in the sense of
a "Secret Key" key distribution protocol. The system administrator
stores the public key on a diskette, put the diskette inside an
envelope, and travels to the node himself, where he installs the
key (and he also installs the public key software and the
operating system.)
Note that it is NOT required that the public keys be transferred
secretly -- you are allowed to copy the diskette in transit (sic!).
But from a practical point of view, there is no other way
of transferring the keys _securely_ - you may transfer
the keys insecurely, of course, if you wish!
In practice you may store the key inside a key loader, and
then distribute the key, protected inside the machine, by
ordinary mail. Does it matter much if you use public or secret
key encryption?
--- It does matter very much if you wish to disconnect a node
from the network. When using secret key encryption you simply
deny the node any more session keys - this can be done on
a time basis, as a function of some event, etc. - a simple
database transaction. When using Public Key Encryption
the key revocation problem is very much more interesting
-- see [4] -- available online. Enjoy!
(Quote from [3])
..."the advantages of public key systems evaporate when one
actually integrates them into a larger system."
Bo D�mstedt
Cryptographer
Protego Information AB
http://www.protego.se
"Bo D�mstedt" wrote:
> It doesn't matter if you use pubic key encryption
> or symmetrical (secret key) encryption. You still have
> to distribute the keys securely. To do that efficiently you
> need a key distribution centre. The centre is called a key
> signing authority if you use public key encryption .
Right or wrong? E-mail me your point of view!
References:
[1]:
Subject: RSA Cryptography Today FAQ (1/3)
Date: 19 Apr 1997 10:31:49 GMT
Message-ID: <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
"Each person's public key is published while the private key is
kept secret. The need for sender and receiver to share secret
information is eliminated: all communications involve only public
keys, and no private key is ever transmitted or shared. No longer
is it necessary to trust some communications channel to be
secure against eavesdropping or betrayal."
[2]:
Subject: Cryptography FAQ (06/10: Public Key Cryptography)
Date: 10 Mar 1999 14:05:59 GMT
Message-ID: <[EMAIL PROTECTED]>
"6.2. How does public-key cryptography solve cryptography's Catch-22?"
..." In a public-key cryptosystem, you just publish
X, and you don't have to worry about spies. Hence public key
cryptography `solves' one of the most vexing problems of all prior
cryptography: the necessity of establishing a secure channel for the
exchange of the key. "
[3]:
Kline, C.S. and Popek, G.J.
"Public Key vs Conventional Key Encryption"
AFPS Conference Proceedings,
Vol 48, 1979 NCC Pages 831-837
(c) 1979 by AFIP Press.
Reprinted by permission in
"Advances in Computer System Security"
by Rein Turn (editor) Chapter 6.2, pages 291-297
(c) 1981 by Artech House, Inc.
ISBN 0-89006-096-7
[4]:
Cooper, David A.
"A Closer Look at Revocation and Key Compromise in
Public Key Infrastructures"
Computer Security Division, NIST
http://csrc.nist.gov/nissc/1998/proceedings/paperG2.pdf
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Message Digest
Date: Wed, 24 Mar 1999 19:34:42 +0100
[EMAIL PROTECTED] wrote:
> Given a 256 bit message, and a 128 bit digest, are there 2^128 256 bit
> messages that will make the same message digest?
Yes. Given a digest function making a 128 bit digest from any 256 bit
message, there is a least one set of 2^128 messages with the same digest.
Proof: if this did not held true, each possible digest would have at most
2^128-1 corresponding messages. There are 2^128 digests, so there would be
at most 2^128*(2^128-1) messages, which is less than the 2^256 messages.
Note 1: if one can find "much" more than 2^128 messages with the same
digest, the digest function is "no good" from a cryptographical point of
view.
Note 2: It is possible to construct functions such that all digests are
exactly equaly likely, but this may not be a good idea.
Other (maybe hard and/or not formulated precisely enough) question : can
one construct a public, computable digest function such that all digests
are exactly equaly likely, but still match usual security requirements
a) it's hard to find two messages with the same digest
b) it's hard to find one message with given digest [weaker]
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Live from the Second AES Conference
Date: 24 Mar 1999 19:04:13 GMT
Yes, I mention AB encryption (or even more) as Super AES in my paper as a
possibility for the paranoid that want to spend the MIPS.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: compare RSA and D-Hellman
Date: 24 Mar 1999 19:06:55 GMT
BTW, Dan Boneh has recently proved that attacking ECDH is fully exponential if
ECDLP is. This analogous statements are not (known to be) true for DH and DLP
and RSA and IFP.
Don Johnson
------------------------------
** 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
******************************
