NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/risks/128

Internet Message Format | 1992-11-17 | 30.3 KB

Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!CSL.SRI.COM!risks
From: [e-mail] (RISKS Forum)
Newsgroups: comp.risks
Subject: RISKS DIGEST 14.05
Message-ID: <[e-mail]>
Date: 17 Nov 92 02:34:38 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Distribution: world
Organization: The Internet
Lines: 704
Approved: [e-mail]

RISKS-LIST: RISKS-FORUM Digest  Monday 16 November 1992  Volume 14 : Issue 05

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

  Contents:
Voting fraud (is it an accident?) (Ray Todd Stevens)
Safe Conduct (Jonathan Bowen)
Retirement award trips up a crook (Ray Todd Stevens)
PINs and Needles (Dik Winter)
Re: "End-Running" Key Registration (Bob Frankston)
Re: Cellular Phones in Aircraft (Berry Kercheval)
Re: Voice mail systems (Jim Purtilo)
Radio to remote computer protocol design (Edward J. Huff)
Re: RISKS of technical people disengaging brain (Daniel Lance Herrick)
Re: Credit Thieves (and learning from mistakes) (Michael J. Zehr)
Re: Accountant's error catches thief! (D King)
Re: Caller-ID (yet again) (Greg Rose)
UNIX security Tutorials (7 Dec, San Jose) (Sun User Group Conference)
    (Nancy Frishberg)
Papers accepted for AUSCRYPT'92 (Yuliang Zheng)

 The RISKS Forum is moderated.  Contributions should be relevant, sound, in
 good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
 welcome.  CONTRIBUTIONS to [e-mail], with relevant, substantive
 "Subject:" line.  Others may be ignored!  Contributions will not be ACKed.
 The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
 especially .UUCP folks.  REQUESTS please to [e-mail].

 Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
 CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 14, j always TWO digits).  Vol i
 summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
 The COLON in "CD RISKS:" is essential.  "CRVAX.SRI.COM" = "128.18.10.1".
 <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

 For information regarding delivery of RISKS by FAX, phone [phone]
 (or send FAX to RISKS at 310-455-2364, or EMail to [e-mail]).

 ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
 Relevant contributions may appear in the RISKS section of regular issues
 of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: 12 Nov 92 12:39:21 EST
From: "Ray Todd Stevens" <[e-mail]>
Subject:  Voting fraud (is it an accident?)

Our voting machines are a series of buttons on the outside of a continuous
sheet of paper.  You can go page to page with buttons.  each button is supposed
to point at a candidate/proposal.  It didn't work that way.

When I went through the ballot I found several pages that pointed at the lines
between the selections, and not at a selection.  I found that it was not
possible to push the button for Clinton, but was possible to push the button
above Bush.  I also found that went I paged forward, and back that the lit
buttons didn't point at the people I had voted for.

I pointed this out to the election judges and was told that "They
only deal with the totals, and therefore it would all average out"

Ray Todd Stevens, Contractor, Resource Protection Dept NSWC Crane Div.
[e-mail]  [phone]  854-3294  854-3289

------------------------------

Date: Fri, 13 Nov 92 12:40:01 GMT
From: [e-mail]
Subject: Safe Conduct

The 12 November 1992 issue of the weekly UK newspaper "Computing" has a three
page spread (pp18-21) on safety-critical systems entitled "Safe Conduct" by
Clair Neesham. In particular, new piece of EC legislatation, the Machine Safety
Directive, comes into effect in the UK on 1 January 1993. This encompasses
software and if there is an error in the machine's logic that results in injury
then a claim can be made under civil law against the supplier. If negligence
can be proved during the product's design or manufacture then criminal
proceedings may be taken against the director or manager in charge.  There will
be a maximum penalty of three months in jail or a large fine.  (This actually
sounds rather low to me.) Suppliers will have to demonstrate that they are
using best working practice including, for example, risk analysis and project
planning. The DTI-funded (Department of Trade and Industry) Safety-Critical
Systems Club is helping to raise awareness of the issues in the UK with regular
meetings and a newsletter.  A knowledge of relevant standards is important
(e.g., ISO9001, 00-55 & 00-56, DO-178, ...). Formal methods (e.g., Z, VDM and
B) are cited as one way of improving matters, but judging from the "site study"
boxes in the article, there is still considerable scepticism in industry about
their applicability at the moment, due to lack of trained personnel, problems
of scaling up, worries about extra cost, etc.  However, they are seen as
promising for the future.
                                Jonathan Bowen, Oxford University

------------------------------

Date: 12 Nov 92 12:39:21 EST
From: "Ray Todd Stevens" <[e-mail]>
Subject:  Retirement award trips up a crook

I number of years ago I was called in as a consultant to look into a suspected
case of fraud.  The reason for the belief that there was fraud involved was
that one of their low paid clerks had retired, and at the end of the year they
give out attendance awards.  They wanted this person to pick up his "20 years
without a sick day" award at the awards banquet, and attempted to invite him.
They found out that this guy had been living it up as a jet setter.  Someone
decided to find out how he could afford it.  It was not hard to figure out.

This guy was in charge of all office supplies for the Corp (a large
multinational).  This meant that he was in charge of ordering and then
confirming receipt of supplies.  He was supposed to keep an inventory on hand,
(central management to the max) and ship out supplies as needed.  The supposed
control was the the office managers were supposed to confirm that they received
what he said he sent them.  He was able to set up a phony company and order
goods from it he then receipted in the goods, and include these in shipments.
If he had missed just one day he would never have been caught.

By the way he basically got a way with it.  I return for keeping his mouth shut
about where he got the money he got to keep all of the interest, and way not
prosecuted.

Ray Todd Stevens, Contractor, Resource Protection Dept NSWC Crane Div.
[e-mail]  [phone]  854-3294  854-3289

------------------------------

Date: Wed, 11 Nov 1992 02:28:13 +0100
From: [e-mail]
Subject: PINs and Needles

(Based on an article in Vrij Nederland of 31 October, 1992.)

For years the Dutch banks have stated that they do not store the PIN code
required for many transactions using cards.  They imply that if somebody
reports illegal use of the card plus PIN code this is only because the owner of
the card has not been careful enough with his code.  They also told us that
there is no way to calculate the code given an account number only.  And they
also imply that a 4-digit PIN code is sufficient for security (as many know,
this is not true).

It has now been revealed that some banks routinely tell customers their PIN
code if they did forget it.  There is one case on record where during a
criminal investigation the police wondered whether a particular number written
down by the person under investigation was the PIN code connected to a
particular account.  They just asked the bank for the PIN code for the account
and received it back, the number as written down was just the code in reverse.

More interesting is here that even though the banks do not store actual PIN
codes (and as such are technically correct in some of their statements), some
have the data available to calculate the code even if the card is not
available.

They still maintain the system is safe.

dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: [e-mail]

------------------------------

Date: Thu 12 Nov 1992 10:08 -0400
From: [e-mail]
Subject: Re: "End-Running" Key Registration

When I talk on cellular phones, I already take precautions by making
allusions to other events and taking full advantage of the shared context so
that the message is innocuous the the casual listeners. This is the norm for
aware people in any case where there is a concern about the possibility of
being overheard.  Teflon John wouldn't be caught dead (or would be dead if
caught?) being too direct over a potentially public (i.e. tappable) channel.
This technique works even without intent to be secret -- just listen to two
MIT students planning their courses for the following semester.

The real issue is exchanging large amounts of data or regular transmissions
such as financial transactions among a large community of users so that all the
information about the techniques is public and all that is hidden are the keys.

BTW, it has long been the case that encryping over Telex by using code words,
or even nonEnglish words, has been illegal in many countries.

------------------------------

Date: Thu, 12 Nov 92 15:30:46 PST
From: [e-mail] (Berry Kercheval)
Subject: Cellular Phones in Aircraft

Mr. Robert Gezelter writes in RISKS-14.04 about cellular phones being used "in
aircraft (at least those operating under Instrument Flight Rules)".

First of all, the FAA (Federal Aviation Administration) leaves the decision of
the use of electronic equipment in aircraft up to the operator of the aircraft.
This means, essentially, the aircraft's owner: either me, in the case of my own
plane, or the company operating the aircraft: American Airlines, for instance.

The frequencies that cellular phones operate on do not directly conflict with
aviation frequencies, but some poorly designed phones could emit RFI (harmonics
of the carrier, or IF frequencies for example) in frequencies that could
interfere with navigation equipment.  Usually this is not a problem, though, as
most avionics gear is tolerably well shielded.

Secondly, the FCC (Federal Communications Commission) is the one that bans
cellular phone use in aircraft, whether under Instrument Flight rules or not.
It turns out that when a cellular phone at, say, 20,000 feet tries to make a
call it will wake up cells for hundreds of miles around and badly confuse the
system, which is expecting to get a signal from only a few cells at once.

The blanket ban *is* due to cell overlap, then, and my guess is the reason
there is not an altitude restriction is that it's too hard to figure out; the
number of cells reached is a complex function of altitude, position of the
aircraft and cells, and the topography of the surrounding landscape.  I can
just picture the FCC bureaucrat saying ``Hell, that's too hard.  Let's just ban
'em all.''.
                                        --berry

------------------------------

Date: Thu, 12 Nov 92 09:33:57 -0500
From: [e-mail] (Jim Purtilo)
Subject: voice mail systems

[e-mail] wrote about the then-new voice mail system installed at
Maryland, and the problems which ensued when students discovered that all the
pass codes were set the same.  One lesson he suggested from this was to the
engineers, who should either make the codes different, or make a better attempt
to warn users about the situation.

The education needs to be given regularly to new employees and also visitors,
else they can become special targets of locals who already "know the system".
As case in point, I cite one of my own (many) experiences with the UM voice
mail system that CMARTIN mentions.  A few months ago I was given a new office,
whose previous occupant had been a prestigious visitor.  My own phone number
lagged behind the move by a few days, so I temporarily got use of phone account
of our visitor, Nancy Leveson.  Guess who didn't get the word to change the
default passcode!

Don't worry, Nancy, none of the messages sounded urgent.  :-)

I discovered you can learn a lot about someone by playing with their
intelligent phone system.  The "redial" button suggested a last user might have
ordered a carry out meal from Cluck-U-Chicken, a popular campus town eatery at
the time.  (If the place had used caller-ID like so many carry-out businesses
these days, then I suppose I could have just ordered the "usual" and found out
the previous user's tastes too.)  I thought it best not to see where the "speed
dialing" buttons got me.  But does anyone know of stock brokers or doctors
offices use caller-ID as a check for letting callers request a transaction or
access info?

CMARTIN did not report the most fun aspect of the voice mail system, which was
not generally open to students.  It was (notice past tense) "call pickup"....
intended, I presume, as convenience in a large office, it lets you answer a
call to your number from someone else's phone. After hearing a distinctive
ring, say while you are down the hall, you can hit one button and get the next
incoming call, picking it up.  Well .... as we know so much in this business,
"programming in the small" is not the same as "programming in the large".  The
call pickup feature does not scale, as we demonstrated empirically.  Some
thoughtful soul had spec'd call pickup in our new system, but, to save money
set up the entire CS department on the same "group". (We were told this was to
save money...  one paid per group, where "group" was a set of numbers within
which the pickup feature would work.)  The net result of this was that whenever
a professor got bored, he or she could play call-pickup-roulette ...  that is,
pick up the phone, punch the "pickup number" and see if anyone was calling
*anyone* in the building.  That is, you could intercept any incoming call with
lucky timing.  (I should note that John Gannon had demonstrated a keen
proficiency in this technique.)  The entertaining part of this was how you
handled the call, which I leave to the reader's imagination.

John has a fertile imagination, especially when egged on by his office
neighbor.  The feature didn't last long.
                                                     Jim

------------------------------

Date: 12 Nov 1992 07:55:05 -0500
From: [e-mail] (Edward J. Huff)
Subject: Radio to remote computer protocol design

Here is a chance to help get some equipment which will be widely used by the
public to work right from the start.  A friend of mine in the communications
industry is a member of a committee made of representatives of equipment
manufacturers.  They are not experts in designing or testing protocols, but are
designing several which will be used to accept messages from the public, carry
them between equipment made by the several companies, ending in a radio
receiver interfaced to the end user's computer.  If things go as they have in
the past, the protocols may be far from robust.  I am not identifying the
parties involved, and I hope that none of them take offense.  None is intended.
Learning to design protocols is not so easy.  Just being smart is not enough.

No doubt the "obviously difficult" parts, like the radio forward error
correction, will be done properly.  It is the "easy" parts involving
asynchronous communications that are likely to be defective in nonobvious ways.
One likely defect is that not every manufacturer's equipment will work properly
with the others.  This is a source of cost, and is the primary reason the
question of validating the equipment and protocols came up.  But of course, if
that sort of defect can arise, probably others which cause the public harm
might also arise.

Anyway, I will capture and forward any e-mail I receive on the subject to the
committee.  Maybe they can be persuaded to publish the protocols in a suitable
Usenet newsgroup, or elsewhere, for comment.  Maybe they can also be persuaded
to make eavesdropping difficult.  Recommendations of books, papers, testing
software, or qualified experts, is solicited.

The correct reply address is "[e-mail]"

------------------------------

Date: Fri, 13 Nov 92 12:26:35 EST
From: ICCGCC.dnet![e-mail] (daniel lance herrick)
Subject: RISKS of technical people disengaging brain

>It's already a cliche, but it's still true: when cryptography is outlawed,
>only outlaws will use cryptography. (And no, I *don't* believe the same
>is true for guns.)

Realizing that anyone who wants it can recover it, I have excised the signature
from this quotation because the author only made himself a representative of a
large class of fuzzy thinkers when he wrote it.

Consider the proposition:

If X is outlawed, then only outlaws will {have|use} X.

The hypothesis of that proposition is merely a statement that some legislative
body has declared the consequent to be true.  The proposition is a tautology,
true for all possible values of the variable X.

In particular, it is true for typewriters.  I believe the samizdat caused at
least one legislative body to substitute typewriter into the proposition for X.
It is true for photocopiers.  It is true for orange peels, though I don't know
of any legislature that has outlawed orange peels.

Most of us are in professions where logic is of some importance.  It hurts
credibility to declare in public, "I *don't* believe" a tautology.

dan herrick     [e-mail]

------------------------------

Date: Wed, 11 Nov 92 14:13:08 -0500
From: [e-mail]
Subject: Re: Credit Thieves (and learning from mistakes)

Credit fraud is a particular concern of mine because I'm going through a
similar situation.  What I found interesting about the article posted by Mr.
Robinson was a parallel to previous well known computer system failures.

In his October 20 talk at MIT, Mr. Neumann pointed out [some of the problems
of] not learning from our mistakes.  The 1980 ARAPANET failure and the 1990
AT&T failure were both caused by propagation of invalid packets across a
network (conceptually speaking, at least).  Cleaning up a corrupted credit
record is a similar problem.  Given the sharing of credit data, one has to
remove the incorrect information from all credit database simultaneously, or
it's likely to spread throughout the system again!

In addition, there's a security risk: the owner of any credit database can
insert faulty information and it will then be propagated throughout the system.

michael j. zehr

------------------------------

Date: Wed, 11 Nov 92 13:24:30 GMT
From: [e-mail]
Subject: Re: Accountant's error catches thief! (RISKS-14.03)

>>  ...  Eventually a screw-up elsewhere in the system
>>  forced a thorough enough audit to plug the hole for one set of
>>  transactions, leading to the transgressor's arrest]

The error, of course, had no essential role in catching the embezzler.  What
had to happen is that occasionally the accounting thoroughness had to far
exceed the bounds of cost-effectiveness.

The random process is all too often an error of some sort, but i understand
that banks do an extreme audit on each branch every six months or so, at random
times.
                                        -dk

------------------------------

Date: Wed, 11 Nov 92 14:01:26 +1100
From: "Greg Rose" <[e-mail]>
Subject: Re: Caller-ID (yet again)

I just thought that readers of RISKS might like to know that IBM Australia has
a newly installed phone system that shows the calling number much of the time.
There has been no public comment (that I have seen) about the availability of
such information, or any way to turn it off. Most people I have talked to don't
know that the feature is available.

I spoke to our Telecom representative. Both ACCI and IBM Australia are ISDN
customers, and Caller-ID is a standard feature of ISDN.  Individual customers
get to enable or disable outgoing caller identification at the time they get
the service. By default the outgoing information is the phone number, but the
PABX can be programmed to send alphanumeric information, such as the caller's
name!  (According to the techie I talked to, most ISDN customers do allow their
identification information to go out, although some don't.  Either way, the
customer has to specifically address the question.  ACCI allows the Caller-ID
information even though our own handsets don't have display capability.)

Caller-ID for non-ISDN customers is technically available on most newer
exchanges, but AUSTEL, the regulatory authority now that Telecom has
competition, has not yet allowed general access until they address the privacy
issues.

I was impressed by this answer, both that it seems Australia is addressing the
issues pro-actively rather than waiting for a hoo-haa to occur, and also
because it was not particularly difficult to get the information.

Greg Rose                 Australian Computing and Communications Institute
[e-mail]                                              [phone]

------------------------------

Date: Thu, 12 Nov 1992 20:00:01 GMT
From: [e-mail] (Nancy Frishberg)
Subject: Tutorials (12/7, San Jose) - UNIX security (Sun User Group Conference)

If you're concerned about UNIX security, you might plan to be at the
Sun User Group Conference (San Jose Convention Center) on Monday,
December 7, 1992. The Conference and Exhibition extends through Thursday.

In the all-day tutorial "Advanced Unix Security",  Matt Bishop
(Dartmouth University) will examine four areas critical to the
functioning of secure Unix systems: user authentication, management of
privileges, defending against malicious logic, and networking.

Concurrently Brent Chapman (Great Circle Associates) will lead
a morning session on "Preparing for Disaster" and Bob Baldwin (Tandem
Computers) will answer the question "Why have Computer Security?" during
the afternoon.

Special offer: 5 full conference registrations (each includes a day of
tutorial) for the price of 4 when preregistering with a single payment.

Other full-day tutorials:
* Sun Network Debugging (Smoot Carl-Mitchell, Texas Internet Consulting)
* Topics in Perl (Tom Christiansen, Convex Computer Corporation)
* Programming in POSIX (Jeffrey S. Haemer, Canary Software)
* UNIX Programming Tools (Kenneth Ingham, consultant)
* The Internet and its Protocols (William LeFebvre, Northwestern University)
* Introduction to UNIX System Administration (Dinah McNutt, Tivoli Systems)
* Integrating C Code and Xt Widgets (Craig Rudlin, MD, Medical Software and
  Computer Systems)

If you just want to go to the exhibits, ask for a free show-only pass.

To get more information by email about these tutorials, the technical program,
or exhibits at the Sun User Group conference, send requests to [e-mail] .

You will receive the full tutorials and program description with
registration information.  Or call 1-800/727-EXPO.  (Outside the U.S.,
use 512/331-7761 (voice) or 512/331-3950 (FAX).)

Nancy Frishberg, Sun User Group.

------------------------------

Date: Fri, 13 Nov 1992 14:57:16 +1100
From: Yuliang Zheng <[e-mail]>
Subject: Papers accepted for AUSCRYPT'92 -- Schedule

        MONDAY, 14TH DECEMBER 1992

Session 1: AUTHENTICATION AND SECRET SHARING I

(9.00-9.50)
Threshold cryptography (invited talk)
Y. Desmedt (University of Wisconsin-Milwaukee, US),

(9.50-10.10)
Authentication codes with perfect protection,
L. Tombak, R. Safavi-Naini (University of Wollongong, Australia)

(10.10-10.30)
Practical proven secure authentication with arbitration
Y. Desmedt (University of Wisconsin-Milwaukee, US),
J. Seberry (university of Wollongong, Australia)

Session 2: AUTHENTICATION AND SECRET SHARING II

(11.00-11.20)
Authentication codes under impersonation attack,
R. Safavi-Naini, L. Tombak (University of Wollongong, Australia)

(11.20-11.40)
Cumulative arrays and geometric secret sharing schemes,
W.A. Jackson (Royal Holloway and Bedford New College, UK),
K.M. Martin (University of Adelaide, Australia)

(11.40-12.00)
Nonperfect secret sharing schemes,
W. Ogata, K. Kurosawa (Tokyo Institute of Technology, Japan)

(12.00-12.20)
A construction of practical secret sharing schemes
using linear block codes,
M. Bertilsson, I. Ingemarsson (Linkoping University, Sweden)

Session 3: SIGNATURES AND HASHING ALGORITHMS

(13.40-14.00)
HAVAL --- a one-way hashing algorithm with variable length of output,
Y. Zheng, J. Pieprzyk, J. Seberry (University of Wollongong, Australia)

(14.00-14.20)
On the power of memory in the design of collision
resistant hash functions,
B. Preneel, R. Govaerts, J. Vandewalle (Katholieke Univesiteit
Leuven, Belgium)

(14.20-14.40)
A practical digital multisignature scheme based on discrete logarithms,
T. Hardjono (ATR Communication Research, Japan),
Y. Zheng (University of Wollongong, Australia)

(14.40-15.00)
Group-oriented undeniable signature schemes without
the assistance of a mutually trusted party,
L. Harn (University of Missouri-Kansas City, US),
S. Yang (University of Science and Technology of China, PRC)

Session 4: THEORY OF S-BOXES

(15.30-15.50)
Highly nonlinear 0-1 balanced Boolean functions satisfying
strict avalanche criterion,
X.M. Zhang, J. Seberry (University of Wollongong, Australia)

(15.50-16.10)
Linear nonequivalence versus nonlinearity,
C. Charnes, J. Pieprzyk University of Wollongong, Australia)

(16.10-16.30)
Constructing large cryptographically strong S-boxes,
J. Detombe, S. Tavares (Queen's University, Canada)

             TUESDAY, 15TH DECEMBER 1992

Session 5: CRYPTANALYSIS

(9.00-9.50)
Wire tape channel (invited talk)
V. Korjik (Bronch-Bruevitch Technical Communications University,
St Petersburg, Russia)

(9.50-10.10)
Cryptanalysis of LOKI91,
L.R. Knudsen (Aarhus University, Denmark)

(10.10-10.30)
Cryptanalysis of summation generator,
E. Dawson (Queensland University of Technology, Australia)

Session 6: PROTOCOLS I

(11.00-11.20)
Secure addition sequence and its application
on the server aided secret computation protocols,
C.S. Laih, S.M. Yen (National Cheng Kung University, Taiwan)

(11.20-11.40)
Subliminal channels for signature transfer and their
application to signature distribution schemes,
K. Sakurai (Mitsubishi Electric Co., Japan),
T. Itoh (Tokyo Institute of Technology, Japan)

(11.40-12.00)
A practical secret voting scheme for large scale elections,
A. Fujioka, T. Okamoto, K. Ohta (NTT, Japan)

(12.00-12.20)
Privacy for multi-party protocols,
T. Satoh, K. Kurosawa (Tokyo Institute of Technology, Japan)

Session 7: PROTOCOLS II

(13.30-13.50)
New protocols for electronic money,
J.C. Pailles (SEPT, France)

(13.50-14.10)
Modeling and analyzing cryptographic protocols using Petri nets,
B.B. Nieh, S.E. Tavares (Queen's University, Canada)

(14.10-14.30)
On verifiable implicit asking protocols for RSA computation,
T. Matsumoto, H. Imai (Yokohama National University, Japan),
C-S. Laih, S-M. Yen (National Cheng Kung University, Taiwan)

(14.30-14.50)
Modified Maurer-Yacobi's scheme and its applications,
C.H. Lim, P.J. Lee (Pohang Institute of Science and Technology, Korea)

Session 8: SEQUENCES

(15.20-15.40)
The vulnerability of geometric sequences based on
fields of odd characteristic,
A. Klapper (University of Manitoba, Canada)

(15.40-16.00)
A fast cryptographic checksum algorithm based on stream ciphers,
X. Lai, R.A. Rueppel, J. Woollven (R^3 Security Engineering,
Switzerland)

(16.00-16.20)
An approach to the initial state reconstruction of a clock-controlled
shift register based on a novel distance measure,
M. Mihaljevic (University of Belgrade, Yugoslavia)

(16.20-16.40)
Construction of m-ary de-Bruijn sequences,
J.H. Yang, Z.D. Dai (Academia Sinica, China)

     WEDNESDAY, 16TH DECEMBER 1992

Session 9: PSEUDORANDOMNESS

(9.00-9.50)
Information technology security standards (invited talk)
J. Snare (Telecom Research Laboratories, Australia)

(9.50-10.10)
Non-interactive generation of shared pseudorandom sequences,
M. Cerecedo, T. Matsumoto, H. Imai (Yokohama National University, Japan)

(10.10-10.30)
A generalized description of DES-based and Benes-based
permutation generators,
M. Portz (RWTH Aachen, Germany)

Session 10: ODDS AND ENDS

(11.00-11.20)
Prime generation with the Demytko-Miller-Trbovich algorithm,
L. Condie (University of New England, Australia)

(11.20-11.40)
Construction of feebly-one-way families of permutations,
A.P. Hiltgen (Swiss Federal Institute of Technology, Switzerland)

(11.40-12.00)
On bit correlations among preimages of "many to one" one-way functions,
K. Sakurai (Mitsubishi Electric Co., Japan),
T. Itoh (Tokyo Institute of Technology, Japan)

(12.00-12.20)
A fast cascade exponentiation algorithm and its
application on cryptography,
S.M. Yen, C.S. Laih (National Cheng Kung University, Taiwan)

Session 11: PUBLIC KEY CRYPTOGRAPHY I

(13.30-14.20)
Public key generation --- state-of-the-art (invited talk)
P. Landrock (Aarhus University, Denmark)

(14.20-14.40)
The design of a conference key distribution system,
C.C. Chang (National Chung Cheng University, Taiwan),
T.C. Wu (National Chiao Tung University, Taiwan),
C.P. Chen (National Chung Cheng University, Taiwan)

(14.40-15.00)
Public-key cryptosystem based on the discrete logarithm problem,
L. Harn (University of Missouri-Kansas City, US),
S. Yang (University of Science and Technology of China, PRC)

Session 12: PUBLIC KEY CRYPTOGRAPHY II

(15.30-15.50)
Elliptic curves over Fp suitable for cryptosystems,
A. Miyaji (Matsushita Electric Industrial Co., Japan)

(15.50-16.10)
New public-key cryptosystems based on factorization of finite groups,
M. Qu, S.A. Vanstone (University of Waterloo, Canada)

(16.10-16.30)
The probability distribution of the Diffie-Hellman key,
C.P. Waldvogel, J.L. Massey
(Swiss Federal Institute of Technology, Switzerland)

(16.30-16.50)
A modular unit based on systolic arrays,
J. Sauerbrey (Technische Universitat Munchen, Germany)

(16.50-17.10)
A comparison of key distribution patterns
constructed from circle geometries,
C.M. O'Keefe (University of Adelaide, Australia)

For more information, please contact

     Auscrypt'92 Secretary,      Office of Educational Services
     Queensland University of Technology,      G.P.O. Box 2434
     Brisbane, QLD 4001       Australia

     Fax:   [phone]         Phone: [phone]
     Email: [e-mail] (Ed Dawson)  or
            [e-mail]   (Bill Caelli)

------------------------------

End of RISKS-FORUM Digest 14.05
************************