HDTenEightyP/NetNews huggingface dataset:
From: rja14@cl.cam.ac.uk (Ross Anderson)
Newsgroups: sci.crypt
Subject: Re: well braid
Date: 18 Aug 92 10:54:37 GMT
Reply-To: rja14@cl.cam.ac.uk (Ross Anderson)
Organization: U of Cambridge Computer Lab, UK


In <13989@elevia.uniforum.qc.ca>, alain@elevia.uniforum.qc.ca (W.A.Simon)
writes:

> The proposed system works by multiplexing (braiding) two or more bit
> streams.  Depending on the value of key bits, the next bit of output
> is taken from one or the other input.

Something similar has been around in the world of stream ciphers since
about 1980. It was demolished in

`Solving a class of stream ciphers', Cryptologia vol XIV no 3 (July 1990)
pp 285 - 288. 

As far as I can see, your system will have to be modified to withstand 
this kind of attack.

Hope this helps

Ross
From: bs@gauss.mitre.org (Robert D. Silverman)
Newsgroups: sci.crypt
Subject: Re: RSA-129 contest
Date: 20 Aug 92 13:49:49 GMT
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA

In article <9208200145.AA29470@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
>
>         D. J. Berstein wrote:
>:To factor RSA-129 with the general number field sieve (GNFS) requires a
>:fifth-degree polynomial
>:
>:  f(x) = c_5 x^5 + c_4 x^4 + c_3 x^3 + c_2 x^2 + c_1 x + c_0,
>:
>:with integer coefficients c_i, and a positive integer m such that f(m)
>:is a small positive integer multiple of RSA-129. Given any random choice
>:of m you can easily expand RSA-129 in base m and find the coefficients
>:c_i. However, for GNFS to finish in a reasonable time, the coefficients
>:must be significantly smaller than random.
>
>         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?
>                           James B. Shearer
 
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.

For a 5th degree polynomial, 'random' coefficients will be about 21 or 22
digits. One needs to factor two sides of a congruence, one in Z, the other
in Q(alpha). The norms on the integer side will be about 10^32.
[M ~ 10^(130/5) and the average b will be about 10^6]. On the algebraic
side they will be about (10^6)^5 * poly coef or about 10^52.
Of course many will be smaller, [for small b]

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.

Their estimates may, of course, differ depending on their assumptions.

I have already done about 1% of the work to factor the RSA-129 with
the two-large-prime variation of the Quadratic Sieve.  I was going
to do it completely, but a deal with Sun to use their internal net
[3000 workstations!] fell through due to management difficulties.
I estimate it was going to take between 5000 and 6000 MIPS-YEARS
to do the computation.


Now if I could just scrape together 3000 Sparcs for 2-3 months, I
could finish the factorization.

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
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 20:19:00 GMT

dla@iso (Don Alvarez) writes,
> The problem has NOTHING to do with encryption.  No matter how you
> encrypt/sign/etc your message, we are still faced with the fact that
> you and I have never met and know nothing about each other.

Ahhhhhh.  I wish you'd said that in the first place.   :-(

You're right, there's a fundamental problem of how to establish the
necessary trust that at least SOME FRACTION of the other people
participating in the network are honest.  The amount of trust that you
place in the secure newsgroup should be exactly proportional to your
trust in the majority of its participants.

For most electronic stuff on the internet, a reasonable solution is
"trust by reputation."  If a large number of respectable "net citizens"
are members, then you're in good shape.

Another method is to make sure that each participant corresponds to a
real person or organization, by making sure that a few of the current
members physically meet, or at least talk on the telephone, with every
prospective new member.  There should also be limits on how quickly the
membership may change.  This prevents "flooding" the membership with
bogus entries, and makes cheating coalitions harder to form.

---

If you're unsatisfied with this, then please consider my proposal to be
a thought-experiment, which begins with the premise,

  "Assume you have the public keys of N people, and are willing to
   trust that no more than 10% of them will form a cheating coalition.
   Implement a secure newsgroup."

I think this is an interesting premise, and I would hope that most 
of our ensuing discussion will be willing to take it for granted.
Discussion about the premise is also OK with me, though.


M.

Xref: sparky sci.crypt:2936 comp.security.misc:1052
From: knight@hal.gnu.ai.mit.edu (Knight of Tossing and Turning)
Newsgroups: sci.crypt
Subject: Opps: mcrypt & DES 8 bit.
Summary: I goofed.
Keywords: DES mcrypt binary
Date: 12 Aug 92 21:16:05 GMT
Organization: Not much, but its a system.

I just confirmed that DES does indeed do 8 bit binary encryptions.
Flame off.  Chill.          

Part of the reason why I started this was due to the fact that all
the varient software I have with DES does only ASCII.

It still doesn't fix the other problems that I've been harping
on DES for:

1)  Slow
2)  It is on the verge of becoming commonly crackable.
    (okay, everyone will flame this, since everything seems to
     be more rumor than naught but since I'm sure this discussion
     has been chewed to death, lets not get into that now.)

If RSA is significantly faster than DES, I'd drop this whole project.

Please be patient with me, I'm spending lots of time and have very
little resources to delve into the subject.  Someone suggested
taking "classes" on cryptography.  Sorry, no such classes are taught
within 200 miles of where I live.  I've ordered some books on
encryption which should arrive at the regional library within a
few months.  Research machines for me include a Prime 4150, my
386 at home, and the FSF machines.  

Sorry to be a slow wheel.  I just see a problem I would like to fix
and I don't care WHAT encryption method I use as long as it fits
my requirements.  I'd rather see something done right the first time,
and mostly I'd just like it see it done.

--  Eric Knight, "Programmer at Large"
Newsgroups: sci.crypt
From: Marc.Ringuette@daisy.learning.cs.cmu.edu
Subject: Re: Cryptographic voting
Organization: The Ohio State University Department of Computer and Information Science
Date: Mon, 17 Aug 1992 20:50:00 GMT

ken@ipa.com (Ken Pizzini) writes (in personal mail),
> Sorry I don't have time right now to do the comparison myself, but
> check out "A Cryptographic Scheme for Computereized General Elections"
> by Kenneth Iverson in the Crypto '91 Proceedings (page 405).

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.  The voter obtains
  an "eligibility token", prior to election day, signed by all the
  candidates.  On election day, the voter submits a vote to each
  candidate using a zero-knowledge protocol so that they can verify
  the validity of the vote but not its contents.  To tally results,
  the candidates must sign and publish their sub-tallies, and (I think)
  only then can the results be computed.  Correctness and privacy is
  assured as long as one of the candidates is honest.

This method of cryptographically masking the votes until an aggregate
is computed seems like a good idea, and probably is superior to my
anonymity-based method.  I don't quite understand how it works, though.

One concern I have with Iverson's method is that the protocol stalls
whenever any of the candidates is unresponsive.  Of course, "candidate"
may be a misnomer -- perhaps the parties involved should be mutually
independent watchdog agencies.


M.

Newsgroups: sci.crypt,alt.society.civil-liberty,talk.politics.misc,comp.org.eff.talk,alt.privacy,comp.security.misc,misc.legal
From: clewis@bwdlh118.bnr.ca (Chris Lewis)
Subject: Re: Using cryptography
Organization: Bell Northern Research
Date: Wed, 12 Aug 1992 18:14:33 GMT

In article <1992Aug11.190541.14019@nntp.hut.fi> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
>I remember reading also that in Canada you must turn the keys over to
>Her Majesty's Post Office if you use encryption.  I hope someone will
>correct me if I'm wrong.

I've done a little checking, and I don't believe that such is required.
Your use of "Her Majesty's Post Office" is rather suggestive, that if
registration was ever required, it was a long time ago:

    - It hasn't been called HMPO for a *long* time.  50s or earlier I'd imagine.
      It's called Canada Post Corporation now.  Unless you're referring
      to the *real* HMPO, but that's been out of the loop for an even
      longer time.
    - The post office wouldn't make much sense.  Intelligence services maybe.
      The RCMP used to be responsible for such things as mail monitoring.  But
      the RCMP has been out of that game for quite some time.  CSIS (Canadian
      Security and Intelligence Service) took over intelligence services.
    - fishing expedition letter opening is probably not legal any longer, ever since
      the RCMP's "writs of assistance" were abolished.  (a "WOA" was basically
      a portable search warrant that didn't need a judge - subject to many
      restrictions, but they don't exist any longer.)  I think CSIS was
      split off after (or at the same time) WOAs were abolished.
    - In such a case now, the RCMP, CSIS or whomever would have to get
      a search warrant, which could be used to require the sender or recipient
      to supply the key.

At one time the RCMP were quite paranoid about "coded" communications.
One bizarre case was when the RCMP spent quite a bit of resources
investigating two kids who were sending paper mail to each other addressed
only by a social insurance number, street number and postal code for some fun.
I don't think that they care much now, unless there's cause.

I could just imagine what the banks would think of having to supply their
ATM keys to the post office ;-)
Newsgroups: sci.crypt
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: The Next Pearl Harbor: We don't audit our chips
Organization: Metaflow Technologies Inc.
Distribution: usa
Date: Tue, 18 Aug 1992 00:28:33 GMT

In article <MJOHNSON.92Aug15145547@netcom.Netcom.COM>, mjohnson@netcom.Netcom.COM (Mark Johnson) writes:
|> In article <64066@cup.portal.com> Christopher_C_Lapp@cup.portal.com writes:
|> 
|>   >  I was at a cocktail party with a number of computer types who work
|>   >  clandestinely for foreign governments.  We got on the topic of silicon
|>   >  compilers, and how one of these computer types invented a virus that would
                   . . .
|>   >  Any comments?
|>   >  Chris
|> 
|> I am one of those people.  But Chris got it wrong on several counts:
|> 
		. . .
|> 
|>   -- M. Johnson

<flame on>
Where the heck do you people find the time to waste on this kind of drivel?
<flame off>
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
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:15:36 GMT

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

> 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.

And, since all Usenet flame wars ultimately evolve to a prediction of
The End Of The Net or a comparison to Hitler, we can concluded that
this flame has reached its ultimate status.  And therefore, it has
reached its natural conclusion.
 
I'd like to thank all the people that contributed to this discussion,
and I'd like to thank all the people that will send me email telling me
that they're new to the net and would like me to explain why their plan
for an authenticated Usenet could be subverted.  I'd also like to thank
Vice President Dan Quayle for the inspiration to include typos and
mis-spelled words here and there throughout the articles that I
posted.
 
Have a Usenet day.

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+
Newsgroups: sci.crypt,comp.org.eff.talk,alt.security
From: tlimonce@drew.drew.edu (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: Drew University - Alumni
Date: Wed, 19 Aug 1992 23:14:19 GMT

In <f1@Warren.MENTORG.COM> tal@Warren.MENTORG.COM (Tom Limoncelli) writes:

> I really hate when people post saying that netnews needs to be
> re-written.

Such posts are always followed by someone talking about how it
can't be done without breaking all old systems.

Tom
--
There is nothing wrong with talking to yourself...
I met an interesting person that way!
-- 
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: knight@hal.gnu.ai.mit.edu (Knight of Tossing and Turning)
Newsgroups: sci.crypt
Subject: Growth of mcrypt due to packets
Summary: Some more clarifications
Keywords: mcrypt
Date: 15 Aug 92 16:29:47 GMT
Article-I.D.: mintaka.1992Aug15.162947.688
Organization: MIT Laboratory for Computer Science


Okay, there has been some debate about "how" my encryption causes the
file to grow.  I'm sorry this took so long for me to post, I've been
spending more of my time writing this program and showing relatives
around my home town of Pueblo (send for your free government catalog)
since they are up from Texas.

To show how this works, lets take a file 1025 bytes long.

Since the encryption deals with 1024 byte chunks, the first "block"
of 1024 bytes is encrypted so that it only needs 1024 bytes to store
all the information..  Basically, same size or one-to-one.

The next block consists of only a single character.  Of course, this
is really bad since this character (or small string of characters
if it is more) could (and probably will) give away methods to solve 
the entire system if mcrypt kept this data the same size prior to
encryption as it would be after the encryption.

To solve for this problem, I opted to just fill the rest of the
data (unused) with garbage, and use the file length to tell the
decryption routine to stop.  Nothing fancy there -- it can be 
drawn straight out of a random number generator.  All the garbage
will be intermixed with plaintext and thereby keeps it protected.

The filelength itself will be placed in a final packet at the end
of the grid (haven't gotten around to placing this yet, I've only
used an integer for testing.)  I figured this number would be
best to encrypt as well because knowing the true file length could
also be considered a 'weakness' of the system.

I'm not worried about the 1-2K of extra data, at least the value 
of growth is a reasonable X+2, and not X1.5 or X^2 or something
that will explode in the long run.  It isn't even a matter of
principle. 

On the "help from others" note:

I've been running benchmarks on mcrypt today, and it runs at 
about 10K/sec on my 386-33 running Linux.  I'll compile it
for single user mode soon.  If anyone has some benches for DES
I'd be interested in knowing how fast it is on your CPU.

Finally, I've grabbed several books on cryptanalysis and hopefully
I'll be able to discuss my idea a little closer to "normal".
Thank you people who have suggested books to read.

Source code will soon be available for people to kick around.

--- Eric Knight
Newsgroups: sci.crypt
From: gordon@sneaky.lonestar.org (Gordon Burditt)
Subject: Re: Cryptographic voting
Organization: Gordon Burditt
Date: Wed, 19 Aug 1992 05:33:33 GMT

>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

One voter or one candidate?  I don't know of any election for an actual
government elected office (student council doesn't count) in which I 
would trust any of the candidates with tallying the election results.

>  the candidates in order to register and vote.  The voter obtains
>  an "eligibility token", prior to election day, signed by all the

In other words, the candidates get to decide who votes (in this case it
appears that one blackball by one candidate denies a voter the right to
vote), by refusing to communicate with them.  The White Supremacy Party
would find it easy to not communicate with certain neighborhoods.

>  candidates.  On election day, the voter submits a vote to each
>  candidate using a zero-knowledge protocol so that they can verify
>  the validity of the vote but not its contents.  To tally results,
>  the candidates must sign and publish their sub-tallies, and (I think)
>  only then can the results be computed.  Correctness and privacy is
>  assured as long as one of the candidates is honest.

This also doesn't seem to address problems with voters double-registering,
voters pretending to be other people who don't usually vote in addition to
themselves, voters using the token of other voters who died between 
registration and the election, and external denial-of-service attacks on 
the voting system.

>One concern I have with Iverson's method is that the protocol stalls
>whenever any of the candidates is unresponsive.  Of course, "candidate"
>may be a misnomer -- perhaps the parties involved should be mutually
>independent watchdog agencies.

Better.

					Gordon L. Burditt
					sneaky.lonestar.org!gordon
From: ccastdg@prism.gatech.EDU (Davide Gaetano)
Newsgroups: sci.crypt
Subject: Where can I find RSAREF
Date: 17 Aug 92 21:29:40 GMT
Distribution: na
Organization: Georgia Institute of Technology


  I had heads a lot of talk about RSAREF a while back, but never did 
  find out where I could get a copy, can someone send me information on 
  this, and or an ftp sight for it ?

Thanks
Davide Gaetano
ccastdg@hydra.gatech.edu
Newsgroups: sci.crypt
From: pmetzger@snark.shearson.com (Perry E. Metzger)
Subject: Amateur cryptosystem design
Keywords: DES mcrypt binary
Organization: Lehman Brothers
Date: Thu, 13 Aug 1992 15:21:33 GMT

knight@hal.gnu.ai.mit.edu (Knight of Tossing and Turning) writes:
>I just confirmed that DES does indeed do 8 bit binary encryptions.
>Flame off.  Chill.          

Gee, for a person contemplating creating a new cryptosystem, wouldn't
it have been nice to know in advance what other cryptosystems do?

>Please be patient with me, I'm spending lots of time and have very
>little resources to delve into the subject.  Someone suggested
>taking "classes" on cryptography.  Sorry, no such classes are taught
>within 200 miles of where I live.  I've ordered some books on
>encryption which should arrive at the regional library within a
>few months.  Research machines for me include a Prime 4150, my
>386 at home, and the FSF machines.  

"Please be patient with me. I'm really enthusiastic about doing brain
surgery, and its highly unfair of all of you to discriminate against
me because I've never read a book on biology, and this stuff about
going to med school, well, I just can't afford it. You are all such
jerks for being nasty to me about all this; I think I can do brain
surgery as well as the next guy. Hell, I bought a scalpel last week,
see!"

--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.
Newsgroups: sci.crypt
From: hal@gateway.mitre.org (Hal Feinstein)
Subject: shift registers??
Organization: Mitre Corporation, McLean, VA
Date: Fri, 14 Aug 1992 13:59:34 GMT

If you havn't seen it, there is an excellent article on what the
Canadian codebreakers are up written up in Cryptologia. Shows some
of their organization, their Cray XMP and other things. What I found
startling was the time they spend training their people on advanced shift 
register theory!  Are these devices still that popular? I would have expected 
them to have been replaced with computer type algorithms certainly within 
the last decade?  Indeed why is their so much interest in them and not in 
things like PKS?
Newsgroups: sci.crypt
From: george@tessi.com (George Mitchell)
Subject: Re: tabulation of primes
Organization: Test Systems Strategies, Inc., Beaverton, Oregon
Date: Wed, 12 Aug 1992 21:48:39 GMT

graef@rs5.hrz.th-darmstadt.de (Ulrich Graef) writes:
>[ . . . ] There is also a group, which worries
>about `reductio ad absurdum' proofs.

I would recommend that anyone worried about the rigor of reductio
ad absurdum enter a field of study other than mathematics.
-- George Mitchell (george@tessi.com)