HDTenEightyP/NetNews huggingface dataset:
From: brnstnd@nyu.edu (D. J. Bernstein)
Newsgroups: sci.crypt
Subject: Re: RSA-129 contest
Date: 30 Aug 92 04:30:12 GMT
Organization: IR

In article <1992Aug27.111639.16325@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:
> :Why are you trying to discourage people from
> :entering the RSA-129 contest, Bob?
> Now this last accusation really is obnoxious, because it puts words
> in my mouth that I have never said.

Bob, you stated that a 6-7 digit improvement in GNFS polynomials in this
range would result in only a 2x speedup. If this were true, it would put
a rather small cap on the possible benefits of the RSA-129 contest.

It is not, in fact, true. It is wildly inaccurate: as I pointed out
before, such an improvement could easily gain an order of magnitude in
speed. (For instance, p(9) is more than ten times p(10), p being the rho
function; here N(a,b) is compared to (max AFB)^9.) You had your chance
to retract the statement, Bob, and you failed.

Someone who believed your misstatement about speedups would obviously be
discouraged from entering the RSA-129 contest. Bob, what's your
motivation? Why are you trying to squash interest in GNFS? You're
achieving the effect of lying to the public, even if you don't mean to
do so. I don't care whether it's obnoxious of me to point this out---I
can't sit by and watch you corrupt the views of people who haven't
learned about GNFS and can only go by what they hear from others.

> All you are doing is gainsaying my data without posting data of your own.

That's right. The bulk of data which I have is part of an article I'm
writing with Arjen Lenstra on our GNFS implementation. That data, like
your data, is not sufficient to conclude that GNFS will probably be
slower than MPQS at 129 digits. Yet you keep stating this conclusion.

> you are confusing the two functions.

My apologies. I mistakenly thought that you were talking about Dickman's
rho function, which (I can say with some assurance now that I've checked
my references) a few people attribute to Knuth and Trabb Pardo (because
Knuth and Trabb Pardo did publish some things about it).

I guess you are referring to the logarithmic sum that Schroeppel
originally suggested for choosing multiples for the continued fraction
method. If so, I am astounded at your statement that it would be nice to
have such a function for the algebraic side of GNFS---everyone knows
what it is, namely the sum of log p times the (easily computable)
probability that a coprime pair a,b has N(a,b) divisible by p^d, over
all p and d.

---Dan
Xref: sparky sci.crypt:3106 comp.security.misc:1156
From: trt@duke.cs.duke.edu (Tom Truscott)
Newsgroups: sci.crypt,comp.security.misc
Subject: Re: "Sneakers" -- action/adventure movie about Cryptography
Date: 4 Sep 92 20:11:40 GMT
Followup-To: sci.crypt
Organization: IBM RTP

>>Anyways, one-time pads are really effective in short
>>messages and are reasonably secure on larger documents.

Arguably this is backwards. As suggested in "Codebreakers",
if I suspect that a "yes" or "no" decision is forthcoming, and I 
intercept a 3 character long message, I can make a reasonable
guess as to the message's contents.

More generally, "traffic analysis" is still a threat.  So some systems
send continuously, just sending nulls or-ed with the pad
(== the pad itself) when there is no real traffic.
From: brnstnd@nyu.edu (D. J. Bernstein)
Newsgroups: sci.crypt
Subject: Re: RSA-129 contest
Date: 26 Aug 92 23:38:52 GMT
Organization: IR

In article <9208260234.AA05450@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
>          Well if you actually had a complete GFNS implementation for
> general numbers I believe you would obtain more reliable estimates by
> performing a whole bunch of "wimpy" factorizations as opposed to a
> single factorization of RSA-129.

Unfortunately not. Example: Arjen Lenstra and I tried our MasPar GNFS
implementation on a 66-digit general number. We used the smallest
sensible factor bases for that architecture---namely 16384 primes on
each side of the sieve---and without any tuning found that we had more
than enough relations *from ff's alone*. No partials were necessary.

When you want to make predictions, the statistics from such a tiny
factorization are worse than useless. One can safely predict how long
GNFS will need to factor a 130-digit number---within an order of
magnitude.

>          You might also have a reliable figure of merit for what con-
> stitutes a good polynomial representation.

This is, unfortunately, an open research problem. The best procedure I
know is to generate many polynomials with relatively small coefficients,
then look for polynomials with ``many'' small algebraic primes in a
certain sense. This is exactly what the RSA-129 contest is meant to
achieve.

(For those who missed the start of the discussion: If your mail address
is joe@foo.bar and you want to see the contest announcement, send mail
to factor@src.dec.com with the two lines

path#joe@foo.bar
rsastatus#

and wait a few minutes.)

---Dan
From: joe@astro.as.utexas.edu (Joe Wang)
Newsgroups: sci.crypt
Subject: Re: authentication
Date: 30 Aug 92 23:00:05 GMT
Distribution: sci
Organization: McDonald Observatory, University of Texas @ Austin

In article <1992Aug28.864.24@ALMAC> keith.willis@almac.co.uk writes:
>        As I said before, I have no way of knowing, for example, that
>        the public key that you see attached to the foot of this
>        letter is the one I put there.  

You could call up random sites receiving sci.crypt and ask them what
public key they received was and then compare that to the one you
sent.
From: keller@cse.ucsc.edu (Jeffrey M. Keller)
Newsgroups: sci.crypt
Subject: guaranteed posting (was Re: Secure network: what form?)
Date: 27 Aug 1992 22:50:01 GMT
Organization: University of California, Santa Cruz (CE/CIS Boards)
NNTP-Posting-Host: oak.ucsc.edu
Summary: A more modest approach to secure net-news.

I think demonstrating the delivery of postings is overkill, as well as
being difficult.  Given a moderator for a newsgroup, one could implement
a simpler scheme as follows:

Let	M(n) be the n-th posting to the group
	D(n) be a digest (e.g. by MD5) of M(n)

When the moderator accepts a posting M(n+1), he appends D(n) to it, signs
the result, and returns a copy to the poster.

The poster is now in a position to prove that he submitted the successor
to M(n).  In addition, any reader who receives M(n+2) without receiving
M(n+1) will detect the omission.  (What he does about this is up to him,
but at least he knows about the problem.)

If the moderator signs two different postings as successors to M(n), and
either author gets ahold of a signed copy of the other posting, then he
is in a position to discredit the moderator.  If there is any means (even
non-deterministic) of making public signed postings (e.g. posting them to
other newsgroups, uploading them to random BBS's, printing them in the
Personals columns of newspapers, etc.), then such inconsistencies are
subject to detection.

Furthermore, if the moderator does fork the newsgroup in such a fashion,
the appended digests prevent seamless merging of the resulting groups.

It remains the case that the moderator can refuse or alter a submission
to the group, but this is traditionally one of his prerogatives.  (Note
that having the moderator sign D(n) without seeing M(n) is unnacceptable.)
If he alters or fails to sign it, the poster will of course know.  If he
signs and suppresses it, he compromises himself as soon as he signs the
next posting.  Of course, he can refuse all postings thereafter, but this
is again his prerogative.

Finally, a moderator must still be chosen; but now his performance (or,
rather, his performance modified by the reliability of the newsfeed) can
be effectively monitored.  (If you miss a posting, I guess you query
archive servers and/or the moderator for it.  If they don't reply, I
guess you start complaining in other newsgroups.  If every moderator
refuses your postings, I guess you get paranoid...)

--
Jeff Keller <keller@cse.ucsc.edu>	CIS Board, UCSC
"If X is the answer, what was the question?" --David Fuller
From: hp48sx@wupost.wustl.edu (HP48SX Archive Maintainer)
Newsgroups: sci.crypt
Subject: Crypt algorithm wanted
Date: 23 Aug 1992 12:22:27 -0500
Organization: Washington University in Saint Louis, MO USA
NNTP-Posting-Host: wuarchive.wustl.edu

First of all, please mail me at hp48sx@wuarchive.wustl.edu, wupost does
not know me.

I am looking for code/algorithm for a safe encrytpion/decryption
algorithm, which is going to be implemented in a DOS program. It must be
fairly fast, and must take some time to break, even if you know the
algorithm. No hacker should be able to decrypt messages within a few
years.

Any pointers/info welcome. Please mail me as I am not reading this list,
and I need the info for a friend.
-- 
Povl H. Pedersen             hp48sx@wuarchive.wustl.edu
HP48sx archive maintainer

All Opinions (C) Copyright the Intergalactic Thought Association
From: strnlght@netcom.com (David Sternlight)
Newsgroups: sci.crypt
Subject: Re: GCHQ's location. No big secret!
Date: 2 Sep 92 01:00:29 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)


Marcus Ranum's bullshit detector is badly in need of psychoanalysis.
I believe the CIA story came from the Washington Post.

He could call up their librarian and check, if he'd like.
From: jgarland@kean.ucs.mun.ca
Subject: Re: DES source code for Aliens
Organization: Memorial University. St.John's Nfld, Canada
Date: Fri, 4 Sep 1992 11:50:42 GMT

In article <1992Sep4.093534.18590@uwm.edu>, markh@csd4.csd.uwm.edu (Mark) writes:
> In article <1992Aug29.214902.27422@cbnewsh.cb.att.com> wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes:
>>(Of course, the way the War On Politically Incorrect Drugs is going,
>>privacy-protection software may soon be declared an "Assault Weapon",
>>but that's a rant for alt.conspiracy :-)
> 
> What may or may not be done in this matter is irrelevant.  There is an
> encryption method which will generate English output from any arbitrary clear
> text.  So how would anyone ever know such and such file is an encrypted file?
> 
> Second, I could write a general purpose file utility which has no explicit
> encryption capibility in it, but which can be caused by the user to act like
 [one].
> 
> No law can draw the line.  Therefore no law can exist.

Your faith in logic is touching.  My faith in lawmakers is less so.  Witness
some of the abuses of the going on under present confiscation
laws (re War on Drugs).   Apparently 60 Minutes even set them up by having a 
black man buy a plane ticket with cash (though I do not watch).

Imagine a law which allows for  your computer system and all related materials
-- including the house in which you keep it -- to be summarily confiscated 
unless YOU -- note NOT the gov't -- can PROVE in civil court that you did NOT 
use the encryption software for illegal purposes or that the file you 
encrypted with a binary editor was NOT a buy order for drugs.

Actually, BTW I don't have to imagine this law, it's in place in the US, it
just hasn't been used in this way yet.

John Garland
jgarland@kean.ucs.mun.ca
From: fletch@framsparc.ocf.llnl.gov (John Fletcher)
Newsgroups: sci.crypt
Subject: Re: DES source code for Aliens
Keywords: DES source, non-US citizens
Date: 28 Aug 92 16:08:29 GMT
Organization: Lawrence Livermore National Laboratory

In article <1992Aug24.071236.3172@monu1.cc.monash.edu.au> amesml@monu1.cc.monash.edu.au (Mark L. Ames) writes:
>There is an excellent DES implementation available by ftp from:
>ghost.unimi.it in /pub/crypt
>nic.funet.fi   in /pub/unix/security/crypt/libdes
>ftp.psy.uq.oz.au in /pub/DES

We obtained a copy of this package and tried it.  It works fine on a Vax
(and was fast), but it improperly encrypts on a Sun3.  Examination of
the source reveals that only little endian computers are provided for;
this is strange since the documentation refers to various big endian
computers.  We also note that 64-bit computers, whether big or little
endian, would give problems.  Are we confused?  Do we have the wrong
version?  What's the story?

			John G. Fletcher
From: jbs@WATSON.IBM.COM
Newsgroups: sci.crypt
Subject: RSA-129 contest
Date: 26 Aug 92 02:00:08 GMT


         Dan Bernstein posts:
:Instead he challenges me, saying, ``Dan, why don't you say what your
:estimates are?'' The answer is obvious: *I don't know*. I don't yet have
:reliable estimates, and until somebody factors a 130-digit general
:number, *nobody* will have reliable estimates.
         and also:
:> Define 'wimpy' please for the rest of the audience.
:
:Under 100 digits.

         Well if you actually had a complete GFNS implementation for
general numbers I believe you would obtain more reliable estimates by
performing a whole bunch of "wimpy" factorizations as opposed to a
single factorization of RSA-129.
         You might also have a reliable figure of merit for what con-
stitutes a good polynomial representation.  Extensive searches for
polynomials using different criteria than the ones you will eventually
use to select a polynomial (which you are encouraging people to per-
form) are a waste of computer time (since such searches are inherant-
ly inefficient).
                    James B. Shearer
From: brnstnd@nyu.edu (D. J. Bernstein)
Newsgroups: sci.crypt
Subject: Re: RSA-129 contest
Date: 23 Aug 92 22:57:02 GMT
Organization: IR

In article <1992Aug22.113206.4385@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:
> I presented the results of quite a few benchmarks for the
> sieving phase of GNFS on general numbers ranging from 30 to 90 digits.

And you try to extrapolate by 45 digits from your highly suboptimal
polynomial choices. You didn't even take Pollard's lattice sieve into
account.

I defy you to make a statement of the form ``GNFS will use more than G
MIPS-years to factor RSA-129, while MPQS will take under M MIPS-years to
factor RSA-129, and G > M,'' rather than hiding behind loose comparisons
such as ``I estimate the crossover point to be around 135 digits.''
Either make a definite statement so that I can demonstrate by actual
experiments that you're wrong, or admit that you can't accurately
estimate the time taken by GNFS.

> Dan's labelling of detractors as 'pretending' is both insulting
> and unprofessional.

I don't think so. Your estimates of GNFS's speed have no more validity
than Adleman's ridiculous estimates a year ago. They are based on
wishful thinking (such as your incorrect estimate of coefficient digits
for a 145-digit number on sci.crypt a few weeks ago) as well as neglect
of existing algorithmic improvements (such as the special-q method).

It was irresponsible of Adleman to state that it wasn't clear whether
GNFS would be faster than MPQS for 330-digit numbers. It is just as
irresponsible of you to claim a 135-digit crossover point. It is neither
insulting nor unprofessional for me to demand that you make your
estimates of GNFS speed sufficiently detailed that I can prove them
false.

> But he still lacks data on QS. Lenstra and Manasse have
> done a few dozen numbers with QS. I've done in excess of 500.

I can't speak for either Arjen Lenstra or Mark Manasse, but it seems to
me that a few dozen numbers ranging up to 116 digits have far more
relevance to 129-digit factorizations than several hundred wimpy
numbers.

---Dan
From: atkinson@itd.nrl.navy.mil (Randall Atkinson)
Newsgroups: sci.crypt
Subject: Re: Secure network: what form?
Date: 27 Aug 92 22:08:18 GMT
Distribution: usa
Organization: Naval Research Laboratory, DC

In article <9208272105.AA12700@news.cis.ohio-state.edu> Marc.Ringuette@daisy.learning.cs.cmu.edu writes:
>I presume we all agree that we should move towards some form of secure
>email and some means of exchanging public keys.  There are a number of
>other cryptographic services we could ask for.  I presume we do NOT all
>agree on exactly what form they should take.

	Movement has been underway for some time now.
Privacy-Enhanced Mail (PEM) should appear in the Internet within the
year (famous last words :-).  Older RFCs for PEM are online.  A newer
set was just/is about to be released.

>How do you think we should take advantage of cryptography in the next
>generation network?  What tools would you use?  What organization?  Is
>there anything you want particularly to avoid?  I think it's important
>for us to develop a more accurate vision of what it is that we want.
>Otherwise, how will people know what to implement for us?

	All good questions.  The IETF has several groups actively
working on Internet Security, some under the Security Area and some
under other areas.  

Ran
atkinson@itd.nrl.navy.mil
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt
Subject: anonymity (was: Re: User authentication)
Date: 28 Aug 92 00:01:42 GMT
Distribution: sci
Organization: Stratus Computer, Software Engineering

In article <1992Aug26.211746.2838@saaf.se> pausch@saaf.se (Paul Schlyter) writes:
>And during such circumstances (we've never met and never will meet, I'm not
>interested in any positive ID like genes, fingerprints etc, and all I know
>is that you say that you've signed a messages and haven't revealed to anyone
>else how to sign it in the same way), who needs RSA signatures?

Let's suppose I'm a programmer working from home.  My employer never meets
me.  I applied for the job over the net.  I do my work over the net.  I get
paid by electronic funds transfer.  The payment goes to a bank account
identified by my RSA key.  I write checks on it by signing them with my RSA
key.

I could be a Martian.  I could be a dozen people working as a group.  The
employer doesn't know and doesn't care.  The company gets work done and
pays for it.  Those payments go to the unit(s) doing the work.

>  They would really say no more than your name and email address.

People keep getting hung up on "me" being a person with a physical body and
a name.  I suppose that's understandable, since we're all people here (or
are we? :-).

It's not that I'm an anonymity freak.  I'm just trying to keep the system
simple.  To me, things like the string "Carl Ellison" are unnecessary -- at
least for exchanges like doing work, getting paid, conversing by e-mail,
posting on USENET, ....  It's more easily remembered than an RSA key -- but
it's not guaranteed unique like an RSA key.  In fact, my father had the
same name.  So did my grandfather.
Newsgroups: sci.crypt
From: eay@psych.psy.uq.oz.au (Eric Young)
Subject: Re: DES source code for Aliens
Keywords: DES source, non-US citizens
Organization: Psychology Department, University of Queensland
Date: Mon, 31 Aug 1992 02:33:18 GMT

In article <134754@lll-winken.LLNL.GOV>, fletch@framsparc.ocf.llnl.gov (John Fletcher) writes:
|> In article <1992Aug24.071236.3172@monu1.cc.monash.edu.au> amesml@monu1.cc.monash.edu.au (Mark L. Ames) writes:
|> >There is an excellent DES implementation available by ftp from:
|> >ghost.unimi.it in /pub/crypt
|> >nic.funet.fi   in /pub/unix/security/crypt/libdes
|> >ftp.psy.uq.oz.au in /pub/DES
|> 
|> We obtained a copy of this package and tried it.  It works fine on a Vax
|> (and was fast), but it improperly encrypts on a Sun3.  Examination of
|> the source reveals that only little endian computers are provided for;
|> this is strange since the documentation refers to various big endian
|> computers.  We also note that 64-bit computers, whether big or little
|> endian, would give problems.  Are we confused?  Do we have the wrong
|> version?  What's the story?
As author of the package, I think you may have an old version.
The original package written quite some time ago was developed on vax and
MIPS processors (which were running in little-endian mode).
I currently use the package on Sparc, sun3's (68020) (big endian)
and MSDOS boxes (little endian).  I have most of the library working on
a 64bit machine (an ETA10) but most of the problems are being caused
by its C compiler defining long's and int's as 8 bytes and shorts as 4 bytes.
I have not finished the mods for this machine due to work commitments and
the fact I do not have access to the machine (debugging by email :-) but if
your C compiler defines longs as 4 bytes the code should work regardless of
endian (all the DES parts of the library appear to work on the ETA10).

The version in pub/DES ftp.psy.uq.oz.au (130.102.32.1) is the most recent
version.  If it still gives some problems, let me know the output of destest
and what compiler etc. you are using on the sun3.

eric (who only has 32bit machines to play on :-)

-- 
Eric Young | Systems programmer - Psychology Dept. Queensland Uni.
aarnet     | eay@psych.psy.uq.oz.au
Newsgroups: sci.crypt
From: ariel@world.std.com (Robert L Ullmann)
Subject: Re: DES source code for Aliens
Organization: The World in Boston
Date: Wed, 26 Aug 1992 19:10:41 GMT

ariel@world.std.com (Robert L Ullmann) writes:

> Note that it is entirely legal for US citizens (or anyone in the US)
> to IMPORT DES code; do feel free to access the FTP sites mentioned.

And an email correspondant tells me that he knows someone who was
fined for that "offense" (importing it, not necessarily by FTP).

Weird stuff. Sometimes you get the impression that the government
makes it up as they go along. Make the rules ambiguous (or, better,
all inclusive), then enforce them selectively. Means they can do
whatever they want. (For the benefit of those readers outside the US:
the law here says that police can't stop a motor vehicle without
cause. But the speed limits are set so that they _always_ have
cause. :-)

Returning you to the serious (and much more interesting) technical
discussion, 

Robert

--
Robert Ullmann		Ariel@World.STD.COM	+1 508 879 6994 x226
Quand Maigret poussa la porte du Tabac Fontaine, vers une heure et demie,
le patron du bar, qui venait de se lever, descendait lentement un escalier
en colimaon qui s'amorait dans l'arrire-salle. ... Arriv derrire le
comptoir, il repousa le garon d'un geste ngligent de la main, saisit
une bouteille de vin blanc, un verre, mlangea au vin de l'eau minrale et,
la tte renverse en arrire, se gargarisa.  -- Simenon

Newsgroups: sci.crypt
From: ken@eskimo.celestial.com (Ken Pizzini)
Subject: Re: Secure netnews
Organization: -> ESKIMO NORTH (206) For-Ever <-
Date: Sat, 29 Aug 1992 00:36:35 GMT

frank@D012S436.sniap.mchp.sni.de writes:
> You could show me your passport (for example), then I'd know who you 
> are.  Enough to associate you with the key you give me. Enough
> to know you weren't skippy...

But the Passport Issuing Authority would have to be a trusted
third party, which, in my understanding of the problem statement,
was to be avoided.

		--Ken Pizzini
From: mcs@wet.UUCP (Gil Nardo)
Newsgroups: sci.crypt
Subject: Re: Unix compatible crypt utility needed
Date: 31 Aug 92 07:20:38 GMT
Organization: Wetware Diversions, San Francisco

jmount+@CS.CMU.EDU (John Mount) writes:
[ previous posters discussing UNIX crypt deleted ]
> 
> No I don't think you understand how crypt works (or have it confused with
> the unix password encryption scheme, which is intended to be one way).  Crypt
> doesn't use DES (see below man page), it is a wimpy Enigma machine.  DES 
> IS invertible (ie. people do decrypt DES messages).
>
[ man page on crypt deleted] 

Crypt DOES use DES through makekey(). The gist of the process goes
something like this:

 1) Pass a seed and user password to makekey() and get
    back a DES'sed password.
 2) Using the new, improved password create the rotor and
    initial rotor positions for the encryption
 3) Read a plaintext char from stdin and translate through rotor
 4) Spit out cyphertext char to stdout, advance rotor, do 3 till eod.

To decrypt, the rotor "assembly" is reversed, so you are effectively
using the previous cyphertext as the plaintext in the above process.

[sensing impending doom, our author puts on a cancer causing asbestos suit]

-- 
Gil Nardo                  | mcs@wet.com
Migrant Computing Services | (415)664-1032
1032 Irving Street, #435   |-----------------
San Francisco, 94122       | Supernova = *!
Newsgroups: sci.crypt