HDTenEightyP/NetNews huggingface dataset:
From: magnus@thep.lu.se (Magnus Olsson)
Subject: Re: tabulation of primes
Organization: Theoretical Physics, Lund University, Sweden
Date: Thu, 13 Aug 1992 18:29:16 GMT

In article <1992Aug12.194603.23527@news.th-darmstadt.de> graef@rs5.hrz.th-darmstadt.de (Ulrich Graef) writes:
>In article <1992Aug12.171656.8755@tessi.com>, george@tessi.com (George Mitchell) writes:
>> graef@rs5.hrz.th-darmstadt.de (Ulrich Graef) writes:
>> 
>> >You must notice, that there exists a small community (even with
>> >mathematicians among them) which does not believe in inductive
>> >proofs. I think, they have a lot of problems with commonly
>> >accepted theorems.
>> 
>> Whoa!  Euclid's proof does not involve induction!  It is a
>> reductio ad absurdum proof, ...
>
>You are right, but I only use the wrong words (english is not
>my native language). There is also a group, which worries
>about `reductio ad absurdum' proofs.
>
>A friend of mine worry about both!!!

But Euclid's proof can easily be rewritten as a totally constructive
proof, one that fulfils even the most stringent constructivist
demands. Of course, then it's no longer a proof that there is an
infinite number of primes (I suppose constructivists wouldn't accept
such a statemnet as meaningful, anyway), but a proof that given any 
(finite) list of primes, one can always construct a prime not on the
list. 

Magnus Olsson                   | \e+      /_
Dept. of Theoretical Physics    |  \  Z   / q
University of Lund, Sweden      |   >----<           
Internet: magnus@thep.lu.se     |  /      \===== g
Bitnet: THEPMO@SELDC52          | /e-      \q
Newsgroups: sci.crypt
From: Marc.Ringuette@daisy.learning.cs.cmu.edu
Subject: Re: Secure netnews
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 19 Aug 1992 16:03:00 GMT

dla@raven.princeton.edu (Don Alvarez) writes,
> There is no way to defend against this because there is no way to prove
> who sent the message stating that machine foo has received an article.

Sorry, Don, but you're just totally 100% wrong.  Digital signatures exist!
They are practical, and they work.

You might want to have a look at any tutorial on RSA, which will tell you
how to do secure authentication (digital signatures) assuming RSA is secure.


M.
From: Dan Yurman <dyurman@igc.apc.org>
Newsgroups: sci.crypt
Date: 15 Aug 92 09:03 PDT
Subject: Re: WANTED: MS-DOS PD program based on 
Nf-ID: #R:1992Aug12.163735.19427@ms.uky.ed:517108043:cdp:1465900004:000:392
Nf-From: cdp.UUCP!dyurman    Aug 15 09:03:00 1992


Regarding public/private key systems in MS-DOS, I would
appreciate pointers to either an FAQ for this group which
explains their use or any ftp archive site / files.  Thanks!
As you might guess I am * new * to this area.

Dan Yurman            | dyurman@igc.org          | 43N
PO Box 1569           | dyurman%igc.org@stanford | 112W
Idaho Falls, ID 83403 | MCI Mail: 364-1277       | -7 GMT
From: smb@ulysses.att.com (Steven Bellovin)
Newsgroups: sci.crypt
Subject: Re: Cheap RSA chips? (Was: Re: shift registers??)
Date: 21 Aug 92 15:10:30 GMT
Distribution: sci

In article <1992Aug20.160528.2155@nessie.mcc.ac.uk>, segr@nessie.mcc.ac.uk (Simon Read) writes:
> I can't see how Rivest Shamir and Adleman can have a patent on
> performing exponentiation (patents cannot cover maths).

They patented a ``cryptographic communications system'' based on the
RSA equations.  They didn't claim either exponentiation or any particular
way of doing it.  As a consequence, if you found a new use for those
exponentiations that's neither claimed by the patent, nor a derivative
of any of its claims, you wouldn't infringe, even though you were
doing the exact same things.

> If anyone has a US patent Number for RSA can they let me know and
> I'll go and have a read. I'm too poor to pay for the search, and
> too busy to do it myself.

4,405,829.
Newsgroups: sci.crypt
From: limonce@pilot.njin.net (Tom Limoncelli)
Subject: Re: Secure netnews
Summary: Oh nothing important.  I just have this Perl script that I use to generate this stream of posts whenever someone posts the silly suggestion that netnews could be made secure.
Keywords: silly automated
Organization: New Jersey Intercampus Network
Date: Wed, 19 Aug 1992 23:15:27 GMT

In <f8@drew.drew.edu> tlimonce@drew.drew.edu (Tom Limoncelli) writes:

>                                                   [...]      Claims
> such as "if netnews isn't secure, it just doesn't have a future" will
> be made.

This kind of remark always blows my mind.  The net right now works
so well that tiny flashes of problems (like the recent cancel monger)
are worth it.  Netnews is supposed to be fun, and if it's not fun
it might as well end.

Tom
--
There is nothing wrong with talking to yourself...
at least you know you're going to win any arguments!
-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
"Oh! I thought it was one of those useless demos of everything that
    a GUI builder could do." -Anonymous person watching demo of
         Solaris 2.0's graphical tool for managing NIS+
Newsgroups: sci.crypt
From: kelly@netcom.com (Kelly Goen)
Subject: Re: The Next Pearl Harbor: We don't audit our chips
Date: Sun, 16 Aug 92 18:13:57 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: usa

 First of all yes it is indeed possible... although I doubt the utility
of the am receiver approach.... Auto-insert logic
is the name of the approach normally used to slide through
a silicon compiler. Strategy in Silicon can indeed be for real
the question is whose has done it yet and to what
degree of subtlety...??
      cheers
      kelly
Newsgroups: sci.crypt
From: ritter@cactus.org (Terry Ritter)
Subject: Re: Growth of mcrypt due to packets
Summary: Corrections and Comments
Keywords: mcrypt
Organization: Capital Area Central Texas UNIX Society, Austin, Tx
Date: Sun, 16 Aug 1992 17:19:13 GMT



 My thanks to those who remind me that each byte has eight bits.
 The values should be 95^1024 keys, controlling 2^8192 possible
 cipherings.  But I'm not sure it matters much.

 Now that I think about it, Mass Encryption is odd in that the
 User Key is so closely connected to the internal key.  Of course,
 any cipher can be insecure with a short key, but the difference
 here is that the User Key is so directly related to the ciphering
 process itself.  Whereas a short key in other ciphers may select
 in a well-distributed fashion from a small number of choices
 hidden among all the possible cipherings (and even this is weak),
 in this cipher a short key means that only a small portion of the
 cipher is really unique.  The rest of the cipher is functionally
 derived from the unique portion which is exposed to attack.

 Whereas in other ciphers a User Key selects a particular
 ciphering as a unit, in this cipher *each character* in the User
 Key *independently* selects a portion of the cipher, a known
 particular byte.  This means that individual characters of the
 User Key can be isolated and attacked separately.  This is unusual
 and very weak.

 Indeed, each User Key character may control *several* particular
 bytes, due to the key expansion formulas; such bytes could be
 anagrammed in an attempt to find a single solution for the
 associated key character, independent of the rest of the key.

 When selections are poorly distributed, the number of possible
 cipherings tells the wrong story.  For example, Simple Substitution
 on 26 letters should select from 26! (that's about 2^88) possible
 cipherings.  Nevertheless, people somehow manage to solve these
 ciphers virtually by examination.  Trial-and-error occurs, but it
 is not a *random* sort of trial-and-error; it is instead directed
 by probable words and probable adjacent characters.  For solution
 purposes, each letter of the substitution key can be worked on
 separately, most of the time.

 Evaluating the number of possible cipherings is useful only to the
 extent that other attacks have been eliminated, and brute force
 remains as the only available attack.  But that is not the case in
 Simple Substitution, and that is not the case in Mass Encryption
 either.

 ---
 Terry Ritter   ritter@cactus.org
From: bsy+@cs.cmu.edu (Bennet Yee)
Newsgroups: sci.crypt
Subject: Re: more mcrypt discussion
Keywords: mcrypt
Date: 13 Aug 92 20:31:03 GMT
Article-I.D.: cs.Bsxvns.LHv.2
Organization: Cranberry Melon, School of Cucumber Science

[ The ">>" text is from knight@gnu.ai.mit.edu ]

In article <1992Aug13.181102.11451@cactus.org> ritter@cactus.org (Terry Ritter) writes:
>>     The increase is the excess blocking.  I encrypt in exactly
>>1024 byte (1K) blocks.  . . .
>> . . . due to computer file clusters, this block doesn't
>>take up any additional space from the drive.
>
> Well, we must be clear about whether the cipher is working on actual
> disk sectors or files.  Only files have been mentioned.
>
> I think it is important to end up (after enciphering and deciphering)
> with an exact duplicate of the original file, in data and length.
> Any change from variable-length (files) to block-oriented processing
> must add something to the original data to be able to recover the
> original length.  And if the original length was 1023 mod 1024, there
> will be no free space in the last block to hold additional data.
> Thus, any block-oriented cipher which works on variable-length files
> must expand some files.  Small blocks imply a small expansion, but
> frequently; large blocks imply a larger expansion less frequently.


You should both read more about DES's modes of use.

Ciphertext-stealing is an excellent way to encipher the short block
(last block) of a file without increasing the length.

A variant of this can be used for number-theoretic based cryptosystems
such as RSA to limit the size increase (of a file) to a single bit.

Also, blocksize of a filesystem is device-dependent.  It ranges from
512 bytes to 8K on ``typical'' Unix boxes.

Now back to the regularly scheduled junk.  And back to real work.

-bsy
-- 
Bennet S. Yee		Phone: +1 412 268-7571		Email: bsy+@cs.cmu.edu
School of Computer Science, Carnegie Mellon, Pittsburgh, PA 15213-3890
From: marc@tanda.isis.org (Marc Thibault)
Reply-To: marc@tanda.isis.org
Newsgroups: sci.crypt
Subject: multi-algorithm encryption
Date: Thu, 13 Aug 92 18:33:19 
Distribution: world
Organization: Thibault & Friends


        Ok - assuming everybody gets a kick at the can -here's mine.

         A search of the literature has unearthed countless references
         to the fact that secret algorithms are out, but no reference
         to an encryption that uses many (known) algorithms, selected
         by the key.

         Assume two reasonably large sets of functions F and G, such
         that Gi reverses Fi for any i. These can be any sort of
         reversible function that operates on a small piece of data
         (eg. a byte). The encryption works as follows:

         1) Use one-way hashes of an arbitrarily long key to produce
         two cryptographically strong keys M and N (A variant of MD5
         that produces longer output?).

         2) Subject the compressed plaintext to a random stub,
         substitution and transposition based on M and/or N to
         complicate a plaintext attack. This produces string D.

         3) Generate E. For each Ei, apply the algorithm from F
         selected by key fragment Mi. Something like

                    Ei = (F(Mi))(N,D,i,E)

        4) Back out step 2. I'm not sure why, but every scheme I've
        seen does this.

        Decryption uses G instead of F and runs i backward.

        This description begs the issues relating to key and block
        lengths, since any scheme can be improved by increasing them.
        The question is, all else being equal, is this an improvement
        over more conventional approaches?

            ,Marc


--
 Marc Thibault        |                              |  Any Warming,
 marc@tanda.isis.org  |  Oxford Mills, Ontario       |  Global or otherwise,
 CIS:71441,2226       |     Canada                   |   appreciated.

Newsgroups: sci.crypt
From: mkwan@cs.mu.OZ.AU (Matthew Kwan)
Subject: Re: Does Lucifer have weaknesses?
Organization: Computer Science, University of Melbourne, Australia
Date: Thu, 13 Aug 1992 01:22:18 GMT

ahaley@eoe.co.uk (Andrew Haley) writes:

>: Does the Lucifer algorithm have any weaknesses?

>Yes.  Lucifer with eight rounds and 128-bit blocks is breakable within
>2**21 steps using 24 chosen ciphertext pairs.  DES is a great
>improvement over this.

>Biham & Shamir, _Differential cryptanalysis of Snefru, Khafre,
>REDOC-II, LOKI and Lucifer_, Proceedings of CRYPTO '91.

Yes, but remember that DES is a 16-round cipher. An 8-round version
of Lucifer has been broken, but the last time I spoke to Eli Biham
he hadn't succeeded in breaking the 16-round (standard) version.

However, Lucifer has quite a few weak keys, and a few easily found
(key, plaintext, ciphertext) triplets where plaintext = ciphertext.
Not a fatal weakness, but it can be a problem when hashing.

mkwan
Newsgroups: sci.crypt
From: tal@Warren.MENTORG.COM (Tom Limoncelli)
Subject: Re: Secure netnews
Summary: Oh nothing important.  I just have this Perl script that I use to generate this stream of posts whenever someone posts the silly suggestion that netnews could be made secure.
Keywords: silly automated
Organization: Mentor Graphics - IC Group
Date: Wed, 19 Aug 1992 23:16:05 GMT

In <f12@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes:

> Brad Templeton is always looking to take a dare and...

...and the whole things starts over.

This is a problem with Usenet.  It has no "memory" so every post risks
repeating an old question, which starts a virtual repeat of the last
time such topic came up.  FAQ postings help, but I think there is
another solution.

My solution would be to have all of Usenet stored on a CD-ROM so that
people could refer back to these threads and not repeat them.  For
example, if someone complains about something that's been discussed
before, we wouldn't have to repeat the entire discussion (as we often
do).  Instead, someone would post:

"Oh, refer to message xxxx for the last time we argued that.  Chances
are you'll find the answer to what you were going to ask has already
been posted.  Please only post your question if you feel that you are
bringing a new element/factor/discovery/revealation to the issue."

I think this would be really useful.  I can think of a number of past
discussions that I'd like to re-read from time to time.  For example, I
still don't think anyone should be selling a CD-ROM full of old Usenet
postings.  Did anyone save that thread?  I'd really like to re-read
it and start that discussion ALL OVER AGAIN!  :-) :-) :-)

Tom
--
There is nothing wrong with talking to yourself...
I do it, and so do I!
-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
"Oh! I thought it was one of those useless demos of everything that
    a GUI builder could do." -Anonymous person watching demo of
         Solaris 2.0's graphical tool for managing NIS+
From: keith.willis@almac.co.uk
Newsgroups: sci.crypt
Subject: shift registers??
Date: 19 Aug 92 18:32:05 GMT
Distribution: sci
Organization: ALMAC PC Board



SR>   As an illustration the fastest modular-exponentiator chips (which are quite
SR>   expensive at about $1000 a throw) can achieve about 64kbps, rising to 128kbps
SR>   soon. (modular-exponentiation is the fundamental step in RSA,

        You mean that one could implement RSA in hardware for a
        reasonably low price?  And would such a device still infringe
        the patents (in the US), or do they only cover software
        implementations?


---
 ~ PQ 2.15 194 ~ Logic outputs like to get high.
--
ALMAC BBS Ltd. 0324-665371
Dos based USENET access,  call for details!
Newsgroups: sci.crypt
From: hgpeach@ms.uky.edu (Harold Peach)
Subject: WANTED: MS-DOS PD program based on RSA Public Key 
Date: Wed, 12 Aug 1992 20:37:35 GMT
Organization: University Of Kentucky, Dept. of Math Sciences

I am looking for an MS-DOS based, public domain program that with
do public key encryption based on the RSA standard.  Does anyone
know the name of such a program and/or an ftp site where it could
be obtained?  A companion program to generate the keys would be
nice too!

Please reply direct as I do not normally subscribe to this group.

Harold
hgpeach@ms.uky.edu
-- 
Harold G. Peach, Jr.       ><>       N4FLZ       _%       hgpeach@s.ms.uky.edu
Newsgroups: sci.crypt
From: tal@Warren.MENTORG.COM (Tom Limoncelli)
Subject: Re: Secure netnews
Summary: Oh nothing important.  I just have this Perl script that I use to generate this stream of posts whenever someone posts the silly suggestion that netnews could be made secure.
Keywords: silly automated
Organization: Mentor Graphics - IC Group
Date: Wed, 19 Aug 1992 23:14:38 GMT

In <f3@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes:

> This is always followed by someone who really believes that they've
> figured out a way to do it.

Yeah, but then Henry or Geoff will beg them to explain their solution.
Tons of flamage will go back and forth because the explaination
won't be very well written.

Finally people will really understand the proposal.

Tom
--
There is nothing wrong with talking to yourself...
I do it, and so do I!
-- 
Tom Limoncelli -- tal@warren.mentorg.com (work) -- tal@plts.uucp (play)
"Oh! I thought it was one of those useless demos of everything that
    a GUI builder could do." -Anonymous person watching demo of
         Solaris 2.0's graphical tool for managing NIS+
From: alain@elevia.uniforum.qc.ca (W.A.Simon)
Newsgroups: sci.crypt
Subject: Re: Cryptographic voting
Date: 18 Aug 92 22:43:30 GMT
	<10370@ember.UUCP>

In <10370@ember.UUCP> pacolley@ember.UUCP (Paul Colley) says:

> In article <9208172116.AA20035@news.cis.ohio-state.edu>
> Marc.Ringuette@daisy.learning.cs.cmu.edu writes:

> >Thanks for the pointer, Ken.  His scheme looks good.  Here's a sketch:
> >  The election takes place between voters and k candidates, at least
> >  one of whom is assumed honest.  Each voter communicates with all of
> >  the candidates in order to register and vote.  [...]

> Ah, if only we could find an honest politician!

	Whyever for?  Party pooper!
	Graft, loot, spoils, are what politics is all about.
	Politics is the art of managing conflicts of interest.

	Any system that posits honest politicians is bound to fail.

	We should build all system (legal, electoral or otherwise)
	with the premises that human beings are not equally honest
	and that politics will appeal to those who are the least
	honest.  Dishonesty is not a requirement, but it is a big
	motivation for entering politics, as well as a large part
	of the art of surviving in it.

	A public key system has the benefit of not relying on
	honesty on anyone's part.



--
 The Vacuum Cleaner Man (reality sucks)
From: jbs@WATSON.IBM.COM
Newsgroups: sci.crypt
Subject: RSA-129 contest
Date: 20 Aug 92 23:35:49 GMT


          I asked:
:>         How small do the coefficients have to be?  I have been led to
:>believe that the speed of the GNFS overall does not depend much on the
:>efficiency of the search for a good polynomial.  If this is the case it
:>would seem to be unwise to devote a lot of effort to finding a good poly-
:>nomial.  What is the point of this contest?
          Robert D. Silverman replied:
>This is NOT the case. The performance is VERY sensitive to the size
>of the coefficients and it is worthwhile spending a significant amount
>of time trying to find small coefficients.
          and also:
>I estimate that to be competitive with the Quadratic sieve they need
>to find coefficients of 'about' 14 digits.  I am not sure it is
>possible.
          Well, let us estimate how many numbers between 10**128 and
10**129 can be so represented.  m will be about 10**23 (so that c5*
m**5 is 10**129).  There are about 10**23 choices for m, 10**14 for
each of the ci.  This gives 10**23*(10**14)**6 or 10**107 representa-
tions.  Hence the chance that a random number between 10**128 and
10**129 has such a representation is below 10**-20.  It would appear
to me that running ECM would be a better bet than this.
                          James B. Shearer
Newsgroups: sci.crypt
From: fischer@ginkgo.theory.cs.yale.edu (Michael Fischer)
Subject: Re: Cryptographic voting
Cc:  fischer-michael
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
X-Newsreader: Tin 1.1az (for az) PL5
Date: Tue, 18 Aug 1992 18:30:55 GMT

Marc.Ringuette@daisy.learning.cs.cmu.edu wrote:
: A recent newswire article about suggestions to allow telephone voting
: got me thinking about the possibility of running a cryptographically
: secure presidential election via email.  I claim that the problem is
: very similar to the problem of untraceable electronic cash, and that
: with a little work, we could concoct a secure protocol for running
: national elections by email, using known technology.
: 
: I made this claim on a local newsgroup, and a colleague, Doug Tygar, 
: disagreed strongly.  I thought I'd run this by you and see if I can
: get a reaction.  Do you think that secure elections are within the
: grasp of modern cryptography?  If so, how would you do it?  If not, 
: what do you see as the major obstacles?

A former student of mine, Josh Cohen Benaloh, did a Ph.D. dissertation
on this problem at Yale back in 1987.  The title is "Verifiable
Secret-Ballot Elections".  A preliminary version of this work appeared
in J. D.  Cohen and M. J.  Fischer, ``A Robust and Verifiable
Cryptographically Secure Election Scheme,'' {\it Proc. 26th IEEE
Symposium on Foundations of Computer Science} (October 1985), 372-382.

The problem is much trickier than might appear at first sight.  In
addition to privacy, two important requirements in a practical voting
scheme are verifiability and robustness.  Verifiability means that all
voters can verify that the votes were counted correctly.  Robustness
means that no small group of participants can invalidate the election,
disenfranchise valid voters, or otherwise have greater influence over
the outcome than their alloted votes would allow.  

While the proposed scheme does allow every voter to verify that his or
her vote is among those posted by the government, it appears to be
subject to various abuses by the government.  For example, the
government can fabricate votes and count them in the final tally.  No
individual or small group of voters can detect that they are
fabricated since they could be legitimate votes of all other voters.
For another, the government might change the value of legitimate
votes, or fail to return a signed vote to the voter.  While the voter
could detect such abuses, there would be no way to prove it to others,
at least without compromising the privacy of the vote.

==================================================
| Michael Fischer <fischer-michael@cs.yale.edu>  |
==================================================

Newsgroups: sci.crypt