HDTenEightyP/NetNews huggingface dataset:
From: karn@chicago.qualcomm.com (Phil Karn)
Newsgroups: sci.crypt
Subject: Re: On Hardware Implementations of DES...
Date: 17 Apr 92 02:53:48 GMT
Organization: Qualcomm, Inc

In article <1992Apr16.221440.27205@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?
>	Having the source (and going through it) is one way to be sure...

Ah, but how do you know that somebody hasn't hacked your *compiler*
too?  (See Ken Thompson's Turing Award speech for the details.) And of
course you may have a perfectly trustworthy DES program running on an
completely untrustworthy machine or operating system...

Phil
From: karn@chicago.qualcomm.com (Phil Karn)
Newsgroups: sci.crypt
Subject: Re: Q: DigiCash & electronic money
Date: 14 Apr 92 07:12:07 GMT
Organization: Qualcomm, Inc


Although I think the idea of electronic cash is wonderful, I'm afraid
it will never get very far given the present worldwide drug hysteria.

Unlike the private use of cryptography, which no government will ever
be able to control, the success of cryptographic cash depends in large
part on governments formally recognizing it as legal tender.

Phil
From: nevries@accucx.cc.ruu.nl (Nico de Vries.)
Newsgroups: sci.crypt
Subject: YAP, yet another patent, question
Date: 8 Apr 92 16:00:49 GMT
Organization: Academic Computer Centre Utrecht

Hi,

my question is simple. Is using DSA for AV (authenticy verification) allowed
or not. I have the following assumptions and want to know it they are true
or if anyone knows more.

- the RSA patent covers public key encryption (which seems impossible to do to
  me with DSA) and not AV
- it is allowed to export AV code from the US to other nations

I am especialy interested in hard facts (laws, jurispriction, documents etc).

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: wierda@ltb.ltb.bso.nl (Gerben Wierda)
Newsgroups: sci.crypt
Subject: Is there a port of PGP for Unix available?
Date: 16 Apr 92 13:39:07 GMT
Organization: BSO/LT, Baarn, The Netherlands

Before I look into it myself. Is there a port of PGP for Unix available. I have
the sources (they come with DOS exe and obj files and an assembler file). I'd
like to play around with it on Unix.

Thanks,
-- 
wierda@ltb.bso.nl (Gerben Wierda) || I speak for myself and not for my employer.
(+31) 2154 84415/(+31) 35 833539  || Support the League for Programming Freedom!
	"If you don't know where you are going, any road will take you there."
	Lewis Carroll, "Alice in Wonderland".
Newsgroups: sci.crypt
From: bfairlan@isis.cs.du.edu (Brian Fairlane)
Subject: Try-out
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Thu, 9 Apr 92 20:40:18 GMT

Assume I had a fast, simple and "secure" encryption algorithm, can I
somewhere, somehow "try this out"? I.e. send an encrypted file
to some pattern research/cryptology place, and ask them to decrypt it,
back to whatever it was before (plain textfiles) encrypting it.
 
I, who created it, can't in no way figure out how it could be done, but
I want some independant, professional people to tell if it is.
 
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).
 
Sceptics; No, it's not a (key) == (length_of_file) "algorithm".
It uses "normal" keys in special ways.

Newsgroups: sci.crypt
From: karger@osf.org (Paul A. Karger)
Subject: Re: Source for _real_ random numbers
Organization: Open Software Foundation
Distribution: na
Date: Thu, 16 Apr 1992 17:51:24 GMT

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.
|> 
|> So my query to the netexperts is: which is it?
|> 
|> The method I'd heard of:
|> 	Cleartext:	The Rain in....
|> 
|> 	1) Open book at pseudo-random. 
|> 	2) Close eyes, point to somewhere on page.
|> 	3) Open eyes, find nearest  'T'
|> 	4) Page 38, line 7, letter 37 
|> 	5) output 38737 or such as encrypted 
|> 	6) Mark page so you do not reuse it.
|> 	7) Loop to 1) for "h" 
|> 		and so forth.
|> 
|> Now, if you never reuse the page, or maybe the paragraph, have you
|> provided enough data so that someone without the same book can decide
|> it or not? I've gotten different answers.
|> 
|> {I can't remember where I heard of this, but it was in the popular
|> press somewhere, maybe a novel.}

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 they were finally brought 
to trial.   As I recall, the basis of breaking book ciphers is that
the book follows the statistics of the English language (or Spanish
or Urdu or whatever).   Can anyone on the net fill in the history
of this better than I can?

(Just for reference, William Friedman was in charge of the group that
broke the Japanese Purple code, prior to Pearl Harbor, and is generally
regarded as the father of modern cryptography.   His wife was also
an outstanding cryptographer, so she is presumably the mother of
modern cryptography!)
From: bs891@cleveland.Freenet.Edu (Robert Anderson)
Newsgroups: sci.crypt
Subject: Re: Q: DigiCash & electronic money
Date: 15 Apr 92 16:07:34 GMT
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)


Thanks to the people who have sent me information on
DigiCash.  Several people asked for more info, so here
are the address and phone numbers.  Unfortunately, I got
two versions from two different people:

DigiCash			DigiCash
Kruislaan 419			Kruislaan 411
1098 VA  Amsterdam		1098SJ Amsterdam
The Netherlands			The Netherlands

Phone: +31 (20) 665-2611	phone: +31 20 592 2242
Fax:   +31 (20) 668-5486	fax           592 5155

Apparently David Chaum is one of the main people involved.
I found a paper by him and 2 others in the Crypto 88
proceedings which describes an electronic cash system that
sounds like what DigiCash is doing.

You go to the "bank", in this case DigiCash, and withdraw
money by offering a "blinded" random number for them to sign.
You can then unblind the number so that even the bank can't
recognize it, but you can still spend it by showing the
store the bank's signature.  The store then sends the number
back to the bank and gets paid.

The really clever feature is that the bank can't recognize
the numbers as they come in from the stores in terms of who
withdrew them.  That is, it can't unless you try to cheat and
spend the same number twice.  Spending the money involves
going through a little protocol with the store owner, and
some randomness in the protocol ensures that if you do it
twice, you'll reveal enough information that the bank can
figure out who you are.  Then they can sue you, or at least
shut your account down.

I'm looking at several other papers by Chaum on this general
topic and on cryptographic solutions for financial privacy
in general.  His ideas look great, but the papers are complex
and it's going to take me a while to really understand what
he's saying.

Bob Anderson
From: gloe@cci.de (Jochen Gloe)
Newsgroups: sci.crypt
Subject: RC2 / RC4 Algorithm
Date: 7 Apr 92 09:15:01 GMT
Organization: Competence Center Informatik GmbH

I have problems in getting information on a single-key algorithm called
RC2 or RC4 Algorithm (RC=Rivest Cipher). This algorithm is implemented
in "Lotus Notes 2.0" to encrypt messages that are sent over the network.

Please send any available information to the following E-Mail address.

Thanking you in advance,

---------------------------------------------------------------------------
| Jochen Gloe                       | Internet        | gloe@cci.de       |
| Competence Center Informatik GmbH | 4470 Meppen     | Tel. 05931-805229 |
| Bereich DV-Sicherheit             | Lohberg 10      | FAX: 05931-805100 |
---------------------------------------------------------------------------
Newsgroups: sci.crypt
From: wayner@cs.cornell.edu (Peter Wayner)
Subject: On Hardware Implementations of DES...
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Wed, 15 Apr 1992 01:48:49 GMT


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. 

-Peter 



-- 
Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850
EMail:wayner@cs.cornell.edu    Office: 607-255-9202 or 255-1008
Home: 116 Oak Ave, Ithaca, NY 14850  Phone: 607-277-6678
From: mather@sees.bangor.ac.uk (Paul Mather)
Newsgroups: sci.crypt
Subject: Re: Public Domain RSAREF-based PEM Projects?
Keywords: public domain, strict licensing.
Date: 16 Apr 92 13:56:59 GMT
Article-I.D.: sees.1992Apr16.145659
Organization: Centre for Applied Obfuscation.

In article <1992Apr16.023320.26222@msuinfo.cl.msu.edu>, mrr@scss3.cl.msu.edu (Mark Riordan) writes:
> How many people out there are writing RSAREF-based Privacy-Enhanced
> Mail programs to be placed in the public domain?

I'm a little confused.  I thought RSAREF had a pretty strict license
agreement surrounding it and, importantly, could not be exported
outside the USA.  As such, non-USAn's such as myself cannot use it.

In this case I suppose it's a matter of "public domain" provided you're
a US citizen living inside the USA. :-(

By the way, what is the current status of RPEM?

Cheers,

Paul.

-- 
e-mail: p.mather@sees.bangor.ac.uk

If your mailer can't reach me, I'm obviously not worth talking to.
Newsgroups: sci.crypt
From: rick@ee.uwm.edu
Subject: Re: PKZIP encryption contest available from garbo
Summary: GET A LOAD OF *THIS*!
Reply-To: rick@discus.mil.wi.us
Organization: Jus' me.
Date: Fri, 10 Apr 1992 14:00:52 GMT

In article <1992Apr9.085156.4858@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
>-From ts@uwasa.fi Thu Apr  9 11:48:57 1992
>Subject: Re: pkzip encryption contest
>To: jloup@chorus.fr (Jean-loup Gailly)
>Date: Thu, 9 Apr 92 11:48:57 EET DST
>Cc: garbo-infolist
>
>>
>> Timo and Harri,
>>
>> Phil Katz has set up a contest to break the encryption scheme used
>> in pkzip. He is offering $1000 to the first person who breaks the
>> password on a file of 12K bytes. With Pkware permission, I have uploaded
>> the file to /pc/incoming/pkcontst.zip.
>>
>> The inner file contest.txt is not encrypted and details the rules
>> of the contest. The password has been chosen in such a way that
>> brute force attacks are not possible.
>>
>> Jean-loup
>
>Thank you Jean-loup.  Your upload is now available as
>
>14433 Apr 3 14:39 garbo.uwasa.fi:/pc/arcutil/pkcontst.zip
>
>   All the best, Timo
>...................................................................
>Prof. Timo Salmi
>Moderating at garbo.uwasa.fi anonymous ftp archives 128.214.87.1
>School of Business Studies, University of Vaasa, SF-65101, Finland
>Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun

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
us each with a share of about $5, eh?)

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
Newsgroups: sci.crypt
From: Lawrie.Brown@adfa.oz.au
Subject: Re: Q: DigiCash & electronic money
Originator: lpb@ccadfa.cc.adfa.oz.au
Organization: Australian Defence Force Academy, Canberra, Australia
Date: Wed, 15 Apr 1992 04:58:02 GMT

bs891@cleveland.Freenet.Edu (Robert Anderson) writes:

>Does anyone have more information on DigiCash, and the
>specifics of their money system?

I would guess that its based on the ideas developed by David Chaum.
See:
Author(s): David L. Chaum
Title    : Security Without Identification: Transaction Systems To Make Big
           Brother Obsolete
Journal  : |CACM|
Volume   : 28
Number   : 10
Date     : |OCT| 1985
Pages    : 1030-1044
Keywords : communication, network, public key, privacy, security
Abstract : The large scale automated transaction systems of the near future can
           be designed to protect the privacy and maintain the security of both
           individuals and organizations.

and a number of subsequent papers in the Crypto or Eurocrypt conference
proceedings.

Cheers
Lawrie.
From: mink@coyote.datalog.com (Clint Ruoho)
Newsgroups: sci.crypt
Subject: DISKREET trapdoor?
Date: 14 Apr 92 00:08:58 GMT
Organization: Datalog Consulting, Tucson, AZ

I recently noticed that Diskreet from Norton Utilities promtly notified
me when I had entered the incorrect password to decrypt a file.  I then
began to think that a CRC of the password (or something of the sort) was
stored in the encrypted file.  It appears as if this is the case. I do not
know how the password is permutated, but I would hope that this is a
one-way algorithm.  However, it could be a reversible algorithm built by
Peter Norton in order to provide a trapdoor.

Here are the first 48 bytes from command.sec, command.com encrypted using
Diskreet with password: thisisatest

6718:0100  50 4E 43 49 43 52 59 50-54 00 01 00 00 00 01 00
6718:0110  42 7E 34 E0 B4 7A BE CC-69 E7 2D 93 F9 FD 4A D3
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6718:0120  43 36 90 98 5F EC 6A C9-BA 9F 43 2B 8E D6 2D 70

Here are the first 48 bytes from chkdsk.sec, chkdsk.com encrypted using
Diskreet with the same password (thisisatest)

6718:0100  50 4E 43 49 43 52 59 50-54 00 01 00 00 00 01 00
6718:0110  42 7E 34 E0 B4 7A BE CC-69 E7 2D 93 F9 FD 4A D3
           ^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
6718:0120  B1 C2 06 23 83 6C 5B E7-B1 95 F7 12 D6 F0 BB BA

Notice how the second line (bytes 10-1f) are the same in both cases!  The
actual encrypted text is apparently stored starting at byte 20.  Besides
the password, these files are absolutely unrelated.

Here is command.sec, command.com encrypted with a new password...

6718:0100  50 4E 43 49 43 52 59 50-54 00 01 00 00 00 01 00
6718:0110  BE A1 7B C1 F5 31 58 61-E2 C1 3D 5C BE 68 50 A9
6718:0120  53 F7 A7 09 CC BB 28 59-46 8B A0 20 05 A8 F1 DA

Notice that when I changed the password, bytes 10-1f also changed.  
Apparently
this is where the permutated password is stored.

Does anybody know what sort of routine Peter Norton uses here?  Is it
reversible?

- C Ruoho

--
Clint Ruoho    4042 East 2nd St     Tucson, AZ 85711-1012
cr@farpoint.tucson.az.us (preferred)
mink@coyote.datalog.com
Newsgroups: sci.crypt
From: prz@sage.cgd.ucar.edu (Philip Zimmermann)
Subject: Avalanche tester
Organization: Climate and Global Dynamics Division/NCAR, Boulder, CO
Date: Sun, 12 Apr 1992 21:20:35 GMT

I am looking for a piece of software that will test the "avalanche
effect" of any block cipher.  That is, it will somehow measure the
amount of intersymbol dependancies between the plaintext and the
ciphertext, and between the key and the ciphertext.  A good block
cipher will cause about half the ciphertext bits to change if only
one bit changes in the key, or if only one bit changes in the
plaintext.  A useful test program would systematically flip bits or
groups of bits in the key or the plaintext, and measure the
statistical properties of the bit changes in the ciphertext, going
through a large number of samples.  

It would save me some work if anyone has such a program handy, in
source form.  C would be nice.  If you have a lengthy answer that
would not be of interest to this newsgroup, you can reply via direct
email to me.  Thanks.

Philip Zimmermann   303/444-4541  prz@sage.cgd.ucar.edu
From: jsutin@mcs213c.cs.umr.edu (SpinDoctor X)
Newsgroups: sci.crypt
Subject: UNIX password encryption
Date: 11 Apr 92 00:59:08 GMT


	I am interested in references which describe the algorithm for the 
UNIX password encryption scheme.  I would appreciate if anyone could e-mail
references to me (jsutin@cs.umr.edu) as I do not regularly read usenet.

	Thank you,
	Jason Sutin

PS. I am also interested in good references of encryption theory.
From: brnstnd@nyu.edu
Newsgroups: sci.crypt
Subject: Re: The idea of a flood cryptosystem
Date: 16 Apr 92 04:17:15 GMT
Organization: IR

In article <2058@transfer.stratus.com> cme@ellisun.sw.stratus.com (Carl Ellison) writes:
> So -- you end up with an algorithm labelled: "secure against IBM PC
> clones with less than 800 MB of hard disk storage", for example, and you
> can prove security without having to resort to complexity arguments.

Yep.

> Of course, all this depends on the shared function of the two streams
> being secret -- or the eavesdropper could compute the function on the
> fly just as the real recipients do.  If the function is secret and
> shared, is this not just another private key system?

It's different---the ``key'' is the initial shared information, but (1)
unlike normal keys it doesn't have to come from a very large space, (2)
it can be transmitted by a relatively weak cryptosystem, and (3) it can
be published immediately after the flooding.

Note on (1): If the initial shared information comes randomly from a
space of one million possibilities, then the attacker can, in principle,
compute all one million functions simultaneously, but in practice this
will be impossible---even though one million can't be considered a large
enough key space for most applications.

---Dan
From: ross@spam.ua.oz.au (Ross Williams)
Newsgroups: sci.crypt
Subject: CALL FOR DISCUSSION: COMP.COMPRESSION.THEORY.
Summary: CALL FOR DISCUSSION: COMP.COMPRESSION.THEORY.
Keywords: comp.compression.theory new group
Date: 14 Apr 92 05:00:18 GMT
Followup-To: news.groups
Organization: Statistics, Pure & Applied Mathematics, University of Adelaide


CALL FOR DISCUSSION: COMP.COMPRESSION.THEORY
============================================
It is proposed that a new newsgroup be created:

   Name    : comp.compression.theory
   Charter : Discussions about data compression algorithms.
   Status  : Unmoderated.

Many researchers have stopped reading comp.compression because of the
volume of non-research traffic (e.g. postings with subject fields such
as "Where can I get Unix compress for MSDOS?"). There is now a strong
need for a newsgroup that can provide a forum for more theoretical
discusions about data compression and data compression algorithms.
Such a newsgroup would assist those who are actually involved in
understanding and developing new algorithms as opposed to merely using
them.

The suffix ".theory" is designed to scare off those who want to
discuss specific computer programs. The term "algorithms" in the
charter is designed to lure back those who got so scared that they
decided it must be a newsgroup for information theorists. It is
intended that the scope of the newsgroup range from information theory
to practical algorithm construction, but no further.

Timetable
---------
Tue 14-Apr-1992 Call for discussion (deadline for agreement 14-May-1992).
Tue 28-Apr-1992 Call for votes.
Thu 21-May-1992 Last day on which votes will be received.
Fri 22-May-1992 Posting of vote tally. 5 day waiting period.
Thu 28-May-1992 Creation of comp.compression.theory.

In accordance with the guidelines for newgroup creation, discussion
about the creation of this newsgroup will take place in "news.groups".

I am sending this message to a few key newsgroups and also to all
those who voted in the comp.compression vote about one year ago. I
urge you to support this proposal which has the potential to
significantly assist data compression researchers around the world.

Ross Williams
ross@spam.adelaide.edu.au
(Creator of comp.compression)
Newsgroups: sci.crypt
From: mattair@sun44.synercom.hounix.org (Charles Mattair)
Subject: Legal basis for crypto export restrictions
Organization: Synercom Technology, Inc., Houston, TX
Distribution: na
Date: Mon, 6 Apr 1992 14:26:23 GMT

Will someone please mail me the relevant citations (USC references) which
enable/require the government to restrict crypto exports?  I would suspect
this was done with some vastly global enabling legislation which was then
actually legislated through the Federal Register.  These citations would also
be appreciated.

tnx...
-- 
Charles Mattair			      (preferred) mattair%synercom@hounix.org
Fast, Cheap, Good.  Choose Two. (anon)		   (or)	mattair@synercom.UUCP
Any opinions offered are my own and do not reflect those of my employer.
--------------------------------------------------------------------------------
Newsgroups: sci.crypt
From: michel@sun3.NoSubdomain.NoDomain (Olivier Michel)
Newsgroups: sci.crypt
Subject: Lookig for ufc-crypt sources
Date: 15 Apr 92 13:31:36 GMT
Organization: Laboratoire de Recherche en Informatique

Hello,

I'm looking for the fast crypt() function called ufc-crypt().
I'm looking for the sources or a librarie of this function. I would apreciate
a FTP site or an Email.

Thank you in advance.

-- 
/=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\
| Olivier MICHEL                          |                               |
| Laboratoire LRI - Universite PARIS_SUD  | Email : michel@lri.lri.fr     |
| Bat. 490- bureau 95                     |       : michel@FRLRI61.BITNET |
| 91405 ORSAY CEDEX                       | Fax   : 33-1-64-46-19-92      |
| FRANCE                                  | Phone : 33-1-69-41-65-79      |
|-------------------------------------------------------------------------|
| Welcome to Potters Bluff, A new way of life				  |
\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt
Subject: Re: The idea of a flood cryptosystem
Date: 9 Apr 92 16:49:25 GMT
Article-I.D.: transfer.2058
Organization: Stratus Computer, Software Engineering

In article <14871.Apr904.10.5392@virtualnews.nyu.edu> brnstnd@nyu.edu (Dan Bernstein) writes:
>In tomorrow's high-speed networks it will be possible to overwhelm a
>typical listener's expected ability to record a lengthy message.
 ^^^^^^^^^^^^^^^^

This is a wonderful idea.  Since the NSA isn't a typical listener (and
would probably be delighted to get the extra budget allocation to
cover the necessary intercept and recording ability), they should have
no objection to this method of operation.

So -- you end up with an algorithm labelled: "secure against IBM PC
clones with less than 800 MB of hard disk storage", for example, and you
can prove security without having to resort to complexity arguments.

Of course, all this depends on the shared function of the two streams
being secret -- or the eavesdropper could compute the function on the
fly just as the real recipients do.  If the function is secret and
shared, is this not just another private key system?