Cryptography-Digest Digest #544, Volume #10 Thu, 11 Nov 99 04:13:03 EST
Contents:
Re: PI digits (was Proposal: Inexpensive Method of "True Random Data" (Hans Moravec)
Re: Research suggestion? (SCOTT19U.ZIP_GUY)
Has anyone used CryptoPunk? (MEGstir)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry
Ritter)
Re: Can the SETI@home client be protected? (David Wagner)
Re: secrecy/generation of IV ([EMAIL PROTECTED])
Re: Is there a secure-messaging service? ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Hans Moravec <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: PI digits (was Proposal: Inexpensive Method of "True Random Data"
Date: Wed, 10 Nov 1999 21:32:11 -0500
[EMAIL PROTECTED](Steven B. Harris):
> However, several million digits [of PI] have been calculated,
> and these are equiprobable, to the limit of what most people
> consider probable ...
That's a little out of date, unless 51,540 counts as several:
http://www.cecm.sfu.ca/personal/jborwein/Kanada_50b.html
Excerpt:
Declared record: 51,539,600,000 decimal digits
Yasumasa KANADA and Daisuke TAKAHASHI
Two independent calculations based on two different algorithms
generated 51,539,607,552 (=3*2^34) decimal digits of pi and
comparison of two generated sequences matched 51,539,607,510
decimal digits, e.g., a 42 decimal digits difference. Then we
are declaring 51,539,600,000 decimal digits as the new world
record. (See related lecture on Pi and Mathland article.)
Frequency distribution for pi-3 up to 50,000,000,000 decimal places:
'0' : 5000012647; '1' : 4999986263; '2' : 5000020237; '3' : 4999914405
'4' : 5000023598; '5' : 4999991499; '6' : 4999928368; '7' : 5000014860
'8' : 5000117637; '9' : 4999990486;
Chi square = 5.60
Frequency distribution for 1/pi up to 50,000,000,000 decimal places:
'0' : 4999969955; '1' : 5000113699; '2' : 4999987893; '3' : 5000040906
'4' : 4999985863; '5' : 4999977583; '6' : 4999990916; '7' : 4999985552
'8' : 4999881183; '9' : 5000066450;
Chi square = 7.04
Main program run:
Job start : 6th June 1997 22:29:06
Job end : 8th June 1997 03:32:17
Elapsed time : 29:03:11
Main memory : 212 GB
Algorithm : Borweins' 4-th order convergent algorithm
(Run the algorithm.)
The 18th iterate actually agrees with Pi to more than 187 billion
digits.
Verification program run:
Job start : 4th July 1997 22:11:42
Job end : 6th July 1997 11:19:58
Elapsed time : 37:08:16
Main memory : 188 GB
Algorithm : Gauss-Legendre algorithm (Brent-Salamin)
Optimized main program run:
Job start : 1st August 1997 23:04:15
Job end : 3rd August 1997 00:18:47
Elapsed time : 25:14:32
Main memory : 212 GB
Algorithm : Borweins' 4-th order convergent algorithm
Machine used: HITACHI SR2201 at the Computer Centre,
University of Tokyo, with 1024 Processors.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Research suggestion?
Date: Thu, 11 Nov 1999 06:33:02 GMT
In article <[EMAIL PROTECTED]>, Peter Pearson <[EMAIL PROTECTED]> wrote:
>Rick Decker wrote:
>>
>> I have a student (senior double major in math, cs) who's interested in
>> doing a thesis in crypto. Problem is that I'm trained as a topological
>> graph theorist cum computer scientist and don't know much more about
>> the subject than what I need to teach it in my algorithms course.
>>
>> Anyone have a suggestion for a research project that would be suitable
>> for a semester-length project? My student is pretty quick, but the
>> project need not lead to original results-- a new interpretation or
>> tweak of an existing result would be satisfactory. The thesis is
>> nominally in cs, but need not include a programming component.
>
He could try to look at "all or nothing" type of crypto systems
such as scott16u compared to any of the short keyed AES systems
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (MEGstir)
Subject: Has anyone used CryptoPunk?
Date: 11 Nov 1999 05:58:23 GMT
Have you used CryptoPunk, if so, what do you think about it? Any comments is
greatly appreciated. Thanks much.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Thu, 11 Nov 1999 06:05:54 GMT
On Thu, 11 Nov 1999 01:27:24 GMT, in <80d61p$r1u$[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] wrote:
>Terry Ritter wrote:
>[EMAIL PROTECTED] wrote:
>[...]
>> >One more time: secret is not the issue. Authenticated
>> >is the issue.
>>
>> Well, in cryptography, there are various kinds of authentication:
>
>Glad you're seeing that.
In the rest of the paragraph -- which you did not see fit to include
here -- I described various types of "authentication."
I named them. You did not. You failed to distinguish between them,
and completely failed to identify what sort of "authentication" you
were addressing. Strangely, it's like you really didn't know what you
were talking about, or at least could not express it clearly. Odd.
>[...]
>> >One side can certainly make a random
>> >choice, but your method calls for them to agree, and
>> >thus the choice must be influenced by messages between
>> >them. You have simply assumed the choice would be
>> >random, without ever presenting how they ensure it
>> >will be random when an attacker may modify the messages
>> >that influence the choice.
>>
>> First of all, the "random" selection I propose is exactly the same
>> sort of thing which produces message keys (or "session keys," if they
>> are used for multiple messages), which are used in almost every
>> serious cipher system. Normally, the public-key component transfers
>> the message key, which is then used in a secret-key system. This is
>> very well known technology, and the issues are also well known, so
>> there should be little need to repeat these well known details.
>
>Many or most serious systems use session keys where
>each key is chosen by one side, thus requiring no
>negotiation.
"Session keys" (more properly called "message keys," in most cases)
are in fact very close to the negotiation which I have been promoting
all along. In my proposal, one end sends a list; the other selects
from that list, repeatedly, perhaps with every message, much like a
message key. Occasionally a new list is requested or just sent. I
suppose one might well say that all this requires "no negotiation,"
and this is the normal situation.
>In systems that negotiate choice of
>cipher the "well known details" are well known for
>their difficulty; failure to authenticate the cipher
>negotiation was a mistake in SSL.
In my proposals, it is has been, and still is, unnecessary to
authenticate the cipher choice. No authentication mistake is possible
with respect to cipher choice. The ciphers themselves must be
authentic, but that is not a cipher-change protocol issue.
>Over and over you've stated that the negotiation is
>secret, protected by a cipher. When did you note
>the need for authentication or name a MAC or
>signature? Now you say it's just like other cipher
>systems, such as public key ciphers. Ciphers provide
>poor authentication, and public key ciphers don't
>really provide any authentication at all. It is
>not the case that your claim of secrecy, protected
>by a cipher implies authentication. In fact it
>implies that you missed the attack.
I have always said that the cipher-change negotiation must occur under
cipher. I am guilty of expecting that cipher system to be effective.
But I missed no attack, because there was and is no attack on the
cipher-change protocol itself, which is all I have been describing.
The cipher-change protocol does *not* have the man-in-the-middle
problems which seem inherent in public-key cryptography. This is
because the cipher-change "negotiation" is simply not exposed to MITM
diddling. A MITM must be detected by the outer cipher layers, for if
not, the plaintext is exposed, making cipher-changes completely
irrelevant. I am unaware of any claim that cipher-changes would solve
the MITM problem for public-key cryptography.
You seem to have several big problems here, the first being the
possibility that I missed something, and so deserve your castigation.
Well, I did *not* miss what you think I did, but even if I had, who
elected you God? If you had found a factual problem, you could
present that. Instead, you cop an attitude and distort reality, both
of which are way out of line.
Then you seem to think that because I made the original proposal, that
if only you could find some error in it, I would be embarrassed.
Sorry. There are always problems with new proposals, because they
have not had the amount of development the old ones have had. The
real issue is whether the underlying idea is correct, and here it is.
Your "authentication" issue is both specious and an embarrassingly
shallow understanding of the real problem.
>> Next, it is true that messages must be sent between the ends to
>> coordinate cipher changes. But these messages are -- once again --
>> sent *under cipher*. By "under cipher," I mean that I require that a
>> cipher already have been established and be in effect. Whatever
>> cipher system has been established will authenticate received messages
>> in some way (often with a hash of the plaintext), and thus will detect
>> "any" attempt by an attacker to "modify the messages."
>
>Now you're starting to get it. This authentication
>was completely missing from your suggestion before
>others pointed out the problem.
There was and is no problem, and what was pointed out was wrong. If
the public-key certification or message authentication is bad, the
original security is bad, and there is no protection for the raw
plaintext that we are trying to protect, so cipher-change negotiation
is the least of the problems.
Your peculiar concentration on "authentication" obscures the real
problem, and that problem is that the original cipher must be secure
in many ways, including algorithm, key, and implementation. Where did
*you* ever say that *those* were required? But they *are* required,
and you missed those "attacks." Tsk, tsk.
>Yes, it can be fixed,
>but the actual protocol design is not the simple
>exercise you had thought.
The protocol is *just* as simple as I first proposed. There is
essentially no protocol there at all: We just select at random from a
list.
The design part of this is the construction of a hidden command
channel behind the plaintext, the various messages and retained state
required to perform a clean transition, and I believe, the ability to
withstand message loss without problem. This does require some
design, and failure here means we will not change ciphers, or may do
so in regular ways.
In other words, the *worst* that can happen from a bad cipher-change
protocol is that we end up using one cipher repeatedly, which is the
*normal* situation now. Failure in the protocol is thus only a
failure to take advantage of new cipher-change strength, and not an
introduction of weakness.
>> >Whether an authentication code be compromised is
>> >beyond the scope of the protocol. The point is the
>> >need for authentication and its absence from your
>> >proposal.
>>
>> If you are describing a need for message authentication, I wholly
>> agree.
>
>So thank people for pointing out that you needed it in
>your negotiation phase, and stop pretending that you had
>it there already.
It was clear enough for almost everyone else who read my proposals.
Stop pretending that you have contributed something important. You
have not. Stop pretending that I have ignored or dissembled about a
real problem. I have not.
As far as I know, the only real problem which came up was the need for
additional protection for the command channel, beyond that used for
the plaintext. That was pointed out by "others," not me. But that is
not your "authentication," and it is easily fixed.
>> This should be a part of any cipher, and is in fact a part of
>> all of my commercial ciphers. This is very well known technology.
>
>The cipher agility of your actual systems is far behind
>the state of the art.
"Cipher agility" would seem to mean the ability to change ciphers
quickly. Any system which can do this is *beyond* the current state
of the art. My proposals thus *are* the state of the art in
non-government cryptography.
My proposals allow ciphers to change, at random, from an approved
list, with *every* *message*. That's about as "agile" as one can get.
>You claim to be long-time advocate
>of standard protocols with interchangeable cipher,
Not only do I claim this, I can prove it, based on archived messages
on my pages and other servers.
>and that
>the design of such protocols is easy.
Really?
I doubt I ever said that the design of such protocols was "easy."
These protocols are, however, far different from the usual obscure
cryptographic protocols which typically have almost endless
possibility of error. In that sense, cipher-change protocols *are*
easi*er*.
>Your commercial
>ciphers contradict such claims.
I'm a little confused here: Are you saying that I have produced
ciphers of such complexity that they obviously were not easy to
design? Guilty.
Actually, my ciphers are fairly simple, as serious systems go. But
the design and actual implementation of real cipher systems is not
easy. Perhaps you should try it, so we can see how well *you* do.
In fact, perhaps you should come up with your own proposal to improve
cryptography, so we can see how well you do at *that*. Maybe you
should write and publish an article so we can judge that too.
Clearly you have trouble with the concept of what an "attack" is, and
it has taken you weeks to understand the basic concept of dynamic
cipher-changing, which most readers got in the first or second
posting. I suggest more study and less ranting.
Frankly, since your years-ago claim to have a break for my Fenced DES
Cipher broke down in your own failure, you have been hard to live
with. The reality is that I produced a design which, in the end,
withstood your attacks; I built a cipher which you thought you could
break, but could not. I'm sure it was very embarrassing for you. But
everyone makes mistakes, and those of us who speak out are especially
exposed; most of us accept reality and move on. Get over it.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Can the SETI@home client be protected?
Date: 10 Nov 1999 22:18:36 -0800
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> You don't explicitly say here: it's vital for this scheme to work that
> computing a valid transcript, or even one likely to be valid, must be
> as expensive as performing the real task. For example, if the task is
> spotting aliens, then a transcript which is just the input dataset
> and the output "No aliens found!" would not be sufficient for this
> protocol to work.
You're right. Good point.
If this were a DES keysearch, the transcript could be the key
(in the assigned chunk of keyspace) which came closest to providing
a correct decryption (in some canonical ordering).
It's not clear, though, whether the SETI problem makes it easy to
find a transcript with the property you mentioned.
Thanks for pointing this out. I overlooked it, and you're right,
it is extremely important.
> I've thought about this one a little, and it seems like it might be
> difficult to meet both this condition and the obvious requirement that
> the extra burden of generating the transcript be small compared to the
> main computational load. However, if the condition can be met, I
> don't see why the server needs to explicitly challenge the client for
> the transcript: since it's deterministic, the server can simply
> generate the transcript itself and see if it matches.
Two reasons:
1. You only want to probabilistically check a small fraction of
the transcripts, otherwise the server has to duplicate all of
the work anyway, and we might as well ignore the clients.
1. Transcripts may be lengthy, and if we're only going to check
a small fraction of them, we'd like to avoid wasting bandwidth
on transcripts we won't check. The `commitment + probabilistic
challenge' technique gives us this for free.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: secrecy/generation of IV
Date: Thu, 11 Nov 1999 06:16:06 GMT
Infact i understand that the RFC's for Mail encryption require that the
IV be sent in the clear as a part of the header information..
so in effect it really doesn't seem to matter...
-rasane_s
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Allen Landsidel) wrote:
> I've recently written a UDP based chat program that encrypts all
> traffic going through it with the users choice of several encryption
> engines..
>
> This has been my first attempt at writing any sort of crypto utility,
> and so far it's been a pleasant success.. however, I've got a two part
> question about the IV used for any/all the schemes.
>
> How important is it to keep the IV secret? I'm assuming very
> important. With that assumption in mind, is there any kind of general
> drawback to using, say, the first 64bits of the secret key as the IV,
> if the required IV is 64bits?
>
> If there are specific drawbacks to different algorithms, here's a list
> of the ones I've implemented in the program so far..
>
> (name keysize/blocksize)
>
> Blowfish 448/64
> Cast 128/64
> Cast 256/128
> Gost 256/64
> IDEA 128/64
> Mars 1248/128
> Misty1 128/64
> RC2 1024/64
> RC5 2048/64
> RC6 2048/128
> Rijndael 256/128
> Twofish 256/128
>
> Thanks for any input.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is there a secure-messaging service?
Date: Thu, 11 Nov 1999 06:35:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I would like to know if there is a web-site out there like the
> following. (If there isn't, remember who gave you the idea when you go
> public.)
We have a secure-message form that
does part of that: anyone can go
to the page and log in with SSL and
post a message. It's PGP-encrypted with
our public key, emailed to us, and then
scrubbed from the server.
It's the secure form at:
www.viacorp.com/address.html
There's more stuff on how this works,
and an even better idea at:
http://www.viacorp.com/crypto.html#messages
>
> This would be a secure messaging service that would allow me to register
> as a person that you could send mail to. You could securely send
> messages to me whether you were registered or not, although you would
> need to be registered for me to send a reply back to you.
We also worked out a setup where
we could get back to the person
securely. They'd need to supply
a pass phase in their first message
to us. Then we'd email them, saying that
a message was waiting, they'd log
in with SSL to an in-box we set up
for them -- with entry allowed only with
their pass phrase. This all worked,
but was not much used.
We even took out a provisional patent
on this broad scheme about a year ago,
but then abandoned it. It was just too
much "in the air", and there were other reasons.
But, yes, it does seem on the right track.
People can cope with secure forms, but few
can cope with encryption software and keeping
their keys secure, and all that.
I have to think that a better answer will
be for all businesses to have a secure
message form. Then at least business-to
-business communication will be fairly
secure, and no bother for anyone. Files
can also be sent this way.
Jim Heath
Viacorp
email address on the site
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
******************************
