List of Archived Posts

2002 Newsgroup Postings (09/12 - 10/12)

Handling variable page sizes?
Do any architectures use instruction count instead of timer
Handling variable page sizes?
The problem with installable operating systems
Handling variable page sizes?
Dumb Question - Hardend Site ?
Dumb Question - Hardend Site ?
Handling variable page sizes?
Backdoor in AES ?
DOS history question
Backdoor in AES ?
DOS history question
End of Moore's law and how it can influence job market
Do any architectures use instruction count instead of timer
fingerprint authentication
What is microcode?
A new e-commerce security proposal
A new e-commerce security proposal
Do any architectures use instruction count instead of timer
A new e-commerce security proposal
A new e-commerce security proposal
Original K & R C Compilers
DOS history question
DOS history question
Original K & R C Compilers
Original K & R C Compilers
Original K & R C Compilers
Root certificate definition
simple architecture machine instruction set
Computer Security Taxonomy
Root certificate definition
simple architecture machine instruction set
Computer Security Taxonomy
simple architecture machine instruction set
good asymmetric algorithm
simple architecture machine instruction set
(OT) acceptance of technology, was: Convenient and secure
Convenient and secure eCommerce using POWF
Convenient and secure eCommerce using POWF
Convenient and secure eCommerce using POWF
Wanted: the SOUNDS of classic computing
History of The Well was AOL
Wanted: the SOUNDS of classic computing
It is GNU/Linux, not just Linux
Beware, Intel to embed digital certificates in Banias
Wanted: the SOUNDS of classic computing
Encryption algorithm for stored data
updated security glossary/taxonomy
History of The Well was AOL
Help in Understanding requirement gathering, design,
Microsoft's innovations [was:the rtf format]
Microsoft's innovations [was:the rtf format]
Microsoft's innovations [was:the rtf format]
Authentication of others is a privilege, not a right
Microsoft's innovations
Beware, Intel to embed digital certificates in Banias
Microsoft's innovations
The next big things that weren't
The next big things that weren't
The next big things that weren't
The next big things that weren't
The next big things that weren't
The next big things that weren't
IBM Announcement
SSL certificate modification
SSL certificate modification
Tweaking old computers?
Tweaking old computers?
Tweaking old computers?
End to Moore's law and job market : conclusion
Tweaking old computers?
The next big things that weren't
Whatever happened to C2 "Orange Book" Windows security?
VLSI and "the real world"
InfiniBand Performance (Hey Pfister!)
New Book
Whatever happened to C2 "Orange Book" Windows security?

Handling variable page sizes?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Handling variable page sizes?
Newsgroups: comp.arch
Date: Thu, 12 Sep 2002 23:05:10 GMT

robertwessel2@yahoo.com (Robert Wessel) writes:

Actually I was asking about the common segment bit in the segment
table entry, which caused the TLB to ignore the STO for comparison
purposes for entries so tagged.  It existed precisely because common
areas were mapped in the same places in different address spaces.

I can't find the specific announcement when common segment bit came
into being ... it appears to probably be 3090.

I did find a reference to an MVS APAR/PTF 0267587 having to do with
running MVS Guest under VM dated 1983. The problem is that the common
segment bit is only applicable when MVS is running directly on the
bare hardware. When MVS is running as a VM guest ... STO-associativity
has to be honored for all TLB entries (since the single MVS's guests
actual segment tables aren't likely to be the only ones that exist in
the system).

here is the zap.

//nnnnnn JOB (6007,X003),nnnnnn,MSGLEVEL=1,MSGCLASS=O,CLASS=B,
// REGION=1024K,NOTIFY=nnnnn
//ZAP EXEC PGM=AMASPZAP
//SYSPRINT DD SYSOUT=
//SYSLIB DD DSN=SYS1.NUCLEUS,DISP=SHR

 FOR VM MVS GUEST, STBVR, TURN OFF USE OF COMMON SEGMENTS

 NAME IEAVNPX1 IEAVNPX1
 VER 0DA2 96026003        OI  SGTCB=1
 REP 0DA2 47000000        NOP
 VER 0DCE 96026003        OI  SGTCB=1
 REP 0DCE 47000000        NOP
//

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Do any architectures use instruction count instead of timer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Do any architectures use instruction count instead of timer
 interrupts  for context changes?
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 12 Sep 2002 23:14:39 GMT

peter@abbnm.com (Peter da Silva) writes:

You can if you have threads.

If you have threads you're not building asynchronous actions on top of
synchronous ones. Threads are an asynchronous mechanism.

The problem is threads are also a very complex mechanism. If all you're
trying to do is deal with asynchrony (rather than, for example, use
kernel threads for multiprocessing) there are good reasons to implement
threads at the user level on top of asynchronous system calls.  Among
other things, it avoids a lot of trips into the kernel, and that can
lead to better performance.

I really think both abstractions have their place.

as well as compare&swap like instructions for barrier semantics ...
as per recent thread about getting compare&swap into original 370.
http://www.garlic.com/~lynn/2002l.html#69

charlie had done a lot of work on fine grain locking for smp operation
and invented the compare&swap instruction as part of that work. CAS
was chosen as the mnemonic because they are charlie's initials
... then had to come up with the compare&swap part to match his
initials.

the guys that owned 370 architecture wouldn't put it into the
architecture purely on the basis of smp (typically kernel) support
... they said that we had to come up with other uses to justify
putting the instruction into 370. the result was the thread-safe
operations that were originally part of the programming notes for the
compare&swap instruction in the 370 POP ... and since been moved to
the appendix.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Handling variable page sizes?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Handling variable page sizes?
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 12 Sep 2002 23:32:12 GMT

"glen herrmannsfeldt" writes:

Using this STO as part of the TLB key, does a PTLB only purge
entries with the current STO?  It seems like it should.

the original 370 (red-book) architecture had

IPTE   purge page table entry
ISTE   purge segment table entry
ISTO   purge segment table origin
PTLB   purge table look aside

IPTE & ISTE turned on the respective "invalid" bits in the table entry
as well as purge associative entries in the TLB.

370/155 & 370/165 processors were already in the field and needed
hardware retrofit to add support for virtual memory. 165 engineers
claimed that to put in any of the TLB selective invalidates would
delay the introduction of 370 virtual memory by an additional six
months (they would need an additional six months just to come up all
the design and implementation for selective invalidate). VS2 claimed
that they would never invalidate more than five pages per second and
that would be done in a batch operation ... so that TLB invalidates
wouldn't happen more than once a second and PTLB might be slightly
more efficient. The result was that the selective invalidate
instructions were dropped from the original introduction of virtual
memory for 370. This was all 30+ years ago.

IPTE selective invalidate was later introduced with 3033s ... in part
because the paging rate had significantly increased by that time and
in part because of some smp syncronization issues (i.e. invalidating
all TLBs in a shared complex).

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

The problem with installable operating systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The problem with installable operating systems.
Newsgroups: alt.folklore.computers
Date: Fri, 13 Sep 2002 00:10:47 GMT

"Rostyslaw J. Lewyckyj" writes:

CP/67 implementing "savesys" around 1968, says nothing about how
someone got the idea to do such a thing.
Could it perhaps be from  the pre existance of such a facility, in the
field on straight single OS systems?
I realize that your experience is on the VM side.
Is that why you don't attempt to answer the question on a date for PCP?
Which was released to the customers first PCP or CP/40?
But all that aside, I am wondering when the technique might be
rediscovered  for the current crop of OSes for personal desktop
computers.

CP/40 was never released to customers ... it was an internal IBM thing.

I remember first doing assemblies with PCP on 360/30 ... i believe
os/360 release 6 in the 1966 time frame (I had a student summer job
for the university to design and implement a 360 monitor that
supported all the 1401 MPIO ur<->tape function for front end to 709).
I don't remember the date for PCP (other than release 6 had to have
been some time in '66). I got to design & implement my own monitor,
interrupt handlers, device drivers, asynchronous task handler, buffer
pool manager, etc.

after that i had a student job that included all responsibility for
the OS/360 operating systems at the university. I did the sysgens,
maintained the systems, etc. My first sysgen was a fairly straight
forward OS/360 release 9.5 MFT. I installed HASP on it and eventually
WATFOR, PLI, misc. other stuff. I started playing with re-arranging
all the system files and members within PDS to optimize thruput as
well as being able to do sysgens as part of standard production job
stream. I gave a couple presentations on this at SHARE and some kind
IBM'er in POK got me a bootlegged copy of a PDS member activity trace.
I could get a trace of all accesses to PDS members and sort it by
frequency and activity.

I expanded on this for my first OS/360 release 11 MFT sysgen ... I did
stage1 in the production workload and got the output of stage2 ... I
then created job cards for all the stage2 execution steps and
re-arranged the job sequence so that datasets would be allocated in
optimal seek distance order. I then went thru the move/copy member
steps and re-arranged all the move/copy statements to optimally order
PDS members within SYS1.LINKLIB, SYS1.SVCLIB, and some others. I gave
some presentations on this at SHARE.

Around the time I was starting on OS/360 release 14 MFT sysgen at the
univeristy, the CSC team showed up and installed CP/67 .... so now in
addition to getting to rewrite and re-org MFT and HASP ... I had
opportunity to do similar stuff for CP/67 and CMS.

My official student job was keeping the production os/360 systems
fully operational and fully tuned up. The CP/67 was just some toy play
stuff that I got to do on the side.

The following is an extract from a combined MFT14 and CP/67
presentation that I gave at fall '68 share meeting in boston.
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

most of the data in the referenced presentation is about MFT14 under
CP/67 .... and a lot of pathlength rewrite that I had done to the
CP/67 kernel. However, part of it also mentions that the "optimized"
MFT14 running stand-alone had thruput about 3 times that of an MFT14
done using the standard sysgen process (for the univeristy
workload). Furthermore, standard PTF & bug fix activity over a six
month period could possibly cut production thruput in half on standard
(non-CP/67) workload environment. PTFs tended to replace PDS members
and mess up the carefully tuned seek ordering. Sometimes it was
necessary to rebuild a system from scratch to regain the necessary
member ordering for optimal seek distance

My next sysgen was an OS/360 release 15/16 MVT system. I also put 2741
and tty terminal support into HASP and a context editor that
implemented the CMS editor syntax (for an early CRJE system). I had
also redone the CP/67 terminal support and put TTY/ASCII support into
it. It was still possible to generate PCP option up thru this period,
it just that I never did.

As a student, I spent most of my time supporting and working on
production OS/360 systems. I don't remember hearing about OS/360
fast-ipl until after head it from some people that had been dealing
with CP/67. It doesn't mean that it didn't happen ... but I don't
remember hearing about it either from IBM or at Share prior to the
CP/67 connection.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Handling variable page sizes?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Handling variable page sizes?
Newsgroups: comp.arch
Date: Fri, 13 Sep 2002 12:02:21 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

So it isn't necessary to increase the page size to get the disk
performance improvements that could also be obtained by increasing
the page size.  But increasing the page size would definitely and
considerably improve this performance.

however they did go to logical "big pages" ... basically swapping was
actually paging of "big pages" that were clusters of 4k pages in track
sized units (on 3380, 10 4k pages). a cluster could be composed
dynamically on the fly of pages that appeared to be referenced
together. on page fault ... the whole (track) big page was brought in

page out had some similarity to log-structured ... it used a moving
cursor and allocated to the closest available track. big-track area
was frequently ten times larger than expected allocated tracks (and
spread across multiple drives) ... and the garbage collection of
typical log-structured filesystem was eliminated since a track was
de-allocated as soon as it was read.

note all of this would further increase "impressive" paging rates
since sometimes there would be additional pages transferred in the
10-page set that wouldn't have been transferred if doing single page
operations, basically transfer bandwidth was traded off against disk
access latency, and there was always write on replace ... since there
was no "home" slot that could be re-used for non-changed replaced
page.

past vm/mvs big page stuff done in the '80s
http://www.garlic.com/~lynn/2001k.html#60 Defrag in linux? - Newbie question
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
http://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
http://www.garlic.com/~lynn/2002f.html#20 Blade architectures
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Dumb Question - Hardend Site ?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dumb Question - Hardend Site ?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 13 Sep 2002 03:57:20 GMT

efinnell@SEEBECK.UA.EDU (Edward J. Finnell, III , Ed) writes:

Extra reinforcment(s)! Money center banks have to be able to go 2 weeks without
external utilities and  survive 9.0 earthquakes. In the military it means surviving heavy
bombardment or first round tactical nukes. Each industry has a "vague definition".
There are both MIL and ISO specs. Searching on case hardened at www.nist.gov
returned 122 hits mostly with concrete and ablative fluids. Guess I first heard the
term in properties of materials and the iron-carbide phase diagram or maybe
it was George Raft......

there are also things about smoke in the building (processing for NYSE
exchange thot they had everything covered ... except one day a
transformer blew up in the basement and contaiminated the building
with PCB), tornadoes, hurricanes, floods (remember chicago merchantile
exchange being taken out by underground flood) etc.

also for operations doing transactions with the outside ... tends to
include things like diverse routing (lot of high availability
stuff). there is a joke about a hardened transaction site in europe
that had all the latest stuff ... except all telco came in thru a
single set of overhead lines ... lightning hit a nearby tree, tree
fell over and took out the telco lines ... site was out as much as if
the lightning had hit the computer itself. A "real" hardened site
would have had at least two sets of underground fiber entering the
building from opposite sides and connecting to totally different
central exchanges (this is for the backhoe scenario taking out all
communication); some will have underground telco and utilities coming
in from four different directions, each connecting to different
central exchanges and power substations.

telco central exchange buildings tend to have quite a bit of this
stuff (there was also something recently about AT&T selling off some
number of bunkered location/facilities).

and then when it still isn't sufficient you replicate somewhere
totally different for continuous availability (geographic
survivability & disaster survivability were terms we coined when we
coined when we were doing ha/cmp) ... aka not only may a site be
hardened but the service may be further "hardened" with geographic
replication.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Dumb Question - Hardend Site ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dumb Question - Hardend Site ?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 13 Sep 2002 11:46:52 GMT

werner.kuehnel@MANNHEIMER.DE (Werner Kuehnel) writes:

We use the German word for 'hardend' for a very secure site, in our case some
RS/6000 running AIX.
The procedure of 'hardening' includes (list is not complete):
- remove, disable or restrict services and daemons (inetd, syslogd, lpd,
sendmail, dns, dhcp, rcp, routed, snmp, ftp server)
- remove default user accounts
- use of stronger password rules
- use of timeout logoff
- setting filters, using IPsec

that was the other thing we looked at with ha/cmp in the late '80s
... detailed vulnerability analysis. random refs:
http://www.garlic.com/~lynn/99.html#48 language based exception handling
http://www.garlic.com/~lynn/2002e.html#58 O'Reilly C Book
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later
http://www.garlic.com/~lynn/subtopic.html#fraud risk, fraud, exploits
http://www.garlic.com/~lynn/subtopic.html#assurance assurance

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Handling variable page sizes?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Handling variable page sizes?
Newsgroups: comp.arch
Date: Fri, 13 Sep 2002 17:05:33 GMT

Anne & Lynn Wheeler writes:

note all of this would further increase "impressive" paging rates
since sometimes there would be additional pages transferred in the
10-page set that wouldn't have been transferred if doing single page
operations, basically transfer bandwidth was traded off against disk
access latency, and there was always write on replace ... since there
was no "home" slot that could be re-used for non-changed replaced
page.

note that even if a big-page fetch of 10 pages was only 50% useful ...
it would still be a win. as per prior postings about relatively disk
performance decline ... there was a factor of 10 more real storage and
at least a factor of two more disk transfer bandwidth (compared to
access performance). In effect there was both excess real memory and
excess disk transfer bandwidth compared to disk latency
access. Getting five "good" pages in a single access at a 100 percent
overhead (five "good" pages plus five "unnecessary" pages) would still
come out ahead ... compared to having five separate faults and five
separate accesses.
http://www.garlic.com/~lynn/95.html#10 virtual memory (a return to the past?)

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Backdoor in AES ?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Backdoor in AES ?
Newsgroups: sci.crypt
Date: Sat, 14 Sep 2002 01:55:04 GMT

"Roger Schlafly" writes:

You are holding DES to a high standard. About once a week, someone
discovers a buffer-overflow or similar bug that allows Windows
computers to be remotely controlled by an adversary.

but it was known how to not have buffer overflows over 30 years ago.
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation.

c string handling libraries did much to invent most buffer overflows

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

DOS history question

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DOS history question
Newsgroups: alt.folklore.computers
Date: Sat, 14 Sep 2002 18:38:18 GMT

tshoppa@wmata.com (Tim Shoppa) writes:

1) VMS didn't exist until 1978.  CP/M had existed several years by then.

2) First versions of VMS used 9.3, just like RSX-11 and its filesystem
ODS-1.

3) VMS doesn't run on a PDP-10.

there was some statement about the head of pok contributing heavily to
VMS ... this was not related to
http://www.garlic.com/~lynn/2001m.html#15 departmental server

in the mid-70s a number of the smaller, outlying operations were being
consolidated.

in '76, vm/370 development in burlington mall was being closed and the
group consolidated in endicott. at some point the head of POK realized
that MVS/XA development was dependent on the VMTOOL (a internal only
version of VM for providing XA virtual machines in support of
operating system development) and the people got told that instead of
moving to Endicott as part of product development they had to move to
POK to support the internal VMTOOL (and another round of VM product
being killed). Some number refused to moved to POK and instead left
IBM to go to work for DEC on VMS.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/

Backdoor in AES ?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Backdoor in AES ?
Newsgroups: sci.crypt
Date: Sat, 14 Sep 2002 19:01:03 GMT

Anne & Lynn Wheeler writes:

but it was known how to not have buffer overflows over 30 years ago.
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation.

c string handling libraries did much to invent most buffer overflows

there may have been something someplace about the 80s & 90s when all
knowledge from the golden ages was lost and the world descended into
chaos, darkness, buffer-overflows, and security vulnerabilities.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

DOS history question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DOS history question
Newsgroups: alt.folklore.computers
Date: Mon, 16 Sep 2002 18:21:13 GMT

Brian Inglis writes:

And also CP(/67?) and CMS from which batch submission, the
standard I/O devices: CON, RDR, PRT, PUN, drive letters, and
perhaps the virtual I/O interface (BDOS/BIOS) ideas may have
come.

an old CMS "EXEC" from cp/67 (aka '60s). cms used blank deliminators with
8+8+2 (where the +2 could default) for file identifiers.

In cms, "wait" was an internal kernel routine that assumed it was
called by program with all hex zeros as deliminating the parameter
list. It was possible to call it from exec processor by careful
editing and inserting hex zeros. The following file had a name of
"waitload exec". The command line processor actually fed into the same
command resolution as internal kernel calls or other command calls
(aka in cms it was actually possible to create files with name of
internal kernel routines and have the alias executed in place of the
real kernel routine). This capability was somewhat inhibited in the
time-frame of CMS for VM/370 (aka early '70s) where a new "fast"
kernel call procedure was implemented (it was expensive to force every
routine linkage thru the same lookup interface as was used for commad
entry from a terminal). It was still possible to do the hack to access
internal routines from command line ... but internal code linkages
started using a fast lookup bypass.

waitload exec:

&CONTROL OFF
CP SP C CL Y
-READ DISK LOAD
&IF &RETCODE EQ 0 &SKIP 1
WAIT RDR1RDR1 ........
-DSKLOAD DISK LOAD
CP SP C CL A

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

End of Moore's law and how it can influence job market

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: End of Moore's law and how it can influence job market .....
Newsgroups: comp.arch
Date: Mon, 16 Sep 2002 23:26:25 GMT

bjl@cs.purdue.edu (Bradley J Lucier) writes:

This seems to be a new meme that Microsoft has been working hard to implant
in people's mind---that software developed, for whatever reasons, from
public funds shouldn't "compete" with commercial producers.  I guess all you
guys would just rather have us bury it, or give it to you to sell.  Now,
that wouldn't be "corporate welfare", would it?

lots of current commercial products started as some sort of
gov. funded research in one way or another. i guess it depends on who
is benefiting and who is competing at any specific point in time. at
least for some of the gov. funded research and spanning multi-year
period ... there could always be some scenario where there was nothing
in the market place at the time gov. funding started ... and then gov.
funding continued over a period of time ... including when commercial
products started to appear (some of which had benefiting from
gov. funding).

slightly related from totally different thread
http://www.garlic.com/~lynn/2002l.html#70

referring to various legislation (mostly during the 80s) that promoted
being able to commercialize gov. funded stuff.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Do any architectures use instruction count instead of timer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Do any architectures use instruction count instead of timer
 interruptsfor context changes?
Newsgroups: alt.folklore.computers
Date: Tue, 17 Sep 2002 18:17:20 GMT

jmfbahciv writes:

Whenever a new supervisor was hired to supervise the TOPS-10 Monitor
Group, JMF's and TW's first task was to train the guy to focus on,
and only on, the two points.  As a result, the supervisor slowly
realized that he was working for JMF and TW..not the other way
around.

i remember some 30 years ago a manager noting that if they spent 90
percent of their time on (working for) the 10 percent most productive
members of the group that they typically increased the group's
productivity by a factor of five. the problem is that they rarely had
opportunity to do that, their time was typically consumed by the 50
percent least productive members of the organization ... and
frequently the PHBs were taken from this group (the members weren't
otherwise being productive ... so they spent the majority of their
time promoting themselves).

slightly related boyd comment
http://www.garlic.com/~lynn/2001m.html#16 mainframe question

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

fingerprint authentication

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: fingerprint authentication
Newsgroups: sci.crypt
Date: Tue, 17 Sep 2002 18:45:29 GMT

"Anton Stiglic" writes:

The  basic idea is that the fingerprint reader scans your finger in order to
get a digital representation of your finger (a fingerprint image).  The
fingerprint reader then typically sends this fingerprint image to some other
entity who will compare it with a template it has in order to authenticate
or identify a user (compares the minutiae, with some pre-determined
acceptable error rate) . This other entity can be a process in a smart card,
or could be a computer server.  The advantage about using a smart card
is that the fingerprint image does not need to travel via some network
cables, so you don't need to worry about confidentiality and integrity and
replay attacks on the messages that are sent.    Note that the comparison
of the fingerprint image and the template can be computationally expensive,
so you would need a smart card with a good processor.  The disadvantage
of storing the template in a smart card is that smart cards can get stolen
and probing techniques and other kinds of attacks can be used in order to
read the template.  Of course, if the templates are stored in a server they
have to be stored in some secure way, just like passwords need to be
stored securely.

frequently the scanner will have a chip that reduces the image to
minutia or something equivalent. this is most of the computationally
intensive operation. there are a number of "match on chip" strategies
that store one or more registered values and then compare a reading
with registered values.

an issue is that biometric readings in general tned to be quite fuzzy
(in fact an exact 100 percent reproduction could be indication of an
attack). most systems have various complex things having to do with
matching thresholds ... degree of match below the threshold are
rejected, while those above the match are accepted. this leads to all
the stuff about false negatives (valid biometric that are rejected)
and false positives (invalid biometric that are accepted).

transmitting the minutia to server-based infrastructure leads to lots
of issues. x9.84 devotes lots of time to server-based infrastructure,
not only the storage of the server registration ... but also the
transmission of the minutia readins as well as the whole end-to-end
infrastructure. smartcards have the advantage that attacks from
stealing a smartcard is extremely localized ... i.e. first a specific
smartcard is stolen and then attacked. compromise of a server-based
infrastructure can lead to exposure of hundreds of thousands of
minutia.

this is analogous to the whole shared-secret vis-a-vis secret
discussion. a registered template in server-based infrastructure is a
shared-secret based operation ... with the additional disadvantage
that it is a little more difficult to re-issue hundreds of thousands
of fingerprints (as composed to re-issuing hundres of thousands of
pins or account numbers). another comparison is the compromises of
payment card databases at merchants ... aka security proportional
to risk:
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk

also related to security proportional to risk, x9.84, biometrics in
transactions/operations involving value and server-based infrastructure is the
issue of threshold levels related to transaction value (possibly
higher threshold levels for higher transaction values). majority of
current cardbased infrastructures have difficulty with adjusting
threshold level to transactions .... except of the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

What is microcode?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What is microcode?
Newsgroups: alt.folklore.computers
Date: Tue, 17 Sep 2002 22:45:58 GMT

Sam Yorko writes:

I once took out my frustration on a wooden door.  The door won.  I was
in a cast for about a month, and the bones didn't heal straight.

once i had been in the machine room for possibly 36 hrs straight and
something went bad so i went to get the most recent backup tapes
... and the door was locked. I kicked it once ... it was solid fir and
it fractored along the grain(?) from top to bottom where the door
handle was. they kept the door around as a desk top on two 2-drawer
file cabinets (i think just as a reminder to me).

what was worse ... the backup tapes had been moved to a different room.

--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/

A new e-commerce security proposal

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A new e-commerce security proposal
Newsgroups: alt.computer.security
Date: Wed, 18 Sep 2002 02:54:46 GMT

zgene writes:

Thank you very much for sharing with me your ideas, which give me a lot of
enlightenings.  I am fully aware that this proposal might not be feasible
for e-commerce site.

Anyway, let's forget about this, and just focus on this question:  if the
access control of a Web server is based on checking a client's
certificate, does the Web server still need to register the client and ask
for his/her user name and password?

In other words, if Amazon.com bases its access control on checking a
client's certificate, is it still necessary for Amazon.com to register the
client and ask for his user name (in Amazon's case, e-mail address) and
password?

typically a merchant wants to know that they are going to get paid. so
what if a user registers a public key, a userid and password with a CA
... and gets back a certificate? how does that help the merchant
believe that they are going to get paid? will the CA pay the merchant?

what does amazon.com gets out of a userid & password? or a
certificate?

merchants typically want to know that they are going to get money.
register all the items you want that have nothing at all to do with
financial related purposes. it doesn't contribute a whole lot to
getting money to the merchant.

so maybe amazon.com ... as part of making the experience simpler for a
user ... pre-registers some amount of information ... especially
information related to amazon.com getting paid; they then place a
unique tag on that information ... a tag that is convinient for the
end user to reproduce but is also is reproduce securely. so that
information is tagged with some form of "id" ... that could be a
certificate id, a user id, a information id, a tag id ... any id. then
it is necessary to authenticate that an entity claiming that id is
really the same entity that registered that id.

So one way is a cookie ... the id goes into the cookie ... a shared-secret
(aka password, pin, key, etc, that happens to be registerd at
the same time as the original information) goes along with the ID. any
person claiming that id ... has to also reproduce the shared-secret
(aka password, pin, key, etc).

So another way is a public key. A certificate with no information
doesn't authenticate anything. There has to be some tie between the
certificate and the information that got registerd at amazon.com. So
lets say that at the same time the original information is registerd
... the certificate is registerd. The entity wanted to establish the
id at amazon.com that they had previously registerd ... sends
something that claims that they own that id ... and sends along a
digital signature to authenticate that they are the originators of
that entry. However, it isn't actually necessary to have a certificate
at all to perform this mechanism. When the entry with all the
information is originally created ... a public key (all by itself) is
included in that information ... and the creation transaction is
digital signed (prooving the entity posseses the corresponding private
key to the public key supplied).

So in this case ... it is possible to substitute a public key as
authentication material in place of password, pin, or some other
key. Any certificate is redundant and superfluous. example of this in
more detail:
http://www.garlic.com/~lynn/x959.html#aads

example of being able to use this method with respect to financial
transactions .... passing digital signature on the financial
transaction and not really needing certificates:
http://www.garlic.com/~lynn/x959.html#x959

some discussion of not needing certificates for SSL, server-based
authentication:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

other forms of using public keys in business processes that currently
are userid/password based:
http://www.garlic.com/~lynn/subtopic.html#radius

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

A new e-commerce security proposal

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A new e-commerce security proposal
Newsgroups: alt.computer.security
Date: Wed, 18 Sep 2002 19:00:44 GMT

zgene writes:

I think in my proposal, the merchant does not have to maintain a customer
database, because the certificate that the customer provides bears all the
necessary information for the merchant to get paid.  For example, the
certificate can have such important information:

Certificate Holder's Legal Name
Mailing Address
Credit Card Number
e-mail Address
Telephone Number
Employer
Social Security Number
Date of Birth
Gender

So on and so forth.

Thus, if a customer wants to place an order from, say, Amazon.com,
Amazon.com will retrieve from his certificate the customer's name, mailing
address, credit card number (desirably only the last 4 digits) and such
and such for him to verify, and if the customer says "yes", Amazon.com
goes ahead and takes the order.  It gets paid, no hassle.

What do you think?

all of that information represents serious privacy issues .... it is
one of the reasons that even simple x.509 "identity" certificates
(containing small subset of what you propose) were cut back by
financial institutions to simple relying-party-only certificates
... containing only account number and public key. Even a small subset
of the above example information you present is a horrible privacy
problem.

lets hypothesis that once a merchant ... or anybody else ... ran
across such information ... would they cache it someplace for future
reference (aka customer profiles stuff)? the only way that I know
where that might be succesful is if it was totally impossible for the
merchant/others to actually read the information. if it was totally
impossible for a merchant to access such information (say encryption)
... one then claims that it is superfluous to actually send it to the
merchant (this is the trivial example showing that relying-party-only
certificates ... aka account number and public key ... are redundant
and superfluous).

one of the critiera given the x9a10 working group for the x9.59
standard was to preserved the integrity of the financial
infrastructure (including consumer/client privacy) for all retail
payments (credit, debit, stored-value), etc) in all environments
(internet, non-internet, point-of-sale, etc).

x9.59 refs:
http://www.garlic.com/~lynn/x959.html#x959

misc. past privacy postings
http://www.garlic.com/~lynn/subtopic.html#privacy

misc. past fraud postings
http://www.garlic.com/~lynn/subtopic.html#fraud

EU actually put out a directive that electronic payments should be as
anonymous as cash. having even a little bit of the information you
suggest in a certificate represents a horrendous privacy violation.

misc. postings regarding relying-party-only certificates (financial
institutions attempting to address the horrendous privacy problems of
even simple x.509 identity certificates):
http://www.garlic.com/~lynn/aadsmore.htm#pressign President Clinton digital signing
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capabilityh
http://www.garlic.com/~lynn/aadsm2.htm#techno digital signatures, technology experiments, and service operations
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#liex509 Lie in X.BlaBla...
http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
http://www.garlic.com/~lynn/aadsm5.htm#spki Simple PKI
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose11 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm11.htm#18 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#21 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002e.html#72 Digital certificate varification

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Do any architectures use instruction count instead of timer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Do any architectures use instruction count instead of timer
 interruptsfor context changes?
Newsgroups: alt.folklore.computers
Date: Thu, 19 Sep 2002 18:18:36 GMT

jmfbahciv writes:

Only five?  I'd expect higher.  Although...I guess a part of that
managing job is to stem rampant productivity, too.  So maybe
five is a good number.

i was once asked if i really needed to use as much computer time as
the whole rest of the organization; i offered to work fewer hours if
it was a problem.

i think that the claim was that management appropriately applied could
increase the productivity of the whole group by a factor of 5-10 aka
over & above what productity already was; and directly attributable to
positive management action ... and not compared to possible absolutely
worst management action.

corrollary was some line about the worst possible manager is somebody
who believe they know what they are doing.

A new e-commerce security proposal

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A new e-commerce security proposal
Newsgroups: alt.computer.security
Date: Thu, 19 Sep 2002 19:06:03 GMT

zgene writes:

Certificate holder's name
Mailing address
e-mail address

Will this be good enough.

A subtheme in all this is that identification and authentication
frequently get confused. It is possible to have strong authentication
and high level of confidence of action w/o requiring identity
information to be broadcast to huge number of locations. Somewhat
analogous to the discussion about security proportional to risk
... having any identity information in large (tens of millions) number
of locations that have little or no formal integrity controls ... aka
http://www.garlic.com/~lynn/2001h.html#61
it isn't just a matter of being able to harvest large amounts of
information for fraudulent financial transactions ... it is also just
having privacy information available at all

from identity information, merchant doesn't even know what the bank
account payment is or even if there is sufficient funds in any bank
account.

Also, the EU privacy guideline is even saying that the name on the
front (or in magstripe) of existing payment cards is a privacy
violation ... addresses even further aggravate that (address may be a
requirement for shipping goods but needs to be removed as requirement
for payment ... and there are now even anonymizers for physical good
shipment).

Identity is not suppose to be part of payment transaction at retail
point of sale (online or physical) .... not a lot of identity, not a
little bit of identity, just plain identity.

Part of the reason for eliminating (all) identity at point of sale is
privacy. The other part .... using reference of current day ISO8583
online transactions ... doesn't need identity to guarentee payment to
the merchant. The problem is actually even worse ... for the majority
of simple retail transactions ... if a merchant ever has to resort to
actually referring to name/address for payment ... they are loosing
money.

some about the current mechanism
http://www.garlic.com/~lynn/aadsm5.htm#asrn1
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn4

is derived from MOTO (mail-order, telephone-order) that does an online
transaction and uses name/mail-address as corroborating authentication
information as part of the online transaction (AVS auth trans).

issue is that the information is effectively shared-secret and can be
harvested and reproduced. the original MOTO assumed small additional
protection that there would always be a hardgood shipment to the
address of record verified in the online transaction. misc. harvesting
refs:
http://www.garlic.com/~lynn/subtopic.html#fraud

furthermore much of the information has to be kept around and
available at the merchant for subsequent business processes related to
the transaction (i.e. you just can't throw it away).

X9.59 mapped to ISO8583 basically tacks a digital signature onto an
existing auth trans (debit, credit, stored-value, etc, and in hardware
token can be done at online as well as point-of-sale) ... it preserves
all the real-time advantage to the merchant that they really know that
they have high probability of getting paid ... and eliminates some of
the weakenesses of the existing shared-secrets for authentication
(even ability to harvest just the account number and use it for
fraudulent transaction).

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

A new e-commerce security proposal

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A new e-commerce security proposal
Newsgroups: alt.computer.security
Date: Thu, 19 Sep 2002 22:47:34 GMT

zgene writes:

Certificate holder's name
Mailing address
e-mail address

let's ignore for the moment that above is effectively equivalent to
x.509 identity certificate ... as per previous posts, financial
institutions have determined that the propagation, distribution,
and/or emailing such information appended to every payment transaction
is privacy issue (whether or not the information is contained in a
certificate or not) ... and has led to the relying-party-only
certificates that only contain account number and public key (as per
the previous references to relying-party-only certificates). This is
analogous to moving towards payment cards that don't require name in
either the plastic or on the magstripe.

let's look at the idea of only needing to execute a commerce
transaction that contains just the above information ... the
merchant/relying-party gets the above ... validates that it is a good
certificate but (as per prior ref) doesn't keep or retain the
information.

applying a little KISS and transposing to the physical world ... I get
a gov. credential with my name, mailing address and e-mail address
(lets just say that it is called a drivers license). With this
credential, I can go into any store in the world, totally fill my
shopping cart, walk up to the check out counter and present my
credential. The clerk confirms my credential as being valid ... but
doesn't record any information from the credential. Furthermore, I
don't need to present any money or payment card ... or any other means
of payment; once the clerk validates that I have a valid drivers
license or other gov. credential ... I'm allowed to walk out with all
the goods w/o ever being required to pay for them.

previous posts in thread:
http://www.garlic.com/~lynn/2002m.html#16 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal

random past e-commerce related threads:
http://www.garlic.com/~lynn/aadsmore.htm#killer0 Killer PKI Applications
http://www.garlic.com/~lynn/aadsmore.htm#killer1 Killer PKI Applications
http://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO!
http://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
http://www.garlic.com/~lynn/aadsm2.htm#integrity Scale (and the SRV record)
http://www.garlic.com/~lynn/aadsm3.htm#cstech cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech2 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#ecomm Authentication in eCommerce applications
http://www.garlic.com/~lynn/aadsm3.htm#imicro Authentication in eCommerce applications
http://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
http://www.garlic.com/~lynn/aadsm5.htm#epaym "e-payments" email discussion list is now "Internet-payments"
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm6.htm#ppsem3 Payment Processing Seminars
http://www.garlic.com/~lynn/aadsm6.htm#terror5 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror9 [FYI] Did Encryption Empower These Terrorists? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#3dsecure 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm8.htm#rhose17 [Fwd: Re: when a fraud is a sale, Re: Rubber hose attack]
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki10 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki13 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
http://www.garlic.com/~lynn/aadsm10.htm#limit2 Q: Where should do I put a max amount in a X.509v3 certificate?
http://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
http://www.garlic.com/~lynn/aadsm11.htm#16 international financial standards (ISO TC68)
http://www.garlic.com/~lynn/aadsm11.htm#17 Alternative to Microsoft Passport: Sunshine vs Hai
http://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
http://www.garlic.com/~lynn/aadsm11.htm#43  PKI: Only Mostly Dead
http://www.garlic.com/~lynn/aadsm12.htm#3 [3d-secure] NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#8 [3d-secure] 3D Secure and EMV
http://www.garlic.com/~lynn/aadsm12.htm#14 Challenge to TCPA/Palladium detractors
http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential downside of TCPA
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram:  Palladium Only for DRM]
http://www.garlic.com/~lynn/ansiepay.htm#aadsach NACHA to Test ATM Card Payments for Consumer Internet Purchases
http://www.garlic.com/~lynn/ansiepay.htm#x959bai X9.59/AADS announcement at BAI
http://www.garlic.com/~lynn/ansiepay.htm#scaads X9.59 related press release at smartcard forum
http://www.garlic.com/~lynn/aepay2.htm#otp X9.59 email purchase transactions (from lynn)
http://www.garlic.com/~lynn/aepay2.htm#fed Federal CP model and financial transactions
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
http://www.garlic.com/~lynn/aepay3.htm#riskaads AADS & RIsk Management, and Information Security Risk Management (ISRM)
http://www.garlic.com/~lynn/aepay3.htm#smrtcrd Smart Cards with Chips encouraged ... fyi
http://www.garlic.com/~lynn/aepay4.htm#comcert Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#miscdns misc. other DNS
http://www.garlic.com/~lynn/aepay6.htm#fraud Online Card Fraud Thirty Times That Offline
http://www.garlic.com/~lynn/aepay6.htm#idf Intel Developer's Forum ... fyi
http://www.garlic.com/~lynn/aepay6.htm#harvest harvesting of credit card numbers
http://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
http://www.garlic.com/~lynn/aepay7.htm#netsecure some recent threads on netbanking & e-commerce security
http://www.garlic.com/~lynn/aepay8.htm#ccfraud Almost Half UK E-Shopper's Fear Card Fraud (CC fraud increased by 50% in 2k)
http://www.garlic.com/~lynn/aepay8.htm#visapass VISA: All Your Password Are Belong to Us
http://www.garlic.com/~lynn/aepay8.htm#x959paper Credit Card Fraud and E-Commerce: A Case Study
http://www.garlic.com/~lynn/aepay10.htm#7 UNCITRAL Electronic Contracting Project
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aepay10.htm#20 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/aepay10.htm#22 PKI: An Insider's View
http://www.garlic.com/~lynn/aepay10.htm#42 FSTC Announces Proximity Payment Trial

http://www.garlic.com/~lynn/98.html#5 x9.59 electronic payment standard
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/98.html#48 X9.59 & AADS
http://www.garlic.com/~lynn/99.html#16 Old Computers
http://www.garlic.com/~lynn/99.html#79 Authentication in eCommerce applications
http://www.garlic.com/~lynn/99.html#80 Authentication in eCommerce applications
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card numbers safely
http://www.garlic.com/~lynn/2000g.html#48 Use of SET?
http://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001e.html#26 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#25 Root certificates
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#64 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce
http://www.garlic.com/~lynn/2001i.html#56 E-commerce security????
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#55 I-net banking security
http://www.garlic.com/~lynn/2001l.html#10 E-commerce security????
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002c.html#31 You think? TOM
http://www.garlic.com/~lynn/2002c.html#35 TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
http://www.garlic.com/~lynn/2002c.html#36 economic trade off in a pure reader system
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#35 PKI Implementation
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#18 Opinion  on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002e.html#40 Smart Cards
http://www.garlic.com/~lynn/2002e.html#73 Blade architectures
http://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002f.html#23 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#27 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002f.html#28 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002f.html#31 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#33 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#34 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002f.html#40 e-commerce future
http://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002g.html#83 Questions about computer security
http://www.garlic.com/~lynn/2002h.html#6 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#31 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
http://www.garlic.com/~lynn/2002j.html#18 Symmetric-Key Credit Card Protocol on Web Site
http://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002k.html#44 how to build tamper-proof unix server?
http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
http://www.garlic.com/~lynn/2002l.html#11 IEEE article on intelligence and security
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2002l.html#35 Cryptography

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Original K & R C Compilers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Original K & R C Compilers.
Newsgroups: alt.folklore.computers
Date: Fri, 20 Sep 2002 19:34:43 GMT

"Douglas H. Quebbeman" writes:

I must be missing something here; EBCDIC is an 8-bit code, right? So 'char'
shouldn't have any trouble being based on EBCDIC instead of ASCII, should
it? Most conversations about the difficulty of implementing C on non-ASCII
machines seemed to center more on the fact that those machines had character
sizes of something other than 8 bits.

As to the standard library, seems like all you need to do is supply a
table with the EBCDIC collating sequence to make strcmp() et. al. work
right.

there are little things that aren't in both character sets
... brackets, braces, dollar/cent signs, etc ... there is even some
issues about being able to do symmetric translation (aka if you
translate ascii->ebcdic and back again ... would you have the
original). i ran into this when i put tty support into cp/67 back in
the '60s. some of this led to us building pcm terminal controller for
ibm mainframe (out of interdata/3):
http://www.garlic.com/~lynn/subtopic.html#360pcm

there was a version of unix ported to a stripped down tss/370 kernel
that was used only inside at&t (it had a code name but it slips my
mind at the moment). random past refs:
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/2000.html#64 distributed locking patents
http://www.garlic.com/~lynn/2000.html#92 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001d.html#77 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#19 SIMTICS
http://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
http://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#17 mainframe question

a former co-worker did some extensive work with the compiler in the
early to mid 80s at a chip-shop porting a number of bezerkely chip
tools to vm/cms. he said that there was a large number of bugs that he
had to fix and also significantly rewrite the code-generation
optimizer. he was also the original beta-test for the c-compiler that
ibm chose to OEM for 370 ... which he also had to do significant
debugging on. past ref
http://www.garlic.com/~lynn/2001l.html#18 mainframe question

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

DOS history question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DOS history question
Newsgroups: alt.folklore.computers
Date: Fri, 20 Sep 2002 23:56:53 GMT

Eric Sosman writes:

The company still exists, more or less; http://www.atex.com/
is their Web site.  They've been sold and re-sold and merged and
re-merged several times, and it appears they've changed their
business focus more than a little.  Not having seen the place
in seventeen years I can't be sure, but I rather imagine the
old hot-rodded PDP-11s that once were their bread and butter may
now be just a fading memory of indigestion.

one of the things that started my wife and i on ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

in the late '80s was platform for the applications for one of their
large customers. following newsgroup posting is totally unrelated
that my wife and i were doing in the late '80s.

From: alexv@Atex.Kodak.COM (Alex Volanis)
Newsgroups: comp.newprod
Date: 1 Jul 92 19:27:54 GMT

NEW PRODUCT ANNOUNCEMENT: Ultra High Performace Fault Tolerant File
Server

Atex Inc., a Kodak subsidiary, a supplier of high availability
publishing systems has developed a Ultra high performance fault
tolerant NFS file server.  The product allows NFS client processes to
continue computing, in the event of any single point of failure of the
server or its network enviroment, even if the failure occured
mid-transaction.  This is accomplished without any modification to
client software.

The fault tolerant system is comprised of two 486 servers, one acting
as a primary server and the other as a secondary server.  Each server
runs Unix V.3.  A proprietary high speed interface connects the two
servers.  The dual servers eliminate all single points of failure.

Continuous diagnostic monitoring of all system interfaces, including
the required un-interuptable powersupply, enables the secondary server
to detect when to take over client processes from a failed primary
server.

A change journal of all data blocks modified since the primary server
went down is used to quickly bring the primary back into data
synchronization when it is returned to service.

A modified UNIX file system copies all file system data updates from
the primary server to the secondary server.  The dual data copies
obviate the need to commit file system data to disk.  The use of a
large buffer cache allows the file server to operate out of memory
with little or no disk reads or writes.  The result is large
improvement in UNIX file system and data base performance.  The
secondary server can be used in a read only mode for further
performance gains.

Atex is looking for a strategic partner to market the FTFS product and
will port the product to the operating system and hardware of the
selected vendor.

For further product information contact:

 Gordon Vinther
 Atex Inc.
 805 Middlesex Tpk.
 Billerica Ma., 01821
 U.S.A.

Tel: (508)670-3133

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

DOS history question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DOS history question
Newsgroups: alt.folklore.computers
Date: Sat, 21 Sep 2002 00:04:54 GMT

misc. other atex ...

Subject: "Can Atex Keep Its Proprietary Place in the Newsroom?"
 Source:  NY Times, 3/17/91, pg F4, John Markoff       <120 LINES>

 'A favorite is being superseded by desktop software'
 o Atex Inc., Billerica MA
   - once the world's premier maker of editorial and advertising systems
   - now under pressure as new technology and nimble competitors challenge
 o Bill Solimeno, Seybold Publishing Group (Media PA) analyst
   "They don't have a competitive product today and they need one quickly"
 o the news lately has been unrelentingly bad
   - 3 multi-million deals have gone to their chief competitor, S11 from
     Systems Integrators, Sacramento CA
     . Toronto Star
     . Washington Post
     . Westchester Rockland Newspapers
   - 2 weeks ago Atex announced the latest in their layoffs
     . they are now down to 600 employees, from 1985's 1,400
   - Time Magazine dropped their hardware service and support contract
     . Time was Atex's premier magazine customer
   - then Time announced plans at the Seybold seminar in Boston last month
     . they're going to create a division and compete with Atex
     . using Macintosh software technology from P.Ink (Germany)
 o Atex was founded in 1973 by Charles and Richard Ying
   - they developed their first system in an unheated loft in Lexington MA
     after graduating from MIT
   - Ray Toothaker, Advanced Technology Solutions pres. & former Atex exec
     "They would be a classic business school study case.
      The thing that's sad is they had the market and they let it go.
      It was a revolutionary business when it started.
      But Kodak slowed us down during a crucial period beginning in 1981.
      They brought in two chemists who knew nothing about high technology"
   - Kodak bought Atex from its founders for $77M

 Atex announced a new president in January, and a new strategy
 o they were developing a "big bang" product with IBM
   - instead they will go to a modular approach
   - they hope for more than a dozen products before yearend
 o Brian Lacey, Atex president and former Monotype (UK) head
   "This company has been in a deep freeze.
    We have to come out and show the what what this technology can do"
 o industry executives say Atex lost it's grip because:
   - they were slow to modernize, and
   - slow to recognize the power of the PC desktop publishing wave
     . Atex's business was based on a minicomputer system from DEC
     . minicomputer sales have largely sagged in the face of PC systems
 o the same features that were exclusive to Atex are available on desktops
   - plus features that newspaper publishers have been looking for
 o Atex may be too late to save it's still-considerable customer base
    - Paul Brainerd, Aldus (Seattle WA) president
      "It's a fundamental change in the business model.
       It's very difficult for a company to make this kind of transition
       when everything is changing in the way you do business"
     . he founded Aldus when he left Atex in 1984
 o Lacey took over with a mandate from Kodak and IBM
   - do whatever it takes to get back on track
 o Atex will adopt to industry hardware and software standards: Lacey
   - they'll also open their product line and work with other companies
   - industry officials are adopting a wait and see:
     . can Atex make progress while cutting headcount?
 o Atex is going to finish new technology projects for newsroom pagination
   - combining digitized photos and text on a computer screen and
     sending the result directly to the printing press
   - the New York Times announced a $22M plan in 1988
     . Atex and IBM would develop a customized system
   - there have been delays with the system, still...
     . installation of the text editing will take place this year
     . without the page layout feature
 o Jonathon Seybold, Seybold Report publisher
   "What you have is a company that has retreated into a corner.
    It's partly ATex's fault and partly its customers fault"
   - large newspapers had become too dependent on Atex
     'the thought of changing systems is too painful to consider'
 o Lacey believes Atex will stave off the desktop onslaught
   "It's very easy for passion to be forgotten when you're part of a large
    multinational company.  We have to bring passion back to what we do"

 Accompanied by a box, "Catching the '4th Wave'"
 o a lot of the talk at the Seybold seminar in Boston was about Time & P.Ink
   - selling sophisticated editorial production software to magazines & papers
 o P.Ink Software Engineering is a modular collection of software programs
   - they combine other commercial software...
     . Quark's Xpress page-layout program
     . a range of database managers, text editors, newswire viewers
 o the programs run on Apple Macintoshes
   - "IBMs RS/6000", Next's Nextstation and other Unix systems to be added
 o P.Ink allows a reporter or editor to write in one window...
   - while watching newswires in another...
   - and simultaneously running other Mac programs
   - it's the holy grail of publishing:
     . combining editing, pagination, and coordinating with dozens of
       other writers and editors
 o Gerald Lelivre, Time director of development for pre-press systems
   "I felt the software had potential, however they were a small German
    company that had no immediate intention of moving into the US.
    I couldn't afford to wait"
   - P.Ink is installed at 10 sites in Germany
   - at Leipziger Volkszeitung, P.Ink controls a system of 140 reporters
     and editors using Macintosh Ilc's

 Accompanied by a chart, "Atex's Stake Amoung Leading Newspapers"
        Newspaper        Circulation   System
 Wall Street Journal       1,835,713   Information Int'l
 USA Today                 1,325,507   Atex
 Daily News                1,194,237   Atex
 Los Angeles Times         1,107,823   Systems Integrators
 New York Times            1,068,217   Atex, Harris
 Washington Post             772,749   Systems Integrators
 Chicago Tribune             720,155   Hazeltine
 Newsday                     700,174   Atex
 Detroit News                690,422   Systems Integrators
 Detroit Free Press          626,434   Atex
 San Francisco Chronicle     560,640   Systems Integrators
 Chicago Sun-Times           535,884   Atex
 Boston Globe                516,031   Atex
 New York Post               507,568   Harris
 Philadelphia Inquirer       504,903   Atex

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Original K & R C Compilers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Original K & R C Compilers.
Newsgroups: alt.folklore.computers
Date: Sat, 21 Sep 2002 00:32:06 GMT

attached some random bit of information. note that the sss/370
(tss/370 kernel work to support running unix on top) for at&t had
started in 1979.

while the compiler ran on cms ... it & runtime libraries were
written using os-simulation (i.e. os/360 kernel api interfaces that
were simulated by cms). the chip-shop work mentioned in previous
reference
http://www.garlic.com/~lynn/2002m.html#21 original K & R C Compilers

in 1984, also undertook to rewrite the internals to use native CMS APIs

Date: 2 Nov 1983 20:46:32-EST (Wednesday)
To: C370_fans
Subject: C compiler for 370.

In reply to your question about C/370 licenses.

Source license is $2000. The contact at ATT for source licenses is:

      Max Wicker     (919) 697-6760
      ATT Technology Licensing
      PO Box 25000
      Greensboro, NC 27420

Binary licenses are $200 (one-time charge). However, ATT does not sell
any binary licenses directly.

You also understand that a C/370 license is independent of any other ATT
software license (e. g. a C/370 license does not imply any rights
with respect to UNIX software, nor does a UNIX license imply
any rights with respect to C/370 software).

Also include a statement of the steps that you will take to protect the
software from users who may not be aware of the above requirements,
such as use of read passwords, etc.

Please let me know if you find/fix any bugs (no flames, please).
For example, the pre-processor reports line numbers in source files
incorrectly, so it is necessary to look at the output of the C
Pre-Processor and do some arithmetic to find the errors reported by the
compiler. There are also problems in the libraries. For example, fseek()
does not seem to work, even in the limited way that is advertized.

There are differences in the ascii-to-ebcdic conversions used by
C/370 from the "standard" IBM translations (I will include VM2CC EXEC
which may help with this if you are trying to import C code).
I have also written routine to use the new PLIST form of command-line
arguments, mixed-case untokenized by CMS. See C_CMDS SCRIPT for info
and C370PRO C for how to install it.

Editing invisible characters on a 3277 is aided by macros FROMCC XEDIT
and TOCC XEDIT (TELLCC XEDIT documents how to type these characters).

______
UNIX is a trademark of Bell Laboratories.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Original K & R C Compilers

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Original K & R C Compilers.
Newsgroups: alt.folklore.computers
Date: Sat, 21 Sep 2002 03:05:33 GMT

Anne & Lynn Wheeler writes:

started in 1979. while the compiler ran on cms ... it & runtime
libraries were written using os-simulation (i.e. os/360 kernel api
interfaces that were simulated by cms). the chip-shop work mentioned
in previous reference
http://www.garlic.com/~lynn/2002m.html#21 original K & R C Compilers

in 1984, also undertook to rewrite the internals to use native CMS APIs

the other item that i had forgotten ... somebody reminded me ... was
that the bell runtime libraries originally had been almost totally
written in assembler. my former co-worker at this chip-shop
... rewrote them almost totally in C (besides various bug fixes,
performance optimizations and support native CMS API conventions).
he/chip-shop had some contract to provide the rewrite back to
bell/at&t.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Original K & R C Compilers

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Original K & R C Compilers.
Newsgroups: alt.folklore.computers
Date: Sat, 21 Sep 2002 03:55:25 GMT

also from some place ...


From: wheeler
Date: 7/13/87 07:37:05 PDT
Subject: high-level debugger;

A friend of mine who use to work for IBM is now working as an
independent consultant.  One of his contracts involved taking the
C-370 compiler that is available from bell labs.  and almost totally
rewritting it.  Another contract was for beta test site for the xxxxxx
compiler (oem'ed by ibm) where he rewrote and fixed a lot of the code.

One of the things he did was to write a CMS C asynchronous environment
that makes it very easy for writing service virtual machine
applications in C (i.e. simple multitasking and other functions).
Another thing he did was to write a super symbolic C debugger that
makes extensive use of the 370 PER hardware and is integrated into the
CMS asynchronous runtime environment (simplifying the problem of
poping into & out of the debugger while the program is running for
things like traces, reading files with symbol tables, saving context
information, etc).

I'm not sure about what if any plans there are to market many of these
enhancements available to xxxxxx (compiler oem'ed by ibm).  Most of
the work was done under contract to one of the VLSI design companies
where he also ported (to CMS) a large percentage of the available VLSI
design packages that are available on UNIX.  I have a feeling that the
company may feel that the resulting super-sophisticated CMS/C
development/production environment provides them with a significant
competitive advantage over the competition ...  CMS on a 3090 is
delivering much more mips than the run of the mill dec/unix machines
...  and the combined CMS/C environment ...  especially with the
debugger is providing a compariable environment (downside is the lack
of shared, hiearchial file system, ... service virtual machines are
providing most of the batch/fork support).

... snip ... top of post, old email index

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Root certificate definition

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Root certificate definition
Newsgroups: sci.crypt
Date: Sat, 21 Sep 2002 20:03:06 GMT

"Johan Stäck" writes:

In PKI, is there a commonly accepted definition of "root certificate"?

In searching the net, I find zillions of references to the phrase, but it
seems everyone assumes that it has a well defined meaning.
Does it?....

it tends to be related with hierarchical trust infrastructure where it
is the root of a specific trust hierarchy and is normally self-signed
(aka rather than having public key and related certificate contents
signed by some other private key ... it is signed by the private key
associated with the public key in the certificate). being the root of
the trust hierarchy it also tends to be obtained or made available by
some out-of-band mechanism ... not associated with the standard
certificate PKI protocol ... and as such, the process by which it is
obtained establishes a major trust component by which all of the rest
of the PKI hierarchy is based.

there has been a number of threads recently that the complexity
(non-KISS) of the PKI infrastructure (certfication authorities,
certification processes, intepretation of certificate options, etc),
is in itself a major vulnerability ... leading to exploits (analogous to
the significant number of exploits and vulnerabilities associated with
the semantics of the c-language string and buffer handling interfaces)
http://www.garlic.com/~lynn/subtopic.html#fraud

from:
http://www.garlic.com/~lynn/secure.htm

root

(I) A CA that is directly trusted by an end entity. Acquiring the
value of a root CA's public key involves an out-of-band procedure. (I)
Hierarchical PKI usage: The CA that is the highest level (most
trusted) CA in a certification hierarchy; i.e., the authority upon
whose public key all certificate users base their trust. (C) In a
hierarchical PKI, a root issues public-key certificates to one or more
additional CAs that form the second highest level. Each of these CAs
may issue certificates to more CAs at the third highest level, and so
on. To initialize operation of a hierarchical PKI, the root's initial
public key is securely distributed to all certificate users in a way
that does not depend on the PKI's certification relationships. The
root's public key may be distributed simply as a numerical value, but
typically is distributed in a self-signed certificate in which the
root is the subject. The root's certificate is signed by the root
itself because there is no higher authority in a certification
hierarchy. The root's certificate is then the first certificate in
every certification path. (O) MISSI usage: A name previously used for
a MISSI policy creation authority, which is not a root as defined
above for general usage, but is a CA at the second level of the MISSI
hierarchy, immediately subordinate to a MISSI policy approving
authority. (O) UNIX usage: A user account (also called 'superuser')
that has all privileges (including all security-related privileges)
and thus can manage the system and its other user accounts. [RFC2828]
(see also certificate, certification, key, Multi-Level Information
System Security Initiative)

root CA

The Certification Authority that is trusted by everyone. The root CA
issues digital certificates to other CAs. [misc] (see also
certification authority, public-key infrastructure)

root certificate

(I) A certificate for which the subject is a root. (I) Hierarchical
PKI usage: The self-signed public-key certificate at the top of a
certification hierarchy. [RFC2828] (see also certification, key,
certificate) root key (I) A public key for which the matching private
key is held by a root. [RFC2828] (see also key)

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

simple architecture machine instruction set

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: simple architecture machine instruction set
Newsgroups: comp.arch
Date: Sat, 21 Sep 2002 21:44:42 GMT

Roberto de Iriarte writes:

The only popular 32 bit ISA that i am aware of that had a documented 24 bit
address space (i.e the remaining bits where "reserved") is , as stated above,
the IBM 360/370 ISA, later extended to 31 bits (370XA), and currently to
64 bits (Z series)

small side note ... the 360 model 67 (mid-60s) had support for two
virtual addressing modes ... 24-bit & 32-bit. adding virtual
addressing & relocating hardware to 370 machines only provided for
24-bit virtual addressing. later with 811/xa on the 3081 ... 31-bit
virtual addressing mode was added to the 24-bit virtual addressing
mode. there were some considerations of why xa used 31-bit vis-a-vis
32-bit that was used in 360.

http://www.garlic.com/~lynn/93.html#14 S/360 addressing
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing not 32 bit?
http://www.garlic.com/~lynn/2001h.html#10 VM: checking some myths.
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002d.html#49 Hardest Mistake in Comp Arch to Fix

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Computer Security Taxonomy

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer Security Taxonomy
Newsgroups: comp.security.unix
Date: Sun, 22 Sep 2002 04:18:39 GMT

NSU writes:

I've been working on a Computer Security Taxonomy, so that people can
create large databases of computer security references.  I've looked
at COAST's security taxonomy and found it seriously lacking.  I was
wondering if anyone could point me at any other taxonomies (does the
Dewey Decimal System or Library of Congress have a good online
taxonomy for computer security?).  Thanks in advance.

of a kind:
http://www.garlic.com/~lynn/index.html#glossary

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Root certificate definition

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Root certificate definition
Newsgroups: sci.crypt
Date: Sun, 22 Sep 2002 04:13:52 GMT

as an aside ... note that the hierarchical PKI trust model somewhat
originated in the '80s targeting an offline, electronic environment
and in many ways patterned after the offline, non-electronic credit
card model of the '60s.

basically the offline credit card model had credentials (plastic
cards), trust hierarchy (brands & logos), and periodic credential
revokation lists. the hierarchical PKI trust model of the '80s in many
ways attempted to emulate this offline model but updated with
electronic technology.

one issue was that the offline, non-electronic credit card model
observed in the '70s that for things of value, the advent of online
electronic operations made it possible to economically transition from
an offline, non-electronic model to an online, electronic model
(completely bypassing a possible intermediate step of offline,
electronic paradigm). in many ways, the '80s hierarchical PKI trust
model was an enormous step backwards except possibly for no-value
operations. As a result there is sometimes something of an oxymoron
relating a trust PKI hierarchy to no-value operations.

The '80s niche that the trust PKI hierarchy was attempting to address
were no-value, offline email of the early '80s; aka a dialed
connection was temporarily made to the entities email post office,
email was exchanged, and the link was broken. The issue in processing
offline email was what authentication mechanism could be used?
... since it was not possible to directly contact an authoritative
reference (as happened in the transition to electronic, online
operation made by the payment card industry in the '70s for valued
opertions).

The alternative model that emerged for processing offline email was
PGP. Rather than explicitly performing out-of-band verification of
each and every trusted 3rd party root certificates ... and then
implicitly relying on the trust in the 3rd parties to correctly verify
all parties that you might wish to communicate with .... you
explicitly used out-of-band verification for every party that you
needed to have valued/trusted email.

The 3rd party trust model never really hit any big time use until SSL
and HTTPS for electronic commerce. This was somewhat a transition
scenario, while SSL & HTTPS were online models, there was a desire to
incrementally deploy pieces of the infrastructure before online
authoritative agencies were available. In fact, one of the major
reasons given for the deployment of SSL & HTTPS at all was various
itegrity concerns with regard to the existing online authoritative
agencies for domain name to ip-address lookup (i.e. the domain name
infrastructure).

Note, however that much of the SSL/HTTPS infrastructure can be
considered somewhat a facade overlaying the existing domain name
infrastructure because the domain name infrastructure, is in fact the
authoritative reference for domain name ownership ... aka when you
apply to a trusted third party certification authority for a domain
name SSL server certificate, the TTP-CA has to rely on the
authoritative agency responsible for domain name ownership ... the
domain name infrastructure (concerns about the integrity of this very
same infrastructure gave rise to having SSL/HTTPS originally).

In what might be considered an apparent catch-22, there are proposals
(including some needed by the TTP CA operations) to signifcantly
improve the integrity of the domain name infrastructure (in no small
part so that TTP CA operations can rely on it). Note however that
significant improvement in the integrity of the (online, realtime)
domain name infrastucture would largely negate the justification for
having SSL domain name server certificates.

random refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

simple architecture machine instruction set

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: simple architecture machine instruction set
Newsgroups: comp.arch
Date: Sun, 22 Sep 2002 19:34:44 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

While that is true at some levels, there are others at which it is
a VASTLY simpler architecture than the high-performance RISCs, let
alone the IA-64.  It may have been evil for the hardware people to
implement, but was relatively easy to code generate for.  To a great
extent, the RISC revolution merely made the complexity Someone Else's
Problem.

in fact, i was in a meeting circa '76 where that was stated as a
primary goal of 801 ... hardware/software complexity trade-offs
... hardware simplicity trade-off against software (& compiler)
complexity.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Computer Security Taxonomy

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer Security Taxonomy
Newsgroups: comp.security.unix
Date: Mon, 23 Sep 2002 14:19:11 GMT

NSU writes:

Wow, do you have tools to parse that?
I can't imagine transcribing it all.

basically my own RYO knowledge base .... a front-end parser to load
entries ... and then a glossary/taxonomy application that spits out
the html.

i also use it for the IETF RFC standards process .... as changes/additions
occur ... they are loaded and the index is regenerated ... but there is
also several consistency checks regarding change/addition are consistent
with the defined standards process for the internet
http://www.garlic.com/~lynn/rfcietff.htm

an idiosyncracy of the glossary/taxonomy application is that URL for
specific entries being automatically generated ... when the knowledge
base changes ... the generated URL for specific entries may change.

some notes regarding sources of the merged gtlossary/taxonomy
http://www.garlic.com/~lynn/index.html#glosnote

while some of the taxonomy structures are gleaned from the original
sources, i've tended to make significant additions.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

simple architecture machine instruction set

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: simple architecture machine instruction set
Newsgroups: comp.arch
Date: Mon, 23 Sep 2002 14:00:06 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Yes.  The papers that I saw proposing that the next step in hardware
design should be for ISAs that were designed for compiler code
generation (as distinct from manual coding or ease and efficiency
of implementation) were in the eaarly 1970s.  It never happened :-(

compiler was pl.8 ... which eventually saw some of its technology
migrate into some other compliers ... and CPr operating system. one of
the things simplified was the whole thing of protection domains,
system calls, etc. code was to be validated at compile and bind time
..  and then at run time there was effectively no differentiation
between application runtime library code and kernel runtime library
code.

the virtual memory segement registers were as accessable as general
purpose registers ... and it was as easy to change a virtual memory
register as it was to change a pointer/addressing register.  to some
extent this gave rise to statements about ROMP (pc/rt) being 40-bit
addressing (inverted tables, 32-bit addresses, 4bit segment register
selection, 28bit segment displacement, 12bit segment register values
...  12+28=40bits ... and then rios being 24+28=52bit addressing).

course nearly all of that started to evaporate when ROMP was
retargeted to unix platfrom instead of displaywriter followon
platform.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

good asymmetric algorithm

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: good asymmetric algorithm
Newsgroups: sci.crypt
Date: Mon, 23 Sep 2002 21:20:30 GMT

"Frank Leggett" writes:

Hi, just wanted to ask your advice on what asymmetric encryption algorithm
to use for a web-based data transfer (using TCP/IP to transfer data from one
place to another). Until now we've used blowfish and twofish (both symmetric
algorithms) but it's a problem that some clients lose their keys so we are
considering using a public/private key system. But we're uncertain how
safe/fast they are compared to symmetric algorithms (speed is next to
irrelevant)

SSL uses asymmetric for (symmetric, session) key exchange ... and then
uses symmetric key for that session. RFC 2246 discusses TLS and various
key exchange (authenticated, anonymous, rsa, diffie-hellman).

While blow/two fish aren't listed in the current ciphersuites the
following from RFC 2246, appendix A.5, pg. 54:

Note: All cipher suites whose first byte is 0xFF are considered
private and can be used for defining local/experimental
algorithms. Interoperability of such types is a local matter.

Note: Additional cipher suites can be registered by publishing an RFC
which specifies the cipher suites, including the necessary TLS
protocol information, including message encoding, premaster secret
derivation, symmetric encryption and MAC calculation and appropriate
reference information for the algorithms involved.  The RFC editor's
office may, at its discretion, choose to publish specifications for
cipher suites which are not completely described (e.g., for classified
algorithms) if it finds the specification to be of technical interest
and completely specified.

Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in SSL
3.

============================================================

also ...

RFC 3268

Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
Security (TLS)

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

simple architecture machine instruction set

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: simple architecture machine instruction set
Newsgroups: comp.arch
Date: Tue, 24 Sep 2002 02:06:17 GMT

J Ahlstrom writes:

What a good idea !
Software is so much cheaper to architect,
design and implement and to replicate, so much
easier to get correct, to modify and to
extend than hardware is.  (Isn't that
why they call it hardware?)  IIRC aggressively
optimizing compilers have always been the
way to get faster performance rather than
waiting for the next hardware implementation.

this has worked for things that can be predetermined and relatively
deterministic since the software/compiler is doing relatively early
binding. as hardware has gotten more capabilities it started adding
support for a lot more transient and less predeterminable
optimizations (say branch prediction).

there are some claims that risc/801 was in part a re-action to the
excessive complexity of FS project where everything and the kitchen
sink was being dropped into hardware ... supposedly one of the things
that killed FS was one report that claimed if a real FS machine was
implemented with the fastest 370 (195) technology then available at
the time ... its thruput would be that of a 370 less than 1/10th as
powerful (370/145).

another past issue was existance of legacy executables tightly coupled
to specific machine and lengthy conversion transition whenever
hardware changed. risc happened to come into its stride in a market
segment that was trying to get away from the tight coupling between
executables and hardware ISA. Promoting compiler technology for
hardware optimization was synergistic with promoting compiler
technology for portability purposes.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

(OT) acceptance of technology, was: Convenient and secure

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: (OT) acceptance of technology, was: Convenient and secure
 eCommerce using POWF
Newsgroups: sci.crypt
Date: Wed, 25 Sep 2002 01:31:04 GMT

"Paul Pires" writes:

Not so. Issuers hold individual card-users harmless for each
particular instance of fraud but the cost of all fraud is passed
through to their customers. It doesn't come out of executive
compensation you know. It is a cost of doing business and
as such is passed on..... to us. Furthermore, If we don't
care or if we percieve that they are paying for it "for us"
we are decieved as well as drained since they now have little
motivation to deal with it. Why worry? We are paying but not
screaming bloody murder.

it isn't just the issuers ... although the issuers is who the card
users typically are dealing with. the default for everything is the
merchant. consumer says that they didn't do/get something, burden of
proof is on the merchant or otherwise the merchant eats it.

if the merchant is bankrupt (or skips town), then the merchant's
financial institution is liable (merchant credit card banks "like"
airline merchants because of the profitable charges ... but they also
really hate it when they go bankrupt, they are on the hook for charges
for undelivered services, which can easily be tens of millions).  The
consumer's issuing bank is at the end of that line behind the
merchants and the merchants' finanical institutions.

Of course fraud, bankruptcy, etc is cost of doing business ... and
shows up in fees and charges one way or another. Merchant has to
accept discount rate on credit card charges as cost of doing business
as well as fraud as cost of doing business. Lots of merchants (and
banks) may buy fraud insurance ... the premiums for that insurance is
also cost of doing business. In much the same way that defrauding
insurance companies result in higher premiums that everybody pays
... defrauding anybody results in higher cost of doing business and is
ultimately passed on to the consumer.

general fraud, exploit, vulnerabilities:
http://www.garlic.com/~lynn/subtopic.html#fraud

lots of card fradu related postings:
http://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in Canada
http://www.garlic.com/~lynn/aadsmore.htm#scanon Smartcard anonymity patents
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror14 [FYI] Did Encryption Empower These Terrorists? (addenda to chargebacks)
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose5 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm10.htm#risks credit card & gift card fraud (from today's comp.risks)
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#bio2 biometrics
http://www.garlic.com/~lynn/aadsm11.htm#44 Web site exposes credit card fraud
http://www.garlic.com/~lynn/aadsm11.htm#45 Web site exposes credit card fraud
http://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
http://www.garlic.com/~lynn/ansiepay.htm#scaads X9.59 related press release at smartcard forum
http://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay3.htm#smrtcrd Smart Cards with Chips encouraged ... fyi
http://www.garlic.com/~lynn/aepay6.htm#fraud Online Card Fraud Thirty Times That Offline
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay8.htm#ccfraud Almost Half UK E-Shopper's Fear Card Fraud (CC fraud increased by 50% in 2k)
http://www.garlic.com/~lynn/aepay8.htm#ccfraud2 Statistics for General and Online Card Fraud
http://www.garlic.com/~lynn/aepay8.htm#visapass VISA: All Your Password Are Belong to Us
http://www.garlic.com/~lynn/aepay8.htm#x959paper Credit Card Fraud and E-Commerce: A Case Study
http://www.garlic.com/~lynn/aepay9.htm#risks credit card & gift card fraud (from today's comp.risks)
http://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#6 credit card & gift card fraud (from today's comp.risks)
http://www.garlic.com/~lynn/aepay10.htm#16 Worker Accused of Selling Colleagues' ID's Online (credit card scam)
http://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting)
http://www.garlic.com/~lynn/aepay10.htm#25 Definese Dept Criticised on Internal Credit Card Fraud
http://www.garlic.com/~lynn/aepay10.htm#26 Definese Dept Criticised on Internal Credit Card Fraud
http://www.garlic.com/~lynn/aepay10.htm#38 Credit card fraud sending night-vision rifle scope to criminal
http://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
http://www.garlic.com/~lynn/aepay10.htm#44 Credit Card Skimming Rising In The US
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002e.html#23 Opinion  on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#40 Smart Cards
http://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002g.html#72 Biometrics not yet good enough?
http://www.garlic.com/~lynn/2002h.html#6 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#8 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Convenient and secure eCommerce using POWF

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Convenient and secure eCommerce using POWF
Newsgroups: sci.crypt
Date: Wed, 25 Sep 2002 01:37:00 GMT

"Ben Mord" writes:

So the issuer and merchants will lose less money to fraud if customers
accept a better technology e.g. smart cards or POWFs. How can they get
customers to accept the new technology? This seems very easy to me. Pass on
some percentage of the fraud savings back to the customers as financial
incentives such as lower APRs, better airline mile deals, direct crediting
of their account, etc. When faced directly with these incentives funded by
the savings in prevented fraud, what customer won't want to adopt this new
technology?

one of the studies during this period was issue of PC/SC and the
requirement for serial port readers. there has been documentation on
significant consumer problems with the consumer installation and
operation of pc/sc serial port readers (including some failures that
resulting having to re-install operating system). this by itself,
independent of card use itself, represented a significant issue.

note that there has been uptake of smartcards in other parts of the
world with point-of-sale terminal support being deployed ... and the
use of the cards at point-of-sale.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Convenient and secure eCommerce using POWF

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Convenient and secure eCommerce using POWF
Newsgroups: sci.crypt
Date: Wed, 25 Sep 2002 05:52:00 GMT

"Roger Schlafly" writes:

That is one of the fundamental problems with smartcards. Unless there
is some secure way of communicating with the card, the reader could
intercept the PIN, have it sign something other than what you want it
to sign, and maybe even steal your private key.

that is part of the objective of the EU finread standard ... certified
readers ... not only certified/secure pin entry, but also
certified/secure display (aka are you really signing what you think
you are signing ... the PC has a virus which sends to the reader for
signing something totally d