2003 Newsgroup postings (11/13 - 12/11) Lynn Wheeler

2003 Newsgroup Postings (11/13 - 12/11)

Weird new IBM created word
An informed populace
Orthographical oddities
Bank security question (newbie question)
Bank security question (newbie question)
perfomance vs. key size
perfomance vs. key size
An informed populace
Bank security question (newbie question)
Bank security question (newbie question)
IS CP/M an OS?
perfomance vs. key size
Database design and confidential data protection
When nerds were nerds
When nerds were nerds
secure delete on 3390
When nerds were nerds
Rationale for Supercomputers
Database design and confidential data protection
More -Fake- Earthlink Inquiries
IS CP/M an OS?
TSO alternative
securID weakness
Tools -vs- Utility
Tools -vs- Utility
Any experience with "The Last One"?
GNOME - viewing multiple workspaces simultaneously
When nerds were nerds
When nerds were nerds
Biometric cards will not stop identity fraud
who invented the "popup" ?
who invented the "popup" ?
who invented the "popup" ?
When nerds were nerds
Will Prescott work on Win64?
Humans
When nerds were nerds
Security of Oyster Cards
When nerds were nerds
MUMPS & MUSIC, was: SMF Records - a side issue
When nerds were nerds
When nerds were nerds
misc. dmksnt
Computer folklore - forecasting Sputnik's orbit with
Biometrics
Any experience with "The Last One"?
What 'NSA'?
Funny Micro$oft patent
incremental cms file backup
Any experience with "The Last One"?
Pub/priv key security
*** New Software: UDP File Transfer Commercial Edition ***
Virtual Machine Concept
Pub/priv key security
An entirely new proprietary hardware strategy
History of Computer Network Industry
An entirely new proprietary hardware strategy
Pub/priv key security
RSA factoring challenge and PKI
1teraflops cell processor possible?
1teraflops cell processor possible?
1teraflops cell processor possible?
1teraflops cell processor possible?
Dumbest optimization ever?
1teraflops cell processor possible?
Dumbest optimization ever?
Dumbest optimization ever?
1teraflops cell processor possible?
History of Computer Network Industry

Weird new IBM created word

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Weird new IBM created word.
Newsgroups: bit.listserv.ibm-main
Date: Thu, 13 Nov 2003 21:25:15 GMT

john.mckown@ibm-main.uiciinsctr.com (McKown, John) writes:
zSynergy? Sheesh!

slight drift ... an old ibm jargon somebody put up:
http://www.212.net/business/jargon.htm

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

An informed populace

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: An informed populace
Newsgroups: alt.folklore.computers
Date: Fri, 14 Nov 2003 14:54:33 GMT

jmfbahciv writes:
The bit gods sure as hell did. TW had to throw a hissy fit to get an RA80 hung off a PDP-10 to do the device driver, etc. The marketing people insisted that the first one off the line be delivered to the customer first. It took an edict from a higher up to overrule the idiot because nobody managed to convince him/her that hardware without the software is just an expensive boat anchor. ISTR similar things about the KL and hardware engineering.

There always seemed to be a hassle getting the gear attached to a system that was used as a computer as a customer would use it.

san jose was somewhat better. in fact, the product test lab (bldg. 15) was supposedly totally independent from the engineering lab (bldg. 14); a trivial example was that nobody was supposedly allowed badged access to both bldgs & corresponding machine rooms. In principle it was that only cleared engineers had badged access to their respective facility and were not to "mingle" with engineers from the other bldg (and attempt at maintaining independence). Somewhat because I was outside the organization, I was one of the very few that had badged access to both facilities.

recent post that includes some reference to such activity:
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story

lots of past refs:
https://www.garlic.com/~lynn/subtopic.html#disk

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Orthographical oddities

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Orthographical oddities
Newsgroups: alt.folklore.computers
Date: Fri, 14 Nov 2003 15:18:37 GMT

jmfbahciv writes:
I never thought of myself in IT either. :-) Our customers were the IT people; I don't recall seeing IT back then.

I always thot of myself as IT ... even when doing development and/or research. I felt that having the "finger feel" of real live production operation .... kept one in touch with reality ... having responsibility for system in a several operations while doing research and development provided for a sense of rubber meets the road. People following standard R&D process might raely (if ever) have direct hands-on experience regarding what they were supposedly doing.

random refs at hone
https://www.garlic.com/~lynn/subtopic.html#hone
random refs at disk labs
https://www.garlic.com/~lynn/subtopic.html#disk

this was during period when joke was that i worked first shift in bldg. 28 (research before it moved up the hill), second shift in bldg. 14&15, third shift in bldg. 90 (STL) and weekends up at HONE.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Bank security question (newbie question)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Bank security question (newbie question)
Newsgroups: sci.crypt
Date: Fri, 14 Nov 2003 19:42:42 GMT

henrik-olsson@tyko.nu (Henrik) writes:
Most of the Internet banks here in Sweden demands that their users use either calculator-like things or "scratch tickets" (probably to avoid the 'man in the middle' problem?) when they log on. I don't know the details of this since the banks aren't too open about it.

if it is anything like calculator-like device mentioned in
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001k.html#55 I-net banking security

it is a (3?)des challenge/response authentication mechanism. it has the advantage that response can not only be entered on PC ... but also presumably anything with numeric keypad.

since it is purely cleartext challenge/response authentication (something you have and possibly something you know), there is no countermeasure for MITM. It does have advantage that it supposedly isn't prone to straightforward static data harvesting (like common magstripe and some chipcards).

Misc. recent authentication threads:
https://www.garlic.com/~lynn/aadsm15.htm#40 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#37 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#38 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm15.htm#39 FAQ: e-Signatures and Payments

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Bank security question (newbie question)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Bank security question (newbie question)
Newsgroups: sci.crypt
Date: Fri, 14 Nov 2003 19:59:55 GMT

Anne & Lynn Wheeler writes:
since it is purely cleartext challenge/response authentication (something you have and possibly something you know), there is no countermeasure for MITM. It does have advantage that it supposedly isn't prone to straightforward static data harvesting (like common magstripe and some chipcards).

minor word smith ... that shouldn't be "cleartext" ... that should be "in the clear" ... i.e. the response is effectively a DES encrypted challenge ... transmitted in the clear. MITM could allow the authentication to occur and then still hijack the rest of the session if they were so inclined.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

perfomance vs. key size

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: perfomance vs. key size
Newsgroups: sci.crypt
Date: Fri, 14 Nov 2003 22:10:39 GMT

Henrick Hellström writes:
There are buffer overruns even in various versions of MS CryptoAPI and OpenSSL. There is no such thing as bug free software. The best you can do is to test the code extensively, and to use a programming style, a language and a compiler that reduce the probability of exploitable bugs and increases the probability that any bugs are detected during the test phase.

there has been a relatively long recognized vulnerability in the way that C language libraries support string/buffer lengths that greatly aggravates buffer overruns bugs.

doing detailed vulnerability analysis of environment in late '80s for HA/CMP ...
https://www.garlic.com/~lynn/subtopic.html#hacmp

we predicted that the C language string libraries would likely result in increase of the incidence of buffer overruns by two orders of magnitude (one hundred times) compared to infrastructures with "better" length paradigms. lots of vulnerability threads ... including some number of buffer overruns:
https://www.garlic.com/~lynn/subintegrity.html#fraud

archeological references to historiical times before buffer overruns existed:
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

perfomance vs. key size

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: perfomance vs. key size
Newsgroups: sci.crypt
Date: Sat, 15 Nov 2003 02:06:21 GMT

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
Each of the two URLs above refers only to a bunch of others. Could you give a few that are of specific/direct interest in this connection? Thanks.

the hacmp reference refers to lots & lots of past postings about High Availability Cluster Multi-Processing product (ha/cmp) that my wife and I did. In that effort we coined the terms geographic survivability and disaster survivability ... to distinguish from disaster recovery. so for a little topic drift ... a post from the ha/cmp thread
https://www.garlic.com/~lynn/95.html#13
that I periodically refer to in the context of SSL and electronic commerce:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

note about the time of the SSL effort mentioned above ... I attended a presentation by a SUN vp on high availability and much of it was almost word for word a marketing blub that I had written in the late 80s. misc minor ha/cmp refs from search engine:
http://lists.sistina.com/pipermail/linux-lvm/2000-June/004873.html
http://lists.community.tummy.com/pipermail/linux-ha-dev/2000-January/000351.html
http://www.storage.ibm.com/tssc/usa/scsi.html ... gone, but not forgotten:
https://web.archive.org/web/20030203025038/http://www.storage.ibm.com/tssc/usa/scsi.html

I thot that I had mentioned that the "fraud" references includes some number of pointers to buffer overflow ... the URLs that refer to buffer overflow ... tend to have the string buffer overflow on the same line following the URL pointer. a couple from with just the subject buffer overflow:
https://www.garlic.com/~lynn/2001n.html#90 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2002.html#19 Buffer overflow
https://www.garlic.com/~lynn/2002.html#23 Buffer overflow
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow
https://www.garlic.com/~lynn/2002.html#32 Buffer overflow

note at the time of referenced news report ... automatic execution of scripts/executables from the network was still on the rise:
https://www.garlic.com/~lynn/99.html#219 Study says buffer overflow is most common security bug

from search engine, specific references to the "study" (computer bug of the decade)
http://community.core-sdi.com/~juliano/0-1003-200-1462855.html
http://community.core-sdi.com/~juliano/leblanc-nt-bof.html
http://mailman.anu.edu.au/pipermail/link/1999-November/041979.html
http://weblog.creedon.net/1999/11/23
http://www.cisco.com/warp/public/779/largeent/issues/security/sbytes/v02i01_0100.html
http://julianor.tripod.com/bufo.html
http://news.com.com/2100-1001-233483.html?legacy=cnet&tag=st.ne.ron.lthd.1003-200-1462855

note that the archeological, historic period does have only a couple URLs.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

An informed populace

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: An informed populace
Newsgroups: alt.folklore.computers
Date: Sat, 15 Nov 2003 16:14:01 GMT

jmfbahciv writes:
That's one way to do it. The downside is that it's difficult for the knowledge of the two groups to cross-fertilize. Did they have a bar between the two buildings so they could conduct informal bullshit sessions?

we could have lunch together ... and we had fridays after work. there was a deli that was frequent for friday's in a courtyard at the shopping strip corner of bernal and santa teresa ... last time I was by it had turned into mexican restaurant.

then a eric's opened up across cottle from bldg. 28. they had a backroom (at the time) that was usually closed off, they let us use for friday's after work ... and for some reason or another they had a name on the door "lynn". they served us pitchers of anchor steam at a dollar off.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Bank security question (newbie question)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Bank security question (newbie question)
Newsgroups: sci.crypt
Date: Sat, 15 Nov 2003 21:41:22 GMT

Jan Panteltje writes
In my bank / calculator I need to use it to log in, then for EVERY transaction I do... That makes it difficult to hijack anything, I think. Most they could do is see your account change.

MITM is somebody sitting between you and the bank.

The question is whether you have an authenticated transaction or you do a challenge/response that is separate from the transaction and then do the transaction.

A purely challenge/response system ... has the bank sending you a challenge (passing thru the MITM) and you send back the response (passing thru the MITM) ... then you do a transaction (passing thru the MITM). If the transaction is passing thru the MITM ... and that the bits in the transaction aren't independently validated (with MAC/digital signature) ... then the MITM can modify the information in the transaction as it passes thru ... and the bank won't be able to detect the modification. Furthermore, the MITM can modify the response from the bank, so you can't detect any modification has taken place.

It is simple characteristic of MITM attacks ... as per the original
https://www.garlic.com/~lynn/2003o.html#3 Bank security question
https://www.garlic.com/~lynn/2003o.html#4 Bank security question

The issue is whether or not independent of challenge/response paradigm... is there something specific that prevents a MITM from modifying data in transit w/o being detected (for instance is all transmission encrypted and/or digitally signed).

Say for an online bill payment transaction ... do you type into the calculator the entity id of who gets the payment and the value of the payment and the date of the payment ... etc ... and get some unique response that is uniquely associated with the fields in the transaction ... and whether a MITM would be able to modify in transit w/o the receiver know that the modification has taken place.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Bank security question (newbie question)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Bank security question (newbie question)
Newsgroups: sci.crypt
Date: Sat, 15 Nov 2003 22:07:13 GMT

Henrick Hellström writes:
No, the advantages of public key cryptography do not disappear. The main advantage of PKC is that the server has a single public key it might distribute to each client without disclosing the private key to any of them. If the bank was distributing a symmetric key to the customers instead, it would mean that all of the key material involved in the cryptographic operations of the transaction would be known to both the client and the server of that transaction. There is no way this wouldn't have security implications, but which ones it would be depends on which symmetric authentication protocol would be used in such a scenario.

the issue in symmetric key operation is the taxonomy associated with shared-secret operation vis-a-vis non-shared-secret operation.

Two characteristics of a (symmetric key) shared-secret operation supposedly are

1) unique secret for every security domain
2) same value can both authenticate as well as originate

In the online bank scenario ... a security domain would be every specific bank/customer pair ... aka a bank has to distribute a unique shared-secret to every customer. That is in effect what the calculator is. However, that implementation is typically restricted to simple challenge/response authentication of the customer. If the calculator was a little more sophisticated .... the bank could transmit all data encrypted with the DES key in the calculator ... and the calculator would decode it for presentation to the customer (lets say its a cellphone or wireless PDA in addition to a calculator). Then whatever the customer responds would be encrypted for transmission back to the bank.

The symmetric keying material would effectively be distributed in much the same way that the current calculator device is distributed.

The calculator solution can have the advantage that the customer never actually has to know what the key is ... the calculator is constructed in such a way that correct use of the key demonstrates possession of something you have authentication. It has the advantage vis-a-vis PIN/password shared-secrets where the customer actually knows the value and can be subject to social engineering (phishing) to extract the information ... more detailed references:
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/Searchresults1?openform&queryE-Security/E-FinancetypePublicationstopicsortDate

From search engines there is also some recent news about paypal phishing

The other downside of symmetric key (shared-secret) is that in an institutional centric environment ... they are set up for a unique key for every customer .... it has been somewhat harder for individuals to adapt to having a unique symmetric key (shared-secret) for every possible relationship.

The individually known shared-secrets are prone to phishing and eventually become impossible to keep track of. For the device (hardware token) scenario, I've also periodically used the analogy from the early/mid 80s when they were some attempts to use a uniquely encoded floppy disk as DRM protection for every application loaded on the hard disk .... for a large number of applications you eventually had a large number of copy protection floppy disks that had to be managed and swapped on every application change. Trying to have multiple applications running concurrently became especially difficult.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IS CP/M an OS?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IS CP/M an OS?
Newsgroups: alt.folklore.computers,comp.os.cpm
Date: Sun, 16 Nov 2003 16:19:58 GMT

"Ross Simpson" writes:
The details I have about this computer state it started in the fall of 1961, but also states that, it was the first production model of the PDP-1, which was installed in the "Kludge Room", next door to a TX-0.

Unfortuately, I don't have the URL on hand, but a Google search for "The World's First Toy Computer"+"SPACEWAR!" should reveal this site.

recent related threads:
https://www.garlic.com/~lynn/2003c.html#0 Wanted: Weird Programming Language
https://www.garlic.com/~lynn/2003c.html#62 Re : OT: One for the historians - 360/91
https://www.garlic.com/~lynn/2003c.html#72 OT: One for the historians - 360/91
https://www.garlic.com/~lynn/2003d.html#28 Why only 24 bits on S/360?
https://www.garlic.com/~lynn/2003d.html#38 The PDP-1 - games machine?
https://www.garlic.com/~lynn/2003f.html#39 1130 Games WAS Re: Any DEC 340 Display System Doco ?
https://www.garlic.com/~lynn/2003g.html#7 Any DEC 340 Display System Doco ?
https://www.garlic.com/~lynn/2003i.html#27 instant messaging
https://www.garlic.com/~lynn/2003m.html#14 Seven of Nine

from seven of nine post ... 9/13/2003

spacewar on pdp1 graphics screen in the 60s:
http://www.mess.org/sysinfo/pdp1.htm
http://slashdot.org/articles/02/02/28/136217.shtml?tid=127

3d tic-tac-toe on tx-0 graphics screen in the 50s
http://coyote.csusm.edu/lynniebhist/comphist.htm

and

http://memex.org/cm-archive10.html
the following from above:

Les Earnest writes: I vaguely recall that someone at Bell Labs built a relay computer that played tic-tac-toe sometime in the late 1940s or early 1950s. The TX-0 computer at MIT also had a tic-tac-toe game when I started playing with it in 1959. It displayed the board on its CRT and you selected moves by pointing with a lite pen.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

perfomance vs. key size

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: perfomance vs. key size
Newsgroups: sci.crypt
Date: Sun, 16 Nov 2003 16:11:35 GMT

Henrick Hellström writes:
No, it is not. Firstly, the number of hits is usually much larger than the number of users. Secondly, think: Peaks.

for interactive ... 24hr avgs can have nominal extended peak periods that hit five to ten times the 24hr average. shopping sites that do something like advertise for major tv program may have peaks associated with the advertisement that is much larger than ten times the 24hr average. for certain sites ... 80 percent of 24hr hits may appear in 5-6hr evening period (somewhat correspond to tv prime-time). The US east/west coast evening period may have gotten somewhat less skewed as the net activity has gone more international, but i believe many sites still see significantly skewed activity distribution.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Database design and confidential data protection

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Database design and confidential data protection
Newsgroups: comp.databases.theory
Date: Sun, 16 Nov 2003 21:47:25 GMT

Christopher Browne writes:
The "standard" work on this is called _Translucent Databases_.
http://www.wayner.org/books/td/

Basically, the idea is that sensitive fields are encrypted using keys that are user-specific. (Probably using some form of PK encryption.)

A characteristic example would be of storage of cases by a national rape crisis organization. In order to do statistical analysis and such, the data needs to be aggregated together across all offices. But the identities of the victims should only be accessible by the staff at the local office, and perhaps only the staff members that have worked with each specific victim.

the problem is different than most PK ... this would have multiple writers and well as multiple readers. PK tends to be multiple writers and a single reader.

For multiple readers ... you typically go thru some sort of access control system that maintains control over any encryption key. If the infrastructure controls the key ... rather than individuals ... then there can be little or no difference whether it is actually a symmetric key or an asymmetric key implementation.

A symmetric key implementation might, however use some sort of derived key for the actual encryption/decryption (making the environment somewhat less susceptable to a brute-force key attack). You find such implementations in the financial infrastructure where the infrastructure generates a derived key (for actual encryption/decryption) from the "master" key combined with some information from the transaction (like account number).

for patient records, a derived key might involve the infrastructure master key and some sort of patient number.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Mon, 17 Nov 2003 16:21:16 GMT

Brian Inglis writes:
It wasn't the interrupt per keystroke that killed the VAX -- PDP-11s had been handling that for years -- it was the lengthy context save and switch times (and lack of multiple GP and MMU register sets?)

i think that the vax were subject to the same competitive pressures as mid-range 370s ... with which they competed against. both vax and mid-range 370s had explosive growth as the departmental and distributed server market developed (although i believe that mid-range 370 had much larger install base) ... and then both saw similar significant declines as that market segment moved to workstation and high-end PC server offerings. somewhat related past posts:
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Mon, 17 Nov 2003 16:31:10 GMT

Keith R. Williams writes:
There is no need for an interrupt on every keystroke. 3270s only interrupt on certain keys (the grey ones ;-). A full screen could be edited with one keystroke to transfer the contents.

but typically three interrups ... one (attention) interrupt for the key, followed by a screen read operation and the associated interrupt, followed by a screen refresh/write operation and the associated interrupt.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

secure delete on 3390

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: secure delete on 3390
Newsgroups: bit.listserv.ibm-main
Date: Mon, 17 Nov 2003 16:52:41 GMT

fjpohlen@ibm-main.gmx.de (Franz Josef Pohlen) writes:
I have a question on 3390 secure deletion. A customer of me with very high data security demands asks for the possibility to delete permanently and 100% unrecoverably old and no longer used 3390 Ramac Devices. Up to now there was a guideline that once there were data on a device, this device never leaves the campus anymore except in a shreddered condition. Is there a utility like wipe on unix systems which securely deletes all data. ICKDSF only clears the vtoc, that's not enough. ALL data have to be cleared completely. Does anybody know, what my customer can do.

is this releasing an operational device security requirement and there is operation re-use requirement security requirement.

one of the security standards level has requirement for zeroization property ... every record replace ... has to replace (or zeroize) the (originaL) physical record and every record delete has to zeroize the physical record.

there has been a number of past threads in other newsgroups about some difficulty in guaranteeing the physical record write property for some disk subsystems .... regardless of the operating system.

for releasing an operational device ... there are some standards for rewriting every physical record multiple (like ten or more) times with patterns of random data. again there are some issues with some disk subsystems about when specifying a record number is the physical location guaranteed consistently rewritten. For instance in a caching implementation with delayed writes ... will multiple consecutive writes to the same record just update the cache and possibly only the last write actually be physically transferred to disk.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Tue, 18 Nov 2003 00:15:53 GMT

Lon Stowell writes:
The 2741 could run in buffered or unbuffered mode. In non-buffered mode, it was pretty much up to the terminal handler in the host to take care of all this trivia. In buffered mode, all editing was done in the local buffer [not like a 3270 at all] and the local buffer was transmitted upon hitting the send key and the host polled the thing.

in 360s ... this was typically characteristic of an outboard terminal controller ... which in the case of the one we built when I was an undergraduate started out as an Interdata/3 minicomputer:
https://www.garlic.com/~lynn/submain.html#360pcm

Later there were ones built from boxes like S/1 ... where things like what characters/keys caused interrupts to the mainframe, as well as some local character editing in the terminal controller.

In the early '80s one of the people that had done the pascal compiler at the los gatos vlsi lab (which eventually turned into vs/pascal), left to do a startup that provided some level of session editing/function for 3270 terminals ... in an outboard 3270 PCM controller box. This was targeted at the MVS/TSO market segment .... because the TSO 3270 response was so absolutely abysmal.

This slightly harkens back to some of my prior topic drifts regarding the SHARE report circa 1974 by CERN on CMS/TSO bakeoff. CERN compared CMS and TSO ... where the TSO numbers came off so badly that within IBM, the report was stamped IBM Confidential, Restricted ... aka available on need to know basis only (aka where some see problems .... others see opportunities).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Rationale for Supercomputers

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Rationale for Supercomputers
Newsgroups: alt.folklore.computers
Date: Tue, 18 Nov 2003 00:00:42 GMT

shoppa@trailing-edge.com (Tim Shoppa) writes:
All the flights in the US probably amount to a million passengers a day. In terms of CRUD/day, that's might be a few million creates (overbooking and rebooking), maybe tens of milions of reads, at least a million updates (one for each actual boarding), and a few million deletes. Rates have to be boosted by a factor of several to allow for "rush hour" peaks in system usage. That's well within the abilities of even a small machine.

less than ten years ago when I did some stuff for a specific res system ... the two "largest" applications were routes and fares:

• fares (looking up fares for scheduling a reservation) amounted to 40 percent of application load (any specific flight segment could have a dozen different fares, any particular trip from two points might have a hundred different fare pieces to take into consideration). changes/updates to fare could amount to tens of millions of updated records per day.

• routes (looking up routes/flight-sgements for scheduling a reservation) amounted to about 25 percent of application load .

Actual PNR (passenger name record) is one of possibly hundreds of applications making up the remainder 45 percent of application load.

PNR management has original creation of the reservation; updates having to do with any changes; updates as flight segments actually happen (checkin, boarding, departure, etc); and then possibly six months after the last flight in a PNR, a delete. On the avg. there will be as many creations each day as there are deletions, which tend to be slightly more expensive since the database index is also updated on PNR creation and deletion. Just updating a PNR for changes is slightly easier since some amount of the index (which could be largely cached) is read, only the actual PNR record has to be read, updated, and rewritten. Linked PNR have some additional database overhead.

transaction rates into the system (at the time) had nominal peak average of 4000 per second. besides all the reservation terminals and ticket printers in the world, it also included all the ticket counter terminals, boarding pass printing terminals, barcode baggage printing terminals, gate checkin terminals, boarding pass printing terminals. There were just starting to also be things like barcode baggage scanners when loading baggage into the plane and boarding pass scanners at the gate. There was also interaction between the airline res system and airport operational systems involving things like running the arrival/departure monitors.

possibly any specific application might be offloaded onto smaller individual machine ... but may have to be carefully considered because of issues like database partitioning and/or need for database replication.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Database design and confidential data protection

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Database design and confidential data protection
Newsgroups: comp.databases.theory
Date: Tue, 18 Nov 2003 00:36:35 GMT

Anne & Lynn Wheeler writes:
A symmetric key implementation might, however use some sort of derived key for the actual encryption/decryption (making the environment somewhat less susceptable to a brute-force key attack). You find such implementations in the financial infrastructure where the infrastructure generates a derived key (for actual encryption/decryption) from the "master" key combined with some information from the transaction (like account number).

for patient records, a derived key might involve the infrastructure master key and some sort of patient number.

note that if crypto is primary thing being used for patient info confidentiality ... with field level encryption & w/o derived key ... then the same condition could always appear as the same encrypted value in all patient records. Information leakage then can occur if the condition for any specific patient is learned ... then all you do is look for the same encrypted value for other patients.

some sort of derived key makes sure that the same condition would encrypt to unique values across all patient records.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

More -Fake- Earthlink Inquiries

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: More -Fake- Earthlink Inquiries
Newsgroups: earthlink.general-discussion,earthlink.support.email,earthlink.support.usenet,earthlink.coffeehouse,alt.provider.earthlink
Date: Tue, 18 Nov 2003 03:16:42 GMT

"Diane L. Schirf" writes:
It's called "phishing."

a large pdf paper on it from the world bank: E-security/E-Finance
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/Searchresults1?openform&queryBanking+Systems,E-Security/E-Finance,Payments+SystemstypePublicationstopicsortDate

Phishing in the Digital Streams: The Growing Threat of Cyber Social Engineering in the Financial Sector
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/(attachmentweb)/PhishingThreattotheFinancialSector10202003/$FILE/Phishing+Threat+to+the+Financial+Sector+10202003.pdf

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IS CP/M an OS?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IS CP/M an OS?
Newsgroups: alt.folklore.computers,comp.os.cpm
Date: Tue, 18 Nov 2003 14:58:15 GMT

jmfbahciv writes:
Other than the fact that this is all BS, I was talking about specialty requirements. I had understood that Multics' was security. So go back to my question. I'm more interested if there was a "something else" reason; if so, what was it?

from a couple threads on buffer overflows
https://www.garlic.com/~lynn/aadsm16.htm#1
https://www.garlic.com/~lynn/aadsm15.htm#23

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

TSO alternative

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSO alternative
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 18 Nov 2003 15:33:17 GMT

usenet5678@ibm-main.yahoo.com (Gilbert Saint-Flour) writes:
In addition to Roscoe, SuperWylbur and Tone (already mentioned), you may also be able to use Condor/MVS (Phoenix Software) and BIM-Edit/MVS (CSI/BIM).

CERN did a SHARE report circa 1974 on its comparison of CMS and TSO. The results so concern some number of people that copies of the report inside IBM were labeled IBM Confidential - Restricted ... available on need to know basis only ... one could sort of claim that the evolution of GML->SGML->HTML->XML, etc ... from the cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech
and a lot of it is now back in cambridge (aka w3c).

Early '80s one of the people that had done pascal at the Los Gatos VLSI lab (which turned into VS/Pascal, etc) left and formed a startup to do a special 3270 terminal controller .... the issue was to try and offload some of the TSO features into the controller in an attempt to achieve sub-second response.

slightly related thread:
https://www.garlic.com/~lynn/2003o.html#14 When nerds were nerds
https://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

securID weakness

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: securID weakness
Newsgroups: comp.security.misc
Date: Tue, 18 Nov 2003 17:06:36 GMT

apm35@student.open.ac.uk (apm) writes:
Security verification is said to be a mix of "what you know, what you have, who you are", with passwords being what you know, things like securID being what you have, and biometrics being what you are.

one security taxonamy is PAIN

Privacy
Authentication (and/or Availability)
Integrity (and/or Identification)
Non-repudiation

an authentication taxonomy is

something you have
something you know
something you are

within something you know ... you can have

shared-secrets
non-shared-secrets

misc. recent taxonomy postings:
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Tools -vs- Utility

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tools -vs- Utility
Newsgroups: alt.folklore.computers
Date: Thu, 20 Nov 2003 17:41:56 GMT

Larry__Weiss writes:
Exactly. Early on there was a lot of speculation about a global computer utility industry, very much like the electrical utility industry. Your tools interact with it, but it itself is not thought of as a tool. Computing units of work would be metered and billed very much like electricity.

The "computer centers" at universities in the 1960's and 1970's established smaller variations on that model. You had an account and your activities were logged and charged against funding sources. That was the paradigm that the "Home Computer Revolution" revolted against.

It's interesting to me that the Internet is somewhat neutral with respect to the Tools -vs- Utility ideas. It enables a mix of both.

lots of the time-sharing service bureaus were like that ... in-house, general commerical, etc. some of the commerical were cp67/vm370 based (like tymshare, idc, ncss, etc):
https://www.garlic.com/~lynn/submain.html#timeshare

from the work at science center, 545 tech sq.
https://www.garlic.com/~lynn/subtopic.html#545tech

one of the largest cp67/vm370 "services" was an in-house collection of datacenters that supported all the field, sales, and marketing activities world-wide:
https://www.garlic.com/~lynn/subtopic.html#hone

both multics (on 5th floor) and cp67/vm370 (on the 4th floor) trace some common heritage back to ctss.

grid, dataprocessing utility and ... computing on demand is currently getting lots of hype. minor on demand refs:
https://www.garlic.com/~lynn/2002n.html#52 Computing on Demand ... was cpu metering
https://www.garlic.com/~lynn/2003j.html#38 Virtual Cleaning Cartridge

also, i believe that the term information utility was originally coined in the late '80s. minor information utility references:
https://www.garlic.com/~lynn/2001.html#20 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2002m.html#61 The next big things that weren't
https://www.garlic.com/~lynn/2003j.html#38 Virtual Cleaning Cartridge

the formation of bcs, early-on established a cp67 inhouse operation ... expanding it and then went on to sell specialized services externally. minor bcs references:
https://www.garlic.com/~lynn/99.html#130 early hardware
https://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001b.html#8 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001b.html#9 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001g.html#56 YKYBHTLW....
https://www.garlic.com/~lynn/2001m.html#55 TSS/360
https://www.garlic.com/~lynn/2002f.html#30 Computers in Science Fiction
https://www.garlic.com/~lynn/2002j.html#22 Computer Terminal Design Over the Years
https://www.garlic.com/~lynn/2002j.html#43 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2002l.html#64 10 choices that were critical to the Net's success
https://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
https://www.garlic.com/~lynn/2002n.html#72 bps loader, was PLX
https://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
https://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
https://www.garlic.com/~lynn/2003l.html#34 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2003l.html#37 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2003m.html#32 SR 15,15 was: IEFBR14 Problems

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Tools -vs- Utility

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tools -vs- Utility
Newsgroups: alt.folklore.computers
Date: Thu, 20 Nov 2003 17:47:10 GMT

Roland Hutchinson writes:
When non-centralized computing came along (actually quite a bit in advance of the minis in some places), there was a strong incentive to use departmental or lab-owned machines where you wouldn't be charged by the second for CPU usage and by the line for I/O.

some discussion of explosion of mid-range (370) computers for departmental & distributed servers .... a market that later was siphoned off by workstation-based servers and even later still the ever increasing power of the pc-based servers:
https://www.garlic.com/~lynn/2001m.html#15 departmental servers

slightly related dicussions of pc network servers:
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
https://www.garlic.com/~lynn/2000g.html#40 No more innovation? Get serious
https://www.garlic.com/~lynn/2002f.html#19 When will IBM buy Sun?
https://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
https://www.garlic.com/~lynn/2003e.html#26 MP cost effectiveness
https://www.garlic.com/~lynn/2003f.html#13 Alpha performance, why?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Any experience with "The Last One"?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any experience with "The Last One"?
Newsgroups: comp.lang.c,alt.folklore.computers
Date: Fri, 21 Nov 2003 12:33:44 GMT

Richard Heathfield writes:
I know what's scary about gets(), but I don't quite see what's scary about strcpy(), when used properly. Would you care to expand on this?

Crossposted to comp.lang.c, followups set to that group.

in general, the paradigm of having data pattern define the (implicit) length is prone to all sorts of mistakes.

it is somewhat analogous to automobiles when driven properly never have accidents; that didn't stop the US from having 50,000 deaths a year in traffic accidents.

recent thread on buffer overflow from sci.crypt with multics reference study that includes reference to not having any buffer overflows:
https://www.garlic.com/~lynn/2003o.html#5 performance vs. key size
https://www.garlic.com/~lynn/2003o.html#6 performance vs. key size

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

GNOME - viewing multiple workspaces simultaneously

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: GNOME - viewing multiple workspaces simultaneously
Newsgroups: linux.redhat.misc
Date: Fri, 21 Nov 2003 13:01:34 GMT

"Tim Lank" writes:
I think I need to clarify. I'm aware of the workspace switcher and viewing any one of multiple workspaces on the physical screen, but only one at a time.

Borrowing from your example, he wants his physical screen to show all four workspaces in small windows for viewing simultaneously. Sort of like being able to view a smaller window of all four workspaces running in the currently selected workspace.

sort of like the 3290 plasma screen from the '70s ... you could either map single window to the screen ... or divide it into four quardrants and map a different window to each of the four quardrants.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Sat, 22 Nov 2003 14:37:51 GMT

Morten Reistad writes:
It took 30 minutes to make the system spiral down to safety and start up again. Post-morten analysis showed that one, single 6-second break in transaction load would have been enough to catch up.

I sitting on the ground in san jose waiting to take off to chicago for a connection to boston ... about 6.30 am. the pilot comes on and says there is a 30 minute hold on take-off because of a t-storm moving thru ohare and a weather slowdown on landings/take-offs there. 30 minutes later the pilot says we are taking off ... that a t-storm had taken 30 minutes to move thru ohare that caused slow-down in traffic during those 30 minutes.

we landed in chicago about 45 minutes late (they had a little routing slowdown in transit) ... and went to check on connecting flight ... and take-offs were running about 2 -3hrs late and appeared to be increasing. by the time the boston flight took-off, it was four hrs late.

it looked like a 30 minute period with ohare traffic thruput cut something like in half (first thing in the morning) ... had spiraled into 4hr delays, six hrs later. note that the actual amount of traffic didn't actually increase ... and possibly had some decrease (some canceled flights). It looked like the only thing that allowed system to return to normal is the effective shutdown&reset that occurs with the 4-5hr overnight period.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Sat, 22 Nov 2003 14:48:16 GMT

Peter Flass writes:
This is why CMS had the (IIRC) "blip" feature. During a long compute process the system would periodically tilt the typeball, producing visible and audible feedback thet the system was still alive and working.

although feature could be used to perturb the early scheduler(s) ... which would reset the process scheduling for any kind of "terminal i/o" ... one of the things that i had to fix (more than once over the years).

lots of fair share scheduling refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare

slightly related post
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story

original Resource Manager "blue letter"
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
which became the basis for HPO

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Biometric cards will not stop identity fraud

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometric cards will not stop identity fraud
Newsgroups: alt.privacy
Date: Sat, 22 Nov 2003 23:50:56 GMT

sethra writes:
Unveiling the proposals last week, the home secretary, David Blunkett, said they are necessary to prevent identity fraud. Every resident would have to carry an ID card containing biometric information, such as an iris scan. Cards could then be checked against a central database to confirm the holder's identity.

say you can register your name and scan of some biological template (scan of fingerprint, iris, face, etc).

then you are some place, they scan your iris and look the scan of the iris up in central database.

There is no need for a card.

x9.84 is standard for biometric authentication. when the biometric template is registered in central database ... and the biometric scan is transmitted to the central database (no need for a card), then the biometric value is effectively a shared-secret and there is significant security protection required to not expose the biometric value to compromise.

At issue is when a PIN/password shared-secret is compromised ... it is possible to get a new, replacement PIN/password substitute. WHen a biometric shared-secret value is compromised, the technology for getting a new replacement is still somewhat tricky.

For a taxonomy of security, there is PAIN

privacy
authentication
integrity
non-repudiation

the taxonomy of authentication can be

something you have (aka hardware token)
something you know (aka pin/password) - shared-secret - non-shared-secret
something you are (aka biometric) - shared-secret - non-shared-secret

https://www.garlic.com/~lynn/subintegrity.html#3factor
An example of three-factor, non-shared-secret authentication is:

hardware token that performas a digital signature that proves somebody has that hardware token (something you have)
hardware token only operates in a specific way when the correct PIN is passed to a hardware token. It is non-shared-secret, since the operation of the hardware token proves something you know w/o having to pass the PIN (to central authority) along with the digital signature.
coupled with the hardware token also being required to validate a biometric value (something you are analogous to the way it validates a PIN) for its operation. It is non-shared-secret since the biometric value doesn't have to be passed with the digital signature.

A magstripe debit card can be considered to be a two-factor shared-secret, i.e. 1) some value is obtained from the card proving something you have and 2) a PIN something you know is entered which is passed along with the card value.

A hardware token or card is used either

provide something you have authentication
allow inferring non-shared-secret something you know and/or something you are by the way the token operates.

If it is purely biometric authentication at a central database, then it is purely shared-secret something you are authentication and there is no need to have the card for either

something you have authentication and/or
inferring non-shared-secret something you are authentication based on the way the card operates.

There are several different kinds of fraud clumped under identity theft. One kind is obtaining enough information to be able to do fraudulent financial transaction against an existing financial account (aka skimming/harvesting credit card numbers and then doing fraudulent transaction). More complex kinds require harvesting sufficient additional information in order to establish new accounts which are ultimately billed to the victim.

Most of these are not so much identification issues but authentication issues (vulnerabilities in the authentication procedures and/or authentication technologies).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

who invented the "popup" ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: who invented the "popup" ?
Newsgroups: alt.folklore.computers
Date: Sun, 23 Nov 2003 04:29:41 GMT

genew@mail.ocis.net (Gene Wirchenko) writes:
What was the model of printer that opened up (possibly spilling injudiciously-placed coffee) when out of paper?

1403N1 ... there were several 1403 ... on the N1, the cover was so heavy(?) that there was screw moter that lifted the cover (instead of manual). There was a button that raised/lowered the cover ... but the cover would also automatically raise when it sensed out of paper.

this is picture of 1403 on the left ... but not an N1, it is possibly a 1403-7 ... with manual cover.
https://web.archive.org/web/20030820180244/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide19.html

here is a picture of 1403-N1 with the cover up:
http://www.nfrpartners.com/comphistory/1403a.htm

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

who invented the "popup" ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: who invented the "popup" ?
Newsgroups: alt.folklore.computers
Date: Sun, 23 Nov 2003 14:42:33 GMT

arargh311NOSPAM writes:
Well, lets see. The 1403 with the 1401 would have been about 1968, and the 1401N1 was on a sys360, so 1970-1974. After that I moved to mini's, and met a Centronics-101. Still have the mini and a 101. :-)

the univ. had a 1403-7(?) with the 1401 ... and got a 1403N1 with the installation of the 360/30 start of the summer of 1966. the 360/30 was replaced with 360/67 in 1967.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

who invented the "popup" ?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: who invented the "popup" ?
Newsgroups: alt.folklore.computers
Date: Sun, 23 Nov 2003 15:12:49 GMT

"Dennis Ritchie" writes:
Troff is a descendant (knockoff, if you prefer, since they didn't share code) of Saltzer's CTSS runoff program (documented in the 1965 manual, perhaps before). Actually around then there were several quite similar formatting programs (embedded formatting commands started by "." that looked pretty much the same). GE-TSS had one, for example, and I gather Digital's was as well.

madnick did script (dot commands) for CMS sometime 67. some number of the ctss people were at science center on the 4th floor, 545 tech sq. (did cms & cp/40 on specially modified 360/40 with hardware virtual memory and then ported to 360/67 and renamed cp/67) and some number were at project mac on the 5th floor.

"G", "M", & "L" (science center, 4th floor) then came up with GML and support was added to script circa 1971 or so (which then was standardized later in the 70s as SGML, and evolved into html, xml, etc).

misc. refs from around the net:
http://www.romankoch.ch/capslock/minigml.htm
http://csgwww.uwaterloo.ca/sdtp/watscr.html
http://www.arrix.com/mdcfdesc.htm
https://web.archive.org/web/20231001185033/http://www.sgmlsource.com/history/roots.htm
https://web.archive.org/web/20230402212558/http://www.sgmlsource.com/history/jasis.htm

there is collection of old posts (93-95) from a.f.c. on the subject
http://users.rcn.com/enf/afc/wp

note in Tom's comment in the above about Stu ... and somewhat science center characteristic of getting your name/initials as part of the product. slight drift ... but in addition to GML ... the other well known is charlie's CAS ... compare and swap instruction.

in any case, from Tom's post in above:


The correct lineage is:
PDP-1 Expensive Typewriter   (Peter Sampson)  about 1962
CTSS RUNOFF   (Jerry Saltzer)  1964-65
CMS SCRIPT   (Stuart E. Madnick)  1967
      CTSS BCPL runoff   (Rudd Canaday, Dennis Ritchie)  1967-68
Multics BCPL runoff   (Canaday, Ritchie, Ossanna)  1968
          UNIX troff    (J. F. Ossanna)  dunno

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Sun, 23 Nov 2003 16:21:04 GMT

Peter Flass writes:
Queueing theory. Once you start to get delays in a loaded system, the delays increase exponentially. All the planes that were held for a half-hour then wanted to take off at roughly the same time, when the system was already loaded with planes scheduled to take off.

so for half-hour .... airport was operating at half thruput ... worst case, take-offs were held at one hundred percent.

normal airport traffic wouldn't have been at 100 percent saturation take-off saturation for the whole next four hours; aka in theory there should have been slightly less than 100 percent take-off capacity saturation over the next four hrs to have absorbed even 30 minutes of 100 percent take-off traffic.

worst case .... slip every scheduled take-off by 30 minutes.

contention is that there should have been some excess take-off capacity during the next four hrs to have absorbed the take-off traffic load from the 30 minute t-storm ... and worst case, (where normal take-off traffic is one hundred percent of capacity for the full four hr period) everything could be shifted by a 30 minute delay.

so after four hrs ... would have expected the worst case for everything to continue on a 30 minute shifted delay ... and during any periods where normal take-off traffic is at less than at one hundred percent workload traffic ... it would have absorbed some of the delayed traffic from early in the morning and started to see the 30 minute shifted delay start to decrease.

The issue is that normal scheduled take-off traffic is at one hundred percent or less of capacity. There was (at most) 30 minutes of excess take-off capacity from first thing in the morning. Worst case is that after four hrs there would have still been 30 minutes of excess queued take-off traffic. Better than worst case would have had that 30 minutes of excess queued traffic (at least partially) absorbed during periods where there was less than 100 percent normal scheduled take-off traffic.

However, there appears to be other negative feedback forces in effect, which starts to greatly magnify the effects of 30 minutes of excess queued take-off traffic. Rather than gracefully absorbing the 30 minutes of excess queued take-off traffic over the period of 8-10 hrs ... the negative take-off delay effects were drastically increasing. It appeared to require the overnight total system shutdown to return to stable condition.

The 30 minute excess queued take-off traffic shouldn't have been causing increases in the amount of other traffic. In fact, there were some number of normally scheduled flights that were canceled during the course of the day (increasing the expected probability that there should have been excess take-off traffic capacity to start absorbing the 30 minute queued traffic from first thing in the morning).

sorry about getting long-winded. i created dynamic adaptive feedback scheduling for cp/67 back when I was an undergraduate in the '60s. It was shipped in the standard product and then dropped in the cp67 to vm370 transition. I then got to put it back in with the resource manager for vm/370 ... as the first charged-for, licensed SCP software (for the privilege of releasing the resource manager, I also was given the privilege of working with the business people for six months to establish the business rules for priced, SCP software). In any case, there was a lot of work done on graceful degradation.

Hypothetically, say there are take-offs spaced once per minute. Normal schedule has plane leaving the gate, taxi'ing to the runway, taking off. With the 30 minute delay, there are 30 extra planes queued for the runway ... waiting for take-off slot. Normal scheduled traffic is now leaving the gate at approximately rate of once per minute (or less) and joining the queue ... which is being emptied at one per minute. For the rest of the day, normal traffic has planes entering the queue at no more than once per minute avg. Worst case should keep 30 planes in the queue for the duration of the day ... and possibly reduce over the course of the day during periods when planes can continue to leave the queue at once per minute, but the arrival rate declines to somewhat less than once per minute.

Queuing theory has exponential delay increases when the arrival rate continues to exceed the departure rate. This scenario, except for the one time 30 minute hit; has the avg. scheduled arrival rate (into the queue) continues thru-out the rest of the day to be no more than the avg. service/departure rate.

So a hypothetical assumption is that the (rest of the) day-long, normal, clear-sky take-off (service) rate of the system is cut in half ... whenever there are 30 queued planes ... such that the (normally scheduled) arrival rate into the queue is now much larger than the departure/service rate (leading to the possibly exponential delay increases). Now, I know of no condition that should drastically cut the normal take-off intervals during normal, clear-sky conditions just because there is a long queue of planes. Also as the queue of planes increases over the day ... the plane take-off rate continues to decline (resulting in what appears to be negative feedback effect). However, the observed situation seems to strongly imply such a conclusion. Note that many service infrastructures tend to have slightly higher/better long-term service rates when there is some queue than when there is no queue (allowing some optimal service re-ordering).

a slightly related long winded reference (there was acutally more code in the resource manager having to do with system integrity than with resource management):
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/ Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Will Prescott work on Win64?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Will Prescott work on Win64?
Newsgroups: comp.arch
Date: Sun, 23 Nov 2003 16:26:24 GMT

"Felger Carbon" writes:
Remember the muscle cars? People finally figured out they didn't need 600HP to drive to the store for a loaf of bread and a quart of milk, so the muscle cars went away. That's when cars got really cheap.

foreign imports seemed to have contributed to making cars really cheap ... that was somewhat reversed with import quotas. government mandated MPG had big effect on muscle cars .... however note that the large SUVs are effectively the same class as the muscle cars (there may actually be higher percentage than during the muscle car days).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Humans

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Humans
Newsgroups: sci.crypt
Date: Sun, 23 Nov 2003 17:02:59 GMT

George Ou writes:
I think Graham means more than just the passwords that humans have to memorize. Sure it's possible for 2 somputers to have secure communications, but it is always cheaper to tie one of the users up and after a few days torture he will divulge whatever information an attacker seeks. Even cheaper would be to put a hidden camera in the room.

However, I don't think this should be an excuse to have bad cryptographic security. In fact that is the whole point fo good cryptographic security, and that's to make it infeasible to do a brute force attack.

phishing has humans giving up information w/o any torture at all. one of the problems with existing infrastructure and shared-secrets is that there are large number of ways that are much less expensive and have a much higher fraud ROI than torture.

The existing scenarios with shared-secrets has so much leakage ... that it brings into question the whole paradigm of human-known shared-secrets (you can't give up what you don't know). This is independent of human memory issues where shared-secrets require a unique value for every security domain and the large proliferation in the number of shared-secrets (and security domains) that humans are being required to manage.

misc. phishing references:
https://www.garlic.com/~lynn/aadsm14.htm#51 Feds, industry warn of spike in ID theft scams
https://www.garlic.com/~lynn/aadsm16.htm#2 Electronic Safety and Soundness: Securing Finance in a New Age
https://www.garlic.com/~lynn/2003o.html#9 Bank security question (newbie question)

you can get a lot more with almost any search engine.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Sun, 23 Nov 2003 22:08:58 GMT

glen herrmannsfeldt writes:
For at least some of IBM's terminals data entry was local, and updated on the screen. When the user hit enter, or some other special key, either the whole screen, or just the input fields, would be read as one operation.

there are degrees of local.

for the 3272/3277 controller/terminal ... it was local in the terminal. we did some local engineering and with little wirewrap and some other stuff could change the repeat delay & speed. Could also install a fifo box that made it a little more like full-duplex and avoid the annoying problem that if you were hitting a key at the same time the system was trying to rewrite the screen ... the keyboard locked and the reset key had to be hit. The fifo buffered the keystrokes and monitored the system write indication to avoid the keyboard lock condition.

along came the newer 3274 controller (& new generation of 3278/3279/3290 terminals) all of that logic was moved back into the 3274 controller (and out of the terminal).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Security of Oyster Cards

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security of Oyster Cards
Newsgroups: uk.transport.london,alt.2600,sci.crypt
Date: Sun, 23 Nov 2003 22:21:46 GMT

"Ernst Lippe" <ernstl-at-planet-dot-nl@ignore.this> writes:
Even though some criminal organizations have a large resources at their disposal, I don't think that they will use them to attack smart cards. It is just a simple matter of economics. The initial investments are pretty big, you need some highly skilled experts and some pretty expensive equipment just to break a single smart card. In almost all smart card systems you don't gain much when you are only able to duplicate a single smart card, because it will be put on the red list and you won't be able to really use any of the duplicates. But even when you are able to make new "cards" (actually, these new devices probably are not smart cards (it is not at all easy to obtain a large set of "empty" smart cards), but other microprocessor devices that pretend that they are smart cards) you still have to make major investments, like producing these new "cards" and more importantly you will have to set up an expensive distribution channel. Given the large financial risks in such an operation, I don't think that is economically very attractive, even for smart cards that have high financial values.

check out yes card references in the following post/trip report (last paragraph):
http://www.smartcard.co.uk/resources/articles/cartes2002.html access problems, trying wayback machine
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

The yes card label supposedly started in the UK press(?)

also mentioned/reference in thread on WYTM (whats your threat model)
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Mon, 24 Nov 2003 16:27:07 GMT

jmfbahciv writes:
Nope. It should have increased. Think about it. You're dealing with human and equipment flows. Connections have to wait for the late plane to get in (because it's the plane that is going to be used for the connection). That affects all flights previous to the connection event. If one of those flights is on the east coast, there's no point putting the plane in the air, if it's going to be circling O'Hare for an hour or taking up the slot space for a plane that has to land, deplane, embark and fly out before the connection can be allowed to land.

so the original implication was that there appeared to be significant systemic negative feedback effects causing delays to increase dramatically during the course of the day (and possibly were likely not related to handling the extra queue of planes waiting for take-off) ... and the only recovery from the significant systemic problems was wait for the overnight effective 4-5hr shutdown to reset the system and start over (i.e. the infrastructure is so fragile that it is difficult to gracefully degrade when presented with some simple common problems).
https://www.garlic.com/~lynn/2003o.html#27 When nerds were nerds

the original (posting) implication was that simple queuing theory in a system capable of dyamically adapting and gracefully degrading .... should have lessoned the effects of the problem ... as time passed (aka in some sense a self repairing infrastructure). The original observation was that rather than the 30 minute delay problem being mitigated over the course of the day ... the effects were severely magnified. It was an observation that there are apparently significant factors that prevent glitch mitigation over time .... and over time amplify the effects of any glitches that occur in the system ... and essentially require the overnight shutdown and reset of the system to recover from significant systemic negative feedback forces.

for a couple years ... a couple times a month i would get to take twa 44 redeye from sfo to kennedy on monday night and then twa flight 8?? back (it was the tel aviv/rome/kennedy/sfo flight) friday afternoon. when twa went bankrupt, i switched to panam flights. panam then sold its pacific routes/planes to united to concentrate on east coast/europe routes. In any case, it got so I would sitdown and fall asleep before take-off ... and then (early tues) I would go directly to the office after landing in kennedy. It got to be so much of a habit, that now just sitting down in a plane seat immediately makes me want to close my eyes. Usually I would get to check into a hotel late tuesday night ... after working all day on the west coast monday and getting maybe five hrs of sleep on the redeye. I remember one tuesday night tho, getting con'ed into going drinking with John Cocke. It started about 8pm and i have very vaque recollection of trying to check into a hotel at 4am weds. morning.
http://www.research.ibm.com/resources/news/20020717_cocke.shtml

anybody have any idea what the boards are in the picture at the above ref (they look a little like some of the boards in the LSM?).

with regard to some of the drift above
https://www.garlic.com/~lynn/subtopic.html#801

also lsm, yse, & eve:
https://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
https://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
https://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
https://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
https://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

MUMPS & MUSIC, was: SMF Records - a side issue

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: MUMPS & MUSIC, was: SMF Records - a side issue
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 24 Nov 2003 17:51:54 GMT

nstutz@ibm-main.talweb.com (Neil Stutz) writes:
There's also an IBM operating system called MUSIC which runs under VM at McGill University and elsewhere. MUSIC stands for Multi-User System for Interactive Computing System Product. See
http://ww2.mcgill.ca/cc/central/ccmusic.htm.

was there any connection between mumps and music?

this entry doesn't mention any
http://www.tutorgig.com/encyclopedia/getdefn.jsp?keywords=Mumps

but I thot I remember some places in boston area during the 70s with some connection between mumps and music.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Tue, 25 Nov 2003 02:37:24 GMT

Steve O'Hara-Smith writes:
So do I, and neither do I.

are you talking about me?

i'm notorious for stuff like that.

there is stanford phd thesis (joint language and computer ai). for nine months in the early 80s they studied (nearly) all my communication. They sat in the back of my office, followed me to meetings, took notes on my conversations (face-to-face and telephone) and got copies of all my incoming and outgoing email as well as log of all my instant messages.

i believe there was also a couple of follow on books from the material.
https://www.garlic.com/~lynn/subnetwork.html#cmc

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When nerds were nerds

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When nerds were nerds
Newsgroups: alt.folklore.computers
Date: Tue, 25 Nov 2003 15:43:03 GMT

jmfbahciv writes:
Think of waves. Unless you have an exact counter wave, all you get is a bigger mess spread over a larger area.

lots of systems tend to mitigate glitches over time. other systems have negative feedback where the effect of glitches are amplified over time. you want to design resilient systems that dampen the effects of glitches rather than amplify them.

probably everybody has seen pictures of the tacoma narrows bridge going down.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

misc. dmksnt

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: misc. dmksnt
Newsgroups: bit.listserv.vmesa-l
Date: Thu, 27 Nov 2003 09:57:58 -0700

At 10:01 11/25/2003 -0600, michaelcoffin@mc wrote:
<gripe> Some of these Program Product directories are in GREAT need of updating! Take a look at ISPF for example, it's written for VM/SP 6 and VM/XA 2! I'd hate to be one of those Linux/390 "newbies" trying to find DMKSNT on my z/VM 4.4 system. The SDO provides a bit more info, but if memory serves me it didn't work as documented because there is no PLANINFO. </gripe>

the whole DMKSNT was supposed to (should have) have gone away in VM/370 release 3. DMKSNT was carry over from CP/67 where the system defined stuff for page-mapped and shared pages. When I moved a lot of stuff from CP/67 to VM/370 (a lot of it had been dropped in the CP/67 to VM/370 port) I had page-mapped filesystem and bunch of shared pages stuff directly supported by CMS infrastructure. Much of the CMS shared-stuff was picked up for VM/370 release 3 but only a subset of the CP changes were picked up .... and were morphed into the discontiguous shared segment paradigm/API (which w/o the full blown interface, the CMS support then had to morph to correspond to what the underlying CP provided).

misc. discussion of page map filesystem implementation
https://www.garlic.com/~lynn/submain.html#mmap

as well as attempting to support allowing the same shared segment to appear at different virtual address in different virtual address spaces
https://www.garlic.com/~lynn/submain.html#adcon

Computer folklore - forecasting Sputnik's orbit with

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Computer folklore - forecasting Sputnik's orbit with
machinelanguage
Newsgroups: alt.folklore.computers
Date: Mon, 01 Dec 2003 23:11:17 GMT

glen herrmannsfeldt writes:
The S/360 architecture was designed independently of any specific implementation. Most implementations were microcoded, in which case the opcodes go into a big lookup table.

Early microprocessor designers may have tried to use bit patterns to directly control gating.

slight cross-over with some of the other threads. I was told regarding seven dwarfs cited in the gov. legal thing with ibm ... that some number of the seven dwarfs testified that in the late '50s everybody in the computer industry realized that having a common interface across all machines in the product line was going to be the single most important characteristic for computer customers. somewhat the issue was that customers bought some machine, developed applications ... and the use of the application then saw explosive growth (either because its use inside the company grew quickly and/or the company was growing). The faster machines in the product line needed to be compatible with the slower machines.

supposedly the testimony was that only IBM was really successful in forcing all of the different machine product groups to tie the line on a common architecture across all machines ... and since it was supposedly the single most important characteristic for the customers ... it achieved some amount of acceptance.

a lot of the system/360 microengines were giving up 10:1 performance to achieve product line compatibility ... i.e. it was taking an avg. of ten instructions on the hardware engine for every 360 instruction executed.

some past refs to seven dwarfs &/or bunch:
https://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
https://www.garlic.com/~lynn/2003.html#36 mainframe
https://www.garlic.com/~lynn/2003.html#71 Card Columns
https://www.garlic.com/~lynn/2003b.html#61 difference between itanium and alpha

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Biometrics

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Biometrics
Newsgroups: alt.computer.security
Date: Tue, 02 Dec 2003 01:45:13 GMT

Gadi Evron writes:
Every system has its downsides.

The whole point is to use the biometric system along with another system. That way you double the technology, and it is more difficult, to a level, to get in. For example, password + finger print. Something you know + something you are.

simple scenario is large segment of population that write their PIN number on their debit cards. So the issue is it more difficult for a crook to steal a debit card ... and

1) use that debit card by entering the PIN written on the card

2) use that debit card by lifting a latent print from the card, duplicating that print ... and when they go to use the card, entering the duplicating latent print ... and hope that it is the one that is suppose to be used

part of the issue is the proliferation of something you know shared-secret infrastructures requiring a unique shared-secret for every different security domain.

lots of past discussions about three factor authentication as part of security paradigm ... and comparison of something you know plus something you are .... along with differentiation between shared-secret and non-shared-secret paradigm

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Any experience with "The Last One"?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any experience with "The Last One"?
Newsgroups: alt.folklore.computers
Date: Thu, 04 Dec 2003 13:55:40 GMT

Brian Inglis writes:
ISTR reading JMF et al.'s paper on TOPS-10 SMP implementation, which basically documented a roadmap for changing a UP OS into an SMP OS, and I doubt it took them two years to do the changes in PDP-10 assembler, testing, and debugging with DDT. I doubt any SMP OS is ever fully debugged: there are always unforeseen hardware / software interactions that require fixes. ISTM from the descriptions and code that about 90% of VM fixes in the 1980s were for obscure SMP edge conditions.

somewhat related posting:
https://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

What 'NSA'?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What 'NSA'?
Newsgroups: sci.crypt
Date: Thu, 04 Dec 2003 14:19:43 GMT

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
3DES was originally intended for protection of transfer of large volumes of money among banks themselves long ago and there was a standard document for such banking use of 3DES, if I don't err. It seems on the other hand not easy for outsiders to get details of how they actually protect that high-value transfer. But nowadays even the customer to bank link is protected by 3DES, at least for certain banks, see e.g.

an issue is security proportional to risk. the attack on DES isn't on the algorithm but brute force against specific keys. 3DES extends the size of the keys making brute force attack much more difficult.

atm machines, etc, have had derived key DES (DUKPT) for some time. a des key is generated from the machine master key and some unique characteristics of the transaction. brute force against any specific transaction DUKPT key ... could eventually recover the contents of what that transaction happened to be ... but will not recover any additional information.

DUKPT is designed to be non-reversible analogous to SHA-1 and misc. other hashes.

that doesn't mean that there aren't attacks on non-reversible techniques ... recent thread on one time password (OTP) attack:
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/2003n.html#1 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?

misc. standards on one time password ... select
https://www.garlic.com/~lynn/rfcietff.htm

and in RFCs listed by select Term (term->RFC#)

and in Acronym Fastpath select "OTP"

i.e.
one-time password (OTP)
see also password
2444 2289 2243 1938 1760

selecting any RFC number, brings up the RFC summary in the lower frame. selecting the ".txt=" field retrieves the actual RFC.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Funny Micro$oft patent

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Funny Micro$oft patent
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 06 Dec 2003 01:58:13 GMT

Shmuel+gen@ibm-main.Patriot.net (Shmuel Metz , Seymour J.) writes:
The VTOX centralizes the extent information for a file in a single DSCB, or at most a small number. The VTOC is designed to allow allocating a small number of large extents, and is wasteful for very small files. The FAT is designed to support a large number of very small extents, and is wasteful for large files.

FAT, unix and cms all started out being able to have random scatter allocate on record by record basis ... w/o any pre-knowledge about (file) size. note that somewhat unix derives from multics done at 5th floor, 545 tech sq ... in turned derived from ctss; cms was done at 4th floor, 545 tech sq ... somewhat derived from ctss.

cms was originally done in conjunction with cp/40 ... running on a custom modified 360/40 with virtual memory ... and later ported to 360/67 and renamed cp/67 ... which in turned later morphed into vm/370. CMS was originally the cambridge monitor system (named for the ibm cambridge science center, 4th floor, 545 tech sq), but was renamed conversational monitor system as part of the morph into vm/370.

archeological reference to early cms file system development 1965/1966 (also some description on how funds were shifted around to fund the virtual memory hardware modifications to the 360/40):
https://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...

side note from above that CMS preformated and treated even CKD disks as logical FBA from the start.

more refs to structure of cms file system
https://www.garlic.com/~lynn/2001n.html#7 More newbie stop the war here!

misc. other 545 tech sq refs:
https://www.garlic.com/~lynn/subtopic.html#545tech

some stuff about having done page mapped enhancement for cms file system:
https://www.garlic.com/~lynn/submain.html#mmap

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

incremental cms file backup

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: incremental cms file backup
Newsgroups: bit.listserv.vmesa-l
Date: Sat, 06 Dec 2003 05:05:40 -0700

At 14:40, 5 dec 2003, jkaba@fhsu.edu wrote:
Is CA's VM:Backup/HIDRO the only game in town when it comes to File Level Backup/Restore capabilities for VM? We currently have their product, but are switching from a 9121 Mod 260 to a 9672-R16, and we will be taking quite a hit in price. Just wondering if there are other products available.

i did incremental file backup for cms that was used internally in some number of places; it then morphed into workstation datasave facility (WDSF), then morphed into adsm (adstar storage manager) and is now called tivoli storage manager (tsm).

random past backup postings:
https://www.garlic.com/~lynn/submain.html#backup

and a little thread drift from ibm-main about filesystems
https://www.garlic.com/~lynn/2003o.html#47 Funny Micro$oft patent

tsm web site:
http://www-3.ibm.com/software/tivoli/products/storage-mgr/
tsm has really morphed from starting out as a cms incremental file backup
http://www-3.ibm.com/fcgi-bin/common/ssi/ssialias?infotype=an&subtype=ca&htmlfid=897/ENUS201-219&appname=demonstration

Any experience with "The Last One"?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any experience with "The Last One"?
Newsgroups: alt.folklore.computers,comp.programming
Date: Sat, 06 Dec 2003 14:51:20 GMT

Jeff Teunissen writes:
The heart of SCO's argument is that IBM ported technology to Linux from AIX (JFS) and Dynix (RCU), the implementations of which (the technologies, not the operating systems) contain no SCO-owned source code.

As for JFS, the situation is very clear. The JFS code that runs on Linux is not only not owned by SCO, it is not even based on the JFS source code from AIX. Its origin is a from-scratch reimplementation of JFS on the OS/2 operating system. It is actually enough better than the AIX implementation that the OS/2/Linux implementation is now being ported to AIX. :)

801/CPr used some unique hardware on 801 for transaction memory this was basically was used for JFS implementation all AIX ... gather up all the unix file system metadata into specific memory area that was profiled as transaction memory ... and being able to track memory change lines.

the (ibm) palo alto group looked at porting AIX (the rios/power version, not the ucla locus stuff that was aix/370 & aix/ps2 ... which had also been done by the palo alto group) to other hardware platforms. One of the issues was to rewrite JFS so that it didn't require the 801 transaction memory hardware features, but instead used standard paradigm logging calls.

the rewrite w/o using the transaction memory hardware feature was actually faster. there was some performance trade-offs between having explicit inline logging calls (using traditional paradigm) ... and doing scans to find changed memory lines for (implicit) logging.

semi-related past refs
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2001f.html#58 JFSes: are they really needed?
https://www.garlic.com/~lynn/2001j.html#17 I hate Compaq
https://www.garlic.com/~lynn/2003d.html#54 Filesystems

generail 801/power posts:
https://www.garlic.com/~lynn/subtopic.html#801

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Pub/priv key security

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pub/priv key security
Newsgroups: comp.security.ssh
Date: Mon, 08 Dec 2003 16:16:33 GMT

"roberto2312@hotmail.com" writes:
I have a small (security question: how many pub/priv key is more secure against password access?

Is true that a 512bit pub/priv key is ~10times more secure than a 10 char pwd (5bit*10=50bit 512/50=~10) against brute-force attack?

side note regarding rsa-576
http://slashdot.org/articles/03/12/07/235214.shtml?tid=126&tid=172&tid=93

misc. general observations

1) pin/password is shared-secret. evesdropping/skimming/harvesting the pin/password allows impersonation.

2) public/private key is non-shared-secret. evesdropping digital signatures doesn't allow for impersonation (other than replay attacks). skimming/harvesting public key at server doesn't allow for impersonation

3) pin/password being a shared-secret paradigm (because of #1) requires unique shared-secret for every security domain ... leading to scores of pin/passwords that each human needs to remember

4) public/private key (directly) is non-shared-secret paradigm ... and can be used to help mitigate human factor problems with having to remember scores of pin/passwords.

Frequently there is a pin/password that is required to decrypt/access the private key .... however this is nominally within the context of a person's private environment and therefor not a shared-secret but a non-shared-secret (i.e. there is only one single pin/password rather than unique pin/password for every infrastructure that the public/private key is to be used).

There has been some observations that recent exploits have been 1/3rd buffer overflows, 1/3rd automated viruses/trojans, and 1/3rd phishing and/or social engineering.

phishing shared-secret pin/password allows attacker to directly impresonate. phishing private key pin/password doesn't directly do the attacker any good unless they can also obtain the entity's private key container (software file or hardware token) ... aka it becomes two-factor authentication (something you have and something you know) rather than simple single-factor authentication, and more specifically a shared-secret something you know paradigm that is part of the human factors problem with scores of shared-secrets.

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

part of thread in sci.crypt that had wandered into issue of key strengths and attacks on keys:
https://www.garlic.com/~lynn/2003o.html#46

and some past postings on assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

* New Software: UDP File Transfer Commercial Edition *

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: *** New Software: UDP File Transfer Commercial Edition ***
Newsgroups: comp.dcom.modems.cable,comp.protocols.tcp-ip
Date: Mon, 08 Dec 2003 19:39:35 GMT

Olathe writes:
Although it's written in an application, that doesn't necessarily make it level 7. For instance, if someone wrote a program for a system that provided Ethernet networking, but not TCP/IP, and he implemented TCP/IP inside his program to allow it to use the Internet, the TCP/IP implementation would not be at level 7.

The levels are based more on the purpose of the algorithm than the location of it.

somewhat aside .... OSI model doesn't allow for either internet and/or LANs, aka there is nothing in the OSI model that corresponds to the IP/internetworking layer.

also, in late '80s, trying to interest ANSI in high-speed protocol that went directly from transport interface (aka level 4) to LAN interface, the observation was that ISO chartered groups responsible for level 3/4 standards group ... could not do standard for something that violated the OSI model. The LAN/MAC interface subsumes level 1, level 2, and reaches effectively mid-way into level 3.

HSP violated OSI model (and therefor couldn't be worked on for standard)

1) went directly from level 4/5 interface to MAC layer ... bypassing the level 3/4 interface ... violating the OSI model.

2) went directly to MAC layer interface ... which sits in the middle of level 3 ... violating the OSI model.

and of course .... the ip or internetworking layer .... with respect to OSI ... exists in a non-existent place between the bottom of level 4/transport and the top of level 3/networking.

random ref:
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Virtual Machine Concept

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virtual Machine Concept
Newsgroups: bit.listserv.ibm-main
Date: Mon, 08 Dec 2003 21:13:25 GMT

"xarax" writes:
Performance is not the issue with the VM concept thing. In the real world, there is the Interpretive Execution Facility (IEF) that lets a guest run in supervisor state and intercepts occur for a few "special cases" that the host must resolve.

The VM concept thing is about a pure software implementation of a VM host that makes it guests *think* they are running in supervisor state when they are actually running in problem state with tightly controlled access to all virtualized machine resources. There is NO WAY for a problem state program to force access to privileged resources so that it could figure out that it is really not running in supervisor state. MVS *allows* unauthorized programs to see some privileged information, like the linkage stack, and that is legal under the VM concept thing.

IBM has been highly compliant with the VM concept thing for decades. The EPSW instruction clearly violates it, and when I complained about it, all I got was, "the hardware is already built" (so what?) and "ESTA can see the PSW anyway, so it's not like this is the first violation" (ESTA can see the PSW *only* because MVS wants it that way, which is allowed by the VM concept rules).

360/370 VM supervisor/kernel has always been outside of the addressable address space of its applications. LPSW allowed for the VM supervisor/kernel in one instruction to

1) totally switch address context from kernel to application/guest (basically the VM kernel ran in real mode, so all the control registers could be loaded with the various address space pointers, then the kernel would switch from real address mode to virtual address mode ... aka DAT mode, bit 5).

2) switch from supervisor state to problem state (problem mode, bit 15)

and all instructions having anything to do with the state and/or resources of the machine were under control of the supervisor/problem mode.

One of the things that added VMA (virtual machine assist) to 370/158 & 370/168 was to improve performance ... especially of guest operating system. MVS significantly increased the ratio of supervisor activity to problem activity .... so the time spent in the VM kernel doing (supervisor instruction) software emulation went up drastically. note that MVS increased lots of areas drastically ... there were instances of MVT and/or VS/1 under VM on 370/158 running faster than MVS native on 370/168.

Later Amdahl series of machines were built with something called macro-code (sort of intermediate layer between standard 370 and microcode) that drastically simplified adding new machine features). They added some number of VM-related enhancements which IBM sort-of responded to with PR/SM

The difficulty in moving the VM kernel completely into some non-real, virtual address space was no provision that allowed swapping from one address space context to a totally different address space context in a single instruction that also switched supervisor/problem mode at the same time (aka MVS design point back to early 360 days was that the kernel and the application code occupied the same address space/context).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Pub/priv key security

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pub/priv key security
Newsgroups: comp.security.ssh
Date: Mon, 08 Dec 2003 23:50:26 GMT

Chris Mattern writes:
No. The 512bit key is (2^512)/(2^50)= prox 10^139

brute force attack on 56bit des key means trying 2^56 possible keys (or on the avg. only one half). brute force attack on 512bit pub/private key means trying the possible prime numbers in 2^512 not all 2^512 numbers (i.e. pub/priv RSA only uses prime numbers).

see recent news item:
http://mathworld.wolfram.com/news/2003-12-05/rsa/
also
http://mathworld.wolfram.com/PrimeNumber.html
http://mathworld.wolfram.com/PrimeFactorization.html

paper that has some analysis and (security?) cost equivalent key sizes (table 2)
http://www.rsasecurity.com/rsalabs/bulletins/bulletin13.html

from the above, 430bit RSA key is about equivalent to 112bit ECC key is about equivalent to 56bit DES key.

advances in factoring affect the relative strength of RSA.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

An entirely new proprietary hardware strategy

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: An entirely new proprietary hardware strategy
Newsgroups: comp.arch
Date: Tue, 09 Dec 2003 05:34:31 GMT

"del cecchi" writes:
Ah, but, especially in the bad old days there was IBM and there was IBM and there was IBM. Guys in Rochester were involved in optical communication that was connected in some way to the early fibre channel stuff. That is the group that went into the optical transceiver business and actually sold them, going back to the days of 266 Mbits. Unfortunately they were part of a midrange systems division (GSD, SPD, ABS etc) that had no way to sell components and get paid for them. So for a while they laundered through Yorktown. Research would sell the parts and give Rochester some of the money. Finally Microelectronics got them and a few years later they were sold to JDS Uniphase. They started out with the idea of using cheap lasers developed for CD players for optical communications. POK was still using LEDs at the time.

The ESCON/FICON story is driven from the beginning by a gruelling mixture including a large portion of Backwards Compatibility. Nobody worries about backwards compatibility like the Mainframe guys, especially after it was burned into their souls by the FS experience.

SSA came out of Hursley, and they didn't think much of farmers from the tundra either. So you know not of what you speak.

SLA was a rs/6000 thing .... somewhat warmed over ESCON which had been knocking around since the late '70s; however SLA was about 10 percent faster and used optical drivers much less expensive than ESCON. A couple of us had done some site visits to some vendors in Japan and I came back with the idea about leveraging consumer electronic components when ever possible. Among other things, I was dealing with something like $6k for T1 modems and observed that I got better technology and forward error correcting chips from a $300 CD player than I was getting in the $6k T1 modems. drift on that subject:
https://www.garlic.com/~lynn/subnetwork.html#hsdt
reference to specific trip:
https://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
in the above trip ... was first time that I walked a surface mount assembly line with real surface mount chips. It looked almost as if the boards were being spray painted black as the chips were being applied. in the US at the time, there was a little use of psuedo surface mount chips ... where the pins were cut flush with the bottom of the chip. in any case, you can blame me for the bit about using components out of consumer electronics.

Downside was that nobody else supported SLA. Rochester made the chips ... and we negotiated a deal for a general router vendor to add SLA to their product. The problem was that the chips had to pass thru something like three internal corporate agencies ... each agency doing the standard corporate markup along the way. The result was that the vendor ... who was doing us a favor ... was being asked to pay something like a 1000 percent markup for the chips.

The engineer that had done SLA ... then wanted to go off and do 800mbit SLA. We leaned hard on him for six months or so ... to instead go off and work on FCS ... which he eventually did ... becoming the FCS document editor.

The problem with FCS and certain contingents in POK ... was that FCS is fundamentally a full-duplex asynchronous protocol. POK is steeped in half-duplex, synchronous protocol ... and it appeared that same decided that they were going to provide support in asynchronous, full-duplex FCS for synchronous, half-duplex operation. There was enormous amounts of mailing list traffic trying to accomplish this.

SSA started out as 9333, with 80mbit/sec, asynchronous serial copper. We had an idea that we could map 9333 into 1/8th speed FCS ... optionally using either serial fiber or serial copper. However, that got lost in some corporate shuffling. random past comment about ssa
https://www.garlic.com/~lynn/95.html#13 SSA

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

History of Computer Network Industry

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of Computer Network Industry
Newsgroups: alt.folklore.computers
Date: Tue, 09 Dec 2003 13:00:37 GMT

wsgr12@yahoo.com (wsgr12) writes:
It is preliminary and any references and suggestion will be appreciated. Thank you in advance,

some collected postings on HSDT ... somewhat related networking
https://www.garlic.com/~lynn/subnetwork.html#hsdt
slightly related posting from yesterday
https://www.garlic.com/~lynn/2003o.html#54 An entirely new proprietary hardware strategy

misc. postings related to internet
https://www.garlic.com/~lynn/subnetwork.html#internet
also
https://www.garlic.com/~lynn/internet.htm
also at:
https://www.garlic.com/~lynn/rfcietff.htm
click on "misc. historical references" in the Introduction.

misc. postings related to earn/bitnet
https://www.garlic.com/~lynn/subnetwork.html#bitnet

misc. postings related to osi, hsp, xtp
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
the above even includes a recent jab at osi from yesterday
https://www.garlic.com/~lynn/2003o.html#51

series of postings discussing interop '88
https://www.garlic.com/~lynn/subnetwork.html#interop

there are a few sna refs regarding sna in the following collection of threads:
https://www.garlic.com/~lynn/subnetwork.html#3tier

there is some claim that the SNA definition (as opposed to low level stuff like SDLC) was a response to

1) failure/cancelling of FS ... misc refs;
https://www.garlic.com/~lynn/submain.html#futuresys
2) PCM control boxes, a project that I worked on as a undergraduate is blamed for
https://www.garlic.com/~lynn/submain.html#360pcm

i.e. SNA creating extremely high level of integration between host computer and outlying control boxes.

some past references to SNA "not being a system", "not being a network" and "not being an architecture":
https://www.garlic.com/~lynn/2000b.html#78 "Database" term ok for plain files?
https://www.garlic.com/~lynn/2002.html#28 Buffer overflow
https://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
https://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned

aka SNA was terminal controller infrastructure that provided high level of integration between host computer and outlying boxes (some medium sized configurations with tens of thousands of terminals). The closest thing that SNA sort of had to network layer came with APPN. However, the raleigh communication group (that owned SNA) non-concurred with the announcement of APPN (we don't need no stink'n networking). After corporate escalation ... the compromise was that APPN could be announced but the announcement letter was carefully rewritten so that there no statements about any sort of connection between APPN (and networking) and SNA. misc. past APPN posts:
https://www.garlic.com/~lynn/2000.html#51 APPC vs TCP/IP
https://www.garlic.com/~lynn/2000.html#53 APPC vs TCP/IP
https://www.garlic.com/~lynn/2000b.html#89 "Database" term ok for plain files?
https://www.garlic.com/~lynn/2000c.html#54 WHAT IS A MAINFRAME???
https://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
https://www.garlic.com/~lynn/2002.html#28 Buffer overflow
https://www.garlic.com/~lynn/2002b.html#54 Computer Naming Conventions
https://www.garlic.com/~lynn/2002c.html#43 Beginning of the end for SNA?
https://www.garlic.com/~lynn/2002g.html#48 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002h.html#12 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002h.html#48 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
https://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
https://www.garlic.com/~lynn/2003d.html#49 unix
https://www.garlic.com/~lynn/2003h.html#9 Why did TCP become popular ?
https://www.garlic.com/~lynn/2003o.html#48 incremental cms file backup

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

An entirely new proprietary hardware strategy

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: An entirely new proprietary hardware strategy
Newsgroups: comp.arch
Date: Tue, 09 Dec 2003 13:03:25 GMT

dkanter@onebox.com (David Kanter) writes:
What was the FS experience?

some number of past posting regarding FS
https://www.garlic.com/~lynn/submain.html#futuresys

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Pub/priv key security

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pub/priv key security
Newsgroups: comp.security.ssh
Date: Tue, 09 Dec 2003 13:16:00 GMT

"lyal" writes:
their respective software modules) must both trust the same public keys. Exchanging public keys is as costly and complex as sharing a secret - and often far more expensive.

but mitigates the human factor problem with having to remember scores of different shared-secrets. also two-factor authentication makes it somewhat more difficult for phishing & social engineering vulnerabilities.

the substition of public key registration for a pin/password registration needs to be no more expensive and use the same exact business process ... aka
https://www.garlic.com/~lynn/x959.html#aads
say in either a straight-forward radius scenario where public key is registered instead of pin/password:
https://www.garlic.com/~lynn/subpubkey.html#radius
or a kerberos pk-init scenario where public key is registered instead of pin/password:
https://www.garlic.com/~lynn/subpubkey.html#kerberos

or even the SSH public key scenario.

The big cost issue for public key comes when there is an attempt to create a major change in the business processes and trust model with a PKI build-out. There seems to have been some PKI implicit assumption that if the trust model and business processes change over could be done on massive enough scale ... that all the PKI costs would eventually be recouped thru scale of operations (i.e. loose $100 on every unit but make up for it in volume).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

RSA factoring challenge and PKI

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA factoring challenge and  PKI
Newsgroups: comp.security.misc
Date: Tue, 09 Dec 2003 13:25:14 GMT

Frank Jansen writes:
Greetings, I saw on slashdot.org recently that some group was supposed to have won another of RSA's factoring challenges. What does this mean for the robustness of the Public Key encryption system ? Do we need to use longer minimum key lengths ? One wonders how few years it will be before mathematicians who feel like a bit of fun will render PKI as easy to break as DES. Thanks in advance.

see recent thread on related subject in comp.security.ssh
https://www.garlic.com/~lynn/2003o.html#53 pub/priv key security
https://www.garlic.com/~lynn/2003o.html#50 pub/priv key security

note from above ... advances in factoring affect the relative strength of RSA (key sizes). there are other computational hard problems that are used for pub/priv key systems.

slightly related thread from sci.script
https://www.garlic.com/~lynn/2003o.html#46 What 'NSA'?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

1teraflops cell processor possible?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1teraflops cell processor possible?
Newsgroups: comp.arch
Date: Tue, 09 Dec 2003 16:22:43 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Oh, yeah? You underestimate the ingenuity of the software community.

or the non-ingenuity ... it seems as if the view is that you don't have to worry about performance issues because the machines are so fast ... so they default to non-linear (much greater than linear) solutions. then you just have to come up with explanations ... like it is really good that it takes so long ... because it is doing so much for you.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

1teraflops cell processor possible?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1teraflops cell processor possible?
Newsgroups: comp.arch
Date: Tue, 09 Dec 2003 16:43:30 GMT

"Rupert Pigott" writes:
I think it would be a great boot time for a 512 node machine with a few TB of spinning dust. Whether it's *fast enough* that is another question... :)

with a little ingenuity ... there is possibly two different issues, the time that it takes to respond to person waiting ... and the time it finalizes stuff with a few TB of spinning dust.

not because of filesystem issues ... but there was an extremely painful and highly visible issue long ago and far away when a major portion of the credit card authorization infrastructure was out for 18 minutes ... just about when lunch was ending on the east coast (in this case it was due to a phone company burp and large majority of all those little POS terminals weren't able to complete their call).

old archeological reference about motivation to improve filesystem recovery from several hours (somewhat) because there was demonstration of an implementation that didn't take several hours. minor multics lore reference:
https://www.garlic.com/~lynn/99.html#53 Internet and/or ARPANET?
https://www.garlic.com/~lynn/2001g.html#52 Compaq kills Alpha
https://www.garlic.com/~lynn/2002b.html#62 TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
https://www.garlic.com/~lynn/2003l.html#17 how long does (or did) it take to boot a timesharing system?

... this whole thread is somewhat deja vu for some

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

1teraflops cell processor possible?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1teraflops cell processor possible?
Newsgroups: comp.arch
Date: Wed, 10 Dec 2003 17:21:04 GMT

hack@watson.ibm.com (hack) writes:
This is what I meant by good block-paging in a previous post. The technique was introduced (afaik) in VM/HPO in the mid-1980s, and is what gives IBM's VM timesharing system subsecond response times for thousands of concurrent interactive users on one mainframe.

big pages for MVS & then VM ... early 1980s.

basically, real storage was 4k pages .... but a 3380 track-size (40k, 10 pages) was defined for tranfers. ten pages from virtual address space were aggregated into a big page for writing. as program reference pattern changed ... the membership in big page could also change (i.e. membership in the same big page tended to be ten virtual pages that were all referenced to same prior recent interval). a fault on any 4k page in any big page ... would fetch all members of the big page.

no home location on disk was preserved ... so any selection of pages for replacement involved forcing a write of the pages (even if they hadn't been changed during the most recent stay in memory)

basically 3380 (compared to 3330) increased transfer rate by about a factor of ten, but only increased arm access rate by possibly factor of three. big pages tended to trade-off the extra transfer rate resource against number of transfers aka big pages might tend to double the overall number of pages transferred, but significantly decreased the number of transfers. note that some of the really impressive (4k) paging rates for the big page systems is because of the increases in transfers caused by the big page methodology (including the increase in writes caused by not keeping a home location for non-changed pages).

misc. past discussions of big pages ... includes some references to observation that over a 15 year period that relative system disk thruput technology had declined by possibly a factor of ten aka processor & memory performance increased by factor of fifty, while disk access thruput only increased by possibly a factor of five:
https://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
https://www.garlic.com/~lynn/2002c.html#48 Swapper was Re: History of Login Names
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
https://www.garlic.com/~lynn/2002f.html#20 Blade architectures
https://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
https://www.garlic.com/~lynn/2002m.html#4 Handling variable page sizes?
https://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003d.html#21 PDP10 and RISC
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#9 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#16 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

1teraflops cell processor possible?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1teraflops cell processor possible?
Newsgroups: comp.arch
Date: Wed, 10 Dec 2003 21:55:11 GMT

glen herrmannsfeldt writes:
Does it use RPS to start the transfer at the next block on the disk, even if it is not at the beginning of the track?

I believe that it always used RPS to start at the same record position for transfers. There had been some discussion of using CKD search non-equal (aka low or high rather than equal) which has been used for database logging doing full track writes ... which would start transfer at the first record that came under the head. then on read, it would do a similar search ... and then be able to reconstruct the ordering by additional information (in logging, it could be included in the data itself, for paging, it might have to be a read key operation to figure out what record position it was at).

There may have been some later implementation that used trick for starting transfer at first encountered record.

as to MVS paging & swapping. Swapping has tended to be an operation that transferred all pages for a process at some scheduling event (either all pages in or all pages out). This is a distinct type of scheduling event independent of the page fault paradigm. The swapping logic can be independent of the disk transfer paradigm.

I believe that MVS paging was single 4k transfers. I believe that swapping could be both the logical scheduling operation ... as well as the disk area for big pages.

The disk area for big pages (if it is referred to as swapping) has been typically defined as ten times larger disk space area than would be actually occupied by allocated pages. Allocation tened to be a (slowly) moving cursor where disk space in front of the cursor is (mostly) empty. That guarantees minimum arm movement for writes. Faults tended to be for big pages in trailing area behind the cursor. When a big page was read, the corresponding disk space is always deallocated (which helps keep future activity in the region of the cursor position ... and some increase in the number of pages that have to be written back to disk).

Other, more traditional swapping and/or other large chunk transfers have tended to be strictly contiguous virtual memory locations. Big pages was slightly more adaptive than strictly contiguous virtual memory paradigm .... i.e. the membership in big page tended to be aggregation of 4k pages (not necessarily contiguous) that were being used together (as opposed to a strictly 40k contiguous section of virtual memory).

big pages tended to transfer larger number of pages than strictly 4k oriented operations (possibly double the number of pages, but the increase in pages transferred was more than offset by the reduction in the number of unique transfer operations). However, big pages would tend to have much less transfer than a paradigm purely based on contiguous virtual memory location.

2305 is fixed head disk ... so all records are logical contiguous w/o requiring arm motion ... where-as big pages attempted to optimize the arm access efficiency of 3380s. 3380s offered a lot larger space area at much lower price/byte than 2305.

A single 4k page fault paradigm mapped to 2305 could get multi-record transfers when servicing some number of independent processes (think cache misses in a mutli-threaded cpu architecture). However, any single process would still encounter the overhead and latency of moving one page at a time (it is at the system level that you see the efficiency of large transfers).

A single 4k page fault paradigm might have a process going thru eight distinct (4k) page faults to bring in 32k bytes of virtual memory in eight distinct transfer operation. Mapped to a big page paradigm might have the process bringing in ten 4k pages on the first fault. In this sense, big page paradigm is somewhat trading off both real storage resources as well as disk transfer rate resources to optimize arm access resources.

Theoritically, there is some possibility of mapping big page operation to 2305 ... but there again, you may be trading off space resources on 2305 against accesses. Since space is much more limited on 2305, and accesses is less of an issue, it might not be a good trade-off. On the other hand, big pages, allows 3380s to approach (and/or possibly exceed in some areas) thruput of 2305 and be able to take advantage of much better price/byte as well as much large space.

possibly more than you wanted to know. previous posting had some references to other detailed description of big pages:
https://www.garlic.com/~lynn/2003o.html#61

some past discussions regarding "dup/no-dup" management of page space ... i.e. when page is read from disk, is the location kept allocated and therefor can save on subsequent write if the page in memory is replaced but never is changed ... or is space occupied by a read page always de-allocated ... which then always required rewriting page when it is subsequently replaced (even if not changed). Most of these discussions were with respect to optimizing used of limited disk space (not having a duplicate of a page both on disk and in real storage). The 3380 big page scenario was part of strategy of trying to help improve disk arm locality:
https://www.garlic.com/~lynn/93.html#12 managing large amounts of vm
https://www.garlic.com/~lynn/93.html#13 managing large amounts of vm
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
https://www.garlic.com/~lynn/2001l.html#55 mainframe question
https://www.garlic.com/~lynn/2001n.html#78 Swap partition no bigger than 128MB?????
https://www.garlic.com/~lynn/2002b.html#10 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#16 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#19 hollow files in unix filesystems?
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#11 What are some impressive page rates?
https://www.garlic.com/~lynn/2002f.html#20 Blade architectures
https://www.garlic.com/~lynn/2002f.html#26 Blade architectures
https://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Dumbest optimization ever?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dumbest optimization ever?
Newsgroups: sci.crypt
Date: Thu, 11 Dec 2003 01:54:09 GMT

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
It's pretty normal for the secret key to be loaded into the smartcard at personalization (manufacturing) time, rather than actually generated on the card. I'd hope it hasn't actually been in such a dumb way as you describe, but nothing would surprise me any more :(.

i know a chip where keygen is done as part of power-on/test of the wafer (aka manufacturing QA; i asked about getting a manufacturing discount if the keygen process could provide better test coverage than their standard tests) ,,, before the chips are sliced & diced; partly because I was trying to eliminate downstream processing steps (having somewhat been exposed in my youth to manufacturing engineering ... i.e. art of engineering the manufacturing process):
https://www.garlic.com/~lynn/x959.html#aads

and for totally different slant on examination of process and assembly lines, thread from comp.arch (comment about using components from consumer electronics):
https://www.garlic.com/~lynn/2003o.html#54 An entirely new proprietary hardware strategy

the above has a side reference to
https://www.garlic.com/~lynn/95.html#13

which somewhat comes back to some crypto relation in the references about electronic commerce:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

note that for some chip cards (remember standard iso 7816 has chips that require external power and that operate at some 3 point mumble mhz ... slower than the 8088 in the original IBM/PC) and for some types of algorithms ... on-card keygen can run to minutes ... this is on a line that might be attempting to do half million cards in 24 hrs (aka cards per second on the line ... not seconds or minutes per card).

this gets even more iffy if you are talking iso 14443 proximity cards which are drawing the power from the air. The power in the air is somewhat limited ... so doing on-card keygen could possibly take an extrodinary amount of time.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

1teraflops cell processor possible?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1teraflops cell processor possible?
Newsgroups: comp.arch
Date: Thu, 11 Dec 2003 15:19:55 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
No - EARLIER! Fancy positioning was introduced for 3330 support, and was more-or-less eliminated in the massive MVT 21.6 "performance enhancement", which was the same one that broke chained scheduling and more-or-less abolished PCI. There were good reasons for many of the changes, but chained scheduling need not have been broken as badly as it was.

RPS wasn't used for picking first record rotating under the head, CKD data was.

lots of CKD disk channel programs would loop for SEARCH-ID equal ... to start transfer at a specific record. This paradigm was originally from early 360 when memory was really expensive and nearly non-existent in outboard boxes. As a result, SEARCH-ID equal would loop in the controller as each record past under the head ... but use the id parameter in the processor memory. That met that the controller was tied up for the duration of the loop (until the record past under the head) as well as the channel interface. This was an inefficiency in a system when there might be 16 drives per controller (having controller dedicated/busy to specific drive operation for extended period) and multiple controllers per channel (having the channel dedicated/busy to specific drive operation for extended period).

This was during a period when (excess) transfer (i/o) resources were traded off for limited memory resources. By the middle 70s the resources constraints had flipped .... memory was much more abundant than i/o resources ... and therefor CKD represented a resource trade-off that was exactly the opposite of the environment.

RPS was introduced to sort of mitigate the problem. The system could have a good idea of the sector position (on the track) for start of each specific record. A channel program was provided that would start the operation and then disconnect the controller and channel until the drive sensed that specific sector position and then attempt to reconnect & resume the channel program. If all things went well, the search-id equal would be executing exactly when the correct record start was passing under the head.

The logging optimization is just the opposite situation, it wanted to start transfer (read or write) as soon as the start of any record rotated under the head (and would write a full tracks worth of records). It would use a search-id parameter that would always be valid for all records. RPS was used to disconnect to avoid dedicating resources for an extended search-id loop until a specific record (sector position) rotated under the head. The logging optimization didn't care what record rotated under the head (and therefor didn't care what the sector position was) ... it just wanted to start transfer at the start of any record.

Now, the '60s (and sysetm/360) use of CKD led to some advantage taken of the fact that the search-id field was always fetch from main memory. One was writing a self-modifying channel program that possibly read the search-id field (for a subsequent channel instruction) from the disk. As a result, it precluded prefetching instructions and parameters (as a optimization method to avoid the tie-up of the resources).

For a little drift from the
https://www.garlic.com/~lynn/2003o.html#54 An entirely new proprietary hardeware strategy thread

The mainframe ESCON (fiber-optic) implementation had been knocking around POK since the 70s. However, it exactly emulated the half-duplex synchronous, bus&tag copper cable operation ... in part because of the non-prefetching rules that were needed to support the channel program modification on the fly capability.

As referenced in the above, SLA for the RS/6000 was sort of an ESCON derivative; and in addition to being about ten percent higher transfer rate and cheaper optical drivers ... it was also full-duplex, asynchronous (in that respect shared much more in common with FCS than ESCON).

As mentioned in previous posts about that era ... HiPPI standard was somewhat driven by LANL as a standardization of the Cray half-duplex, parallel copper channel and FCS stnadard was somewhat driven by LLNL as a fiber-optic standardization of the Ancor, non-blocking switch installation they had (adding a little more drift to another thread).

The other extreme optimization of the 360s paradigm that even carries over until today was the use of multi-track search for finding things on disk (as means of minimizing real-storage caching of index information). This was implemented in two os/360 faclities, the drive VTOC (i.e. directory of datasets/files on the disk) and library PDS (directory of members in a library dataset/file). Multi-track search, extended the search paradigm to scanning all records on all tracks on a cylinder for a matching entry. For 3330, this met that an unsuccusful search could take 19 revolutions (@ 60/second) during which time the (shared) channel and (shared) controller were tied up and dedicated to the operation (aka 1/3rd second per). In pathelogical situations this could have severe performance penalty. All of this to avoid tieing up (1960s) "scarce" real storage for caching of highly used directory information. Note that RPS didn't do anything for the multi-track search operations because they kept no pre-knowledge about where the record position (that they were searching for) might be.

some past drifts about HiPPI, LANL, FCS, LLNL, ancor, escon, sla, cdrom, etc.
https://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
https://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Dumbest optimization ever?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dumbest optimization ever?
Newsgroups: sci.crypt
Date: Thu, 11 Dec 2003 15:33:52 GMT

"Ernst Lippe" <ernstl-at-planet-dot-nl@ignore.this> writes:
This is the frequency (3.57 MHz) of the CLK signal for the communication, there is no requirement that the chip itself should also use this signal for its internal clock.

it can be different ... but it was originally specified because that is what the chips at the time did and many still do. chips exist that run at much higher frequency ... and could do various keygens in much shorter time ... but the chips used in production environments that tend to require external key generation and key injection ... require external key generation and key injection specifically because they aren't running faster. If you are talking about chips that are getting external keygen and key injection ... then you are probably talking about chips that aren't running faster ... as opposed to the possible world of chips that do run faster.

the comment was external power source was two fold

1) some hardware tokens have batteries and could do certain things when they aren't directly connected

2) production card lines have the cards moving down an assembly line stopping briefly at various stations for short periods of times (kind of of imagine a miniture car assembly line). any power that the cards gets tends to be during the short periods when they are momentarily at rest at a specific station. a card exists on this assembly line for much longer duration than the stay at any specific station ... but it wouldn't be drawing any power except during brief periods at specific station(s). even key injection may take more time than is normally alloted for a station stay. some of these automated lines have looked at multiple parallel stations for some of the chip operations ... so that the thruput of the overall line doesn't degrade to the elapsed time at a station that takes significantly longer than all of the other stations.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Dumbest optimization ever?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dumbest optimization ever?
Newsgroups: sci.crypt
Date: Thu, 11 Dec 2003 17:16:33 GMT

Grumble writes:
Hello Anne & Lynn Wheeler,

There is a spare SHIFT key on my keyboard. I was thinking you might be interested.

reply to similar comment
https://www.garlic.com/~lynn/2003o.html#40 WHen nerds were nerds

... i'm notorious for stuff like this.

there is stanford phd thesis (joint language and computer ai) from some 20 years ago ... for nine months in the early 80s, somebody sat in the back of my office and took notes on all my conversations, went to me with meetings and had log of all my (incoming and outgoing) email as well as all my instant messages. there were also a couple of follow-on books based on the material.

collection of postings (computer mediated communication) related to the project:
https://www.garlic.com/~lynn/subnetwork.html#cmc

there were comments like yours ... there were also observations that some newsgroups/mailing lists consisted over half my typing. I've actually slowed down quite a bit in the past 20 years.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

1teraflops cell processor possible?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1teraflops cell processor possible?
Newsgroups: comp.arch
Date: Thu, 11 Dec 2003 20:43:18 GMT

glen herrmannsfeldt writes:
The one I was thinking about, though I am not sure how it would work, would be to do something like READ SECTOR to find the current position, and then you would know which block to start writing at. It seems, though, that READ SECTOR only works after another READ operation.

cheat, start writing at the first record ... write track full of records and then do the read after writing the last record ... which should be the information of the first record.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

History of Computer Network Industry

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History of Computer Network Industry
Newsgroups: alt.folklore.computers
Date: Fri, 12 Dec 2003 04:49:46 GMT

Morten Reistad writes:
A lot of hard work were put into OSI/Decnet5//GOSIP, Frame Relay, the bysantine complexity of ATM, and other networks that went nowhere, because they were made for the computers, not for the customers.

Now we take TCP/IP for granted. But we as middle managers of customer sites had to push really hard for it.

And I suspect we have to put in a repeat performance for IPV6 soon. Cisco, are you listening? No more C boxes until you really support this!

as several times before ... I would claim that OSI was standardization & large organization process that reflected the point-to-point telco orientation of at least pre-70s. it also was much more similar to the pre-1/1/83 (pre-IP, pre-internetworking) arpanet organization. in previous discussions, i believe that OSI was finally getting standardization approval about the time that IP and LANS appeared (neither of which is provided for in OSI).

actually I know a lot of IP running over both frame-relay and ATM infrastructures (you probably find some significant percentage of corporate and possibly lower tier ISPs that use frame-relay to connect to upstream ISPs). standards for IP over frame-relay and ATM are going strong. In fact, if you don't have end-to-end copper between your house and the central office (say some fiber somewhere in that circuit) ... instead of getting DSL T1 for something like 39.99/month, the phone company would be more than happy to provide you with frame-relay T1 at $1400/month.

big part of early TCP/IP success was linked with LAN success ... and the ability to transparently gateway between local environment and the internet. as repeatedly mentioned OSI doesn't have provision for gateways and the internetworking layer. OSI has transport layer, level 4 that goes directly to network layer, level 3.

I've repeatedly asserted that a primary reason that the internal network was larger than the arpanet/internet for just about the whole period up until about mid-85 ... was that the internal network had effectively gateway function in every node. arpanet/internet didn't get that kind of gateway function into the switch-over to IP on 1/1/83.

previous post
https://www.garlic.com/~lynn/2003o.html#55 History of COmputer Network Industry

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

next, previous, index - home