HDTenEightyP/NetNews huggingface dataset:
From: opnsmurf@ubvmsb.cc.buffalo.edu (Da Smurf)
Newsgroups: sci.crypt
Subject: Re: On Hardware Implementations of DES...
Date: 16 Apr 92 08:58:00 GMT
Organization: ... or lack thereof.
News-Software: VAX/VMS VNEWS 1.41

In article <1992Apr16.010949.24520@tfs.com>, kudzu@tfs.com (Michael Sierchio) writes...
>In article <1992Apr15.014849.16768@cs.cornell.edu> 
>>Does anyone have any good information on the various hardware
>>implementation of DES chips that are floating around on the market?
>Western Digital makes one.  BTW, hardware is the *only* way DES is
>implemented.  At least according to the spec.
>-- 
>Michael Sierchio                               TRW Financial Systems

hmm... atleast according to unix man-pages: the des command offers a
switch to fall back to software implemented des, just incase you dont
have to hardware installed.

Jm.

-------------------------------------------------------------------------------
Jeff Murphy. SUNY at Buffalo Network Repair and Installation. OpnSmurf@UBVMS
Standard disclaimers apply...|=================================================
-----------------------------| "Die Now!"
Newsgroups: sci.crypt
From: franke@andrej.informatik.rwth-aachen.de (Christian Franke)
Subject: Re: On Hardware Implementations of DES...
Organization: RBI - RWTH Aachen
Date: 16 Apr 92 06:52:45 GMT

wayner@cs.cornell.edu (Peter Wayner) writes:

>Does anyone have any good information on the various hardware
>implementation of DES chips that are floating around on the market?
>I'm curious about the price and speed for the usual reasons. 

Here the (european !) chips I know:

1. Cryptech CRY12C102

	22.5Mbit/s according to Data Sheet, with 32 Bit interface

	We use this one, because it was the only one available
	when we started the project. No problems !

2. Pijnenburg PCC100

	20Mbit/s according to Data Sheet

	Address: PIJNENBURG B.V., Boxtelswweg 26, NL-5261 NE Vught,
	The Netherlands

3. INFOSYS DES Chip (Germany)

	S-Boxes must be loaded by software. So you can modify the
	Algorithm.

	Sorry, I don't have the data sheet handy. Please E-Mail me
	if you need further information.

Regards,

	Christian Franke
	Aachen University of Technology
	Lehrstuhl fuer Informatik I
	Ahornstrasse 55
	W-5100 Aachen
	Germany
	Tel.: 0241 / 80-21111

	E-Mail : franke@informatik.rwth-aachen.de

Newsgroups: sci.crypt
From: kocherp@leland.Stanford.EDU (Paul Carl Kocher)
Subject: Re: Try-out
Organization: DSG, Stanford University, CA 94305, USA
Date: Fri, 10 Apr 92 03:00:47 GMT

In article <1992Apr9.204018.12320@mnemosyne.cs.du.edu> bfairlan@isis.cs.du.edu (Brian Fairlane) writes:
>Interested people/companies: Send me textfiles, and I will encrypt
>                             them and send them back (uu-encoded).
>                             Of course I will use the same key for all
>                             your files, so you have One chance of making
>                             it (don't ask me how though).

You've just (re)invented security through obscurity.  The goal is to find
algorithms that are secure, even if the algorithm is publicly known, and
the "enemy" has access to other data encrypted with the same key (in both
encrypted & non-encrypted form), etc.  If knowing the algorithm makes it
possible to defeat the encryption, your system is of little practical use,
since anyone with a reverse-assembler and patience can figure out how the
encryption is done.

If you post your complete algorithm, I'm sure you'll get plenty of
feedback/suggestions.

-- Paul Kocher

________kocherp@leland.stanford.edu_________kocherp@jacobs.cs.orst.edu________
I am an undergrad at Stanford seeking summer work or contract jobs programming
(IBM PC), doing technical writing, or assisting with research. Send e-mail for
resume if interested!  - Paul Kocher/Box 13554/Stanford CA 94309, 415/497-6438
Newsgroups: sci.crypt
From: marcusj@apricot.co.uk (Marcus Jenkins)
Newsgroups: sci.crypt
Subject: MD4 and MD5 optimisations
Date: 9 Apr 92 14:30:06 GMT
Organization: Apricot Computers Limited

I have seen the MD4 and MD5 implementations from the /pub/md*/portable
directories of RSA's server.  When compiled in the (16-bit) DOS
environment, the actual digestor code comprises about 5-7k binary,
with about 200 bytes data requirement (unless I read my map file
wrong).  I'll admit that I haven't seen anything from the
/pub/md*/optimized directories yet, but I assume that these are
optimised for speed.

I am interested in implementations that have been optimised with
*size* in mind.  Has anybody done this?  Can anybody comfirm the
data space requirement?

 _ _ _
' ) ) )                         Internet: marcusj@apricot.co.uk
 / / / __.  __  _. . . _        UUCP: marcusj@apricot.uucp
/ ' (_(_/|_/ (_(__(_/_/_)_      If all else fails from US, try:  
Marcus Jenkins                  apricot!marcusj@relay.EU.net
Tel: +44 21 472 3002  Fax: +44 21 471 2935
Disclaimer:  Anything I wrote above is, of course, my own view and
             does not in any way represent my employer.
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: sci.crypt
Subject: DSA prime number length and security.
Date: 8 Apr 92 09:36:34 GMT
Organization: Academic Computer Centre Utrecht

I assume the length of the primes in DSA (p&q 512 and 160 bits) has some
influence on the riliability of the system. What I would like to know
is how much. If I double the length of the exponent (160->320) what
happens? How can I determine the time needed to break DSA in relation to
those two numbers?

Anyone who can enligten this?

Nico de Vries
-----------------------------------------------------------------------------
USENET: nevries@cc.ruu.nl                 FIDO      : 2:281/708.1  (very new) 
VOICE : +31-3404-24931 (+31-30-316931)    FAX       : +31-30-312033 
BBS   : +31-30-341401 (Nico De_vries)     COMPUSERVE: (comming)
MAIL  : Hortensialaan 45, 3702VE, Zeist, The Netherlands 

IMPORT StdDisclaimer, MyPersonalOpinion;          - O   Place reserved for
Complaints about my spelling to DEV/NUL please.    |    funny joke. Sugestions 
I work for BITECH, I don't SPEAK for BITECH.      \_/   apreciated.
From: opnsmurf@ubvmsb.cc.buffalo.edu (Da Smurf)
Newsgroups: sci.crypt
Subject: Re: On Hardware Implementations of DES...
Date: 16 Apr 92 23:14:00 GMT
Article-I.D.: acsu.1992Apr16.221440.27205
Organization: ... or lack thereof.
News-Software: VAX/VMS VNEWS 1.41

In article <1992Apr16.165945.23208@qualcomm.com>, karn@chicago.qualcomm.com (Phil Karn) writes...
>In article <1992Apr16.075856.1768@acsu.buffalo.edu> opnsmurf@ubvmsb.cc.buffalo.edu (Da Smurf) writes:
>threats in your own situation. E.g., how do you *know* that somebody
>hasn't hacked the 'des' command on your workstation to record keys?
> 
>Phil

	Having the source (and going through it) is one way to be sure...


Jm.
Newsgroups: sci.crypt
From: logo@opal.cs.tu-berlin.de (Peter Mischau)
Subject: NONCES
Keywords: authentication, nonces
Organization: Techn. University of Berlin, Germany
Date: Tue, 7 Apr 1992 18:43:34 GMT

Hello folks,

I'm a graduate student of computer science.
For about half a year, I deal with authentication and the appropriate
protocols of the authentication literature.
In this context I`ve got a question, which drives me into desparation.
Perhaps somebody can help me:

There are three ways to generate nonces:
1)
The nonce is a kind of time stamp. That guarantees that every nonce
can be generated only one time.
2)
The nonce is a sequence number, but independent of the time.
3)
The nonce is a pseudo, random number.

Is it necessary or at least useful to implement a management of generated
and used nonces ?
For which side is it useful ?
Are there Nonce-Generation-Algorithms, preventing the
generation of the same NONCE a second time ?

I appreciate every answer,
thanks in advance,

Peter.

E-Mail: logo@opal.cs.tu-berlin.de


--

ja ja, dieser Mischau   8-)
Newsgroups: sci.crypt
From: ggr@corowa.acci.com.au (Greg Rose)
Subject: Re: Simple encryption(?)
Organization: Australian Computing and Communications Institute
Date: Mon, 13 Apr 1992 06:19:29 GMT

In article <1992Apr11.170301.4743@mnemosyne.cs.du.edu> bfairlan@isis.cs.du.edu (Brian Fairlane) writes:
>                     data : This is the text I want to hide from the NSA
>            key1 (nisse)  : nissenissenissenissenissenissenissenissenisse
>            key2 (bagare) : bagarebagarebagarebagarebagarebagarebagarebagare
>   key3 (towerofeiffel's) : towerofeiffel'stowerofeiffel'stowerofeiffel's

This was discussed recently, and I think I can recount the discussion
fairly easily.  Basically, the use of the three keys in this context,
of length 5, 6, and 15, respectively, is equivalent to the use of a
single key of length of the least common multiple of these, i.e. 30.
Thus, the unicity distance will be 30. Given a sample of say 60
characters of output, you would almost certainly be able to discover
this unicity distance by shifting, xoring, and then computing
frequencies. (The redundancies are quite significant; it came as a
surprise to me that so few characters would enable one to spot the
unicity distance.)

So then you are down to a polyalphabetic cipher, that is, effectively
30 separate ciphers. (Actually 29, as the combination 'sae' occurs
twice each thirty characters, another not-very-surprising
demonstration of redundancy at work.)

The permutation at this point contributes relatively little to the
security, as permutation of groups of say 5 characters merely means
checking 120 possible permutations. This is well within the bounds of
brute force, and I imagine that digram or trigram frequencies could be
used to unravel much larger permutations once the individual
characters are back in the right "alphabet". I don't think
permutation-only ciphers have ever been used successfully, although I
an happy to be proven wrong on this.
--
Greg Rose                 Australian Computing and Communications Institute
ggr@acci.com.au                                              +61 3 282 2517
From: mrr@scss3.cl.msu.edu (Mark Riordan)
Newsgroups: sci.crypt
Subject: Public Domain RSAREF-based PEM Projects?
Date: 16 Apr 92 02:33:20 GMT
Organization: Michigan State University

How many people out there are writing RSAREF-based Privacy-Enhanced
Mail programs to be placed in the public domain?

I have been planning on writing such a beast since the RSAREF beta
test period, but I haven't had the time until now.  In the meantime,
I figure it's pretty likely that several others have started similar
projects.  I'm eying my long list of potential personal projects,
and wondering whether I'd be duplicating effort if I were to start
work on an RSAREF-based PEM program now that I've waited so long.

So, if you're working on an public domain RSAREF-based PEM program,
please speak up.  Not only would you help me plan my life for the
next few months, but you may benefit from other developers who
also speak up.  A PEM development project would surely stand to 
benefit from interchange amoungst developers.

Mark Riordan     riordanmr@clvax1.cl.msu.edu
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: sci.crypt
Subject: Random-dot stereograms
Date: 6 Apr 92 18:55:36 GMT
Organization: AIAI, University of Edinburgh, Scotland

It occurs to me that random-dot stereograms could be used for
transmitting small amounts of information securely.  The recipient
would be provided in advance with one half of the stereogram, and the
other half would be constructed when needed.  This is equivalent to a
one-time pad, with the advantages that

 (a) it can be decoded with no equipment in a few seconds
 (b) it can easily be used for transmitting diagrams as well as text.

Has this ever been done?

[A random-dot stereogram consists of two images of random dots.  The
two are identical except that some areas of dots are displaced slightly
in one of the images (and the resulting gap filled with more random dots).
If one image is viewed with each eye (which can be done by crossing your
eyes) the displaced areas are perceived as being at different distances.]

-- Richard
-- 
Richard Tobin,
AI Applications Institute,                                R.Tobin@ed.ac.uk
Edinburgh University.
From: filibert@vista (Daniel Filiberti)
Newsgroups: sci.crypt
Subject: FAQ? Where?
Date: 10 Apr 92 18:03:18 GMT
Article-I.D.: ohsu.1992Apr10.180318.21529
Reply-To: filibert@ohsu.edu
Organization: Oregon Health Sciences University


Is there a FAQ posting for this newsgroup?  Where can I get
it?

	Thanks,

		Daniel

--
************************************************************
Motto for a monitor, "It's better to burn out, than to fade
 away..."  [8?)}
************************************************************
 
Daniel Filiberti
Oregon Health Sciences University
Biomedical Information Communication Center (BICC)
3181 Sam Jackson Park Road
Portland, Oregon  97201-3098
email:  filibert@ohsu.edu
Newsgroups: sci.crypt
From: hal@backup.mitre.org (Hal Feinstein)
Subject: Re: Source for _real_ random numbers
Organization: Mitre Corporation, McLean, VA
Distribution: na
Date: Thu, 16 Apr 1992 19:15:04 GMT

In article <1992Apr16.175124.11574@osf.org> karger@osf.org (Paul A. Karger) writes:
>In article <ksvk2iINNj20@mthvax.cs.miami.edu>, wb8foz@mthvax.cs.miami.edu (David Lesher) writes:
>|> Recently I suggested that a book could substitute for a one-time pad.
>|> I've gotten several pieces of mail claiming the method I was proposing
>|> was trivial to break.  Others have said it is not.
>I don't have my copy of Kahn's, The Codebreakers, with me, but as I recall, William Friedman broke a book cipher of this sort during the 1930s.  The cipher was in use by some kind of smugglers, and Friedman only found out what book they were using when th
`
Also, Friedman broke another book cipher given to him by the British around
1917(?)  and he was able to break that too. Reading through Yardley's book
he also cracks a bunch of book ciphers some of which were dictionary.
Lastly, In Fricks, "War Secrets in the Ether" he says the German's were
able to break a combination book and grill system used by a Soviet agent
captured in France. Here, I think the Germans could only figure out the
langauge that the book was written in but had to await the agents arrest
to find the actual book itself.  All this happened fifty to a hundred years
ago! Things may have advanced since then.
From: mgflax@phoenix.Princeton.EDU (Marshall G. Flax)
Newsgroups: sci.crypt
Subject: Re: Random-dot stereograms
Date: 8 Apr 92 03:26:39 GMT
Organization: Princeton University

In article <1992Apr7.172817@sees.bangor.ac.uk> graham@sees.bangor.ac.uk (The Land of Confusion) writes:
>As the information in a random dot stereogram is stored in the disparities
>between corresponding dots in the pair of images, isn't it necessary to
>have the plain text in advance of constructing *both* images? 

Nope.  Here a simple algorithm.  Suppose the left half has already been
sent.  Then take a copy of the left image, cut out the plaintext in
bubble letters of the like, slide it over, and fill in the holes with
more random dots.  Now you have the right side image.  It's not
difficult at all.  It's just a lot of info to transmit over secure
lines!!!

marshall
-- 
+++++++++++++++++++++++++++f+++++n+++++o+++++r+++++d+++++++++++++++++++++++++++
++++++++++++++  40 Linden Lane|Princeton, NJ 08540|609-921-0962  ++++++++++++++
+++++  Copyright 1992, Marshall Gene Flax <mgflax@phoenix.Princeton.EDU>  +++++
+ c/o Jack Gelfand|Psychology Dept|Princeton University,NJ 08544|609-258-6739 +
From: brnstnd@nyu.edu (Dan Bernstein)
Newsgroups: sci.crypt
Subject: The idea of a flood cryptosystem
Date: 9 Apr 92 04:10:53 GMT
Article-I.D.: virtualn.14871.Apr904.10.5392
Organization: IR

What follows is a rather obvious generalization of a well-known idea by
Sloane on how to foil an eavesdropper who has a noisy channel. Save this
article---this will prevent anyone from patenting the idea in the
future.

In tomorrow's high-speed networks it will be possible to overwhelm a
typical listener's expected ability to record a lengthy message. So
imagine two parties, X and Y, sharing some information. X and Y exchange
a large amount of data, more than an listener can be expected to record;
both X and Y compute on the fly a function of the data which depends on
the shared information. Unless the listener has enough knowledge of the
shared information to attack the system by brute force, he will never be
able to figure out any information about the value of the function,
provided of course that the data and function are cryptographically
strong. X and Y can exchange any amount of data this way, perhaps for
later use as a one-time pad, subject only to the capacity of the
network.

Notice that the initial shared information need not be perfectly secure.
It could even be publicized after it's used! The listener can, at best,
attempt to compute the function of the data simultaneously for all
possible values of the shared information, and if the shared information
comes from a sufficiently large space then this will be impractical. The
shared information could even have been transmitted by a weak
cryptosystem, provided that the listener is not able to break that
system before being flooded. So flooding can turn a weak cryptosystem
into a strong cryptosystem.

---Dan
From: mystical@beta.lanl.gov (Gurupartap Davis)
Newsgroups: sci.crypt
Subject: Re: Random-dot stereograms
Date: 8 Apr 92 23:54:19 GMT
Article-I.D.: newshost.1992Apr8.235419.28502
Organization: Los Alamos National Laboratory

In article <1992Apr8.032639.28004@Princeton.EDU> mgflax@phoenix.Princeton.EDU (Marshall G. Flax) writes:
>In article <1992Apr7.172817@sees.bangor.ac.uk> graham@sees.bangor.ac.uk (The Land of Confusion) writes:
>>As the information in a random dot stereogram is stored in the disparities
>>between corresponding dots in the pair of images, isn't it necessary to
>>have the plain text in advance of constructing *both* images? 
>
>Nope.  Here a simple algorithm.  Suppose the left half has already been
>sent.  Then take a copy of the left image, cut out the plaintext in
>bubble letters of the like, slide it over, and fill in the holes with
>more random dots.  Now you have the right side image.  It's not

I think I see how this works, but how do you fit the two images together?
Do you just place them side by side?  If so, then a particularly wide picture
would require some serious eye-focusing exercise.  In that case, do you
make the picture up of alternating left and right-eye views?  How excactly
is this accomplished?

--Partap
From: JRowe@exua.exeter.ac.uk (John Rowe)
Newsgroups: sci.crypt
Subject: Re: WANTED: Exportable encryption algorithm
Date: 10 Apr 92 17:22:52 GMT
Organization: Computer Unit. - University of Exeter. UK
In-reply-to: nevries@accucx.cc.ruu.nl's message of 2 Apr 92 05:54:24 GMT


Sorry to post a real newby question to sci.crypt, but:

In article <2306@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:

>   You could try the NSEA algorithm from Peter Gutman. It was described here
>   some time ago and it is part of HPACK 0.75 if memory serves right (sources
>   available). NSEA is a Peter Gurman invention wo is from New Zealand which
>   makes it available in a legal way all over the world. 

Does anyonr know of a site for the sources? archie gives me a number
of sites but the one I managed to get through to was an ms-dos
executable :-(.

More specifically, I'm just looking for the source to a reasonable
encoder (encrypter?) and decoder/decrypter that I can just compile
and go. US legality doesn't matter! 

Many thanks.

John Rowe, Exeter University, UK.
From: fjoh@alcbel.be (Ferry Johann)
Newsgroups: sci.crypt
Subject: Re: Q: DigiCash & electronic money
Date: 14 Apr 92 10:10:12 GMT
Reply-To: fjoh@alcbel.UUCP (Ferry Johann)
Organization: Alcatel-Bell Telephone, Antwerpen, Belgium

I think the company you refer to is called CWI (Centre for Mathematics and
Information Science). I only know they are in the Kruislaan at Amsterdam or
Amstelveen. You should contact them yourself to get more information. The guy
who knows more about is is called David Chaumbers (I thought).

Ferry Johann
Alcatel Bell Research Centre
Francis Wellesplein 1
Newsgroups: sci.crypt
From: franke@andrej.informatik.rwth-aachen.de (Christian Franke)
Subject: Re: On Hardware Implementations of DES...
Organization: RBI - RWTH Aachen
Date: 16 Apr 92 12:06:47 GMT

wayner@cs.cornell.edu (Peter Wayner) writes:

>Does anyone have any good information on the various hardware
>implementation of DES chips that are floating around on the market?
>I'm curious about the price and speed for the usual reasons. 

Here the (european !) chips I know:

1. Cryptech CRY12C102

	22.5Mbit/s according to Data Sheet, with 32 Bit interface

	We use this one, because it was the only one available
	when we started the project. No problems !

2. Pijnenburg PCC100

	20Mbit/s according to Data Sheet

	Address: PIJNENBURG B.V., Boxtelswweg 26, NL-5261 NE Vught,
	The Netherlands

3. INFOSYS DES Chip (Germany)

	S-Boxes must be loaded by software. So you can modify the
	Algorithm.

	Sorry, I don't have the data sheet handy. Please E-Mail me
	if you need further information.

Regards,

	Christian Franke
	Aachen University of Technology
	Lehrstuhl fuer Informatik I
	Ahornstrasse 55
	W-5100 Aachen
	Germany
	Tel.: 0241 / 80-21111

	E-Mail : franke@informatik.rwth-aachen.de
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: sci.crypt
Subject: Re: PKZIP encryption contest available from garbo
Date: 10 Apr 92 15:35:04 GMT
Organization: Academic Computer Centre Utrecht

In <1992Apr10.140052.28412@uwm.edu> rick@ee.uwm.edu writes:

>>[info about availability of PKCONTST.ZIP]
>Ok, I'll bite...  How does one choose a key "in such a way that brute
>force attacks are not possible"???  I think I'll try "zzzzzzzz".  :-)
>Gimme a break!  Brute force is *always* "possible"...  It's just not
>very *quick* sometimes.  Tell ya what...  let's divide up the keyspace
>between all of us, and break it just for fun!  (That'd probably leave

I'm in. If someone has a nice way to do this I will make it available to
as many people as possible. What about this one: make a program which starts
at a random value and keeps increasing. This could be seen as some sort
of lotery. With a real prize even! If enough people waste their computer
nights on this it should be possible (of cource the author should get
a nice thank you bonus like 0.01% or some other generous amount, I would
like to see a licence agreement dealing with this BTW).

>us each with a share of about $5, eh?)
Would only be anough to pay 200 persons. Just enough to get rid of one
bytes leaves 256^6 (wasn't the password 7 characters?) options. I have
a ZX81 here somewhere, should be no problem.

But to say something serious about this. I don't think the PKCONTST proves
much. It does perhaps prove the scheme is good (nice to know) but it does
not prove it is good. The major advantage remains (in my option) that there
is very little time with the PK scheme between trying a password and knowing
it is good. The NSEA scheme for example seems much better in this respect.
You can always claim the user should use a better password but we all know
users :-). At least the program should warn when a too simple password is
used (hint, are you listening PK?).

>Serge!  Here's your chance to finance your trip to CalTech!  Go for it!!!

>Rick Miller  rick@discus.mil.wi.us  discus!rick@uwm.edu  rick@ee.uwm.edu

Nico
Newsgroups: sci.crypt