2007 Newsgroup postings (01/18 - 01/27) Lynn Wheeler

2007 Newsgroup Postings (01/18 - 01/27)

old discussion of disk controller chache
Decoding the encryption puzzle
some old network related discussion
"New Universal Man-in-the-Middle Phishing Kit" ?
"The Elements of Programming Style"
old productivity response time studies
Securing financial transactions a high priority for 2007
Miniature clusters
Securing financial transactions a high priority for 2007
Decoding the encryption puzzle
Securing financial transactions a high priority for 2007
Decoding the encryption puzzle
Special characters in passwords was Re: RACF - Password rules
(old) distributed 4341s
How many 36-bit Unix ports in the old days?
Securing financial transactions a high priority for 2007
How many 36-bit Unix ports in the old days?
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
How many 36-bit Unix ports in the old days?
How many 36-bit Unix ports in the old days?
How many 36-bit Unix ports in the old days?
Securing financial transactions a high priority for 2007
How many 36-bit Unix ports in the old days?
"The Elements of Programming Style"
Special characters in passwords was Re: RACF - Password rules
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Being "Open" (Was: Mainframe vs. "Server")
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
"The Elements of Programming Style"
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Point-of-Sale security
How many 36-bit Unix ports in the old days?
Keep VM 24X7 365 days
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
SVCs
Securing financial transactions a high priority for 2007
SVCs
EXTERNAL INTERRUPT and SAPL
SVCs
How many 36-bit Unix ports in the old days?
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
Securing financial transactions a high priority for 2007
IBM URL of all available lists?
"The Elements of Programming Style"
SVCs

old discussion of disk controller chache

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: old discussion of disk controller chache
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 18:16:48 -0700

I had come up with the dup/no-dup strategy earlier for fixed-head paging drums (2305), partially in conjunction with "SYSPAG" changes a few past posts
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2006t.html#18 Why magnetic drums was/are worse than disks ?

along with some enhancements to "page migration" ... that I originally shipped in the resource manager ... some collected posts
https://www.garlic.com/~lynn/subtopic.html#fairshare

Date: 12/07/82 09:10:05
From: wheeler
To: vm development group

re: 3880-11; IRONWOOD is too small to be effectively used for much of anything. I've been to Tucson to meet with the IRONWOOD (& IRONWOOD follow on) people. Best thing that could be done immediately for IRONWOOD is to have two modes of operation. As long as the hit rate was satisfactory, do basically the current code. When the hit rate begins to drop off, switch algorithms. Problem is that IRONWOOD is very small compared to real storage sizes.

If a page is read into core, it is then very likely to exist in both IRONWOOD & real memory (this is referred to as duplicates). Assuming an interactive environment, then that page will probably be stolen and another page will be read in ... long before IRONWOOD replaces that particular page in its private store. In a highly interactive environment, it is possible that almost every page in the IRONWOOD is a duplicate ... i.e. it exists in both real memory & IRONWOOD.

What are the implications of that???? If real memory takes a page fault ... that means that the page isn't in real memory. The page will have to be read in from IRONWOOD. What is the probability of the page existing in the IRONWOOD ("hit"). The "hit" ratio is a function of the size of the IRONWOOD and the locality of the code. A quick look at IRONWOOD would indicate that it is an eight megabyte cache ... right? Because of duplicates ... wrong. If there is seven megabytes of duplicates ... what does that mean. That means that there are seven megabytes of pages which are both in IRONWOOD and real storage. A page fault in real storage indicates that the page that is desired is not in real storage .... that means that 1) it is not one of the seven megabytes of duplicate pages, 2) the IRONWOOD contains only one megabyte of pages that it could possible be. Because of duplicates in this situation ... the IRONWOOD isn't even an eight megabyte cache ... it is effectively a one megabyte cache.

Mechanism to solve this problem is to get rid of duplicates. The second mode of operation (which I referred to) is to do a READ/DISCARD ... which tells the IRONWOOD that as soon as the page is transferred to real storage ... make the IRONWOOD slot available for other data. Then VM will artificially have to force the STORAGE ALTERATION flag ... so that the page will be written out if it is ever stolen. The overhead in CP is increased because all pages that are stolen, must be written out (rather than just changed pages) ... but it drastically increases the effective cache size.

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

IRONWOOD was a 8mbyte 4k-byte record cache added to the 3880 disk controller (product referred to as "3880-11") and was done in Tucson.

following from Tucson engineer:

Date: 01/06/83 09:09:05
To: wheeler

Hi Lynn,

In our Ironwood testing we have noticed a problem when running both drums and Ironwoods as primary paging. It appears that the ALLOC blocks will fill to the level of the smallest blocks. This is hindering us in trying to perform the complete set of configurations that we would like to run. Your original response to this problem turns out not to be the solution.... could you please get in contact with XXXXXX to pursue this problem. Thanks.

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

Decoding the encryption puzzle

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Decoding the encryption puzzle
Newsgroups: bit.listserv.ibm-main
Date: Thu, 18 Jan 2007 18:35:38 -0700

Hal Merritt wrote:
The encryption software starts before Windows. The software failed with a blue screen of death.

My sense is that one or more critical files on the hard drive used by the software became corrupt as PC files are known to do. But I don't know.

But my point was the laptop was put out of service for several days. Doesn't really matter why. This may be tolerable (or even expected) with a PC. But on a mainframe?

The complete loss of mission critical data even for a few days could be catastrophic to the company. One solution is to have backups that aren't encrypted. But, then, what would be the point of encryption in the first place? As I said, a puzzlement.

for a little drift ... another crypto related thread (FDE ... full disk encryption)
https://www.garlic.com/~lynn/aadsm26.htm#23 It's a Presidential Mandate, Feds use it. How come you are not using FDE?

one of the things that was driving "key escrow" ... was that if the data (at rest) was always encrypted ... then the backups would also be encrypted. "key escrow" was required to satisfy "no single point of failure" scenario (loosing the key) and disaster recovery.

There is a separate issue if a vulnerable laptop containing the only copy of business/mission critical data ... this is again normally dealt with as a disaster recovery and "no single point of failure" scenario (regardless of what kind of availability standard any piece of equipment might meet).

For a totally different rant ... there is a big effort to solve some vulnerability problems using encryption ... which I claim would be better addressed by eliminating risk associated with some forms of data ... and eliminating requirement for other kinds of data altogether. recent long-winded posts on the subject
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007

some old network related discussion

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: some old network related discussion
Newsgroups: alt.folklore.computers
Date: Thu, 18 Jan 2007 18:46:44 -0700

CJN corporate started to manage internal network configuration (VNET) add/delete/changes. misc. collected posts mentioning internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

I had done a program that automated some of the administrative operations associated with the operations.

Note example of "MAPCHANGE UPDTxxx" files (format had been slightly modified to meet my suggestion) can be seen here ... associated with announcement of 1000th node in 1983
https://www.garlic.com/~lynn/internet.htm#22
https://www.garlic.com/~lynn/99.html#112

Date: 12/06/82 15:42:01
To: wheeler

Lynn,

I will try to alter the MAPCHANG UPDTxxx files so that your process will work. When you mentioned the name of your program it sounded familiar. I recalled that you had sent us a copy of it last February (I think). We were then, and still are, using a program called ROUTE that also updates the RSCS directory. However, after talking to XXXXXX, my "senior partner" here, he informed me that your program might be a good thing for us to use since it looks at the "connected to" node when routing. What all this rambling comes down to, is that I was wondering if there is a later version of the program than the one I received from you in February. If so, could you please send it? If there is any type of script file for it could you please send it because I don't have any at all right now. Thanks.

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

and another old email with a network related subject ....

This would be networking code running in a virtual machine ... the issue is "EC-mode" virtual machines have more overhead simulation (compared to "BC-mode" virtual machines). STNSM was an instruction only simulated for "EC-mode" virtual machines ... the issue is how to get the equivalent function while running in "BC-mode".

Date: 12/14/82 18:43:23
To: wheeler

Lynn:

I don't remember if you were the one who told me, but I gather there is a way of simulating the function of STNSM, to allow one to restore the system mask to the previous value when returning from a subsystem. I think it involved performing some kind of SVC and then picking up the old PSW from a storage location. Could you help me refresh on this, or point me to an example of how this is done? The Wisconsin joint CSNET project, which was the one that prompted the questions about STNSM and EC mode in the first place, has decided that requiring the user to specify EC mode just to be able to do STNSM seems like too much trouble (especially if running with EC mode on incurs a performance penalty), but would still like to simulate the function if it is possible.

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

"New Universal Man-in-the-Middle Phishing Kit" ?

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "New Universal Man-in-the-Middle Phishing Kit"  ?
Newsgroups: comp.security.misc
Date: Thu, 18 Jan 2007 19:03:25 -0700

Barry Margolin <barmar@alum.mit.edu> writes:
Maybe. But that's true of traditional phishing sites, it's nothing new in this case. The MitM attack simply adds the ability of the site to display things on the page that supposedly only the real site can display (such as your last ATM transaction).

or supposedly the latest online banking countermeasures for fraudulent website (phishing) impostors ... recent discussion in another n.g.
https://www.garlic.com/~lynn/2007b.html#53 Forbidding Special characters in passwords
https://www.garlic.com/~lynn/2007b.html#54 Forbidding Special characters in passwords
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007

misc. past posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

"The Elements of Programming Style"

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 04:01:51 -0700

re:
https://www.garlic.com/~lynn/2007b.html#44 Why so little parallelism?
https://www.garlic.com/~lynn/2007b.html#57 "The Elements of Programming Style"

With An 80-Core Chip On The Way, Software Needs To Start Changing
http://www.informationweek.com/showArticle.jhtml?articleID=196901935

from above:
Intel is about a month away from unveiling the specs for a research prototype of an 80-core chip that they've developed. That's right: Not an 8-core; this is an 80-core chip. The microprocessor manufacturer has jumped way ahead of the expected progression from dual-core to quad-core to 8-core, etc., to delve into different ways to make something as complicated as an 80-core chip actually work.

... snip ...

and for something a little bit older ...

DMKLOK had to do with SMP/multiprocessor lock operations. This email talks about DUMPRX enhancement to do some amount of automated diagnostic operations for failures related to SMP locking operations.

Date: 12/16/82 11:45:15
From: wheeler

I'm sending out a newer copy of DUMPRXE with additional support for processing LOK abends. Code attempts to check if the R1 pointer to lockword is contained in DMKLOK & then runs thru the list of various known LOCKWORDS. Would appreciate testing against any dumps you currently may have.

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

misc. collected posts mentioning DUMPRX, problem analysis, failure signatures, etc
https://www.garlic.com/~lynn/submain.html#dumprx

lots of collected posts mentioning multiprocessor operation and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp

and misc. past posts mentioning an old 5-way SMP project from 1975
https://www.garlic.com/~lynn/submain.html#bounce

and some old email on ha/medusa that talks about scale-up in cluster manner
https://www.garlic.com/~lynn/lhwemail.html#medusa

old productivity response time studies

Refed: **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: old productivity response time studies
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 04:57:58 -0700

from long ago and far away ...

Date: 01/21/83 11:38:34
From: wheeler
To: somebody in bldg. 14, disk engineering lab

re: response time; Also when I was in YKT last week, I got several copies of new studies comparing productivity and response times. One particular study compared engineers doing design work on graphics devices. To minimize some of the external variances, they broke the engineers into three categories; novice, general, experienced. With one second response time, the experienced engineers were working only slightly faster than novice engineers. At less than .25 second response the experienced engineers were working over 10 times faster than the novice engineers (and in fact their transaction rate went off the end of the graf).

>From the 2nd 327x document i sent, the best case for the newest 3274 coming down the line is .18 second hardware response ... that time is added to the system response time to come up with the total response time ... i.e. with the best 3274 being planned, it is still practical impossible to achieve less than .25 second response time.

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

misc. past posts mentioning working with bldg. 14 engineers
https://www.garlic.com/~lynn/subtopic.html#disk

and misc. past posts mentioning sub-second response time studies ... including some discussion with problems using 3274 controllers to replace 3272 controllers
https://www.garlic.com/~lynn/2001k.html#30 3270 protocol
https://www.garlic.com/~lynn/2001m.html#17 3270 protocol
https://www.garlic.com/~lynn/2001m.html#19 3270 protocol
https://www.garlic.com/~lynn/2002j.html#77 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2002k.html#2 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2003e.html#43 IBM 3174
https://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
https://www.garlic.com/~lynn/2003o.html#36 When nerds were nerds
https://www.garlic.com/~lynn/2004e.html#0 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#28 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
https://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2006t.html#34 The Future of CPUs: What's After Multi-Core?

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 09:53:28 -0700

Andrew Swallow <am.swallow@btopenworld.com> writes:
Does the internal number, as used by the back office functions, need to be the same as the account number entered by the user?

Conversion can be performed by table look up with only a very small number of programs being authorized to read the table. Back office, internet access and id conversion can be performed on 3 different computers. Prevent hacking by using physical transference rather than "email". You can buy 2 giga-byte memory cards for $40 these days.
https://www.amazon.com/Kingston-CF-2GB-S-ElitePro-CompactFlash/dp/B00062WV86/

there have been some attempts at things like that ... the issue is that account numbers are actually used by a large number of business processes spread all over the place. as a result there isn't a single interface where they would translation occur (their are more like tens of millions).

one of the most vulnerable is all the merchant backroom operations ... i.e. as i've refereed to several times in security proportional to risk post
https://www.garlic.com/~lynn/2001h.html#61

where you may have tens/hundreds of millions of such merchant operations ... some number involve entry-level employees with little training and only semi-automated processes.

one of the places that such attempts like that (in the past) fell down was dispute/charge-back. the merchant has the transaction log as the consumer account number. the consumer calls their consumer/issuing bank to complain about something giving 1) account number, 2) amount, 3) date, 4) merchant. the merchant is eventually contacted giving 1) account number, 2) amount, 3) date. The merchant then has to look it up in their records/log by the consumer's account number. all this (can) happens by phone.

the simplest place to do this is at the issuing/consumer financial institution ... by contrast to the tens/hundreds of millions of merchants ... their are possibly only thousands. however, the financial institutions are frequently already the best protected and the lest likely to have a breach (so it doesn't provide much additional overall improvement ... since it doesn't hit the weakest link).

furthermore, most financial institutions already have an implementation that already does something similar .... re-issuing cards (lost/stolen) with new number ... they will carry both the new number and the old number mapped to common account (however, it isn't a prevention to skimming/harvest attack since you just need the number used at the merchant). something similar is used for linked, family cards.

having the conversion occur at the merchant ... where the biggest threat exist ... means putting a copy of the table out in tens/hundreds of millions of merchants ... that is manually accessible by entry-level employees.

when we were working on what was to be called electronic commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

we made a suggestion (as countermeasure to insider) that all merchant employees have full FBI background checks ... which can be quite expensive and time-consuming ... recent posting on subject
https://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules

akin, it works for various workers in financial institutions ... but again there are a lot fewer institutions and it involves significantly fewer workers (compared to tens/hundreds of million merchant operations)

now, there is a variation on account numbers that they are trying ... but it is pushed out to the consumer ... which is one-time-account numbers. the consumer is issued with a large number of account numbers ... all linked to the "backroom" account. this account numbers can only be used once ... so if they are skimmed/harvested from the merchant logs ... they can't be used in replay-attack. The tens/hundreds of millions of merchant processes don't change.

the problem here is the inconvenience to the consumer ... and there have been claims that the account number domain is getting depleted. they have quite a few digits ... but several are used for association and routing (a little akin to telephone area codes), having a unique account number for every purchase ... makes them go quickly (so approach isn't widely deployed ... and several deployments in the early 70s didn't last long and were abandoned).

past posts in this thread:
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007

Miniature clusters

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Miniature clusters
Newsgroups: comp.arch
Date: Fri, 19 Jan 2007 10:02:27 -0700

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
This isn't really an architecture question, so much as a design one, but I can't think of a more appropriate forum.

I am referring to systems with at least 16 CPUs (preferably actually CPUs, not just cores) with a reasonable specification (e.g. ECC if possible), that are suitable for putting in an ordinary office or using at home. E.g. they must all run off a single 13A socket, not be too noisy (I am happy with 80 dB, but not everyone is), not need special conditions and not be too bulky.

past emails discussing MEDUSA (cluster-in-a-rack) ... prototype was 16 processors in a rack ... the product was going to have 32 processors in a rack (and you scale it up with multiple racks)
https://www.garlic.com/~lynn/lhwemail.html#medusa

and as mentioned here ... the project was transferred, announce in a different venue, and we were told we couldn't work on anything with more than four processors
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/2001n.html#83

I had attempted something nearly a decade earlier ... but the density was significantly less
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

of course, the amount you can package in physical space has significantly increased since either of these previous activities.

so where does 80-core chip fit in?
https://www.garlic.com/~lynn/2007c.html#4 "The Elements of Programming Style"

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 12:13:24 -0700

re:
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007

Retail security breach may be biggest in U.S.
http://www.iht.com/articles/2007/01/19/business/data.php

one more time can you say security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61

lots of past posts mentioning account harvesting/skimming for simple replay attacks
https://www.garlic.com/~lynn/subintegrity.html#harvest

even for some supposedly "modern" chip technology
https://www.garlic.com/~lynn/subintegrity.html#yescard

and past posts with general comments about threats, risks, vulnerabilities, fraud, etc
https://www.garlic.com/~lynn/subintegrity.html#fraud

Decoding the encryption puzzle

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Decoding the encryption puzzle
Newsgroups: bit.listserv.ibm-main
Date: Fri, 19 Jan 2007 12:52:40 -0700

Anne & Lynn Wheeler wrote:
for a little drift ... another crypto related thread (FDE ... full disk encryption)
https://www.garlic.com/~lynn/aadsm26.htm#23 It's a Presidential Mandate, Feds use it. How come you are not using FDE?

re:
https://www.garlic.com/~lynn/2007c.html#1 Decoding the encryption puzzle

the older article

Feds crawl toward encryption
http://weblog.infoworld.com/techwatch/archives/009492.html

from above:
Such appears to be the case with this year's infamous data-leak episode of millions of U.S. veterans' private information last May, which prompted the White House to issue a presidential mandate [PDF] requiring all agency mobile laptops and devices storing sensitive data to have fully encrypted hard drives.

... snip ...

and the referenced gov. document
http://www2.cit.cornell.edu/computer/history/Cogger.html

new article

Firms face pressure to encrypt data
http://www.boston.com/business/articles/2007/01/18/firms_face_pressure_to_encrypt_data/

and new item on vulnerability

Retail security breach may be biggest in U.S.
http://www.iht.com/articles/2007/01/19/business/data.php

and, of course, old posting on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

and comment here
https://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 19 Jan 2007 13:10:07 -0700

Anne & Lynn Wheeler wrote:
one of the things that the x9a10 financial standard working group had to take into account was that in the mid-90s the EU had made some statement that retail payments should be as anonymous as cash ... i.e. no name, no address, no telephone number, and no other personal gorp.

in that sense we attempted to make the x9.59 financial standard for all retail payments, privacy agnostic.
https://www.garlic.com/~lynn/subpubkey.html#x959

x9.59 would meet the requirement given the x9a10 financial standard working group to preserve the integrity of the financial infrastructure for all retail payments ... as well as

1) eliminate account number vulnerabilities (didn't do anything about eliminating data breaches and security breaches ... but drastically reduced the risk when such breaches happened ... especially related to "account fraud") and

2) drastically reduced the places (all retail payments) where personal information might be required (and therefor drastically reduced the repositories containing such personal information ... hopefully helping reduce actually occurrences of other types of "identity theft") ... also meeting the EU statement on making retail payments as anonymous as cash ... or at least privacy agnostic

some of this led up to being the co-author of the x9.99 financial industry privacy standard. as part of that effort ... I pulled together a merged (eu-dpd, glba, hipaa, etc) privacy taxonomy and glossary ... references to merged taxonomy and glossary activities
https://www.garlic.com/~lynn/index.html#glosnote

re:
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007

TJX Hack Highlights Payment Information Insecurity
http://www.informationweek.com/showArticle.jhtml;jsessionid=MFDDZSZDTWEVAQSNDLRCKHSCJUNN2JVN?articleID=196902075

from above:
The cost of data breaches, whether the information is lost or stolen, continues to escalate, costing companies an average of $182 per compromised record.

... snip ...

that may not include the cost/aggravation to the individuals who get fraudulent charges on their accounts.

other related posts
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007

and this
https://www.garlic.com/~lynn/2007c.html#1 Decoding the encryption puzzle
https://www.garlic.com/~lynn/2007c.html#9 Decoding the encryption puzzle

of course there is the issue of insiders as well as security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

or the observation here about account number leakage even if the planet was buried under miles of encryption
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007

Decoding the encryption puzzle

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Decoding the encryption puzzle
Newsgroups: bit.listserv.ibm-main
Date: Fri, 19 Jan 2007 13:53:55 -0700

Howard Brazee wrote:
Decades before, people kept printed copies of programs they wrote. Sometimes they even used them in job interviews.

Is that significantly different?

potentially by several orders of magnitude ... also might completely change the possible fraud "return-on-investment" equation.

something that might have 1percent fraud ... if it changed by two orders of magnitude ... it could go to nearly all fraud ... possibly resulting in collapse of the infrastructure

recent posts in this thread:
https://www.garlic.com/~lynn/2007c.html#1 Decoding the encryption puzzle
https://www.garlic.com/~lynn/2007c.html#9 Decoding the encryption puzzle

the whole data breach, security breach that has been in the news for the past year or two ... is that the attacker's cost for an electronic breach and to translate that electronic information directly into fraud can be a couple orders of magnitude lower per account ... than saying physical operation of holdup at gunpoint to obtain somebody's wallet. If you take the time&effort of a physical holdup for a couple of credit cards .... the cost to the attacker (per account) can be easily several orders of magnitude larger compared to the cost to the attacker (per account) for an electronic breach involving a couple million account records.

and of course, reference to old security proportional to risk post
https://www.garlic.com/~lynn/2001h.html#61

lots of past posts involving some kind of fraud, threat, vulnerability, exploit, etc

https://www.garlic.com/~lynn/subintegrity.html#fraud

and loads of past posts specifically mentioning data breaches and/or security breaches
https://www.garlic.com/~lynn/aadsmail.htm#mfraud AADS, X9.59, security, flaws, privacy
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/ansiepay.htm#theory Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm6.htm#terror4 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay12.htm#5 Law aims to reduce identity theft

Special characters in passwords was Re: RACF - Password rules

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Special characters in passwords was Re: RACF - Password rules .
Newsgroups: bit.listserv.ibm-main
Date: Fri, 19 Jan 2007 17:12:26 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
One of my hobbies was building enhanced, customized operating systems for internal distribution. I've joked before (sometimes with multics aficionados) that the number of customers vm installations was larger than the number of internal vm installations; and the total number of internal vm installations were significantly larger than the number of customer vm installations; and that i directly distributed customized vm operation system to. However, at various times, the number of internal installations that I built and directly distributed customized operating systems for ... were as large as the total number of Multics systems that ever existed.

and for a little cross-over from b.l.i n.g. re:
https://www.garlic.com/~lynn/2007b.html#51 Special characters in passwords was Re: RACF - Password rules

In the following "put tapes" are monthly cumulative update distribution tapes.

"SJJ" ... is updated name for sjr/vm ... standing for "san jose joint" (system)

Date: 07/05/83 12:50:04
From: wheeler
To: somebody at lidingo sweden

re: sjj VM system; Shouldn't be much trouble installing SJJ. We still haven't finished with a CLEAN distribution tape so everything installs cleanly. You should be aware that we are built on top of common with all our own updates.

We are currently running on an early CSL24 system ... we worked with Kingston to convert CSL23 to SP1.18+HPO2. We have most PTFs applied from SP1 put tapes up thru about March. We are almost done with bringing PTF level up to the current PUT tape. We have early releases of several pieces of code already integrated (like IRONWOOD with local fixes and enhancements ... also new PVM stuff). We are most of the way thru HPO2.5 integration (primarily >16meg support).

Over and above that we have quite a few local changes (more than Hursley). System is currently running on something over 50 machines from 4331s to 3081Ks and is supported by 5-8 system programming teams.

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

and recent post with old email mentioning IRONWOOD
https://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller cache

and post with old mention of >16meg support
https://www.garlic.com/~lynn/2007b.html#34 Just another example of mainframe costs

and a status update ... from STL (now called silicon valley lab)

Date: 07/09/83 11:24:39
From: wheeler

re: stl; stl i/s crew said yesterday that some of the IS machines are going for 30 days at a time w/o a software system failure and stl i/s has gone a week at a time w/o any machine taking a software failure.

This apparently is the first time that anything like that has happened for them. Supposedly they attribute it primarily to this SJJ VM system and the co-operation that has gone on (at least when talking to me).

There are at least three things that contribute to the improvement. 1) there is a lot of local code in the SJJ system specifically for reliability purposes, 2) the debugging activity is shared by all the locations running the SJJ system so the quality and number of people finding&fixing bugs is greater, 3) my DUMPRX CP problem determination package has improved the ability of the people to do problem determination.

as I said before, the I/S survey for STL shows marked improvement. Besides reliability, another factor is the removal of a lot of the logon restrictions. They were talked into substituting my local mods. for GROUP FAIR SHARE for the logon number limits.

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

a couple recent posts mentioning the old group fair share work:
https://www.garlic.com/~lynn/2007.html#14 vm/sp1
https://www.garlic.com/~lynn/2007b.html#39 How many 36-bit Unix ports in the old days?

and a collected posts mentioning resource manager and/or fair share work
https://www.garlic.com/~lynn/subtopic.html#fairshare

a lot of the reliability updates, I had original done as part of IOS subsystem rewrite I did for reliability in the disk engineering and product test labs (bldgs 14&15)
https://www.garlic.com/~lynn/subtopic.html#disk

and lots of past posts mentioning dumprx
https://www.garlic.com/~lynn/submain.html#dumprx

posts with old email mentioning internal distribution
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?
with old email from apr75 about distribution
https://www.garlic.com/~lynn/2006w.html#email750430

post about sjr/vm distribution
https://www.garlic.com/~lynn/2006u.html#26 Assembler question
with old email from apr80 about the distribution
https://www.garlic.com/~lynn/2006u.html#email800429

Date: 07/11/83 10:28:40
From: wheeler

the swedish inquiry for VM is for their hdqrtrs location ... which will package and install the same vm system for all internal IBM sites in Sweden. They would like an up-to-date ... realistic version of the R6TAPE MEMO. Don't know for sure what the arraignments to on-site install are yet. With the interest from Europe, there should be the possibility of getting somebody to cover the basic expense and once that happens all the rest of the sites will always come-up with and delta expense. I'm going to be too busy to go ... so if anybody else is interested in picking up the ball ... go ahead. They will be expecting some amount of familiarity with the system and help to easily install it and run it thru its paces.

There is the potential for at least visiting 2-3 other locations in Europe, at least for SJJ sales trip, if not for actual installs.

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

R6TAPE MEMO was the detailed distribution document for the sjr/vm release 6 mentioned here
https://www.garlic.com/~lynn/2006u.html#26 Assembler question

and for something a little different, announcement for the monthly bay area vm users meeting

Date: 07/11/83 20:55:48
To: distribution

On July 19th, at 7:30pm at the monthly Bay Area VM users meeting "BayBunch," Norm Radder, from the Bank of America's programming staff, will discuss the Bank's implementation of the PROTECT EXEC. The Bank thinks that this EXEC addresses ten security problems inherent in VM. The basis of the PROTECT EXEC is to address the weakness in password only protection for the LINK command. It allows the M-disk owner to state who may LINK. I don't know all the bells and whistles that the Bank has added to their EXEC. A PROTECT EXEC was an integral part of the NCSS VM like timesharing system (NOMAD). The Baybunch meeting will be held at SLAC (Stanford Linear Accelerator) in Menlo Park, California.

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

... the security issue is basically adding an access control list (ACL) capability to VM.

NCSS was one of the early timesharing service bureaus that started with cp67. misc. past posts referring to various of these timesharing service bureaus
https://www.garlic.com/~lynn/submain.html#timeshare

(old) distributed 4341s

Refed: **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: (old) distributed 4341s
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 06:40:21 -0700

a little SNA/3705 problem/issue with (French) distributed 4341s project.

index of old email mentioning 43xx machines
https://www.garlic.com/~lynn/lhwemail.html#4341

earlier post mentioning this project:
https://www.garlic.com/~lynn/2006p.html#34 "25th Anniversary of the Personal Computer"

Date: 25 January 1983, 09:04:00 SET
To: wheeler

hi,

Our 4341 DDP project is now officially launched. One of our major problems is the connection of the 4341's to the Concentrator network:

At the end of the experimental phase, we should have about 100 local terminals connected to one distributed 4341. These terminals will be partly used by people having access to MVS/IMS applications, like WTAAS, through PVM (327x emulation) and the Concentrator network.

Is seems unreasonable to have so many lines (4 to 6 ?) between each 4341 and the Concentrator network.

Could you tell me what the status of the VMNSF project is. Could the use of a S/1 N.I.P instead of a 3705 be a possible solution to our problem? Any information related to this topic would be useful for us. Thank you for your help

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

recent mention of general SNA issues
https://www.garlic.com/~lynn/2006x.html#8 vmshare

i.e. it wasn't an issue of having a (non-SNA) network interconnecting distributed 4341s ... it was having each of the 4341s connected into a corporate (sna-based) terminal communication infrastructure ("concentrator network").

and misc. posts mentioning internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 07:42:00 -0700

re:
https://www.garlic.com/~lynn/2007b.html#39 How many 36-bit Unix ports in the old days?

references to group fair share scheduling (for unix, in the above post) also shows up here in the x-over posting
https://www.garlic.com/~lynn/2007c.html#12 Special characters in passwords was Re: RACF - Password rules

and some (more vm) unix related email

Date: 8 January 1985, 01:51:41 ET
From: ???
To: wheeler
Subj:Caveat lector.

I am planning to tell the world you think our UNIX design was better than the IX/370 UNIX design unless you object. (Charts appended)

The world in this case is an ACIS review of our UNIX HOST strategy; but I may not stop there.

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

The ix/370 unix design was from the dallas organization that had done the tss/370 rpq work for at&t. recent reference
https://www.garlic.com/~lynn/2007b.html#3 How many 36-bit Unix ports in the old days?

the above post has old email
https://www.garlic.com/~lynn/2007b.html#email800408

that includes reference looking for a 370 C compiler

this email is from the palo alto group that was doing the work on BSD port for 370 (and trying to get me into trouble). This never actually shipped, since they were eventually directed to retarget the BSD port for PC/RT (801/romp) which was announced as "AOS". old bsd/aos post
https://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ....
https://www.garlic.com/~lynn/2004f.html#44 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal R&D

lots of past 801 related posts
https://www.garlic.com/~lynn/subtopic.html#801

the palo alto group did later do 370 (and 386) port for UCLA's Locus which was announced as aix/370 (and aix/386). recent post w/reference to aix/370
https://www.garlic.com/~lynn/2007.html#32 V2X2 vs. Shark (SnapShot v. FlashCopy)

=====

And somewhat related to recent cluster thread
https://www.garlic.com/~lynn/2007c.html#7 Miniature clusters
and
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor

... as opposed to (HA/MEDUSA) cluster scale-up
https://www.garlic.com/~lynn/lhwemail.html#medusa

Date: 07/12/85 09:15:51
From: wheeler

spent afternoon talking to KERNAL adtech group in boeblingen ... they have an alternative nucleus that is being proposed as a SSI replacement for IX/370 (although they don't want to talk those details at this point). They also have some part of a MVS simulation running to the point that numerous MVS applications run under their kernel ... for instance on 37t.

They also had some interesting things to say about how they would support a processor complex configuration. They already are already down the road on not wanting to support channels but a high-speed bus ... and they have done work on how they would support multiple "local" processors. They are also looking at Multi-bus II which supposedly has off the shelf hardware that would go to the 40 megabyte/second range. That could configure numerous one board 370 processors.

The kernel group felt Roman was a lot further along (hope to talk to somebody in that group on monday) ... they thot that 1987 was a product availability. Roman project is now under processor development and no longer in adtech ... and has fairly large organization. I'll try and find out on monday how long it might take them to have a four processor with bus interface adtech machine available. If they could have a cheap multi-bus II quickly ... now have to worry about what is managing the bulk store). It might be faster than trying to get A74 group to design a bus interface and build a four processor version.

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

At this time, Europe/Germany (boeblingen) was putting a lot of effort into ix/370 for a product (some of the dallas people were on assignment there)

"37t" was 4331 repackaged into approx. size of desk-side two-drawer file cabinet.

"roman" was a "new" 370 chip set (about performance of 168-3) ... previous post with mention of mini-cluster, roman, as well as iliad
https://www.garlic.com/~lynn/2002l.html#27 End of Moore's law and how it can influence job market

"A74" was 370 processor attached to ibm/pc (with much better thruput than earlier xt/at/370) announced as 7437 ... several 7437 press items
https://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home

other mention of a74/7437
https://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
https://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM PC software?

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 10:39:51 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
now, there is a variation on account numbers that they are trying ... but it is pushed out to the consumer ... which is one-time-account numbers. the consumer is issued with a large number of account numbers ... all linked to the "backroom" account. this account numbers can only be used once ... so if they are skimmed/harvested from the merchant logs ... they can't be used in replay-attack. The tens/hundreds of millions of merchant processes don't change.

the problem here is the inconvenience to the consumer ... and there have been claims that the account number domain is getting depleted. they have quite a few digits ... but several are used for association and routing (a little akin to telephone area codes), having a unique account number for every purchase ... makes them go quickly (so approach isn't widely deployed ... and several deployments in the early 70s didn't last long and were abandoned).

re:
https://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007

that "early 70s" is mistype ... should refer to early part of this decade in Europe and only a couple years ago in the US

a couple old posts on single-use/one-time account numbers
https://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
https://www.garlic.com/~lynn/aadsm21.htm#18 'Virtual Card' Offers Online Security Blanket

and for drift ... several posts on one-time passwords ... similar countermeasure to evesdropping/harvesting and replay attacks
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003o.html#46 What 'NSA'?
https://www.garlic.com/~lynn/2003p.html#10 Secure web logins w random passwords
https://www.garlic.com/~lynn/2005f.html#40 OTP (One-Time Pad Generator Program) and MD5 signature
https://www.garlic.com/~lynn/2005i.html#50 XOR passphrase with a constant
https://www.garlic.com/~lynn/2005l.html#8 derive key from password
https://www.garlic.com/~lynn/2005o.html#0 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005t.html#31 Looking for Information on password systems
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006k.html#28 Hashes and Passwords
https://www.garlic.com/~lynn/2006r.html#38 Trying to underdtand 2-factor authentication
https://www.garlic.com/~lynn/2006u.html#4 ssh - password control or key control?

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 10:56:47 -0700

krw <krw@att.bizzzz> writes:
If you want to get literal about it, 370s don't "boot" at all. The processor doesn't pick itself up by its bootstraps, rather the service processor initializes the processor, memory, and I/O. There is a *lot* of stuff that goes on at IMPL. Loading microcode and the OS is a small part of the process.

for some drift ... service processor came into existence to satisfy field engineering requirement to be able to have a field service "bootstrap" diagnostic process ... starting with being able to scope "failed" components. starting with 3081, it was no longer possible to scope the components. so they built in a "service processor" with lots of probes to numerous parts of the system. the FE could scope the "service processor" (if it was failing) and then use the "service processor" to diagnose the real machine.

for 3090, the service processor was going to be a 4331 running a highly modified version of vm370 release6; the FE could scope the 4331 and then use the 4331 to diagnose the 3090. before shipping, this was replaced with a pair of 4361s (still running vm370); the FE no longer needed to bootstrap scope the service processor (to diagnose a service processor failure) ... because there was a spare service processor.

at the time, i wasn't paying a lot of attention on packaging so i'm not sure of how much repacking went on for the 4331/4361 to use it as 3090 service processor ... and whether any of that repacking was involved in creating 37t (a deskside 370) ... recent post
https://www.garlic.com/~lynn/2007c.html#14
with old email that mentioned the 37t
https://www.garlic.com/~lynn/2007c.html#email850712

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 11:10:30 -0700

jmfbahciv writes:
None of this helps. My mother writes a check at the grocery store. The first time she wrote one, it took minutes to "clear" it. Now it takes no time to clear it. I am assuming this is because the store has her banking information, along with an "OK" bit set.

It doesn't need a thief to really screw the banking system up. Just one software or procedural hiccup will make a horrible mess.

systemic risk ... various types of failures or compromises that can cascade and take down the whole system. some amount of worrying is done about such things. there is old story about a situation in (inter-bank) overnight settlement in Europe some years ago ... that nearly brought down the whole infrastructure.

there was also big push in the mid-90s to convert fedwire (interbank transfers ... including interbank overnight settlement) to digital certificates ... one for each of the 30k some financial institutions. one fedres governor came out strongly against ... at the time there was going to be a single certification authority ... and it was pointed out if the certification authority was compromised ... then all 30k digital certificates would instantly become invalid ... and at the time it was estimated that it would take over three months to re-issue all 30k digital certificates. systemic risk big time.

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 11:44:25 -0700

jmfbahciv writes:
The only way to plug up the hole that's been made is to have a voucher (a.k.a. check) match each posting. Nowadays, posting the payments no longer needs an accompanying piece of paper. So any repetition done at current CPU and comm speeds can't be stopped.

there is actually a mechanism built into much of the infrastructure that is left over from days of lots of dropped lines and/or communication glitches ... when it was common for clerks to reswipe the card when they didn't get the expected ACK. they built in stuff that would reject duplicate transactions that occurred in period of several minutes (up to something like 20 minutes). it has been known to catch situations involving valid duplicate transactions. A person purchases one item of something and then with 5-10 minutes decides that they want a second.

however, as previously detailed ... most attempts doing that fraudulently at the originating merchant are quickly caught and the merchant dealt with (as part of transaction fraud detection software). as a result most of the harvesting/skimming attacks involve taking acquired account numbers and performing fraudulent transactions as far away from the original compromise (merchant) as possible.
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007

original post in this thread with news URL article about existing operations
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007

and other recent posts with news URLs about existing operations
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007
http://www.secureidnews.com/news/2006/12/22/securing-financial-transactions-a-high-priority-for-2007/
Encryption a perfect response to the Year of the Breach
http://scmagazine.com/us/news/article/623768/encryption-perfect-response-year-breach
Bots, breaches and bugs plague 2006
http://www.securityfocus.com/news/11432
By the numbers: A dismal year for data breaches
http://blogs.zdnet.com/BTL/?p=4169
VanBokkelen: 2006: The year of the breach
http://www.fcw.com/article97098-12-18-06-Print
Personal data security breaches hit 100 million milestone in US
http://www.finextra.com/fullstory.asp?id=16296
An Ominous Milestone: 100 Million Data Leaks (data breach)
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=22030
100m US records exposed by security blunders
http://www.theregister.com/2006/12/18/data_breach_milestone/
100 Million Victims of Data Theft (data breach)
http://it.slashdot.org/it/06/12/17/2214219.shtml
Boeing laptop theft puts U.S. data breach tally over 100M
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9006140&intsrc=hm_list
The Corrosive Siege Over Signature-Card Interchange
http://www.digitaltransactions.net/newsstory.cfm?newsid=1223
Retail security breach may be biggest in U.S.
http://www.iht.com/articles/2007/01/19/business/data.php
TJX Hack Highlights Payment Information Insecurity
http://www.informationweek.com/showArticle.jhtml;jsessionid=MFDDZSZDTWEVAQSNDLRCKHSCJUNN2JVN?articleID=196902075

now while credit cards and signature-debit cards appear to operate almost the same ... there is some amount of difference between the backend when fraud occurs. in the case of credit, none of your money actually disappears. a couple past posts
https://www.garlic.com/~lynn/2006e.html#4 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006u.html#48 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#1 New attacks on the financial PIN processing

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 13:52:38 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
this email is from the palo alto group that was doing the work on BSD port for 370 (and trying to get me into trouble). This never actually shipped, since they were eventually directed to retarget the BSD port for PC/RT (801/romp) which was announced as "AOS". old bsd/aos post
https://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ....
https://www.garlic.com/~lynn/2004f.html#44 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005s.html#33 Power5 and Cell, new issue of IBM Journal R&D

re:
https://www.garlic.com/~lynn/2007c.html#14 How many 36-bit Unix ports in the old days?

and earlier ref ...

Date: 08/03/83 14:17:32
From: wheeler

just got back from 3 weeks vacation, have i missed much? Got a notice that there is a Berkeley joint study. Been invited to meeting next week in Palo Alto on the 9th and the following day In Berkeley on the 10th.

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

above references kick-off for the bsd/370 effort which was later retargeted to pc/rt (announced as AOS)

and ...

Date: 08/03/83 14:36:36
From: wheeler

XXXXXX from the branch office is attempting to set up a meeting with a guy from Univ. of Santa Cruz who is responsible for specifying the computers for the new 400in telescope that will be in Hawaii. There will be computers at Hawaii and data will be shipped back to Santa Cruz for processing on local computers there.

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

misc. past posts with references to the effort:
https://www.garlic.com/~lynn/2004h.html#7 CCD technology
https://www.garlic.com/~lynn/2004h.html#8 CCD technology
https://www.garlic.com/~lynn/2004h.html#9 CCD technology
https://www.garlic.com/~lynn/2005l.html#9 Jack Kilby dead
https://www.garlic.com/~lynn/2006t.html#12 Ranking of non-IBM mainframe builders?
https://www.garlic.com/~lynn/2007.html#19 NSFNET (long post warning)

and meeting conflict with 801 chip cache design meeting

Date: 08/04/83 01:21:13
From: wheeler

just realized that i may have gotten myself in a bind. CPU(801) cache design meeting is in Los Gatos next week at the same time as the Palo Alto/Berkeley UNIX meetings.

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

index to old email mentioning 801, romp, etc
https://www.garlic.com/~lynn/lhwemail.html#801

and collected old posts mentioning 801, romp, rios, pc/rt, rs/6000, power/pc, etc
https://www.garlic.com/~lynn/subtopic.html#801

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sat, 20 Jan 2007 16:32:09 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
just got back from 3 weeks vacation, have i missed much? Got a notice that there is a Berkeley joint study. Been invited to meeting next week in Palo Alto on the 9th and the following day In Berkeley on the 10th.

re:
https://www.garlic.com/~lynn/2007c.html#19 How many 36-bit Unix ports in the old days?

more trips down nostalgia lane ..

Date: 4 August 1983, 15:05:24 PDT
From: somebody in disk product test lab (bldg. 15)
To: wheeler

Lynn; Glad to see you back from vacation. Hope you had a good time. If you are in the mood for looking at dumps, I have a PROG5 that occurs after an interface control check. We end up with a director in status pending, trace shows cu busy followed by cu end on a specific address. (what happened to your fix for this problem?) We hang and end up having to stop the cpu and clear the 3880. Then we blow with a prog 5 in DMKDAD. Device which is having problem is a 3380 on a different channel than the original hang. MIH is invoked and the trace shows a dummy interrupt on the 3380. DAD picks up RDEVIOB which has been nicely filled in to read "FREE" and blows the first time he tries to use the address. I suspect FRE but could see no place in trace table where we freted the rdevblok. Dump is 1132. I backed off the latest IOS change as I ran into same IOS11's. How were the mountians?

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

i.e. a bug in bldg. 15 vm3033 system that occurred while i was on vacation.

a little more about meeting conflicts with 801 hardware cache design and bsd meetings ... as well as (what is now called) Keck 10meter telescope

Date: 08/04/83 22:27:33
From: wheeler
To: somebody at Palo Alto science center

... will try and make meeting on Tuesday ... have a hardware cache design meeting in Los Gatos on Tues, weds. & thurs ... will try and work something out.

Was on vacation until yesterday.

Was talking to XXXXX yesterday ... he says that you have two VAXs somewhere around.

I was contacted by branch office about something to do with professor at Santa Cruz selecting computers for 400in telescope to be placed in Hawaii (he was interested in getting a meeting specifically to talk about shipping data between Hawaii and Santa Cruz ... hyperchannel and satellites). I also suggested that science center might have somebody interested in the subject. He was going to contact XXXXXX and may have meeting either up there or at research.

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

some amount of the Keck 10meter telescope effort was because of our HSDT activity with T1 and higher speed transmission links (both terrestrial and satellite)
https://www.garlic.com/~lynn/subnetwork.html#hsdt

ref: previous email
https://www.garlic.com/~lynn/2007c.html#email830803b

we were dealing with some amount of satellite capacity (in addition to terrestrial connections). satellite broadcast intrinsically looks a lot more like LAN infrastructure ... and TDMA satellite is somewhat analogous to token-ring. I had been doing dynamic adaptive resource allocation for some 15 years at this point ... so I figured I could design a different satellite adapter interface that looked a lot more like a LAN interface (for computer operation ... rather than full-duplex terrestrial link) ... and effectively provide adjusted on-demand bandwidth at the (satellite) super-frame boundary.

in the case of Hawaii to Santa Cruz ... the operation could even look a lot more like current satellite TV ... (data channel) broadcast signal from Hawaii with terrestrial telco control channel (1200baud looked like it might even be sufficient). the possibility was to even allow simultaneous reception for more than one downlink at a time.

... and then to time slicing between cache design and bsd/370 ... status on palo alto BSD meeting ... i.e. previous email

Date: 08/09/83 20:54:18
From: wheeler

XXXXXX wants to put up a UNIX 4.2 as soon as possible ... something executing by next spring so that it could be in the hands of 2-3 early test sites by summer for review. I had to leave early to get to the los gatos meeting so not sure what else went on.

Both YYYYYY & I (and possibly others) have suggested that going with multiple address space CP mods (even if they are identical to the Cambridge mods. and if they have already been shipped) may not be feasible for him ... just because of the magnitude of the 4.2 hits to support/use such a design. It doesn't look like that much can be done other than 370 port ... preserving kernel design supporting running on one machine with one real storage space.

There will be a meeting tomorrow in Berkeley and then two week joint design review in Berkeley scheduled for Sept.

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

and more on the bsd/370 design and possible requirement to effectively add smp support to bsd.

Date: 08/10/83 08:28:34
From: wheeler

re: vm/unix; i'm equating the multiple virtual machine approach logically to upgrading the unix kernel to supporting real multi-processors when running native. I may be mis-understanding. Porting to 370 native (or single virtual machine) would require changes for the implementation of the hardware ... but the logic flow thru the kernel should pretty much remain the same. There appears to be a delta change to support multiple virtual machines comparable to the serialization problems encountered when moving a operating system from a UP implementation to MP implementation (i.e. on a native-UP, the unix kernel is going to be aware of the exact sequence execution of all events ... and the possibility exists that there are dependencies because of the predictable sequence ... not sure what the effect might be if VM pre-empts execution in a critical section).

My guess is purely hypothetical, YYYYYY would know more about any such potential exposures requiring additional logic &/or design changes to 4.2 (if any).

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

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 09:12:53 -0700

Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
On IBM systems, cold and warm did not apply to the state of the processor prior to the OS load, it was an option given to the OS which implied that system areas were reinitialized as if the system had just been installed, so crash, error, paging, spool, swap, and similar areas were wiped, or treated as such.

VM spool file system had cold, warm, and chkpt. Cold and Warm were originally part of cp67. warm was dependent on their being a clean shutdown (or a system failure that would save spool file information along with image of real storage). chkpt was added in vm370 ... but it was sort of like (unix) fsck on restart ... it involved periodic chkpt (somewhat like journaled file system) which was read on recovery ... but then it required reading each spool file serially, one at a time. this was all processed before system was up and running (and users could log on or other processing could start) if warm failed (like a power outage), and forced to go to chkpt ... a large system could be unavailable for upwards of an hour doing this process. normal system failure with warm restart would fail and re-ipl and automagically be back up and running within a couple minutes. description comparing this to multics
https://www.multicians.org/thvv/360-67.html

The chkpt operations also impacted the total number of spool files (new/create and old/delete) that could be processed per second.

The problem for HSDT
https://www.garlic.com/~lynn/subnetwork.html#hsdt

in conjunction with (internal network) VNET operations
https://www.garlic.com/~lynn/subnetwork.html#internalnet

was chkpt (and some other serial spool file processing) significantly impacted the aggregate thruput thru a network node ... typically capping things around 5-8 4k blocks/sec (20k-30k bytes/sec). That wasn't much of an issue with 9.6kbaud lines ... but it really was issue with multiple full-duplex T1s (needing aggregate thruput of mbyte/sec or more). While the "official" corporate vnet backbone nodes weren't hitting the HSDT thruput, there were having significant thruput problems with the standard implementation

Date: 04/16/86 15:37:05
From: wheeler
To: distribution (including corporate vnet backbone support staff)

re: sbf update; I'm going to merge the four levels of SBF updates into a single level for distribution ... and at the same time no-op a couple of the debug checking abends (we haven't been having any ... but there is an abend check for all zero CCPD pointer ... it is possible under certain spool DASD I/O errors, that would ordinarily result in aborting the processing of that particular spool file ... for the CCPD pointer to be zeros ... the debug check would cause the system to fail in an otherwise recoverable situation).

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

I had done spool file system rewrite in several stages ... 1) a whole bunch of updates that left the basic spool file processing in the kernel ... but significantly improved the aggregate thruput and 2) a complete rewrite in vs/pascal that moved spool file processing out of the kernel into a virtual address space.

Date: 04/17/86 08:50:45
From: wheeler
To: corporate vnet backbone support staff

re: sbrmisc; all the normal PID code appears to ignore the SBRMISC field when reading a file. When creating a file, everyone clears the field to zeros .... and standard spool file processing then stuffs in the pointer to the first block of the file ... while monitor, accounting, etc leave it zeros.

I've added code to the multiple buffer diagnose read code that validates the SBRMISC field when processing a file ... to make sure there aren't any bugs in the spool file system. I believe I've cleaned up the abends ... if the field is incorrect and just terminate processing the file .... but I haven't recently had an opportunity to test the code.

As long as you don't process a accounting/monitor/etc. spool file (from a non-SBF system) with standard diagnose 14 (on a SBF system) then there should be no problem. The other way around should also be no problem because normal reads and diag. 14 reads ignore the field.

It would appear that the original design of the spool file system might of included some provision for later addition of code that would use the SBRMISC field pointer back to the first record ... but they never got around to implementing it. The "specialized" spool files (accounting, monitor, VMDUMP, etc.) were all added after the initial implementation ... and they apparently ignored and/or never crossed their minds to preserve the SBRMISC convention since it wasn't documented and nobody used it.

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

Date: 18 April 1986, 08:13:58 EST
From: corporate vnet backbone support staff
To: wheeler

Hi,

The CP turbo spool mods are running on VNETCMC since this morning. No problem so far (I didn't expect any).

Will start putting them up on *GATE machines some time next week.

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

corporate backbone support starting to refer to the initial set of changes as "turbo".

Date: THU, 01/08/87 11:18:26 PST
From: wheeler
re: hsdt-sfs;

The work on the proto-type spool file system progresses again ... after being side-tracked to investigate peculiar operational performance characteristics of 3380s when operating at 400-550 page transfers per second. I also shipped SFSPTAPE (CP SPTAPE DUMP emulator) that supports both PAM and pid-3380 configurations.

The access/start-up of the hsdt-sfs spool file disk is working reliably and reasonably fast (still some unanswered questions about 3380 performance at 500+ page transfer per second). hsdt-sfs can import spool files from any PID spool file system that it has DASD access to (i.e. either from the same system or different systems). I'm now starting working on the IUCV interface to support standard PID cp spooling commands and read/writing of spool files.

Currently, hsdt-sfs uses four 4k buffers when processing spool files. On spool file output, the 4 4k blocks are configured as a pair of 8k buffers, with spool disk i/o writes overlapping spool buffer processing. On spool file input, processing attempts to read 16k from the spool disk at a time.

hsdt-sfs eliminates the standard CP checkpoint record and replaces it with spool file descriptor records, or SFFR (spool file first record). Packed into the SFFR is a copy of the SFBLOK, index pointers to data records in the spool file and possibly spool file data (in the case of a spool file <3000 bytes all data and control information is packed into the SFFR record).

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

Part of the complete rewrite, eliminated the old "chkpt" process and effectively made each spool file record self-describing. The rewritten startup chkpt process would start reading the spool file areas a cylinder at a time (reading whole tracks in one operation) and building up current, valid files. This would process at nearly four 3380 cylinders/sec ... a dedicated 3380 spool pack in a little over 200 seconds ... and it could process multiple 3380 spool packs in parallel.

old posts on the complete hsdt-sfs rewrite (in vs/pascal)
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2001n.html#7 More newbie stop the war here!
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
https://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
https://www.garlic.com/~lynn/2004g.html#19 HERCULES
https://www.garlic.com/~lynn/2004p.html#3 History of C
https://www.garlic.com/~lynn/2005d.html#38 Thou shalt have no other gods before the ANSI C standard
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 10:37:58 -0700

jmfbahciv writes:
At the moment, I'm not as concerned about the money disappearing. The problem is the amount of calendar-time it would take to get an account straightened out. Consider people who live on a marginal income and don't have pots of money in other accounts. My parents, as most oldsters who were green and blue collar workers, are in this situation. Any delay of access to money is serious in their life-style.

re:
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007

what i'm looking at is the difference in probability of fraud occurring in various ways and the number of people it might impact as well as the aggregate impact. Furthermore, if it is possible to significantly alter the major threats, it would leave more resources left to address threats that have less aggregate impact.

somebody capturing a file with 50million accounts ... and hitting several million of those accounts (and may never get caught) ... vis-a-vis a merchant site that submits some number of (fraudulent) duplicate accounts ... it is recognized within 24hrs, has them reversed, and the merchant has card processing turned off.

the probability of a merchant doing something like that is further reduced by the prospect that it will almost always be quickly recognized and they would not be able to actually enjoy any of the benefit of the fraudulent activity. crooks tend to go for exploits where they are much more anonymous ... making it harder to connect back to them.

however, it is possible to come up with serious individual impact for almost any kind of scenario ... and if you pick something that has frequency ... say on the order of injury/death motor vehicle accident ... then the impact on victim of injury/death (and the probability) would make a case for banning all motor vehicles and eliminating all alcohol sales.

another scenario was I was asked to give keynote on identity theft a couple years ago at large annual industry conference ... the talk was on the systemic issues related to identity theft and how to improve the overall environment. however, for the most part, the only audience questions were from individuals who were personally experiencing identity theft (and how could they recover) ... and little or nothing about the systemic issues.

A side issue is that both account fraud (doing fraudulent transactions against existing accounts) as well as identity fraud (opening new accounts or other types of new activity involving impersonation) ... are typically lumped together under identity theft.

further drift, past posts mentioning motor vehicle accidents (usually related to comparisons with other types of exploits/vulnerabilities)
https://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2003m.html#17 Throughput vs. response time
https://www.garlic.com/~lynn/2003o.html#25 Any experience with "The Last One"?
https://www.garlic.com/~lynn/2004c.html#36 If there had been no MS-DOS
https://www.garlic.com/~lynn/2004j.html#29 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004l.html#45 "Perfect" or "Provable" security both crypto and non-crypto?
https://www.garlic.com/~lynn/2005r.html#36 X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
https://www.garlic.com/~lynn/2006e.html#34 CJ Date on Missing Information
https://www.garlic.com/~lynn/2006p.html#5 sorting
https://www.garlic.com/~lynn/2006p.html#12 sorting

misc. past posts in this thread:
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#15 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#17 Securing financial transactions a high priority for 2007

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 11:21:29 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
I am planning to tell the world you think our UNIX design was better than the IX/370 UNIX design unless you object. (Charts appended)

re:
https://www.garlic.com/~lynn/2007c.html#14 How many 36-bit Unix ports in the old days?

old email trying to get me into trouble
https://www.garlic.com/~lynn/2007c.html#email850108

other recent posts containing old email about various "unix under vm" subjects
https://www.garlic.com/~lynn/2007b.html#3 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#39 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007c.html#19 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007c.html#20 How many 36-bit Unix ports in the old days?

Date: 12/09/86 07:51:50
From: somebody in austin
To: wheeler
Subject: /370 UNIX

Lynn, it was suggested I get your thoughts on file mapping under a /370 UNIX. about is if we can enhance IX/370 by using a true mapped file system for I/O. (What I'd like to eventually do is get AIX on /370 with a new kernel, which could either be brand new, a merged SSS-IX/370 kernel, or a modified CP/XA supervisor (a la VM/IX). Native or virtual machine is still an open question.)

In any case, we might be able to help IX/370 in the short run and get the mapping interface in for the long term. Of course, the first thing to consider is whether there are any interesting applications that would run on /370 and move to the interface. Because I doubt there will be many, the problem is only marginally interesting. Considering it anyway, the two ways I can think of are to in some way use your PAM; or to use VAM, which is already in the SSS. In both cases, I think we would have to muck with the UNIX buffer and I/O mgt to use the underlying I/O. Still, it's worth thinking about.

Have you considered this before? Do you have any ideas? Anything you have to offer would be appreciated. Thanks.

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

"SSS" was tss/370 rpq for (internal) at&t ... recent reference
https://www.garlic.com/~lynn/2007b.html#3 How many 36-bit Unix ports in the old days?

Date: 12/09/86 07:56:56
From: wheeler
To: somebody in austin

early on, I worked with the people in Palo Alto on the 4.2 370 port ... tried to convince them to use PAM ... however they had some peculiar ideas on what CP mods would be acceptable to the company and which wouldn't be (i.e. absolutely minimum mods. necessary).

The mods. I have for CMS start out rather trivial and essentially use PAM diagnose almost the same way that standard diagnose is used (i.e. file is windowed thru page buffers instead of memory mapping complete file at one time, rather trivial mod. to standard CMS EDF/4k support). That buys some incremental improvements to CMS w/o requiring rewriting file system to do true memory map. Some additional hooks into CMS DMSMOD (loadmod/genmod) provides memory mapping for program modules (one of the primary reasons that PAM was picked up and shipped for at/370).

One of the side affects of PAM is that it buys device independence for the virtual machine. There are also some pathlength advantages and other performance improvement advantages associated with using the PAM interface ... independent of going to memory mapped file system support.

We are also looking at some trivial enhancements that PAM can take advantage of expanded store. There are two mechanisms, enhancements to PAM to cache minidisk page records in expanded store ... and creating expanded store t-disks (i.e. we already have pam support for 3880 -11 and -21 ... with two variations, standard mdisks require special synchronous writes down the base exposure, and volatile tdisks using standard -11/-21 page i/o with no special handling of writes). expanded store Minidisk page record caching is little more complex since basically the equivalent of -11/-21 function has to be incorporated into DMKPAM.

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

lots of past posts mentioning pam implementation ... i originally implemented in the early 70s on cp67
https://www.garlic.com/~lynn/submain.html#mmap

"-11" was 3880-11/ironwood cache ... mentioned recently here
https://www.garlic.com/~lynn/2007c.html#0 old discussion of disk controller cache

"-21" was 3880-21/sahara, an ironwood upgrade to 32mbytes (from 8mbytes) and misc other enhancements.

"expanded store" was introduced on 3090 ... which was basically system level (software managed) electronic "cache" ... recent post about record I/O tracing and modeling various caching strategies ... showing for any given amount of aggregate cache ... single global system cache outperformed any partitioning of that (aggregate) electronic store (aka analogous to local LRU).
https://www.garlic.com/~lynn/2007.html#3 The Future of CPUs: What's After Multi-Core?

and, of course, this is similar to my whole global LRU theme dating back to when i was an undergraduate in the 60s ... some old email mentioning global LRU
https://www.garlic.com/~lynn/lhwemail.html#globallru
and collected past posts mentioning page replace, global LRU, caches, etc
https://www.garlic.com/~lynn/subtopic.html#wsclock

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 13:54:08 -0700

Walter Bushell <proto@panix.com> writes:
And now, one has to break things down finer and arrange tasks that can be initiated at the same time into separate threads.

there is long running thread over in comp.arch called "Why so little parallelism?" with a recent reference to
http://research.microsoft.com/~simonpj/papers/stm/index.htm

and some comments in the thread about leveraging the spreadsheet metaphor for a programming paradigm that is more easily threaded/parallelized.

something of a side note, there was something similar suggested in ieee chip workshop last year; basically go to a much higher level functional specification that allows the underlying infrastructure much greater latitude in how processing of the program specification may execute.

misc. past postings in this thread with references to the comp.arch thread
https://www.garlic.com/~lynn/2006y.html#24 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2006y.html#29 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2006y.html#31 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007b.html#57 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007c.html#4 "The Elements of Programming Style"

Special characters in passwords was Re: RACF - Password rules

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Special characters in passwords was Re: RACF - Password rules .
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 21 Jan 2007 15:24:05 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
... several times Boyd quoted Guderian (before the blitzkrieg) as directing verbal orders only ... for much the same reason (minimizing troops worrying that afterwards getting blamed for making less than optimal decisions in the fog of war, doing something would be better than decision paralysis).

re:
https://www.garlic.com/~lynn/2007b.html#37 Special characters in passwords was Re: RACF - Password rules .

for other boyd drift ... from somebody's website:
http://www.users.cloud9.net/~bradmcc/welcome.html

here is account of one of Boyd's briefings ... at YKT research
http://www.users.cloud9.net/~bradmcc/thoughts.html#OODA

I remember driving him back to the airport from ykt and having a really lengthy discussion in the car ... so it seems that it must have been La Guardia ... rather than Westchester County a (but for some reason i remember driving down 684, which goes right by Westchester County airport ... I normally would the Taconic to La Guardia from YKT).

This is discussion of Boyd's briefing that was eventually scheduled in San Jose research auditorium.

Date: 04/13/83 15:33:16
From: wheeler

re: talk; talk is tentatively scheduled for the 2nd week in May to have Boyd (sp?) out (col. from DC). Full research auditorium is only available on the 9th. Other choice is Los Gatos lunch room ... especially since they are footing the bill. Be nice to shoot for 30 people, I would like to have room for 50 just in case ... also most rooms are more comfortable if they aren't full (side wings on research auditorium are pretty tight with 30+ people).

Talk is 4.5 to 5 hours. For Los Gatos that means running late with an afternoon talk only or long break across lunch so that room can be arraigned, re-arraigned, re-arraigned, and then re-arraigned again.

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

Date: 05/13/83 12:00:55
From: wheeler

re: friday; cc: friday;

Nice that the sun shines around here ... even if it does seem infrequent. For those that attended the Boyd pitch on Monday, I have the foil copies. We'll have hard copy to work discussions from. Even we can figure out what he was talking about, we might be able to get things straight so if we heard it again ... the subject would be understandable.

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

And email drafting abstract announcement for talk at YKT research (and Boyd's talk did overrun the allotted time).

Date: 83/05/16 17:05:17
To: wheeler

Does this sound halfway plausible as an abstract for Boyd?

PATTERNS OF CONFLICT (9:00-11:30 and 1:00-3:00)

This presentation examines the role of conflict in military history and examines how that challenge was dealt with. Although presented in a military context, the presentation includes specific observations and guidelines for dealing with conflict in non-military situations, and much of the material is useful in inter-personal and organizational situations. Specific guidelines are presented for

Situational analysis - identification of resources available for dealing with a problem; analysis of the strengths, weaknesses and limits of available resources; analysis of challenger's capabilities.

Adaptive strategy development - dealing with changes in the situation

Anticipation of competitive reaction

Action plan implementation

Special emphasis is placed on organizational dynamics and coordination.

ORGANIC DESIGN FOR COMMAND AND CONTROL (3:15-4:00)

This short talk builds on the material presented in Patterns of Conflict and describes the importance of individuals to a functioning organization, and considers the role of harmony among individuals within an organization as an important aspect of the ability to meet the goals of that organization. The talk also attempts to indicate situations in which an organization will have difficulty meeting its goals.

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

collected posts mentioning Boyd &/or OODA-loops
https://www.garlic.com/~lynn/subboyd.html#boyd
misc. URLs from around the web mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 15:47:11 -0700

greymaus writes:
Re big accounts being stolen.. the point has been made that if someone has a big CC account, it is only possible to use a small number of them before the fact is noticed.. 50 accounts would be as useful for the crooks as 500000..

re:
https://www.garlic.com/~lynn/2007c.html#22 Securing financial transactions a high priority for 2007

actually some of these crooks are fairly crafty ... they've stolen millions of records ... where the original breach wasn't noticed i.e. say credit card transaction logs at retail chain involving lots of different kinds of credit cards involving people from all over the country ... my old, often referenced post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

Then fraudulent transactions were performed against accounts quite a bit later with significant randomness of pattern at widely dispersed geographic locations. It frequently can take quite some time to determine any possible commonality in the fraudulent transactions, recognizing where a possible breach might have occur ed and/or even when. 500,000 accounts is quite useful in this scenario ... since it allows quite a bit large degree of randomness by the crooks.

in some of these scenarios they've managed to take on the order of avg of thousand per account and total take easily runs to millions before pattern/commonality was identified and then authorities could characterize all the possible accounts at risk and have the related cards re-issued (i.e. with different account numbers ... and deactivating the old account numbers). a retail store with transaction log involving only fifty different accounts wouldn't result in total take getting any where close to the millions (and data mining for commonality for such a small community of transactions would be relatively easy to spot).

lots of past posts on fraud, threats, vulnerabilities, exploits, etc
https://www.garlic.com/~lynn/subintegrity.html#fraud

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 16:38:27 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
actually some of these crooks are fairly crafty ... they've stolen millions of records ... where the original breach wasn't noticed i.e. say credit card transaction logs at retail chain involving lots of different kinds of credit cards involving people from all over the country ... my old, often referenced post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

Then fraudulent transactions were performed against accounts quite a bit later with significant randomness of pattern at widely dispersed geographic locations. It frequently can take quite some time to determine any possible commonality in the fraudulent transactions, recognizing where a possible breach might have occur ed and/or even when. 500,000 accounts is quite useful in this scenario ... since it allows quite a bit large degree of randomness by the crooks.

in some of these scenarios they've managed to take on the order of avg of thousand per account and total take easily runs to millions before pattern/commonality was identified and then authorities could characterize all the possible accounts at risk and have the related cards re-issued (i.e. with different account numbers ... and deactivating the old account numbers). a retail store with transaction log involving only fifty different accounts wouldn't result in total take getting any where close to the millions (and data mining for commonality for such a small community of transactions would be relatively easy to spot).

re:
https://www.garlic.com/~lynn/2007c.html#26 Securing financial transactions a high priority for 2007

the latest in the ongoing saga

Credit Card Data, A Hack, And A Rush To Contain The Damage
http://www.informationweek.com/showArticle.jhtml?articleID=196902211

from above:
Given TJX's size--its assets include 826 T.J. Maxx, 751 Marshalls, and 271 HomeGoods locations--the security breach into the portion of its computer network handling credit card, debit card, check, and merchandise return transactions is proportionately worrisome. The company knows some customer information was stolen but admitted in a statement that the extent of the theft is unknown.

... snip ...

recent posts with a number of URLs on the subject
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007

including this one

Retail security breach may be biggest in U.S.
http://www.iht.com/articles/2007/01/19/business/data.php

from above:
While the investigation is in its early stages, the number of accounts potentially exposed at TJX could exceed the 40 million involved in a data breach at the payment processor CardSystems Solutions in 2005, people briefed on the findings said Thursday.

... snip ...

Will they go ahead and re-issue possibly 50 million cards with new account numbers (deactivating the old account numbers)?

What would happen if something like this were to happen ever several months?

another post not only references the above reference about possibly the largest in the US

https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007

but also references this one

TJX Hack Highlights Payment Information Insecurity
http://www.informationweek.com/showArticle.jhtml;jsessionid=MFDDZSZDTWEVAQSNDLRCKHSCJUNN2JVN?articleID=196902075

from above:
The cost of data breaches, whether the information is lost or stolen, continues to escalate, costing companies an average of $182 per compromised record.

... snip ...

it is interesting phrasing ... is that $182/account to rectify the situation (identify the compromised accounts, deactivate the old accounts, and re-issue cards for new accounts) ... and/or does it also include any fraud, i.e. is that the total fraud+loss+expense related to any breach? Even at only $182/account, if there really is only 40 million compromised records (rather than more), a data breach of that size possibly would run $7.28B??

lots of past posts on fraud, threats, vulnerabilities, exploits, etc
https://www.garlic.com/~lynn/subintegrity.html#fraud

other posts in this thread:
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#15 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#17 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#22 Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Sun, 21 Jan 2007 17:11:53 -0700

and
https://www.garlic.com/~lynn/2007c.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#27 Securing financial transactions a high priority for 2007

here is one from last spring regarding "brand, new" chip-and-pin deployment at Shell petro stations in the UK

Petrol giant Shell has suspended chip-and-pin payments in 600 UK petrol stations after more than GBP1m was siphoned out of customers' accounts.
http://news.bbc.co.uk/2/hi/uk_news/england/4980190.stm

this appears to have only involved compromising a modest number of transaction processing at pumps (i don't remember anybody coming out and say how many pumps were actually compromised) and a few(?) thousand accounts.

some more on the compromise from last spring/summer

Eight held over chip and pin fraud
http://www.guardian.co.uk/uklatest/story/0,,-5803656,00.html Eight held over chip and pin fraud
http://www.thisislondon.co.uk/news/articles/PA_NEWA19204681146904793A00?source=PA%20Feed Eight held over chip and pin fraud
http://www.24dash.com/content/news/viewNews.php?navID=34&newsID=5478

the customers start noticing and reporting suspicious transactions on their accounts. the datamining starts looking for common factors involving reported accounts. with a relatively small population of accounts ... datamining relatively quickly identifies processing that was common across all the accounts with fraudulent transactions. when a common compromise is identified ... then they can re-issue cards for all possible accounts processed at the point(s) of compromise (deactivating the old accounts).

with a much large population of accounts ... crooks have a much greater latitude in attempting to obfuscate where the possible compromise might have happened

... numerous postings specifically discussing compromise of this technology
https://www.garlic.com/~lynn/subintegrity.html#yescard

and lots of past posts mentioning fraud, vulnerabilities, threats, compromises, and/or exploits
https://www.garlic.com/~lynn/subintegrity.html#fraud

Being "Open" (Was: Mainframe vs. "Server")

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Being "Open" (Was: Mainframe vs. "Server")
Newsgroups: bit.listserv.ibm-main
Date: Mon, 22 Jan 2007 00:48:02 -0700

Edward Jaffe wrote:
This line of discussion is tangential at best. Open source is *not* a requirement for conformance of any operating system or application component to open standards. For example, the use of TCP/IP networking is considered "open". There is no requirement that the source code for the TCP/IP stack itself be made available.

This paper may be of interest: http://www.csrstds.com/openstds.html.

while that may be strictly true... one of the things that helped TCP/IP prevail was the availability of source implementations.

strictly speaking, one of the things that differentiated IETF standards from ISO standards was that IETF required two or more interoperable implementations as part of the standardization process (while this didn't mandate availability of source ... source availability could sure help). In the late 80s thru the early 90s ... multiple organizations had specified eliminating tcp/ip and required conversion to ISO OSI implementations ... including the federal gov. with GOSIP.

At an "official" level, a major differentiation between IETF and ISO was the requirement for not only some implementation (before final passing as a standard) but two or more interoperable implementations (i.e. a standard could pass in ISO w/o there ever being any implementations).

the mainframe tcp/ip product stack had been done in vs/pascal. however, there were a very large number of platforms that deployed BSD tcp/ip stack implementation written in C ... i.e. sometimes being an open standard isn't sufficient for it to become widely adopted ... but ready availability of source implementation can significantly improve wide adoption. An open standard process may not require or mandate open source (just interoperable implementations) ... but ready availability of source can significantly improve uptake/adoption.

within standards process, this may sometimes be recognized with a readily available "reference model" implementation. even then open source may not be an absolute requirement ... other than readily available source for portable implementation that can be used by lots of different organizations at least for development and testing.

a lot of times, organizations with proprietary device drivers aren't attempting to address wide portability and adoption .. just some sort of competitive advantage for their specific hardware product. these organizations will typical strictly control the portability and where their product may be operational/available. they may even consider portability across a wide-range of different environments not an interesting market consideration (and/or they've made business trade-off decision regarding wide portability vis-a-vis competitive advantage).

collected past posts mentioning having done the rfc1044 implementation (in vs/pascal) for mainframe tcp/ip stack
https://www.garlic.com/~lynn/subnetwork.html#1044

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 22 Jan 2007 10:18:45 -0700

jmfbahciv writes:
Now think about on-line banking and shopping when the user's PC is wireless.

the transition from VANs (value-added networks) to internet somewhat originally carried some assumptions that you were moving from a environment with some degree of security to a somewhat totally open anarchy ... with lots of evesdropping and man-in-the-middle.

early move of online banking to VANs to internet ... had lots of people worrying about the wide open anarchy of the internet (this was really hot topic at various conferences in the mid-90s). any move from fixed-wire internet to wireless internet doesn't actually change the nature of the concerns ... although it may now occur to more people that there are issues with wireless ... when they weren't paying any attention when it involved wires.

so recent post in this thread mentioning the online banking scenario
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007

above references these posts which discuss in a little more detail
https://www.garlic.com/~lynn/2007b.html#53 Forbidding Special characters in passwords
https://www.garlic.com/~lynn/2007b.html#54 Forbidding Special characters in passwords

so part of the whole issue of looking for compensating security in the move from VANs to the internet was SSL (issue of internet wires/wireless doesn't actually impact the nature of the problems, but possible impacts the perception). However, SSL wasn't just encryption, it was a series of processes that were necessary to actually provide end-to-end security. When it became common to bypass some of these steps ... it effectively could result in compromising the whole end-to-end operation ... even tho encryption continued to be used. the above posts go into some of this discussion ... how some of the ways that SSL was deployed resulted in negating some of the security operations.

for other drift ... as mentioned in these posts, in the early 80s when portable terminals and PCs were starting to come into use for accessing corporate systems & email ... there was some detailed vulnerability analysis done. a really significant vulnerability was identified with most hotel pbx rooms. while it was direct telco call to corporate systems ... and no internet was involved ... there was still a significant possibility that hotel pbx could be compromised and there would be evesdropping and/or mitm-attacks (similar to what was later identified as internet vulnerabilities). the countermeasure was to build a special corporate encrypting modem that was required used for all offsite access to corporate systems
https://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
https://www.garlic.com/~lynn/2003j.html#17 pbx security from 20 years ago
https://www.garlic.com/~lynn/2004g.html#34 network history
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006p.html#35 Metroliner telephone article
https://www.garlic.com/~lynn/2006t.html#5 Are there more stupid people in IT than there used to be?
https://www.garlic.com/~lynn/aadsm26.htm#23 It's a Presidential Mandate, Feds use it. How come you are not using FDE?

and other posts/threads where the above encryption post leaked over to:
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#1 Decoding the encryption puzzle
https://www.garlic.com/~lynn/2007c.html#9 Decoding the encryption puzzle

old post about working with small client/server startup for doing financial transactions ... and adopting this technology they had called SSL ... parts of which have since come to be called electronic commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

and misc past posts going into some more detail of issues with how SSL was deployed and used ... that could undermine its original end-to-end security requirements.
https://www.garlic.com/~lynn/aadsm14.htm#5 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
https://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model
https://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/2003n.html#10 Cracking SSL
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004q.html#42 browser without "padlock" secure?
https://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#44 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005l.html#19 Bank of America - On Line Banking *NOT* Secure?
https://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
https://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
https://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2006c.html#36 Secure web page?
https://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor
https://www.garlic.com/~lynn/2006k.html#2 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006s.html#11 Why not 2048 or 4096 bit RSA key issuance?
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 22 Jan 2007 10:46:17 -0700

jmfbahciv writes:
I've heard nothing about opening new accounts without verification. In olden days, the bank tellers knew their customers by name, which they go to, their kids' names, their grandkids' names and where everybody lived because the tellers went past these houses when driving. Then the local banks gets bought out by a conglomerate, fires all the local tellers, and new people show up who have just moved to the area.

re:
https://www.garlic.com/~lynn/2007c.html#22 Securing financial transactions a high priority for 2007

for just one specific category, try using search engine with the terms "mortgage fraud" and "identity theft"

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 22 Jan 2007 13:50:30 -0700

Steve O'Hara-Smith <steveo@eircom.net> writes:
This should not be a major problem as long as the encryption used on the SSL link is unbroken. Of course if that gets compromised all the bets are off.

as per
https://www.garlic.com/~lynn/2007c.html#30 Securing financial transactions a high priority for 2007

the issue wasn't the encryption. ssl was suppose to be both a countermeasure to impersonation and mitm-attacks ... as well as countermeasure to evesdropping attacks with encryption. the encryption can still work ... but because of some issues in how ssl is used (as per numerous previous references) there still are a large number of impersonation and mitm-attacks ... for instance
https://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"

some number of past posts mentioning mitm-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

the other issue is that SSL encryption was just compensating procedures for moving sensitive operations from VANs (and other somewhat less vulnerable communication mechanisms) to the wild anarchy of the internet. it didn't otherwise improve the backroom situation ... i.e. just hiding the transaction while it was "in-flight" ... and not doing anything about when the transaction was in the backroom and/or "at-rest".

so something like 70percent of identity fraud involves insiders ... while SSL is effectively only a countermeasure to outsider attacks directly on the transaction "in-flight" ... aka trying to maintain the previous status quo ... pre-internet, pre-e-commerce.

a possibly overlooked problem was that with the advent of the internet, there was a large increase in the backrooms also being connected to the internet; so while SSL tried to maintain the status quo in the transition of transaction to the wild anarchy of the internet ... it didn't address the other new vulnerability that electronic commerce opened up ... which was the vulnerability of a lot of new backrooms connected to the internet and therefor vulnerable to attacks over the internet (separate from the fact that backroom and other infrastructures are still subject to insider attacks ... which supposedly continue to account for seventy percent of identity fraud).

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

other past posts in this thread:
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#15 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#17 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#22 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#30 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#31 Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 22 Jan 2007 14:12:39 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
the issue wasn't the encryption. ssl was suppose to be both a countermeasure to impersonation and mitm-attacks ... as well as countermeasure to evesdropping attacks with encryption. the encryption can still work ... but because of some issues in how ssl is used (as per numerous previous references) there still are a large number of impersonation and mitm-attacks ... for instance
https://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"

some number of past posts mentioning mitm-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

re:
https://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007

collected past posts mentioning account number exploits involving harvesting, skimming, evesdropping, etc
https://www.garlic.com/~lynn/subintegrity.html#harvest

there have actually been some number of past threads discussing the fact that since backroom operations yield up such massive amount of data (in outsider attack) ... that even if SSL encryption didn't exist ... they still might not be a lot of transaction "in-flight" evesdropping attack. For the amount of work, attacking the backroom transaction log provides possibly ten times to thousands of times more fraud potential (for the attack effort) vis-a-vis evesdropping (why pick up pennies and nickles when there are so many hundred dollar bills laying around).

for a little additional drift ... past posts that describe various characteristics and comment that even if the planet was buried miles deep in encryption ... it still wouldn't be sufficient to prevent account info leakage
https://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
https://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
https://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
https://www.garlic.com/~lynn/2005k.html#26 More on garbage
https://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006p.html#8 SSL, Apache 2 and RSA key sizes
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Mon, 22 Jan 2007 14:37:43 -0700

sort of this cross-over from another thread
https://www.garlic.com/~lynn/2007b.html#17 How Many 36-bit Unix ports in the old days?

reference from above:
The Standish Group's original study concluded that software projects costing less than $1 Mil had a probability of success of 54%, projects costing 1-5 Mil or thereabouts had a probability of success of 17% and projects over $5 Mil had a probability of success of only 7%. These numbers are probably over five years old but the results may still be the same.

... snip ...

so slightly different drift

MIT Develops Measures To Predict Performance Of Complex Systems
http://www.sciencedaily.com/releases/2007/01/070119115301.htm

from above:
The 13 leading indicators defined by the MIT team include risk handling trends. This indicator would be used by management to determine whether a project team is proactively handling potential problems (or risks) at the appropriate times with the goal of minimizing or eliminating their occurrence. If the actions to address a given project risk are not taken, then there is a higher probability that the risk will be realized, resulting in negative impact to project cost, schedule, performance or customer satisfaction.

... snip ...

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 22 Jan 2007 15:59:06 -0700

Morten Reistad <first@last.name> writes:
Is this not a matter of simple aliasing ?

You have one account number that is the master. This is the one the tax authorities get, and the one that carries the authorizations.

The number of this account does not work for actual transactions, except queries for audits, and access grant/revocation through an out of band channel.

Attached to this ID are 1..n actual transaction IDs. Like credit card numbers, debit card numbers etc.

These are granted and revoked easily. Transactions to revoked numbers give instant alarms. Etc.

Getting flashbacks to cache coherency algorithms here.

so this is effectively what does happen. the issue is that the transaction (account) numbers are involved in backroom processes at tens/hundreds of millions of intermediate points ... and it isn't until you get into the bowels of the financial infrastructure do you get to anything else. all the compromises and vulnerabilities are involving the tens/hundreds of millions of intermediate points and then using the information ... effectively for replay attacks.

revoking a transaction (account) numbers ... includes issuing new cards. also because of various things ... valid transactions might be delayed for several days before they reach a financial institution ... and all backroom processing involving a transaction (and the associated number) may drag on for a couple months.

there have been some deployments of "one-time numbers" as a countermeasure to replay attacks ... but that is pushing a lot of complexity onto the end consumer. recent post mentioning one-time numbers
https://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#15 Securing financial transactions a high priority for 2007

in the mid-90s, the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 financial standard for all retail payments
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

instead of trying to protect (encrypt/hide) the account number as countermeasure to replay attacks ... X9.59 eliminated replay attacks ... x9.59 defined a transaction to require strong authentication and strong integrity. account numbers used in x9.59 transactions could not be used in transactions that weren't strongly authenticated and having strong integrity. It was no longer possible for crook to acquire an account number (used in x9.59 transactions) and re-use it (in some sort of replay attack) ... since it wouldn't be valid w/o the appropriate authentication. This is slightly analogous to you "master" account number that isn't usable for transactions ... however, in x9.59 scenario ... the account number can only be used in x9.59 transactions ... and a x9.59 transaction has a lot of other armoring and countermeasures against fraud.

from the security PAIN acronym

P ... privacy (sometime CAIN & confidentiality) A ... authentication I ... integrity N ... non-repudiation

... X9.59 uses authentication and integrity to provide security for financial transactions ... furthermore, it can be claimed that it is no longer necessary to "hide" (encrypt) a x9.59 transaction in order to preserve the integrity of the financial infrastructure. Any attacker obtaining information about previous (x9.59) transaction (evesdropping, breaking encryption, backroom logs, backroom databases, insiders, outsiders, etc) cannot use the information to perform a fraudulent transaction. This eliminates the requirement for SSL transactions on the internet (for hiding account numbers) ... but also eliminates the risk associated with current spat of data breaches and security breaches. X9.59 doesn't do anything about preventing such breaches ... it just eliminates the usefulness of such breaches to crooks for doing fraudulent transactions.

in previous post in this thread ... it was also mentioned that work was done on x9.59 to try and meet an EU statement (from the mid-90s) that all retail electronic transactions should be as anonymous as cash ... at least making x9.59 privacy agnostic ... not requiring name, address, phone number, driver's license ... and/or other mechanisms at the point of the retail transaction (reducing the ways that various kinds of personal and privacy information can show up in merchant backroom processing).
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007

for some drift, a few posts referencing cache alias/synonym and/or caches with more than single directory/index structure
https://www.garlic.com/~lynn/2003j.html#42 Flash 10208
https://www.garlic.com/~lynn/2004h.html#16 Page coloring required?
https://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC
https://www.garlic.com/~lynn/2006y.html#36 Multiple mappings
https://www.garlic.com/~lynn/2006y.html#40 Multiple mappings

========

previous posts in this thread about x9.59 addressing both the transaction "in-flight" risks as well as the transaction "at-rest" risks.
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#17 Securing financial transactions a high priority for 2007

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 22 Jan 2007 16:17:29 -0700

Morten Reistad <first@last.name> writes:
Signing batch entry with your key dongle would help a lot against this problem. But, no, the banks have decided to trust the PC once a single, valid login has been performed.

re:
https://www.garlic.com/~lynn/2007c.html#26 Securing financial transactions a high priority for 2007

note that in the EU ... not only is signing an transaction an issue ... providing for authentication and integrity ... recent post mentioning authentication and integrity with x9.59.
https://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007

... but the EU finread standard ... lots of past posts discussing EU finread standard
https://www.garlic.com/~lynn/subintegrity.html#finread

attempted to address the environment in which the signing was performed i.e. countermeasures for situation where the "transaction you see" is NOT the "transaction you are signing" ... as well as keyloggers and various other vulnerabilities involving PIN-entry associated with two-factor authentication tokens.

hardware token by itself is not necessarily sufficient ... as pointed out by vulnerabilities raised by finread activity.

there can also be issues with how the infrastructure associated with a hardware token is designed and implemented. in the yes card exploit associated with one kind of deployed hardware tokens ... some even made the unkind remark about the hardware token even increased the vulnerability of the payment system compared to magstripe cards. misc. past posts mentioning yes card exploit
https://www.garlic.com/~lynn/subintegrity.html#yescard

the scenario was that the point-of-sale terminal would initially authenticate the token ... and then ask the token three questions ... technology to capture the authentication information was effectively the same as that used to skim/harvest magstripe information. A counterfeit yes card would then be loaded with that valid authentication material ... and a yes card would be programmed to always answer YES to the terminals questions

1) was the correct PIN entered 2) should this be an offline transaction 3) is the transaction within the account limit

i.e. if it was going to be an offline transaction ... then the countermeasure of deactivating an account number is no longer effective. an attacker didn't need to know the correct PIN since a yes card would always answer YES regardless of what was entered. also since it was going to be an offline transaction, then the terminal had no way of knowing whether the account's limit had been exceeded other than asking the token.

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Mon, 22 Jan 2007 22:39:51 -0700

re:
https://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007

and post with URL pointers to some recent articles
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007

a few more recent articles

Latest Breach May Force a New Approach to Data Security
http://www.digitaltransactions.net/newsstory.cfm?newsid=1226

from above:
In a research note she was preparing for Gartner clients on Monday, Litan says, Gartner believes that it's impractical for the card industry to expect up to 5 million retailers to become security experts and change their systems to fix security holes. It's time for the banks to own up to the problem and accept responsibility. They must make changes to the payment system so that, even if data are stolen, the data are useless to the thieves.

... snip ...

can you say security proportional to risk?
https://www.garlic.com/~lynn/2001h.html#61

sounds like part of what x9a10 financial standard working group was working starting in mid-90s ... recent related post
https://www.garlic.com/~lynn/2007c.html#33 Securing financial transactions a high priority for 2007
in any case, can you say x9.59?
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

and other news URLs

Dear [Blank]: You've Been Breached
http://www.fool.com/personal-finance/general/2007/01/22/dear-blank-youve-been-breached.aspx
Targetted Hack Compromises Credit Database for TJ Maxx, Marshalls
http://www.dailytech.com/article.aspx?newsid=5784
Some customers' accounts closed after data breach
http://news.bostonherald.com/localRegional/view.bg?articleid=178301 Computer breach at U.S. retailer began last May, detected in December
http://www.canada.com/topics/technology/story.html?id=ccc7326a-97dd-4dfd-bd6a-44a5595cffbf&k=29093 Credit Card Companies Watchful After TJX Data Breach
http://www.thebostonchannel.com/news/10800988/detail.html?rss=bos&psp=news
Breach at TJX Puts Card Info at Risk
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=280123&taxonomyId=17&intsrc=kc_top&taxonomyId=17&intsrc=kc_top
Probes launched into data security breaches
http://www.theglobeandmail.com/servlet/story/LAC.20070119.RCIBC19/TPStory/Bu TJX Security Breach Forces Some Account Closures
http://cbs4boston.com/local/local_story_021164857.html Security boosted after data breach
http://www.syracuse.com/business/poststandard/index.ssf?/base/business-7/1169287569176740.xml&coll=1
Elkhart Man's Identity Stolen in Connection to TJ Maxx Security Breach
http://www.wndu.com/home/headlines/5282856.html

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Tue, 23 Jan 2007 10:02:10 -0700

Walter Bushell <proto@panix.com> writes:
Sounds obvious to me. Sam & Ella's coffee shop cannot afford to hire a security expert.

re:
https://www.garlic.com/~lynn/2007c.html#37 Securing financial transactions a high priority for 2007

try my oft referenced post, security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

you can plug in different numbers than the example ... but it still comes out pretty much the same ... security to the merchant is some percent of the profit they make on the transaction. what the crook sees ... and therefor how strongly they are motivated ... and therefor what the actual risk is ... is effectively the credit limit on the account .... the account credit limit tends to be easily an order of magnitude or two larger than any small percent of transaction profit. This disparity (between the merchant resources and the risk) tends to remain relatively proportional, regardless of the merchant size.

a side issue is that for at least some market segments ... like c-stores ... payment system fees are already their largest expense, additional security requirements could significantly drive that up.

and from previous post
https://www.garlic.com/~lynn/2007c.html#27 Securing financial transactions a high priority for 2007

Interchange Fees: The tipping point
http://www.cyberwarzone.com/united-states-leaking-1tb-data-daily-foreign-countries

from above
Fed up with out-of-control interchange fees, retailers are fighting back with concerted legal and educational tactics -- and, in some cases, proactive offensives of their own.

... snip ...

http://www.epaynews.com/newsletter/epaynews322.html
gone
404
but there is the way-back machines
https://web.archive.org/web/20051031071238/http://www.epaynews.com/newsletter/epaynews322.html

from above:
Convenience store operators can make more money on a 12-ounce cup of coffee than they can on a 12-gallon tank of gas. Credit card fees now account for almost half of a typical store's expenses - more than labor.

... snip ...

Payments Technologies Vie For Banks' IT Dollars
https://web.archive.org/web/20060526221137/http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1147439455861413176&block=

from above:
Payments revenues at European banks typically represent 10 per cent of annual revenues, while in the US, this figure is nearer to 40 per cent

... snip ...

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Tue, 23 Jan 2007 10:07:46 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
and from previous post
https://www.garlic.com/~lynn/2007c.html#27 Securing financial transactions a high priority for 2007

re:
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007

oops ... finger fumble typo ... the referenced post should be:

https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007

Point-of-Sale security

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Point-of-Sale security
Newsgroups: comp.security.firewalls
Date: Tue, 23 Jan 2007 21:05:08 -0700

"Dale I. Green" <dig@notmail.com> writes:
Practically, I don't see how we could afford this level of security, especially from an expertise standpoint. The restaurant is a seasonal mom-n-pop quick-service (window) shop. i.e. The budget is tight.

Latest Breach May Force a New Approach to Data Security
http://www.digitaltransactions.net/newsstory.cfm?newsid=1226

somewhat related thread here
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007

above reply to somebody's comment about the Gartner article:
Sounds obvious to me. Sam & Ella's coffee shop cannot afford to hire a security expert.

... snip ...

and old post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Wed, 24 Jan 2007 10:17:58 -0700

jmfbahciv writes:
Well, TOPS-10's seelling point was it's recovery time from a system crash. It was always an ongoing project to shave off as much time as possible so that users didn't have to go out to lunch and dine before the system was back up and able to grant login services.

i've often made reference to this multics story comparing cp67 recovery time to multics
https://www.multicians.org/thvv/360-67.html

most recently in this previous post in this thread
https://www.garlic.com/~lynn/2007c.html#21 How many 36-bit Unix ports in the old days?

the above post was numerous changes, including how recovery in the case of power-failures ... where there wasn't system crash processing that had saved all system infrastructure information ... and startup/boot/ipl had to reconstruct much of the system status.

the original intention of the power-failure recovery changes ... was mostly about drastically changing how the system "checkpointing" was being done (regularly saving little pieces of system status to be used in case of recovery after power failure) because it was drastically impacting some aspects of system thruput ... namely some network processing with respect to HSDT
https://www.garlic.com/~lynn/subnetwork.html#hsdt

this was ongoing system degradation in anticipation of power failure .... whether one occurred at all. Secondary was being able to drastically improve recovery time in case a power failure had occurred.

discussed were also a number of other enhancements that improved thruput (again, motivated by HSDT requirement) ... including some changes that corporate internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

backbone people referred to as turbo ... old email:
https://www.garlic.com/~lynn/2007c.html#email860418

the best is not crashing at all ... post about various (vm370) system enhancements improving uptime
https://www.garlic.com/~lynn/2007c.html#12 Special characters in passwords was Re: RACF - Passwords rules

and old email discussing effect of the improvements at STL (now called silicon valley lab)
https://www.garlic.com/~lynn/2007c.html#email830709

Keep VM 24X7 365 days

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Keep VM 24X7 365 days
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Wed, 24 Jan 2007 11:24:01 -0700

Tom Duerbusch wore:
There are multiple layers to this...

1. As others have said, you can switch to another LPAR on the same or different hardware. 2. I've read about, but haven't actually used, a facility in Linux to switch a work load from one Linux machine to another. I think that started in SLES8. 3. The major applications, such as Oracle, have a facility to switch to another Oracle image running somewhere else (with both being in sync).

It all depends on what you need and what you are willing to pay for. That last few minutes towards true 24X7 is rather costly.

It isn't really a VM issue because VM isn't a true 24X7 operation system. With VM, we can fake things and come close to true 24X7, but compared to z/OS and parallel sysplex, not close.

some recent postings with old historical references

a couple recent posts about fast recovery after failure
https://www.garlic.com/~lynn/2007c.html#21
https://www.garlic.com/~lynn/2007c.html#41

i had worked on complete rewrite of i/o subsystem for the disk engineering and product test labs (bldg. 14&15) ... when I started they were doing all their "testcell" testings in stand-alone environment. They had done some attempts with MVS ... but at the time, MVS MTBF (system crash or hang) was 15 minutes. The point of i/o subsystem rewrite was to make it absolute bullet proof so that they could have "on-demand" testing with multiple concurrent "testcells".
https://www.garlic.com/~lynn/subtopic.html#disk

some of this got me in lots of trouble with manager of MVS RAS when I happen to mention some of it (like it was my fault that MVS was crashing) ... reference to one example:
https://www.garlic.com/~lynn/2007.html#2

with old email example
https://www.garlic.com/~lynn/2007.html#email801015

another recent with old reference:
https://www.garlic.com/~lynn/2007b.html#28

then there is internal distribution of combination of lots of enhancements
https://www.garlic.com/~lynn/2007c.html#12

that includes old email about it drastically improving uptime at STL (now called silicon valley lab)
https://www.garlic.com/~lynn/2007c.html#email830709

There was a project in this time frame SJR to do a high availability configuration with multiple vm/4341s ... however it ran into a lot of internal corporate political problems. Pieces had to be significantly modified (resulting in functional and performance degradation) before any of it shipped. This was sort of in the same time-frame as R-Star and Starburst. System/R was the original relational/sql implementation done on VM. R-Star and Starburst were follow-on distributed efforts
https://www.garlic.com/~lynn/submain.html#systemr

Of course, when we got around to doing real HA product, it wasn't with VM or mainframes
https://www.garlic.com/~lynn/subtopic.html#hacmp

In HA/CMP we had actually done the work on scale-up with Oracle ... some past references
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/2001n.html#83
https://www.garlic.com/~lynn/2007b.html#16

with old email
https://www.garlic.com/~lynn/2007b.html#email910928

A lot of work involved doing the DLM (distributed lock manager) for HA/CMP ... since then, similar implementations with similar fall-over recovery implementations have appeared.

My wife had earlier been con'ed into going to POK to be in charge of loosely-coupled architecture. While there she had created the Peer-Coupled Shared Data architecture
https://www.garlic.com/~lynn/submain.html#shareddata

However, except for IMS hotstandby, there wasn't a lot of uptake until sysplex.

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Wed, 24 Jan 2007 11:58:22 -0700

Steve O'Hara-Smith <steveo@eircom.net> writes:
If anyone breaks SSL then I expect to hear about it pretty quickly

a vulnerability issue with SSL isn't with the encryption. SSL was suppose to address two different issues: 1) impersonation (are you really talking to the server you think you are talking to) and 2) hiding information (mostly hiding financial transactions with encryption).

there are lots of scenarios now where clients are talking to servers other than who they believe they are talking to ... even with SSL being used. the problem now isn't hiding information (with encryption) from eavesdroppers (at myriad places in the internet infrastructure) ... but SSL hasn't eliminated the impersonation ... in large part because of the way its being deployed and used.

furthermore ... the long standing use of SSL for financial transactions ... dates back when we were asked to do some consulting with a small client/server startup that wanted to do payment transactions on their servers ... and they had this technology they called SSL
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

even then, SSL was purely being used as compensating security for transition from VANs and other technologies to the wild anarchy of the internet (previous infrastructures were slightly less prone to evesdropping and somewhat higher confidence that you would be talking to who you thot you were talking to).

but even then, the primary consideration was the data "at-rest" ... recent posts in this thread about data "at-rest" issues
https://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007

as mentioned in the above post and this one
https://www.garlic.com/~lynn/2007c.html#40 Point-of-Sale security

there is significant issue that the sensitive information is widely dispersed and suggestion that the infrastructure should be changed so that such sensitive information is useless to crooks & attackers (for fraudulent purposes).

shortly after having worked with the small client/server startup that had this technology called SSL ... we did a stint in the x9a10 financial standards working group. In the mid-90s, the X9A10 financial standards working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

One of the things recognized was the (even then) enormous exposure of the payment infrastructure to account number & account transaction harvesting, etc
https://www.garlic.com/~lynn/subintegrity.html#harvest

where the attackers (and insiders) were capturing huge amount of sensitive information from "at rest" repositories. One of the objectives of the x9.59 standard wasn't to eliminate all situation where that information was being harvested ... but instead, eliminate the usefulness of the information to crooks for performing fraudulent transactions.

this is part of my oft repeated theme that even if the planet was buried miles deep under layers of information hiding encryption ... it still couldn't prevent such account number leakage.

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Wed, 24 Jan 2007 13:35:34 -0700

Steve O'Hara-Smith <steveo@eircom.net> writes:
If I control the computer then I expect to be able to keep my data private - OTOH if someone else controls the computer then yes there is no privacy. One of the many reasons I dislike the mess that's going into Vista and PC hardware in the name of DRM enforcement.

for a little drift ... recent post discussing DRM:
https://www.garlic.com/~lynn/2007b.html#59 Peter Gutmann Rips Windows Vista Content Protection
somewhat related to this post about Lisa
https://www.garlic.com/~lynn/2007b.html#56 old lisa info

the EU finread terminal (standard) for personal financial transactions ... misc. past posts mentioning the EU finread standard
https://www.garlic.com/~lynn/subintegrity.html#finread

... was suppose to address PC-related vulnerabilities where 1) the transaction displayed wasn't the transaction you were actually authorizing and 2) keyloggers capturing your PIN.

this assumed a hardware token for something you have authentication ... but instead of connecting it directly to your PC ... it was connected/inserted to finread terminal. The transaction to be authorized would be transmitted from the PC to the finread terminal. The finread terminal would display (in its own display) the actual amount of the transactions) and also require that you enter a PIN ... on the finread terminal pin-pad.

x9.59 standard, previous post
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007

provided for

1) end-to-end strong authentication and integrity 2) crooks could not use any information from the transaction to perform their own fraudulent transactions (regardless of how the information might leak)

however, x9.59 didn't directly address the end-point security of the transaction originating environment. However there was a provision in x9.59 that could be used to help the authorizing/relying-party assess the integrity of the originating environment.

The EU finread terminal standard provided for integrity specification of the transaction originating environment. The vulnerability was that the authorizing/relying-party had no way of knowing that a EU finread terminal was actually in use for any specific transactions.

X9.59 transaction provided for digital signature on the transaction for end-to-end authentication and integrity. In addition, the x9.59 standard allowed for the transaction to be "co-signed" by the environment that originated the transactions. We sort of referred to this as parametrized risk management ... which is separate from my oft reference post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

parametrized risk management allows the authorizing/relying-party (example, the consumer financial institution) to access the integrity and risk of each transaction as part of authorization. For each transaction, in addition to assessing things like credit limit ... parametrized risk could be evaluated for things like integrity of the transaction originating environment, as well as other things like location of the transaction origin. An authorizing/relying-party might even establishes different levels of required integrity/security based on the amount of a transactions.

for other drift about DRM drift ... "TPM" supposedly was also going to be usable for "TPM" applications ... effectively as a more sophisticated version of the hardware that was in the Lisa (or went into original 370 mainframes)

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

SVCs

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SVCs
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Jan 2007 19:09:02 -0700

Rick Fochtman wrote:
WAY BACK WHEN I worked at a time-sharing service bureau running systems based on CP67/CMS, we used still another mechanism. CP67 was modified to use a BAL to a particular address in low storage, which went to a setup routine, which in turn called the appropriate service. Reason: interrupts took too long to process The actual service and its parameters were determined by the contents of storage immediately following the BAL instruction. All SVC's in the virtual machine were processed by the CMS code in the user's virtual machine and interactions between CMS and CP67 were handled via HVC (Hypervisor Call aka DIAGNOSE) and its parm list.

Interrupts are expensive; avoid them whenever possible; even the PSW-SWAP is very slow!!!

Three people from science center had come out the last week in jan68 to install cp67 at the university. this was before any of them had left to the time-sharing service bureaus
https://www.garlic.com/~lynn/submain.html#timeshare

a couple posts with anecdote about first service bureau formed and people leaving the week before they were supposed to teach a class:
https://www.garlic.com/~lynn/2006k.html#35 PDP-1
https://www.garlic.com/~lynn/2006k.html#36 PDP-1
https://www.garlic.com/~lynn/2007.html#12 "The Elements of Programming Style"

As an undergraduate, I had done three different things in this area to the CP67 kernel:

1) all internal kernel linkages were via SVC. Part of the SVC linkage was to dynamically allocate and deallocate savearea for the called routine along with some debug information. (from fading memory) this was just a little under 300mics pathlength on 360/67. I cut this to about 80-some mics.

also there were a fixed reserved number of 100 saveareas. I changed this so that it could dynamically expand the number of saveareas if it exhausted the existing supply.

2) a lot of internal calls were to high-use routines that did some operation and immediately returned. they didn't need a string of dynamically allocated saveareas ... they just needed a single temporary area that could be carved out of page zero (low storage). since it was no longer necessary to dynamically allocate a savearea for save/restore ... i could change the svc call to a direct BALR. As a result ... for the majority of high-use calls ... it eliminated the whole

3) simulation of virtual machine SVC calls were also handled in the same SVC interrupt handler (that handled internal kernel calling). I created something I called "fastpath" interrupt reflection (i.e. simulation of the virtual machine interrupts) that cut the svc simulation pathlength by approximately a factor of ten times or more.

following is old post with pieces of presentation that I made at the fall68 share meeting in Atlantic City.
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

It has some detail on numerous performance enhancements I had made to OS/360 MFT14 .... speeding up elapsed time for typical university workload by a factor of about three times. This was stand alone or in virtual machine (i.e. independent of running in virtual machine or on bare machine).

It also has some comparisons of cp67 before and after I had done a lot of kernel pathlength rewrite. I gave total elapsed time ... but effectively all of the elapsed time increase under cp67 was doing to cp67 kernel pathlength overhead.


                                                       cp67
elapsed   overhead
OS/MFT14 standalone elapsed time test:     322 sec
same work under original CP67:             856 sec    534 sec
same work under after CP67 changes:        435 sec    113 sec

There was reduction of nearly 80percent in overall CP67 overhead ... but for some specific pathlengths I had improved things by a factor of ten to hundred times (especially in the case of some of the fastpath stuff) to get the aggregate of 80percent.

Now, from the 306/67 functional characteristics manual off bitsavers .. it lists 3.75mics for the time to do SVC instruction and 3.95mics to process the supervisor call interruption ("from the time the interruption is discovered until the time of the next instruction is started") ... appears to be almost 8mics total. For other bits from the same document; external interrupt: 3.15mics, program interrupt: 3.15 mics, machine check interrupt: approx. 25mics, I/O interrupt: 4.65 mics.

for a little drift ... low-storage from gcard ios3270 ... q&d conversion to html
https://www.garlic.com/~lynn/gcard.html#4

For something completely different ... all of CMS calling/linkage was (originally) via SVC "202" .... with what was being called, passed as parameter list pointer in R1. Folklore is that "202" was chosen since it is hex x'CA' ... short for CAmbridge (i.e. CMS originally was Cambridge Monitor System ... it morphed to Conversation Monitor System for vm370). The parameter list started with 8character name of what was being called. This applied to whether it was internal (CMS) kernel routine, executable from the filesystem, or EXEC executable script from the filesystem.

The CMS 202 convention was that a four byte address constant (for error returns) immediately followed the "0ACA" instruction (had to be "AL4" to avoid forcing fullword alignment). A non-error return would come back to the SVC interrupt address "plus 4" ... i.e. four bytes after the SVC instruction.

Address constants in general caused me all sorts of heartburn when I was doing relocating shared segments for CMS ... originally on cp67 ... but ported to vm370. lots of past posts mentioning the heartburn that os360 address constant convention (also used by CMS) caused me
https://www.garlic.com/~lynn/submain.html#adcon

So, for a quick & dirty work around ... I defined an SVC202 instruction in CMS (virtual machine) page zero ... and hacked a lot of cms application code to stuff in error return address following the low-core SVC202 and then "BAL R14" to the SVC in low core. ... i.e. past post discussing it in more detail
https://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Wed, 24 Jan 2007 22:36:09 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
a few more recent articles Latest Breach May Force a New Approach to Data Security
http://www.digitaltransactions.net/newsstory.cfm?newsid=1226

from above:

In a research note she was preparing for Gartner clients on Monday, Litan says, Gartner believes that it's impractical for the card industry to expect up to 5 million retailers to become security experts and change their systems to fix security holes. It's time for the banks to own up to the problem and accept responsibility. They must make changes to the payment system so that, even if data are stolen, the data are useless to the thieves.

... snip ...

re:
https://www.garlic.com/~lynn/2007c.html#37 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#40 Point-of-Sale security

and news URL mentioning the Gartner presentation

Analyst: Banks Must Make Credit Card Accounts Useless to Data Theives
http://www.informationweek.com/showArticle.jhtml;jsessionid=E34WIOTVAIIHKQSNDLPCKHSCJUNN2JVN?articleID=197000263

from above:
"Banks must own up to this problem and change their payment systems so that, even if data is stolen, it is useless to thieves," says Avivah Litan, an analyst with Gartner.

... snip ...

one of the long time themes of x9.59 standard ... from x9a10 financial standard working group ... in the mid-90s given the requirement to preserve the integrity of the financial infrastructure for all retail payments.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

lots of other posts in this thread:
https://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2006y.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#15 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#17 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#22 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#30 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#31 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#33 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#36 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#39 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#44 Securing financial transactions a high priority for 2007

SVCs

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SVCs
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 25 Jan 2007 09:03:50 -0700

DASDBill2@ibm-main.lst wrote:
Another reason why interrupts are expensive is context switching, which means a set of code entirely different from what was executing suddenly starts executing. Thus all the high-speed buffers used in instruction fetching and processing (instruction pipeline and translation look-aside, e.g.) will have many misses for a while, and the code that processes that particular type of interrupt may need to clear the buffers that are clearable via software. This context switching causes a significant degradation in instruction execution time, and it is large enough that IBM invented at least one new instruction (Test Pending Interrupt) and add several functions (IOS uses TPI and SRM enables/disables CPUs for I/O interrupts) into MVS in order to reduce the effect.

re:
https://www.garlic.com/~lynn/2007c.html#45 SVCs

As an undergraduate in the 60s ... for cp67, i had also done a lot of stuff with dynamic adaptive resource management and page replacement algorithms ... separate from the pathlength stuff.

for some topic drift ... some old email related to page replacement stuff
https://www.garlic.com/~lynn/lhwemail.html#globallru

including this bit involving big uproar and opposition to granting somebody a Phd from Stanford ... effectively about stuff that I had done more than ten years earlier as an undergraduate
https://www.garlic.com/~lynn/2006w.html#email821019
in this post
https://www.garlic.com/~lynn/2006w.html#46 The Future of CPUs: What's After Multi-Core

and of course lots of past posts mentioning page replacement stuff
https://www.garlic.com/~lynn/subtopic.html#wsclock

I even had something of a set-to with the POK performance modeling group on the subject during the early days of SVS development ... and some choice they made for page replacement ... which took nearly five years ... well into MVS releases ... before they could understand how really bad the design choice was.

In any case, a lot of the work I did as an undergraduate on cp67 was dropped in the morph to vm370. I was given an opportunity to re-introduce the changes as the vm370 resource manager. And to get back somewhat on topic ... the resource manager had some dynamic code deciding on whether to dispatch virtual address spaces enabled or disabled for I/O interrupts ... in order to minimize the effect of context switch on cache hit ratios (long before MVS was doing it). lots of past posts on dynamic adaptive resource control, fairshare scheduling and resource manager
https://www.garlic.com/~lynn/subtopic.html#fairshare

So the 360/67 functional specification (of bitsavers) lists 3.75mics for the SVC instruction and 3.95mics for the SVC interrupt ... assuming this are actually different and not included as a subset/superset of the other ... then the aggregate is nearly 8mics.

So the equivalent might be a SSM instruction (going from disabled to enabled) plus an I/O interrupt. Time for an I/O interrupt is listed as 4.65 mics and the time for SSM is 4.16 mics ... aggregate of nearly 9mics.

So my resource manager actually did two things ... 1) after running in the hypervisor disabled for i/o interrupts ... and just before the dispatcher was going to choose the next task to run, load up all the registers and stuff ... it would do a pair of SSM instructions to enable/disable for interrupts. Basically any pending I/O interrupt was giving a chance to "interrupt" ... in the interrupt window ... and skip all the wasted overhead of attempting to dispatch another task ... and 2) dynamically decide depending on interrupt rate ... whether to run task enabled or disabled for i/o interrupts. This was on 370 w/o any special new instructions.

Somewhat related posts about doing internal operating system distribution on vm370 for internal distributions (including lots of stuff other than what was chosen for release as the resource manager) ... including some old email
https://www.garlic.com/~lynn/lhwemail.html#1973
https://www.garlic.com/~lynn/2006w.html#8 Why these original FORTRAN quirks?

so for other topic drift ... unbundling was announced on 23jun69 ... starting to charge for application software ... instead of all software being free. however, there was an argument used to leave kernel software free (i.e. bundled) ... because it was required for operation of the hardware. However, by the time it was decided to release the resource manager ... things were started to shift towards wanting to charge for kernel software only ... and the resource manager got chosen to be the guinea pig ... so i got to spend a lot of time with the business people working on policy for charging for kernel software. lots of past posts mentioning unbundling and the transition to charging for software
https://www.garlic.com/~lynn/submain.html#unbundle

Now some additional topic drift about context-switch and cache hit ratios (this wasn't issue on 360/67 because it didn't have processor cache). Now while Charlie had invented the compare&swap instruction (compare&swap mnemonic was chose because CAS are charlie's initials) doing a lot of work at the science center on multiprocessor support for cp67 on 360/67 .... vm370 didn't ship with support for multiprocessor operation. Further topic drift, POK owners of 370 architecture actually rejected compare&swap instruction for 370 architecture ... saying that a new "multiprocessor" instruction was required (test&set was sufficient). In order to justify compare&swap instruction for 370 ... uses other than multiprocessor specific operation was needed. Thus was born that whole programming notes how applications enabled for interrupts can use compare&swap instruction for atomic operations (regardless of whether running in multiprocessor or not). Lots of past posts on multiprocessor operation and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp

So for the vm370 release after the resource manager shipped ... it was decided to put in vm370 multiprocessor operation. I had done a lot of work in this area ... and in fact, the resource manager had a bunch of code included related to vm370 kernel code restructure for supporting multiprocessor operation. In any case, the multiprocessor support that shipped in the next release of vm370 was structured that it tended to keep a task running on a processor helping promote improved cache hit ratio (w/o having explicit code that looked at cache affinity ... it just fell out of how the code executed ... I use to make comments that best fastpath was not having to explicitly execute any code at all, let it be 2nd order side effects of how other code executed ... however, such stuff made for problems with long term maintainability).

So standard 370 cache machines slowed down machine cycle by ten percent for two-processor operation i.e. the effective hardware execution of two processor was 1.8 times a single processor ... after throwing in multiprocessor software overhead ... standard claim was that two-processor tended to have thruput of around 1.5times a single processor. However, because of the way the original vm370 multiprocessor dispatching tended to work ... there was sometimes where two-processors operation was getting more than twice the mip rate of a single processor (even tho the hardware cycle was only 1.8 times because each processor running at .9 times) on same workload ... because of the way cache hit stuff was happening.

So the other problem with vm370 resource manager and the initial release of vm370 multiprocessor support had to do with unbundling. Policy decision at the time for charging for kernel hardware was that if it was directly involved in supporting hardware ... which multiprocessor support was ... it was still to be free. The problem was that vm370 multiprocessor support had big dependency on the kernel restructure that had already been shipped in the vm370 resource manager for the prior release. It would be violation of the policy to have "free" hardware support dependent on a component that was charged for. So the decision was made to remove about 70-80 percent of the code from the resource manager and merged it into the "free" base system.

EXTERNAL INTERRUPT and SAPL

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: EXTERNAL INTERRUPT and SAPL
Newsgroups: bit.listserv.ibm-main
Date: Thu, 25 Jan 2007 13:59:38 -0700

Rick Fochtman wrote:
IIRC, the 360 Interval Timer also created a "External" Interrupt.

timer, external interrupt button, and SIGP (signal processor) instruction. SIGP was used in multiprocessor configurations to wakeup other processors. Also something is trying to jog my memory about write&read direct (WRD & RDD)

listed here WRD(84) and RDD(85) as privileged instructions
https://www.garlic.com/~lynn/gcard.html#11

part of the "direct control" facility. current principle of ops indicate that WRD/RDD didn't survive past 370

from trusty 360 princ. of ops off of bitsaver
Direct Control Feature

The direct control feature provides two instructions, READ DIRECT and WRITE DIRECT, and six external interruption lines. The read and write instructions provide for the transfer of a single byte of information between an external device and the main storage of the system.

... snip ...

SVCs

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SVCs
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 26 Jan 2007 13:25:37 -0700

previous post
https://www.garlic.com/~lynn/2007c.html#47 SVCs

... and old email on dispatching "disabled" from long ago and far away

Date: 21 January 1986, 07:11:46
To: wheeler
Subject: Dispatcher change for VM/XA

I am planning on changing the XA dispatcher to execute the SIE instruction with I/O interrupts disabled (external interrupts will still be enabled). The SIE instruction is a very expensive instruction and I want to give the virtual machine a chance to do some productive work before taking an interrupt. With I/O interrupts disabled, the virtual machine will get to run until it relinquishes control to CP or hits the end of the dispatcher timeslice. The I/O supervisor already uses the TPI instruction to process all pending interrupts before returning control to the dispatcher.

Do you have any thoughts on the matter? I have read CPDESIGN FORUM on the IBMVM disk, so I know what has been discussed there. Do you have a ballpark figure for the maximum allowable dispatcher timeslice which would allow satisfactory I/O throughput? I am thinking about disabling I/O interrupts for a maximum of 10 milliseconds. Another alternative would be to have DMKSTP set/reset the interrupt mask based upon the observed I/O interrupt rate.

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

i.e. some amount of the stuff in the original vm370 resource manager got modified in unusual ways over extended period of time (i.e from decade earlier that above email)

misc. collected posts mentioning resource manager, dynamic adaptive resource control, fair share, etc
https://www.garlic.com/~lynn/subtopic.html#fairshare

previous post
https://www.garlic.com/~lynn/2006j.html#27 virtual memory

with old email discussing SIE implementation differences between 3081 and 3090 in some detail
https://www.garlic.com/~lynn/2006j.html#email810630

How many 36-bit Unix ports in the old days?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many 36-bit Unix ports in the old days?
Newsgroups: alt.folklore.computers
Date: Fri, 26 Jan 2007 13:42:05 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
a little more about meeting conflicts with 801 hardware cache design and bsd meetings ... as well as (what is now called) Keck 10meter telescope

re:
https://www.garlic.com/~lynn/2007c.html#20 How many 36-bit Unix ports in the old days?

and some other old email about conflicts with 801 hardware design meetings ... although the above references are to the summer of '83, while this is the fall of '84.



Date: 15 October 1984, 14:44:57 EDT
To: distribution
RE:  Architecture Issues
for ROMP Extension

Listed is the agenda for our forthcoming architecture meetings.  We
hope to settle as many issues as possible and therefore have allowed
ample time for discussions.

******************************************************************

ROMP EXTENSION ARCHITECTURE MEETING
                      Tuesday, Oct. 23

ROOM 26-004
9:00 a.m.

1. Shared Objects and Synonyms

2. I/O:  Real/Virtual
Interrupts, bus arbitration

3. Co-Processor Interface and Floating Point

4. Page Clearing

5. Architecture Extensions

********************************************************************

                     WEDNESDAY, OCTOBER 24

ROOM 88-GO
9:00 a.m.

9:00   Smart SCU
       Block Moves
Separate L/S via I/O

10:30  RP3 Mp requirements

1:00   Instruction Trace Capture
       Software traps via Romp Hardware

** OTHER MP ISSUES**

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

Date: 10/16/84 09:30:17
From: wheeler

i have to be in washington d.c. by 2.30 on Tuesday afternoon. I can be in YKT for a short time early Tuesday morning. I will be in YKT all day weds.-friday (although I may be tied up for a time on Thursday with other meetings).

====== referenced email =====

Lynn, We currently have arranged an important Architecture meeting between the 801 people and Los Gatos, for Tues. Oct 23, from 9:00 to 12:00. I feel it is important that you be there. I have a 3rd hand message that you may not be able to attend. If true, we will try to rearrange the meeting. PLEASE LET ME KNOW AS SOON AS POSSIBLE IF YOU CAN OR CAN NOT ATTEND.

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

recent post with related email from this same period
https://www.garlic.com/~lynn/2006y.html#36 Multiple mappings

index of old romp (iliad, 801, etc) email
https://www.garlic.com/~lynn/lhwemail.html#801

past posts mentioning 801, romp, rios, pc/rt, rs6000, power/pc, etc
https://www.garlic.com/~lynn/subtopic.html#801

and a recent thread where RP3 was brought up
https://www.garlic.com/~lynn/2006w.html#26 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#38 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#39 Why so little parallelism?
https://www.garlic.com/~lynn/2006w.html#40 Why so little parallelism?

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 26 Jan 2007 14:12:02 -0700

jmfbahciv writes:
Sigh! And only the bit gods will know for sure. My mother wouldn't have any idea what an encruptions are, let alone what to about it.

cross-over post:
Study Shows "Extended Validation" TLS Certs Ineffective

Abstract. In this usability study of phishing attacks and browser anti-phishing defenses, 27 users each classfied 12 web sites as fraudulent or legitimate. By dividing these users into three groups, our controlled study measured both the effect of extended validation certicates that appear only at legitimate sites and the effect of reading a help file about security features in Internet Explorer 7. Across all groups, we found that picture-in-picture attacks showing a fake browser window were as effective as the best other phishing technique, the homograph attack. Extended validation did not help users identify either attack. Additionally, reading the help file made users more likely to classify both real and fake web sites as legitimate when the phishing warning did not appear.

http://www.usablesecurity.org/papers/jackson.pdf

... snip ...

recent past posts on this subject:
https://www.garlic.com/~lynn/2007.html#7 SSL info
https://www.garlic.com/~lynn/2007b.html#53 Forbidding Special characters in passwords
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007

i.e. SSL/TLS was targeted at addressing two issues 1) are you really talking to the webserver you think you are talking to and 2) if #1 is true, then encrypt all communication. however, there are problems in the various processes that can negate the effectiveness of #1 ... and if you don't know who you are talking to ... #2 may not serve much of useful purpose.

lots of past posts on SSL digital certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert

and past posts mentioning some specific issues with the certification process for digital certificates
https://www.garlic.com/~lynn/subpubkey.html#catch22

and to go back to the earlier theme ... that was one of the issues addressed by X9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

from recent post in this thread:
https://www.garlic.com/~lynn/2007c.html#46 Securing financial transactions a high priority for 2007

Latest Breach May Force a New Approach to Data Security
http://www.digitaltransactions.net/newsstory.cfm?newsid=1226

Analyst: Banks Must Make Credit Card Accounts Useless to Data Theives
http://www.informationweek.com/showArticle.jhtml;jsessionid=E34WIOTVAIIHKQSNDLPCKHSCJUNN2JVN?articleID=197000263

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 26 Jan 2007 14:27:48 -0700

jmfbahciv writes:
Sigh! And only the bit gods will know for sure. My mother wouldn't have any idea what an encruptions are, let alone what to about it.

... and a different kind of old email on encryption to research librarian

Date: 01/20/86 19:24:11
From: wheeler

do you know who handles ordering reference books ... I need a reference book for the HSDT project ... not a library book. The book is

Two Issues in Public Key Cryptography: RSA Bit Security and a New Knapsack Type System, by Ben-Zion Chor

book has a number 0-262-03121-3 and can be ordered for $20 from Mit Press, MIT, 28 Carlton Street, Cambridge, Ma, 02142.

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

i.e. I was having to deal with a lot of crypto issues for the high-speed data transport (HSDT) project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

misc. old email with some kind of crypto reference
https://www.garlic.com/~lynn/2006n.html#email790312
https://www.garlic.com/~lynn/2006n.html#email790403
https://www.garlic.com/~lynn/2007.html#email801006
https://www.garlic.com/~lynn/2007b.html#email841226
https://www.garlic.com/~lynn/2006t.html#email850625
https://www.garlic.com/~lynn/2006.html#email850701
https://www.garlic.com/~lynn/2006t.html#email860407
https://www.garlic.com/~lynn/2006v.html#email970624

even this public key infrastructure suggestion from 1981:
https://www.garlic.com/~lynn/2006w.html#email810515

Securing financial transactions a high priority for 2007

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Securing financial transactions a high priority for 2007
Newsgroups: alt.folklore.computers
Date: Fri, 26 Jan 2007 18:05:34 -0700

Anne & Lynn Wheeler <lynn@garlic.com> writes:
this is part of my oft repeated theme that even if the planet was buried miles deep under layers of information hiding encryption ... it still couldn't prevent such account number leakage.

re:
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007

I was checking some old email with crypto references ... i.e.
https://www.garlic.com/~lynn/2007c.html#52 Securing financial transactions a high priority for 2007

and stumbled across old email with reference to 20JUN83 posting on "Computer Disasters" in net.unix-wizards, net.ai (these postings continue to the present time in comp.risks newsgroup). this particular post includes a one-line reference:
Credit/debit card copying despite encryption (Metro, BART, etc.)

... snip ...

it can even be found in Google groups:
http://groups.google.com/group/net.unix-wizards/browse_thread/thread/c73f14bf9124fa1a/bd810b1f233a127c?lnk=st&q=&rnum=1#bd810b1f233a127c

... in any case, the recent data breaches and security breaches aren't exactly a new occurrence.

most recent comment
https://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007

and recent crop of news URLs concerning more recent events

As many as 30% of New Englanders could be hit by TJX breach
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9009300&intsrc=hm_list
Consumers advised on how to handle TJX data breach
http://www.metrowestdailynews.com/homepage/8998978363922055166
Consumers advised on how to handle TJX data breach
http://www.townonline.com/homepage/8998978363922055166
State investigating credit card breach
http://www.wcax.com/global/story.asp?s=5994926
NH banks issuing new credit cards after breach
http://www.eyewitnessnewstv.com/Global/story.asp?S=5994791
NATIONWIDE SECURITY BREACH Department Store Chain Reports A Major Security Breach
http://www.wtvm.com/Global/story.asp?S=5996504&nav=8fap
Clothing chain tipped to security breach
http://www.globeinvestor.com/servlet/story/RTGAM.20070126.wcards26/GIStory/
Banks Report Fraud Spurred By TJX Breach
http://www.baselinemag.com/article2/0,1540,2087844,00.asp
Fraud linked to TJX data heist spreads
http://www.securityfocus.com/news/11438?ref=rss

IBM URL of all available lists?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM URL of all available lists?
Newsgroups: bit.listserv.ibm-main
Date: Fri, 26 Jan 2007 17:41:34 -0700

wfarrell@ibm-main.lst (Walt Farrell) writes:
No, there's no -IBM- web page that lists all the lists, because IBM does not run nor own these lists. Perhaps someone else will have a pointer to something non-IBM that has the list you want; many readers of this list will not have seen your message, because you posted it to the newsgroup instead of the mailing list.

the "bit.listserv" usenet hierarchy was originally for gatewaying BITNET "listserv" mailing list based discussion groups to usenet. Over the years, there has been various levels of how different (BITNET) mailing lists interacted with any usenet gateway (transitioning in&out of defunct, only working as shadow ... not having traffic work in both directions, etc). you could get a list of all newsgroups in the "bit.listserv" hierarchy ... many of them tend to be IBM related ... since original BITNET was originally IBM software-based infrastructure ... and in numerous cases also heavily subsidized by IBM.

lots of past posts about bitnet (and/or earn, the European counterpart)
https://www.garlic.com/~lynn/subnetwork.html#bitnet

BITNET was based on somewhat similar software that was used for the internal corporate network ... larger than (whole) arpanet/internet from just about the beginning until possibly sometime mid-85. lots of past posts about internal corporate network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

the precursor to listserv (and some of its subsequent look-alikes, majordomo, etc) was an internal corporate application on the internal corporate network.

this website has a catalog of large number of such lists:
http://www.lsoft.com/lists/listref.html

they have some history going back to mid-80s (although the internal version predates the bitnet activity)
http://www.lsoft.com/corporate/history.asp

"The Elements of Programming Style"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "The Elements of Programming Style"
Newsgroups: alt.folklore.computers
Date: Sat, 27 Jan 2007 03:19:43 -0700

Charlton Wilbur <cwilbur@chromatico.net> writes:
IBM is pushing POWER workstations and Cell processors for game consoles very hard. I suspect that given the choice between selling 2 million chips a year for certain to Apple and hundreds of millions of chips a year with luck to Microsoft and Sony, they opted for the latter.

romp->rios went to high-end chip-set used in rs/6000 workstation.

precursor to rs/6000 was pc/rt with romp. originally, pc/rt was going to be follow-on to office products division (OPD) displaywriter. when that project was canceled it was retargeted to the unix workstation market ... and the company that had done the at&t unit port for pc/ix ... was hired to do one to the pc/rt ... announced as aix.

somerset was joint ibm/motorola project to do single chip 801. the executive we reported to when we were doing ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

went over to head up somerset. a big difference between original "power" and power/pc ... was that power/pc would have support for multiprocessor operation.
https://en.wikipedia.org/wiki/PowerPC

misc. old email mentioning 801, romp, fort knox, etc
https://www.garlic.com/~lynn/lhwemail.html#801

lots of past posts mentioning 801, romp, rios, power, power/pc, etc
https://www.garlic.com/~lynn/subtopic.html#801

the original workstation power/pc chip was 601, however there was whole "400" family effort ... for the embedded processor market ... looking at really large volumes.

Programming Model Differences of the IBM PowerPC 400 Family and 600/700 Family Processors
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256997006EB430/$file/4xx_6xx_an.pdf

IBM and Mentor Graphics to Expand Reach of PowerPC Chip Architecture for Embedded Consumer and Communications Applications
http://www-03.ibm.com/press/us/en/pressrelease/2384.wss

PowerPC 400 wiki page
https://en.wikipedia.org/wiki/PowerPC_400

PowerPC 600 wiki page
https://en.wikipedia.org/wiki/PowerPC_600

note the above mentions 602 in 1995 ... a stripped down 603 targeted at game consoles.

misc 801, power, etc history and background here
https://en.wikipedia.org/wiki/IBM_POWER

SVCs

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SVCs
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 27 Jan 2007 09:05:13 -0700

Anne & Lynn Wheeler wrote:
I even had something of a set-to with the POK performance modeling group on the subject during the early days of SVS development ... and some choice they made for page replacement ... which took well into MVS releases ... before they could understand how really bad the design choice was.

re:
https://www.garlic.com/~lynn/2007c.html#47 SVCs

... some old email ...

Date: 05/06/81 14:41:17
From: wheeler

re: unchanged pages on the free list 1st; I've been repeating that you can't screw up a LRU algorithm that way. I told the AOS people that way back in 71-72 but they wouldn't listen. If you are going to permute the LRU algorithm you have to do it randomly. Unchanged pages is a non-random permutation of the LRU algorithm. AOS went 1st customer ship & a couple of years before they realized that shared, nucleus storage was being biased against in favor of private, individual data areas (i.e. pages in shared LINKPACK would be biased against, in favor of private data pages). A LRU algorithm, is a LRU algorithm, is a LRU algorithm. There is at least as good a case or better for selecting change pages to be placed on the free list ahead of non-changed pages (there is higher probability that r/o pages are program pages, there are lot more instances of re-use of program pages while data pages change than there is of the inverse).

Problem of concentrating/optimization for just one area of the system w/o paying attention to overall system relationships & design can lead to unanticipated problems & results. Page replacement is a total complex system problem which spans the use of CPU, real storage and I/O devices. Local optimization very quickly can lead to sub-optimal global system optimization.

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

in the above, "AOS" was the prototype of VS2/SVS ... which morphed into VS2/MVS ... still with the same replacement algorithm. It wasn't until well into the MVS release cycle that they understood how bad it was and changed it.

note, "is a LRU algorithm" ... there is, of course, "local LRU" and global LRU. I had done global LRU as an undergraduate in the 60s ... at about the same time that there was some amount of academic literature on "local LRU". More than a decade later there was a lot of uproar generated about awarding a Stanford Phd on the subject of global LRU.

recent post
https://www.garlic.com/~lynn/2006w.html#45 The Future of CPUs: What's After Multi-Core?

with some old communication (19Oct82) jumping right into the middle of dispute (took me nearly a year to get approval to send the communication):
https://www.garlic.com/~lynn/2006w.html#email821019

misc. other "old" email on the subject of global LRU
https://www.garlic.com/~lynn/lhwemail.html#globallru

and collected posts mentioning the subject
https://www.garlic.com/~lynn/subtopic.html#wsclock

previous, next, index - home