HDTenEightyP/NetNews huggingface dataset:
From: Graham.Shaw@newcastle.ac.uk (G.D.Shaw)
Newsgroups: sci.crypt,alt.security
Subject: Re: Are DES restriction even logically sound?
Date: 8 Sep 92 10:26:42 GMT
Organization: University of Newcastle upon Tyne, UK NE1 7RU

In article <18h94qINNlkq@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Sep6.094022.28262@uwm.edu> markh@csd4.csd.uwm.edu (Mark) writes:
>>(4) If it's described in English, is it regarded as software?  English is
>>    executable under a suitably designed specialized natural language
>>    interpreter.
>
>When we really have compilers capable of executing free-form English, the
>government may adjust their notion of the distinction between software and
>human-oriented description.  Since the description of DES *is* in a public
>domain document (a US FIPS), it's clearly not considered to be a software
>implementation that is subject to export restrictions.
>
True for DES (and indeed most ciphers), but what about intrinsically much
simpler systems like RSA?  With suitable maths software, the distinction
between a 'human-orientated description' and a 'computer program' becomes
a very fine one.

Graham Shaw (dph3gds@tuda.ncl.ac.uk)
Department of Physics, Durham University, England
Newsgroups: sci.crypt
From: sghahn@sol.kaist.ac.kr (Hahn Sang Geun)
Subject: Is DES broken ?
Organization: KAIST
Date: Sun, 6 Sep 92 03:14:18 GMT


I heard from a colleague in electronics department that
16 round DES was broken at the 1992 CRYPTO meeting.

He told me a progress in differential cryptalanalysis
made it possible.

Is that correct ?
If so, how practical is that ?

S. HAHN
Mathematics Department
KAIST
South Korea

Newsgroups: sci.crypt,rec.arts.movies
From: kadie@herodotus.cs.uiuc.edu (Carl M. Kadie)
Subject: Re: "Sneakers" -- action/adventure movie about Cryptography
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 15 Sep 1992 09:50:17 GMT

[Spoilers ...]

I think the biggest flaw in "Sneakers" is that it treats information
(the decryption program) as a physical object (by actually putting it
in a physical object).

In a more realistic movie, everyone would be searching hard disks for
copies of the program rather than the Bay Area for a box. The movie
would have ended when someone posted the "Too Many Secrets" program to
sci.crypt.

- Carl
--
Carl Kadie -- kadie@cs.uiuc.edu -- University of Illinois at Urbana-Champaign
Xref: sparky sci.crypt:3181 alt.security:4333 comp.security.misc:1230
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt,alt.security,comp.security.misc
Subject: Re: ATM fraud
Date: 10 Sep 92 16:13:45 GMT
Followup-To: sci.crypt
Organization: Stratus Computer, Software Engineering

In article <JIM.92Sep9125700@hunter.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes:
>Indeed. The UK banks do tell customers to keep PIN numbers secret, but
>they don't properly explain why this is necessary.

Even if they did, there's no way to write the necessary warning.

"Keep the PIN secret" can not mean "refuse to enter it on any keypad,
no matter how official looking".
From: pacolley@ember.UUCP (Paul Colley)
Newsgroups: sci.crypt,alt.security,comp.security.misc
Subject: Re: ATM fraud
Date: 9 Sep 92 18:50:37 GMT
Reply-To: pacolley@ember.UUCP (Paul Colley)
Followup-To: sci.crypt
Organization: Ember---private system


In article <ARI.HUTTUNEN.92Sep9013737@supergirl.hut.fi> Ari.Huttunen@hut.fi
(Ari Juhani Huttunen) writes:

>It just shows that the current idea of an 'ATM card' is no good. We need
>intelligent tokens and pretty damn fast. By 'intelligent token' I mean
>a card that can be challenged by the computer of the bank. I've seen this
>talked about in many books, so it's nothing new. What I would like to know
>is that how soon such devices will be available?

Once upon a time I worked for a bank.  I read a report estimating
losses on credit cards from fraud vs. other causes, as well as
detailing some of the security measures on today's cards.

The long and the short of it is:  Losses due to fraud are currently
an order of magnitude less than losses due to simple non-payment
of what's owed.

Until fraud becomes a more significant problem, there is little
motivation to invest resources into reducing fraud when the same
resources could be used to try and reduce non-payment of debts.


At the same unnamed bank, we were required to use smart cards for
some things, and heavily encouraged to use them in some pilot
customer-type projects.  This was two years ago, and maybe state
of the art has improved, but the smart cards we were using had a
lot of reliability problems (chip popping out of card, not working
after you sat on your wallet, not surviving exposure to water,
etc.).  Customers already get very upset when their mag-stripe
cards stop working, and replacing them with something that is much
more fragile doesn't seem like a good idea.


So smart cards are likely to be delayed until costs fall nearer to
the costs of making a mag-stripe card, and reliability increases
to a level similar to a mag-stripe card.

Or until fraud becomes a more serious problem...

- Paul Colley
University:  colley@qucis.queensu.ca
Home:        pacolley@ember.uucp   watmath!ember!pacolley  +1 613 545 3807
<Ring> [...] "Sorry, I'm all booked up." "Who was that?" "The library." - B.C.

Xref: sparky sci.crypt:3139 alt.security:4285
From: barmar@think.com (Barry Margolin)
Newsgroups: sci.crypt,alt.security
Subject: Re: Are DES restriction even logically sound?
Date: 8 Sep 1992 04:11:06 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Sep6.094022.28262@uwm.edu> markh@csd4.csd.uwm.edu (Mark) writes:
>(4) If it's described in English, is it regarded as software?  English is
>    executable under a suitably designed specialized natural language
>    interpreter.

When we really have compilers capable of executing free-form English, the
government may adjust their notion of the distinction between software and
human-oriented description.  Since the description of DES *is* in a public
domain document (a US FIPS), it's clearly not considered to be a software
implementation that is subject to export restrictions.

In answer to the other posting about US citizens being the only people able
to turn descriptions into implementations, that's not the issue.  The
government doesn't want us to facilitate the creation of munitions by our
enemies (encryption devices are considered to be weapons -- remember, the
development of computers was catalyzed by the use of encryption during
WWII), and selling working implementations of DES is considered
facilitation.  There are also published articles that detail how to build
bombs, yet the government also controls their export as well.

Of course, these days encryption is more useful for commercial uses than
military, and the government is shooting the economy in the foot by
restricting its sales.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: masticol@cadenza.rutgers.edu (Steve Masticola)
Newsgroups: sci.crypt
Subject: Re: "Sneakers" -- action/adventure movie about Cryptography
Date: 14 Sep 92 00:55:01 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

ken@sugra.uucp (Kenneth Ng) writes:

>Now, how does one put tension on an electronic lock? :-)

Easy! 150 KV across any exposed metal. That's high tension!

Seriously, can you open those things by using an electromagnet
external to the lock? If the hasp is magnetic and isn't held in place
by a separate catch, I'd tend to think so. But then I guess it'd be
free to spring back, making it vulnerable to carding.

- Steve (masticol@cs.rutgers.edu).
From: il@bambam.u.washington.edu (Il Hwan Oh)
Newsgroups: sci.crypt
Subject: Re: "Sneakers" -- action/adventure movie about Cryptography
Date: 16 Sep 92 00:05:45 GMT
Reply-To: iho@cac.washington.edu
Organization: University of Washington, Tacoma

krazykid@csa.bu.edu (Ernest Kim) writes:
spoilers!


> In a more realistic movie, they wouldn't be using modems where you put
> the telephone mouth piece on a suction cup to make a connection with a
> computer.

I thought the only time they used that was as a hookup to their "lie
detector" thing.

-- 
Il Hwan Oh                              | What is "Martinizing",
Computer Facilities Manager             |  and why does it
University of Washington, Tacoma        |   take one hour?
iho@cac.washington.edu                  | 
Newsgroups: sci.crypt
From: forrie@morwyn.uucp (Forrie Aldrich)
Subject: Secure password generation
Organization: Vision Graphics
			  Dover, NH
			  USA
Date: Sat, 12 Sep 1992 02:07:56 GMT


I've been advised to post this request to this group ...

I'm seeking a program/method which will generate pronounceable passwords,
securely.  Meaning the process by which the actual password is generated
should be genuinely random enough so an attack at the algorithm (by
whatever means) would be infeasable.

We are using a John F. Haugh's shadow login utility here.  I've seen,
documented, a similar feature available under some derivitive that
SCO UNIX has provided.  IE the feature is embedded within the actual
passwd program.  If I can get a decent utility to provide this 
functionality, I would like to embed this in our passwd program.  Of
course, everyone has their own view of what is considered a 
pronounceable password.  

I think (?) UUNET has such a procedure, but am not sure.

Any help would be greatly appreciated.  Please respond via email as
our site does not get fed this group (yet).

Forrest
-- 
	   -----------	      Forrest Aldrich	      -----------
	   -------     morwyn!forrie@unhtel.unh.edu	  -------
	   ----						     ----
	   --	     VISION GRAPHICS --	Dover, NH - USA	       --
	   ------------------------------------------------------
From: tk@ai.mit.edu (Tom Knight)
Newsgroups: sci.crypt
Subject: Re: "Sneakers" -- action/adventure movie about Cryptography
Date: 15 Sep 92 23:33:27 GMT
	<1992Sep4.205842.12303@qualcomm.com>
	<1992Sep10.034159.1617@qiclab.scn.rain.com>
	<1992Sep14.150328.11198@b11.b11.ingr.com>
Organization: MIT Artificial Intelligence Lab
In-reply-to: craig@jido.b11.ingr.com's message of 14 Sep 92 15:03:28 GMT

In article <1992Sep14.150328.11198@b11.b11.ingr.com> craig@jido.b11.ingr.com (Craig Presson) writes:

   From: craig@jido.b11.ingr.com (Craig Presson)
   A much better job was done on the standard spy stuff....

Well... Does it bother anyone else while looking at movies or reading
a newspaper that the writers are uniformly misinformed about subjects
you know something about?  Extra credit: extrapolate to subjects that
you don't know about, but which (presumably) someone else is
proficient at.  Frightening, isn't it.

Any real spy want to comment on Sneakers?
From: grayt@Software.Mitel.COM (Tom Gray)
Newsgroups: sci.crypt
Subject: Re: ATM fraud
Date: 11 Sep 92 12:01:58 GMT
Organization: Mitel. Kanata (Ontario). Canada.

In article <7161518255083@c00506-119rd.eos.ncsu.edu> cddukes@c00506-119rd.eos.ncsu.edu (PakRat's Anonymous) writes:
>One point worth making.  Even with an ATM card that challenges the 
>machine to see if it is authentic, an individual could either tap
>the keyboard and appropriate elements to find out who belongs
>to the pin number.  Or design a front that records what is
>going on and relays it to a a working secure machine.




Perhaps a comment from a layman will be thought appropriate.
ATM fraud is an economic enterprise. That is the crook is going 
to have to make money on the deal. Complicated schemes to gather
thousands of PIN's to rob thousands of accounts are all very well.
However if the outcome of this is too deposit thousands of individual
sums into the account of Joe Bloggs (computer thief and chef international),
the long arm of the law will not be far behind him on the electronic road.
The cops say to break up an elaborate criminal conspiracy, one should
follow the money. Here the crook is not only leaving a paper path, he
is providing a road map.

IMHO anyway




-- 
i.sinature
Newsgroups: sci.crypt
From: karger@osf.org (Paul A. Karger)
Subject: Re: ATM fraud
Organization: Open Software Foundation
Date: Fri, 11 Sep 1992 14:37:16 GMT

In article <7161518255083@c00506-119rd.eos.ncsu.edu>, cddukes@c00506-119rd.eos.ncsu.edu (PakRat's Anonymous) writes:
|> One point worth making.  Even with an ATM card that challenges the 
|> machine to see if it is authentic, an individual could either tap
|> the keyboard and appropriate elements to find out who belongs
|> to the pin number.  Or design a front that records what is
|> going on and relays it to a a working secure machine.
|> 

All true - this is why the smart ATM card needs its own keyboard
and on-board encryption device.  Then the bi-directional challenges
are fully encrypted, and a completely bogus machine cannot interfere.
What this means is something like a credit-card sized calculator.

Certainly the ATM cards typically in use today in the US are insufficient.
Some of the European smart cards are approaching what is required, but
the real issue is building a smartcard with a keyboard that can survive
in a person's wallet or purse or whatever and doesn't cost significantly
more than current mag-stripe ATM cards.   This is a major engineering
challenge to the power and packaging people!!
From: billy@terminus.umd.edu (Billy E. Taylor Jr.)
Newsgroups: sci.crypt
Subject: Re: RSA's faq hosed up?
Date: 15 Sep 92 15:21:46 GMT

In article <1992Sep14.163511.204@news.uwyo.edu> jimkirk@news.uwyo.edu writes:
> I recently obtainted the faq from rsa.com, but the postscript file seems
> messed up.  When viewed with DEC's dxpsview utility (DECstation 3100,
> Ultrix), I first get an error message about no enough memory, then
> dxpsview hangs when I try to view the next page.
> [...more deleted...]
Here's the readme from the /pub/faq directory on rsa.com:
======================================================================
This directory contains files for the document

                         Answers To
                 FREQUENTLY ASKED QUESTIONS
                 About Today's Cryptography

                       by Paul Fahn
             A Publication of RSA Laboratories


It is available in three formats:

1. postscript
   Take the file faq.ps.Z. Uncompress to obtain faq.ps. If it fails to
   print due to lack of memory in your printer (it is a very large file),
   take the file faq-k.ps.Z, uncompress to obtain faq-k.ps.

2. LaTeX
   Take the files faq.tex and crypto.bib. Run latex on faq.tex and bibtex
   on crypto.bib. Do this for a couple of iterations to ensure correctness.
   
3. Hard copy
   Send $20 (to cover expenses) to 
     RSA Laboratories, 100 Marine Parkway, Redwood City, CA  94065.


Send questions, comments, and suggestions to faq-editor@rsa.com.
===========================================================================

rtfming my heart out,
billy.

-----------------------------------------------------------------------------
Billy E. Taylor, Jr.  | (301) 403-4616         | "...carped the deim like
Comp Sci Ctr, U of MD | billy@terminus.umd edu | a mother..."  -- RICHH
College Pk, MD 20742  | Disclaimer: I don't know, maybe it's me...
From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: sci.crypt
Subject: Re: IDEA cipher (was: PGP 2.0 Announcement)
Date: 11 Sep 92 21:45:37 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: Tin 1.1 PL5

Peter Gutmann (pgut1@cs.aukuni.ac.nz) wrote:
: In <1398@eouk9.eoe.co.uk> ahaley@eoe.co.uk (Andrew Haley) writes:
: 
: >Yes, IDEA has a 128 bit key.  It's rather beautiful algorithm,
: >involving multiplications mod 65537 (which is prime, so the
: >multiplications are invertible because every number (except zero) has
: >an inverse mod a prime), additions mod 65536, and XORs.  These
: >operations are combined in a network which thoroughly scrambles the
: >data.  There are no table lookups or bit permutations at all.
: >
: >BAD NEWS: It's PATENTED.  Not just in the USA but in Europe as well.
: >If enforced, this patent will probably prevent the widespread adoption
: >of this algorithm.  A great shame.
: 
: However the patent owners, Ascom-Tech AG, are being very reasonable about
: the patent (totally unlike PKP).  They let us use it in PGP without having
: to pay any license fees since PGP is free, and are very approachable about
: it's use in other programs.  Still, I ended up not using it in my PGP-compatible
: archiver since I have a religious thing about patents - however, IDEA is a very
: good cipher and the way the patent is being administered is one of the more
: enlightened I've seen.

I utterly disagree.  There is no way to describe the enforcement of an
algorithm patent as "enlightened".  It's like saying "Frank is a good
jailer, he doesn't tie my shackles too tight".  They (the IDEA
licensors) _do not_ allow the free use in PGP in general, only in
noncommercial cases.  Which means that you and I can communicate with
PGP until we wish to discuss business; then we have to start paying
money.

I am not opposed to the copyrighting of code, but algorithm patents
are a way to prevent the application of ideas, something we haven't
seen since the dark ages.

Followups to comp.patents.

: 
: Peter.

Andrew.

P.S.  Support the League for Programming Freedom!
From: pcl@oxford.ac.uk (Paul Leyland)
Newsgroups: sci.crypt
Subject: Re: "Sneakers" -- action/adventure movie about Cryptography
Date: 15 Sep 92 08:24:49 GMT
Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, OX2
	6NN
In-reply-to: leonard@qiclab.scn.rain.com's message of 4 Sep 92 01:25:39 GMT

leonard@qiclab.scn.rain.com (Leonard Erickson) writes:

] just for old times sake.....
] 
] RYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRY
] JQWST HBAMQ VB@SR EJPPF ^\CEN IPWHZ KVLUY PZBRF NIWVZ NQ@IE PV\HB MLEQT 
] PZKNL UYGRC HJATE EF]CA NQZWF HCRLU XF^\S TNLPF ^[Q@N QTFJH CPNIW VN\SE 
] NMYR@ [[FDA \V^]K RDATV \YSIM QZGDX KTMEW V\HCI MYZF^ HCTMA RPZBR CM]VW 
] @]KTL UYB@X [OMUV WJ[SI NQ\R@ XKRLT PGDYK QNURW F]CEL PW@ZB PMAID RN]SE 
] DATV\ YSIMQ ZGDXK TLURB @QSIL QWV\Y KTEXP DB[SD DADR@ Z[NM] [R@]C HLEZB 
] @\[EN YRWDX KLDAW VLHCY M]ZR@ XKRLT PFB]@ MAITV Z\CON IZFB[ STDAD V\]CE 
] NIWFJ ]A@NM TWHYK SEXP@ ZBPMA IRV\Y A@NQY FB[SS MUTWF \[IM] W@ZBP 
] RYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRYRY
] 
] :-)

Who is this MacHinery person anyway?

Paul
--
Paul Leyland <pcl@oxford.ac.uk>          | Hanging on in quiet desperation is
Oxford University Computing Service      |     the English way.
13 Banbury Road, Oxford, OX2 6NN, UK     | The time is come, the song is over.
Tel: +44-865-273200  Fax: +44-865-273275 | Thought I'd something more to say.
From: keith.willis@almac.co.uk
Newsgroups: sci.crypt
Subject: are des restriction e
Date: 10 Sep 92 12:30:52 GMT
Distribution: sci
Organization: ALMAC BBS Ltd



In article <1992Sep7.051916.16197@qualcomm.com>, 
        karn@servo.qualcomm.com (Phil Karn) writes:

PK>   Obviously only Americans are capable of taking an algorithm
PK>   description and turning it into working code. The next thing you know,
PK>   the US government will be revoking the passports of anyone suspected
PK>   of being able to program...

        And the international gravy train for those of us living
        outside the 'Land of the Free', rolls resolutely on <g>

$SET MODE /WAFFLE=ON_TOPIC


---
 ~ PQ 2.15 194 ~ 
----- PGP v1.0 --- public key ------ keith.willis@almac.co.uk

section 1 of uuencode 5.15 of file keith.pub    by R.E.M.

begin 644 keith.pub
MF;``0A8U*BI7:6QL:7,L($ME:71H("`@("!K96ET:"YW:6QL:7-`86QM86,N
M8V\N=6O>`^5^EYDE<?D,&>2!MNH>T+*/9_\.1-=WDSF_;.]<THIK/X]5R[T"
MY41S!CX_EE1=E;&V8PN<9*5?9],UV,J/(7S=`C-3S+>*+7`1T[8-8Q*@_@"I
LIR(5-E1Z*\@=1W42HU<X*^WG'GXL8#R0C@;=](&@IQ>0#2,4G@F9FS<%`!$%
`
end
sum -r/size 40780/274 section (from "begin" to "end")
sum -r/size 57997/179 entire input file
--
ALMAC BBS Ltd. 0324-665371
Dos based USENET access,  call for details!
Newsgroups: sci.crypt
From: mccurley@cs.sandia.gov (Kevin S. McCurley)
Subject: Re: SHS/SHA source code + random thoughts
Organization: Sandia National Laboratories, Albuquerque, NM
Date: Sat, 12 Sep 92 03:39:25 GMT

In article <1992Sep11.090308.26993@cs.aukuni.ac.nz> pgut1@cs.aukuni.ac.nz (Peter Gutmann) writes:

>Then in article <1992Sep4.060230.28313@cs.aukuni.ac.nz> tall men in dark
>    coats forced Kevin S. McCurley <mccurley@cs.sandia.gov> to write:

followed by some highly relevant technical information.  I assume that
Peter was trying to be funny here, but for the record, no one forces
me to say anything regarding this, nor has anyone tried to put words
in my mouth regarding any other cryptographic issues.

Even if they had, the US government is just as likely to employ short
blonde females as tall dark men!

Kevin McCurley
From: unruh@physics.ubc.ca (William Unruh)
Subject: Re: RSA's FAQ
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Tue, 15 Sep 1992 23:02:09 GMT


Having not read the FAQ, just the topic titles this sounds more like an
advert for RSA than a discussion of cryptography as advertised. To those
whove read it, has it got more in it than advertising?

Newsgroups: sci.crypt,alt.security,comp.security.misc,local.crypto
From: karger@osf.org (Paul A. Karger)
Subject: Re: ATM fraud
Organization: Open Software Foundation
Date: Tue, 8 Sep 1992 16:46:52 GMT

In article <1992Sep8.115050.8694@cl.cam.ac.uk>, rja14@cl.cam.ac.uk (Ross Anderson) writes:

|> This sort of `false terminal attack' was first reported in the USA in
|> about 1988. You'd think the banks would warn people about it, but
|> instead they seem determined to introduce PIN pads in retail outlets 
|> here. The idiots seem to believe that this will cut fraud from the 
|> current \pounds 200 million plus, but in practice it means that every 
|> bent merchant in the country will be able to collect card and PIN data.

This type of attack has been going on for a lot longer than that, and it
doesn't require a fraudulent merchant to perpetrate.  There were a couple of
cases in the late 70s/early 80s of someone building a bogus ATM machine and
placing it directly in front of a real bank ATM machine.  I believe one case
was in New York and the other in Italy, but my memory may be flakey on this 
point.

This points up the need for one of the B2 and up security measures from
the orange book - namely trusted path.  There must be a way for the user
to authenticate to the system, but there must also be a way for the system
to authenticate itself to the user, so that user knows that this is the
real bank ATM or terminal or workstation or whatever...
Xref: sparky sci.crypt:3231 alt.security:4367 comp.security.misc:1249