2006 Newsgroup postings (03/07 - 03/22) Lynn Wheeler

2006 Newsgroup Postings (03/07 - 03/22)

About TLB in lower-level caches
About TLB in lower-level caches
When *not* to sign an e-mail message?
When *not* to sign an e-mail message?
When *not* to sign an e-mail message?
About TLB in lower-level caches
About TLB in lower-level caches
About TLB in lower-level caches
Beginner's Pubkey Crypto Question
terminals was: Caller ID "spoofing"
Caller ID "spoofing"
Caller ID "spoofing"
About TLB in lower-level caches
X.509 and ssh
X.509 and ssh
About TLB in lower-level caches
X.509 and ssh
X.509 and ssh
X.509 and ssh
About TLB in lower-level caches
About TLB in lower-level caches
Debit Cards HACKED now
Debit Cards HACKED now
Debit Cards HACKED now
Debit Cards HACKED now
About TLB in lower-level caches
Debit Cards HACKED now
X.509 and ssh
MCTS
X.509 and ssh
Debit Cards HACKED now
MCTS
transputers again was: The demise of Commodore
MCTS
CJ Date on Missing Information
The Pankian Metaphor
The Pankian Metaphor
The Pankian Metaphor
The Pankian Metaphor
The Pankian Metaphor
transputers again was: The demise of Commodore
CJ Date on Missing Information
SSL Certificate Signing
transputers again was: The demise of Commodore
Does the Data Protection Act of 2005 Make Sense
using 3390 mod-9s
using 3390 mod-9s
sci.crypt

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Tue, 07 Mar 2006 15:23:23 -0700

"Dale Morris" writes:
The question of context switch is really independent of CMP or resource sharing among logical processors. In the old days, TLBs were typically flushed on context switch, but today most designs include information as part of the TLB mapping entry that makes it unique within that OS environment. For example, the mapping might include some sort of process ID tag. An example would be Region IDs in Itanium processors. With this information, there's no need to remove TLB entries on context switch.

virtual memory on 370/165 (early 70s) had a 7-entry sto-stack. tlb entries had 3-bit sto-identifier ... which mapped to one of the 7-entries in the sto-stack (plus identifier for unused).

virtual address space had a segment table ... the address of which (aka segment-table-origin) was loaded into segment table register ... and which the hardware used to uniquely identify a virtual address space.

when segment register was changed, the hardware would check to see of the address (sto) was already in the TLB sto-stack. if not, one of the sto-stack entries was replaced and all the TLB-entries associated with the sto-stack entry were automatically purged.

The lower-end 370s tended to flush their complete TLB on every segment register switch.

the 165 implementation carried thru the 370/168 and into the 3033 (which started out being 168 wiring diagram mapped to faster chip technology). one of the people that went on to later be an itanium architect ... introduced "dual-address" space for the 3033 (instructions and support for directly accessing data in a different virtual address space). For some operations, this would double the number of active virtual address spaces and there were rumors at the time of significant sto-stack (and therefor tlb-entry) thrashing as a result.

801 was originally designed to be a much more closed, proprietary, dedicated environment. instead of segment table and segment table register, it had inverted tables and segment-identifiers.
https://www.garlic.com/~lynn/subtopic.html#801

romp in the early 80s, implemented a 12-bit segment identifier. romp had 32bit virtual addressing ... the top four bits mapping to one of sixteen segment registers. each segment register could have an arbitrary 12bit segment identifier value. To do virtual->real mapping, the hardware indexed a segment register (using the top four bits of the virtual address), took the 12-bit segment identifier from the segment register and then used to do a lookup in the TLB for the appropriate virtual page entry (i.e. using 12-bit segment identifier value, plus 16-bit virtual page number, within a segment). This was sometimes referred to as 40-bit virtual address (combination of the 12-bit segment identifier value plus 28bit virtual address). It was theoretically possible to have the same 12-bit segment identifier appear in each of the 16 segment registers ... which would result in 16 different possible (32bit) virtual addresses all mapping to the same TLB entry.

for rios/power, the segment identifier was doubled from 12bits to 24bits ... and you sometimes saw writeups describing the rios/power implementation as being 52-bit virtual addressing.

for some drift, the original virtual machine virtualization support in 360 (and later 370) ... created "shadow" segment and page table for a virtual machine (that translated from the virtual machine's "3rd" level virtual memory to the hardware's "1st" level real memory) that followed TLB (which happened to be called associative array on 360, somewhat more expensive and fully associative) hardware rules. Every time the virtual machine changed the virtual segment register, the shadow table entries would be completely reset (i.e. the low-end 370 hardware model). In the mid-70s an performance enhancement was implemented for virtual machine support that somewhat emulated the 168 sto-stack ... with multiple "shadow" tables possible for each virtual machine.

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Tue, 07 Mar 2006 18:28:39 -0700

Andy Glew writes:
Who was this? (HM? DA?)

I know most of the itanium architects.

http://www.hpl.hp.com/news/2001/apr-jun/worley.html
http://www.hpl.hp.com/news/2001/apr-jun/itanium.html

and

had to go to the way-back machine for this one
https://web.archive.org/web/20000415125122/http://www.hpl.hp.com/features/bill_worley_interview.html

slightly related recent post
https://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed

for some real topic drift .. a dc3 flight from h*** in the late 60s to visit him at cornell for a meeting about HASP
https://www.garlic.com/~lynn/2006b.html#27 IBM 610 workstation computer

other drift, after some number of people left for the labs in early 80s, i was getting frequent emails polling who else did i know that might be joining them and/or whether i might also join them.

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

When not to sign an e-mail message?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When *not* to sign an e-mail message?
Newsgroups: sci.crypt,comp.security.pgp.discuss
Date: Wed, 08 Mar 2006 10:06:29 -0700

Andrew Swallow writes:
In Britain the credit card companies no longer accept handwritten signatures. You have to type a 4 digit pin.

credit cards have been something you have authentication and the hardwritten signature has been demonstration of intent.

pin-debit has had two-factor authentication, the card as something you have and the pin as something you know ... from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are

with the standard pin-debit POS operation, you swipe your card (something you have authentication) and enter your pin (something you know authentication, pin/password shared-secrets can be considered countermeasure to lost/stolen cards).

the POS then displays the value and asks you to press a yes/agree button as a demonstration of intent (the equivalent of the "human signature").

slight topic drift on the chip&pin subject:
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner

slightly more drift mentioning chip&pin:
https://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"

in the magstripe generation of cards ... reading the magstripe was proof of something you have authentication. however, the magstripe was "static data" and was subject to skimming/evesdropping vulnerabilities and became fairly straight-forward to generate counterfeit cards from the "static data".

the chip&pin is substituting public key and digital signature operation in lieu of reading magstripe ... as proof of something you have authentication (with the pin still something you know authentication as countermeasure to lost/stolen card). however, the authentication processes (including digital signature) are orthogonal to establishing "intent" established by requiring somebody to press a button (the "intent" equivalence that is also addressed by human signature).

lengthy discussion, including use of public key and digital signatures for establishing proof of something you have authentication hardware token:
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"

past posts in this thread ... including discussion of POS pressing button as evidence of intent (i.e. human signature) separate from authentication processes:
https://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006d.html#33 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006d.html#34 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006d.html#36 When *not* to sign an e-mail message?

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

When not to sign an e-mail message?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When *not* to sign an e-mail message?
Newsgroups: sci.crypt,comp.security.pgp.discuss
Date: Wed, 08 Mar 2006 13:17:22 -0700

Anne & Lynn Wheeler writes:
slight topic drift on the chip&pin subject:
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner

ref:
https://www.garlic.com/~lynn/2006e.html#2 When *not* to sign an e-mail message?

in the above yes card scenarios, i've seen reference to a number of different implementations.

the yes card scenarios supposedly are "static data" exploits ... i.e. the token authenticates itself by presenting a digital certificate (i.e. static data) to the terminal. the terminal verifies the digital signature on the certificate and accepts the card as authenticated. this turned out to be vulnerable to the same skimming technology that has been used for magstripes. there is some more detailed information at the URL cited by the posting mentioned above.

the countermeasure becomes "dynamic data" ... the terminal basically sends a form of challenge, which is digitally signed and both the digital signature and the digital certificate is returned. the terminal now verifies the digital signature on the digital certificate and uses the public key in the digital certificate to verify the digital signature on the challenge.

i've heard rumors of mitm-attacks tho ... since the digital signature on the challenge and the execution of the transaction are separate, distinct operations. the countermeasure for mitm-attack is to directly digitally sign the transaction ... as opposed to having separate operation for token digital signature authentication and the execution of the transaction.

this then starts to look much more like the x9.59 model
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

the original work on x9.59 for directly digitally signing the transaction was going on in the same time-frame as the original work on the definition for th chip&pin stuff ... where authentication was going to be done separately from the transaction.

in any case, as in past posts on the subject, the verification of the digital signature establishes the implication of something you have authentication (aka the entity has access to and use of the corresponding private key). then some certified process that binds a private key to some chip ... then sort of establishes the equivalence between something you have private key and something you have chip.

however, digital signature isn't being used to imply intent as in human signatures ... or in the human button pressing operation in response to some message (as in POS terminal).

any change from doing a digital signature on a purely challenge (possibly random data) authentication operation ... to applying a digital signature to the transaction itself ... wouldn't be to create any more of a (false) impression of human signature ... but to close possible mitm-attacks that might be possible between doing an independent authentication operation and then doing a separate transaction (aka one of the original x9.59 countermeasure scenarios).

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

When not to sign an e-mail message?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When *not* to sign an e-mail message?
Newsgroups: sci.crypt,comp.security.pgp.discuss
Date: Wed, 08 Mar 2006 13:33:46 -0700

"nemo_outis" writes:
I would argue that a handwritten signature is not quite equivalent to any of these. However, it could be regarded as a derivative of the something you are category with additional refinements. [or we could add a new category: "something you do"]

ref:
https://www.garlic.com/~lynn/2006e.html#2 When *not* to sign an e-mail message?

however, if you look at the contrast between signature-debit and pin-debit .... signature-debit is effectively treated as a credit card transaction from the standpoint of fraud ... while pin-debit is considered to be two-factor authentication ... possibly lower fraud (modulo the issue that it is possible for some skimming technology to simultaneously capture both the magstripe and the pin ... defeating some basic assumptions with multi-factor authentication that the different factors are subject to independent threats/vulnerabilities).

POS terminals for pin-debit, w/o the signature and straight two-factor authentication ... then goes to the interaction with a message being displayed asking for the person to press a button to establish "intent" (which is otherwise provided by a human signature).

within 3-factor authentication model ... human signature would possible be something you are, since it is it would be taken as distinctive representation of human physical characteristics.

however, there aren't a lot of current infrastructure deployments that take human signatures as part of serious multi-factor authentication infrastructure (not that you can't do it, it just doesn't seem to be taken very seriously).

there was some work on elevating writing a signature to status of acceptable something you are authentication .... it wasn't so much the resulting signature ... but that the physical motions in executing the signature have been demonstrated to be distinctive.

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Wed, 08 Mar 2006 13:56:17 -0700

Anne & Lynn Wheeler writes:
virtual memory on 370/165 (early 70s) had a 7-entry sto-stack. tlb entries had 3-bit sto-identifier ... which mapped to one of the 7-entries in the sto-stack (plus identifier for unused).

ref:
https://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches

for some additional drift ... there was actually quite a bit of work put into the original 370 virtual memory architecture that allowed for TLBs hardware implementations to be

1) simple, clear all entries, whenever switching address space

2) "sto-associative" ... this is from the above description, basically TLB entries were associated with a "STO", segment table origin ... i.e. the real address of the start of segment table (which was unique definition for a virtual address space).

3) "pto-associative" ... this is page-table origin associative.

370 had a virtual address space segment table with segment entries that were pointers to the start of individual page tables (containing page table entries mapping specific virtual page to real page address). 370 architecture allowed for shared segments (i.e. the same page table pointed to by different segment tables ... same page-table appearing in different virtual address spaces).

I don't know of any general TLB hardware implementations that actually did general pto-associative (i.e. multiple different address spaces would have shared segment addresses mapping to the same TLB entries).

In effect, the 801 implementation (described in the original post) is a flavor of pto-associative ... but for an inverted page table architecture. since you don't have an explicit table, there is no explicit table start address to uniquely identify each segment ... therefor the definition of arbitrary 12-bit segment identifier (in romp) ... and later expanded to 24-bit segment identifier (for rios/power).

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Wed, 08 Mar 2006 19:38:47 -0700

"Eric P." writes:
What do you mean by "shadow table entries would be completely reset"? Do you mean the TLB was flushed, or all the mapped physical pages had to be released (like a working set flush), or something else?

shadow tables were page tables that emulated TLB semantics; aka ... shadow tables provided function equivalent to TLB but for the operation of the virtual machine. processes that would result in flushing entry in TLB needed to provide equivalent operation with regard to the shadow tables .... in this case invalidating page table entries ... which are the constructs used to emulate hardware TLB for the virtual machine. Now such page table entries are being invalidated real page tables (even if they are "shadow" table constructs for the virtual machine), will, in turn require that you turn around and flush entries in the real TLB.

the original 370 virtual memory architecture included hardware instructions, IPTE (invalidate page table entry), ISTE (invalidate segment table entry), and PTLB (purge table look-aside buffer). IPTE turns the invalid bit in the PTE entry and would flush any associated TLB entry. ISTE turns the invalid bit in the STE entry and would flush any associated TLB entries. PTLB flushes all TLB entries. IPTE and ISTE instructions were dropped from original shipped products.

various web pages (from search engine) with more detailed discussion about virtual machine implementation and shadow tables
http://www.cap-lore.com/Software/virtualVirtual.html
http://www.cs.duke.edu/~narten/110/nachos/main/node34.html
http://www.virtualization.info/archive/2005_01_01_archive.html
http://lists.xensource.com/archives/html/xen-devel/2004-08/msg00261.html
https://www.leeandmelindavarian.com/Melinda/25paper.pdf
http://swpat.ffii.org/pikta/txt/ep/0171/475/
http://www.cs.princeton.edu/courses/archive/spring06/cos592/bib/future_trends-rosenblum.pdf
http://www.stanford.edu/class/cs240/readings/waldspurger.pdf
http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWSE05008_WinHEC05.ppt
http://www.stanford.edu/~talg/papers/COMPUTER05/virtual-future-computer05.pdf
http://www.usenix.org/events/osdi02/tech/waldspurger/waldspurger_html/node3.html
http://www.vmware.com/pdf/esx2_performance_implications.pdf
http://www.cs.ubc.ca/~norm/cs538a/ibmrd2706L.pdf
http://www.cs.wisc.edu/~stjones/proj/vm_reading/ibmrd2706L.pdf
http://www.patentstorm.us/patents/4814975.html
http://www.uic.edu/depts/accc/inform/ibmglossary.html

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Thu, 09 Mar 2006 11:49:35 -0700

Anne & Lynn Wheeler writes:
various web pages (from search engine) with more detailed discussion about virtual machine implementation and shadow tables
http://www.cap-lore.com/Software/virtualVirtual.html
https://www.leeandmelindavarian.com/Melinda/25paper.pdf

a little more shadow table lore. cp/67 originally only had virtual machine support for vanilla 360 machines ... i.e. no virtual memory support (no support for the virtual memory hardware shipped in 360/67s). cp/67 ran on 360/67 and made use of the virtual memory hardware as part of providing (360) virtual machines ... but didn't provide 360/67 virtual machine. as a result, cp/67 couldn't run "under" cp/67.

one of the people at the grenoble science center got an assignment at the cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech

and while on the assignment, added 360/67 virtual machine support to cp/67 (including the original shadow table support).

this was not too long before the joint cambridge/endicott ("cp67h" and "cp67i") project started to provide 370 virtual machine support under 360/67. 370s were originally announced w/o virtual memory support, but the architecture had been defined. the 370 virtual memory architecture had some number of differences from that found in 360/67 including some differences in the definition for the segment and page tables (used by the hardware).

for the "cp67h" level changes to cp/67 ... there was mode-switch defining whether 360/67 virtual memory was being emulated or 370 virtual memory was being emulated. the "shadow tables" were the same format ... since they were being referenced by the real 360/67 hardware ... however, the segment and page tables that were in the memory of the virtual machine ... which the cp/67 simulation worked with ... were slightly different (but both formats need to be translated to native hardware format for shadow tables).

minor trivia, some years later the person that had done the original virtualizing 360/67 and shadow table support found himself setting up EARN ... reference:
https://www.garlic.com/~lynn/2001h.html#65

misc. past posts mention "cp67h" and "cp67i" work (it was up and running standard production ... a year before the first engineering 370 machine with virtual memory support was operational ... and well before virtual memory for 370 was announced, other trivia, the multi-level source update process was also developed as part of the "cp67h" and "cp67i" effort)
https://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
https://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block boundaries
https://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
https://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?

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

Beginner's Pubkey Crypto Question

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Beginner's Pubkey Crypto Question
Newsgroups: sci.crypt
Date: Thu, 09 Mar 2006 16:45:31 -0700

Kristian Gjøsteen <kristiag+news@item.ntnu.no> writes:
Suppose we have a whistle-blower named Alice that sends you some important documents encrypted with your public key and signed with an anonymous key. She also includes the self-signed anonymous public key. (She may want to send further communications to you, therefore the signing.)

The evil corporation that was about to get exposed happily intercepts the e-mail. They would really like to know the contents of the e-mail in order to find the whistle-blower, but since it is encrypted with your public key, they can't break it unless they can fool you into decrypting it.

They remove the self-signature from the public key, inserts the identity of Clara (not Eve, that would make you suspicious) in the public key and registers it on every key server they can find. Then they forward the original e-mail on to you, without the self-signed anonymous public key.

there has been some number of glitches with some of the public key digital signature scenarios over the years ... some of them from concentrating way too hard on the original sender being able to proove that they sent the message ... and ignoring some of the other threats.

if the whistle-blower signed the unencrypted message, sent the encrypted message, the digital signature and the public key .. mitm-attack replacing the digital signature and public key doesn't work because the mitm doesn't have access to the original unsigned message ... this basically impacts the integrity of the overall message. removing the signature and public key can be done ... but if the contents is kept confidential, then only the sender and the recipient have knowledge of the contents ... which could be used to substantiate future messages from the same entity.

another scenario is including the digital signature as part of plain-test message before encryption ... so that it is encrypted along with the rest of the message. in any case, responses can be posted to public place which have been encrypted with the original public key (only after there is high level of confidence that the public key being used, has a trust chain that uniquely binds it to the original message).

a similar, but different sequence cropped up over the definition and use of the non-repudiation bit in digital certificates. basically you have message (unencrypted or encrypted) with digital signature and digital certificate attached. recent thread also mentioning non-repudiation:
https://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006d.html#36 When *not* to sign an e-mail message?

now lets say you have two different digital certificates for the same public key ... one with the non-repudiation bit set and one w/o the non-repudiation bit set. you intend to only authenticate some data; package up the message, the digital signature, and the digital certificate with the non-repudiation bit OFF and send it. however, there is no proof which digital certificate you actually attached to the package. the recipient wants to hold you to higher liability ... so they scour the internet for a copy of you digital certificate with the non-repudiation bit set ON ... and in some dispute, present the original message, the original digital signature, and the substituted digital certificate (the one with the non-repudiation bit set ON). basic digital certificate standards didn't appear to anticipate this sort of threat (in part because there was enormous confusion about the non-repudiation bit ... and whether it carried with it additional obligations).

this scenario sort of cropped up in the mid-90s with one of the efforts to do a digitally signed payment transaction that included attached digital certificate (as opposed to certificate-less operation). One flyer to try and induce merchants to deploy implementations ... was a suggestion that if consumers were to attach digital certificates that included the non-repudiation bit having been set ON, it would reverse the burden of proof in any dispute (currently in any such dispute, the burden of proof is on the merchant ... not the consumer).

A possible vulnerability for consumers that didn't want to attach digital certificates with the non-repudiation bit set (and have the burden of proof shifted to themselves in a dispute) was that the protocol provided for no proof of the contents of attached digital certificate (merchants could reduce their costs by attempting to conjure up any valid digital certificate for the consumer's public key, that included the non-repudiation bit). This approach was eventually discredited along with most of the other hypothetical suggestions for the non-repudiation bit in digital certificate (aka it wasn't in the consumer's interest to claim non-repudiation, however it was proposed that it would become in the merchant's interest to show that they had a non-repudiation certificate for each consumer).

Of course that wasn't the only problem facing the certificate-based digitally signed payment transactions efforts. They had realized by that time that the x.509 identity certificate standards stuff represented significant privacy and liability issues ... so they had already retrenched to relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

basically the financial institution takes in all the information and records it in an account record (including any issued digital certificate and associated public key). they then issue a relying-party-only certicate which fundamentally contains only the account number and the public key. whenever somebody does a payment transaction ... they would include in the payment transaction all the standard, necessary information in the transaction, digitally sign it ... and send off the transaction, the digital signature and the relying-party-only ceritifcate attached.

the financial institution retrieves the account number from the transaction, reads the account record, uses the public key from the account record to verify the digital signature and discards the attached digital certificate. It wasn't that the attached digital certificate was just redundant and superfluous ... but it also resulted in enormous payload bloat. The typical 8583 payment transaction is on the order of 60-80 bytes. The digital certificate attachment overhead (even for relying-party-only certificates) was running 4k to 12k bytes (an enormous payload bloat of two orders of magnitude, increasing transaction payload by a factor of 100 times for something that was useless, redundant and superfluous).

the enormous digital certificate payload bloat was perceived as a significant issue and the X9F financial standards group started a project to define a compressed digital certificate standard for financial transactions ... hoping to get digital certificate payload down into the 300 byte range. One of the things that seemed to give them the most benefit was to eliminate digital certificate fields that were common across all the relying-party-only consumer certificates issued by the same financial institution. I suggested to them that they could even go further, not only could they eliminate all common fields ... but using some basic principles of information theory, they could eliminate all fields in the digital certificate that were already in possession of the financial institution.

I was quickly able to show that it was possible to come up with a digital certificate standard for zero-byte digital certificates. This seemed to have significant benefit ... being able to attach zero-byte digital certificates to every transaction, which turned out to be useless, redundant and superfluous anyway (since the financial institution was going to simply discard them immediately, already having a copy of all the original information stored in the account record). It seemed to be much more acceptable to demonstrate that useless, redundant and superfluous zero-byte digital certificates were being attached to every payment transaction (as opposed to saying that there was no point to attach useless, redundant and superfluous digital certificates at all).

misc. past posts about zero-byte digital certificate effort
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
https://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#8 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
https://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
https://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
https://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing

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

terminals was: Caller ID "spoofing"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: terminals was: Caller ID "spoofing"
Newsgroups: alt.folklore.computers
Date: Fri, 10 Mar 2006 11:05:01 -0700

eugene@cse.ucsc.edu (Eugene Miya) writes:
My first were a combination of custom double keyboards hooked to Tektronix refresh storage tubes (for high resolution graphics of that era). More buttons don't make the future. I think I never used a 3270 thru 3279 until much later. I remember all kinds of bad terminals LSI ADM-3s, etc. If Dennis is lurking, one favorite were HP 2640s with lots of memory (apparently export controlled, the only way one would be a munition was if you dropped it from a plane), but smart terminals never caught on despite the Blit and BBN. Perkin-Elmers were PK as well for Ined. Vt100s and 3270 were least common denominators.

But in the end I really grew to appreciate termcap and termio, and that's one part Unix history I want to make certain the historians don't forget (over 300 entries the last time I bothered to look).

there was a Tektronix display add-on to 3277 terminal (called 3277ga, i.e. 3277 graphics adapter). Wire went into the side of 3277. low-level operating system programming looked like 3277 terminal ... however, application programming was able to generate terminal data streams to drive the Tektronix display. somewhat could take advantage of the 640kbyte/sec of the 3272/3277 channel/controller/coax operation.

the monster displays were the GE/CALMAs ... found in some of vlsi chip design operations. Used embedded HYPERchannel A400 adapters to provide local area network for cluster of CALMAs. a couple past posts mentioning CALMAs
https://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
https://www.garlic.com/~lynn/2005r.html#24 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005u.html#6 Fast action games on System/360+?

a few past posts mentioning 3277ga ... saw some use in some of the internal vlsi chip shops as less expensive CALMAs
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
https://www.garlic.com/~lynn/2002p.html#29 Vector display systems
https://www.garlic.com/~lynn/2004l.html#27 Shipwrecks
https://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
https://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?

for some drift, lots of posts mentioning various HYPERchannel activities
https://www.garlic.com/~lynn/subnetwork.html#hsdt

for other drift ... collection of posts about taking interdata/3, adding mainframe channel card and programming it to emulate mainframe terminal controller. went thru several generations ... and later Perkin-Elmer bought Interdata and they continued to be marketed under the Perkin-Elmer brand
https://www.garlic.com/~lynn/submain.html#360pcm

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

Caller ID "spoofing"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Caller ID "spoofing"
Newsgroups: alt.folklore.computers
Date: Sat, 11 Mar 2006 12:03:20 -0700

Anne & Lynn Wheeler writes:
So the approach by x9.59 was to eliminate the shared-secret status of (x9.59) account numbers (i.e. akin to passwords, just knowing the value enables impersonation and/or fraud) ... using strong authentication as a substitute for strong privacy/confidentiality.

ref:
https://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"

note that pin is part of shared-secret infrastructure.

from 3-factor authentication,
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have • something you know • something you are

where multi-factor is considered more secure if the different factors are subject to different threats/vulnerabilities. pins (something you know) were somewhat countermeasures to lost/stolen card (something you have). however, reading magstripe on the card was representation/proof of unique something you have. by the early 90s, skimming technology was starting to appear that represented a common threat to both pins (something you know) and cards (reading magstripe to establish proof of something you have).

discussion of some vulnerability characteristics
https://www.garlic.com/~lynn/aadsm22.htm#20
https://www.garlic.com/~lynn/2006e.html#3

some URLs from earlier in the week about current attacks on PINs
https://www.garlic.com/~lynn/aadsm22.htm#21

some URLs from today on PIN attacks: PIN Scandal 'Worst Hack Ever'
http://yro.slashdot.org/yro/06/03/11/0543249.shtml
Worldwide Wave of Debit Card Fraud
http://www.pcworld.com/news/article/0,aid,125053,00.asp
Debit-card fraud continues
http://www.securityfocus.com/brief/160
New Theft Scam Targets Debit Cards
http://www.wsfa.com/Global/story.asp?S=4615928&nav=0RdDcDuj
Worldwide Wave of Debit Card Fraud
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=19588

basically all 3-factor types can use static data authentication mechanisms ... i.e. information that can be recorded and later reproduced for fraudulent purposes. this falls under the general category of replay attacks. for multi-factor authentication to be effective, different factors need to be subject to different threat/vulnerabilities. in the case of the general category of replay attacks ... at least one of the factors needs to be resistant to recording and later replay/reproduction.

this analysis can also be approached from the standpoint of availability and "no-single-point-of-failure" ... although in this case it is more like "no-single-point-of-attack". misc. collected posts on high-availability
https://www.garlic.com/~lynn/subtopic.html#hacmp

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

Caller ID "spoofing"

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Caller ID "spoofing"
Newsgroups: alt.folklore.computers
Date: Sat, 11 Mar 2006 13:46:48 -0700

Anne & Lynn Wheeler writes:
this analysis can also be approached from the standpoint of availability and "no-single-point-of-failure" ... although in this case it is more like "no-single-point-of-attack". misc. collected posts on high-availability
https://www.garlic.com/~lynn/subtopic.html#hacmp

ref:
https://www.garlic.com/~lynn/2006e.html#10 Caller ID "spoofing"

sort of trivial example was when we started work on ha/cmp project, there was a detailed vulnerability analysis (including tc/ip). nearly ten years later, the largest online service provider had been fighting a tcp/ip vulnerability for a couple months and nobody (that they had brought in so far) had been able to identify it. one day, one of the people caught me after work and offered to buy me a hamburger while he explained the problem. it turned out to be a relatively trivial (but somewhat obscure) vulnerability that we had identified nearly ten years earlier. a couple scribbled instructions that they applied later that night was a quick&dirty fix for the problem.

a couple minor past refrences to the incident:
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Sun, 12 Mar 2006 15:03:24 -0700

"Eric P." writes:
So I suppose my question should have been, why the 3 levels and full shadow rebuilds instead of 2 levels and guest access traps? Performance, and/or compatibility with different 360/370 architectures are possibilities.

the virtual machine thinks it is running on the real hardware.

table 1:

the virtual machine operating system is running virtual address space ... which requires a mapping between what the operating system (kernel) running in the virtual machine thinks are the virtual address space mappings to what it thinks are its real addresses.

table 2:

the hypervisor running on the real hardware has a set of virtual address tables for each virtual machine ... which gives the mapping between what the virtual machine operating thinks are "real addresses" (but in reallity are virtual addresses) and the "real", "real" addresses of the real hardware.

when the hypervisor (providing virtual machines capability) running on the real hardware ... dispatches a virtual machine ... the virtual machine may be expecting to run it real address mode of the virtual machine (in which case, the hypervisor loads the "table 2" into the appropriate hardware registers.

table 3 (shadow table):

when the hypervisor (providing virtual machines capability) running on the real hardware ... dispatches a virtual machine ... the virtual machine may be expecting to run it virtual address mode of the virtual machine. The virtual machine has specified "table 1" for running. However, since "table 1" only provide address mapping from the virtual address space mapping (maintained by the kernel running in the virtual machine) to the virtual machine's "real addresses" ... and since the virtual machine's "real addresses" aren't in fact the real machine's real addresses ... using "table 1" would produce invalid results.

as a result, the hypervisor running on the real hardware builds a shadow of "table 1" ... which goes thru a double mapping. It takes an entry from "table 1", and translates the virtual machine "real address", using "table 2" to get the real, real address on the real machine ... and places that value in the corresponding entry in the "shadow table" (shadow of table 1).

the rules for maintaining the hardware TLB are followed for maintaining the shadow of "table 1". This is because, in part because the TLB architecture is defined as also being a shadow/copy of "table 1" (for the virtual machine) ... and can result in incorrect and/or unpredictable results if the values in the TLB aren't kept in sync with the values in entries from "table 1". The virtual machine hypervisor takes advantage of the shadow/copy characteristics of the real hardware TLB ... for maintaining the entries in the "shadow" of "table 1". Note however, the "shadow table" (with translated shadow/copy entries from "table 1") has to maintained consistent with both the "table 1" entries as well as "table 2" entries.

the original shadow table implementation had only a single physical set of storage for a shadow table for each virtual machine. This corresponded with hardware tlb implementations that only remembered entries for the current address space ... and didn't have capability for remembering entries for multiple different address spaces. in this implementation, every time there is a virtual address space change ... all the existing hardware tlb entries have to be flushed. Simiarily, in the single shadaw table (per virtual machine) implementation (where only entries for a single virtual address space is remembered), every time the virtual machine changes virtual address space, all entries in the shadow table are flushed (faithfully emulating what is done by hardware TLBs).

later shadow table implementations provided for having additional storage allocated per virtual machine for remembering entries from multiple different virtual address spaces (for a specific virtual machine). this corresponds (and emulates) hardware tlbs that remember entries from multiple differen virtual address spaces (multiple "table 1" per virtual machine). In this scenario ... there are a fixed, maximum amount of fixed storage for shadow tables ... analogous to the 370/165 TLB description of being STO-associative and having a seven-sto stack (can remember entries for up to seven different virtual address spaces simultaneously). However, analogous to the 370/165 TLB description ... when a new address space is loaded that doesn't correspond to one of the (saved) shadow tables ... and all the existing physical shadow tables are already associated with a specific "table 1" ... then one of the existing shadow tables has to have all its entries flushed and that specific shadow table re-allocated to the new virtual address space for the virtual machine (new "table 1" for the virtual machine). Akin this emulates the rules for maintaining hardware TLB entries.

Now, newer hardware with additional capability could provide virtual machine hardware support for hardware TLB miss ... where the TLB miss processing and TLB entry load ... recognizes that it is running in virtual machine mode ... and that the hardware has to go thru a two level lookup before obtaining the real, real address; aka this takes the virtual real address entry from "table 1", does a 2nd lookup using "table 2" ... in order to obtain, the real, real address (as opposed to the virtual, real address) for loading into the real hardware TLB entry.

The shadow table description is where the TLB hardware doesn't have direct hardware support for doing the two-level table lookup (doing the lookup in the virtual machine's Table1 ... and then doing a 2nd lookup in the hypervisor's Table2 in order to obtain the real, real hardware address) ... and the two-level lookup is done in software on behalf of the hardware TLB ... and then when running that specific virtual address space ... the hardware really runs using the "shadow table" (when the hardware TLB implementation doesn't directly support virtual machine operation mode and performing a two level lookup automagically in hardware).

There is also a gotcha for any shadow-table bypass and virtual machine hardware TLB two-level entry-miss & entry-load implementation and that is recursive implementation. Part of early virtual machine work was running a test virtual machine hypervisor under a production virtual mahcine hypervisor ... where a guest virtual memory operating system was being tested in the test virtual machine hypervisor. Now you have three levels of tables (and, in theory, recursive might work to any level). In the three level scenario:

virtual address space "LEVEL-1" running in virtual machine defined by virtual address space "TABLE-1" of a operating system running in a virtual machine

virtual address space "LEVEL-2" which the virtual machine operating system thinks are real address, but is really defined by "TABLE-2" of a virtual machine hypervisor "A" that thinks it is running on real hardware

virtual address space "LEVEL-3" which the virtual machine hypervisor "A" thinks are real address, but is really defined by "TABLE-3" of a virtual machine hypervisor "B" that may or may not be running on real hardware.

Now the real TLB hardware (that doesn't have any builtin two-level lookup virtual machine capability) is expecting real virtual address space tables to provide mapping from virtual address space to real, real addresses (virtual page number to real, real page number).

The problem with "TABLE-1" defining virtual address space "LEVEL-1" is not providing mapping between virtual addresses and the real, real hardware page numbers ... "TABLE-1" entries provide mapping between virtual addess space "LEVEL-1" and virtual address space "LEVEL-2" ... the mapping defined by "TABLE-2" (not the real, real hardware addresses). Furthermore, the problem with "TABLE-2" is that doesn't actually provide the mapping between virtual address space "LEVEL-2" and the real, real hardware page numbers ... but it provides the mapping between virtual address space "LEVEL-2" and the virtual address space "LEVEL-3" defined by "TABLE-3". If this is truely recursive ... it isn't until you get to "LEVEL-n" that you really have a "TABLE-n" that is actually providing any mapping between a virtual address space and the real, real page numbers.

So to generalize this, the virtual machine hypervisor at LEVEL-n, builds shadow tables (that emulate the semantics of real hardware TLBs) for virtual machine virtual address tables at LEVEL-(n-1). The virtual machine hypervisor shadow tables emulate the virtual address space tables at LEVEL-(n-1) but using what it believes to be real addresses at LEVEL-n. If the virtual machine hypervisor is really running in a virtual machine recursive environment ... there could be several generations of shadow tables ... each providing for converting the virtual, real page numbers at level (n-1) into page numbers of level (n). It isn't until you get to the very bottom, real hardware level do you finally encounter a shadow table that might get loaded into the real, real hardware registers ... because it actually is the only table that contains the real, real page numbers.

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

X.509 and ssh

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Sun, 12 Mar 2006 20:25:19 -0700

"Richard E. Silverman" writes:
I was actually wondering why you constantly post rambling, multi-page crypto-stream-of-consciousness, punctuated with pathetic ellipses where you couldn't be bothered to actually complete a sentence.

But, this response is utterly priceless in its cluelessness, so thanks anyway.

ref:
https://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh

the referenced phd thesis analyzes my computer communications in several hundred pages ... lot more detail than i could ever supply ... if you are truely interested.

misc. related postings on computer mediated communication
https://www.garlic.com/~lynn/subnetwork.html#cmc

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

X.509 and ssh

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Sun, 12 Mar 2006 20:50:46 -0700

"Nico Kadel-Garcia" writes:
Which doesn't explain why you ramble or fail to use periods correctly, and the capital keys seem to be missing from your keyboard. It helps destroy any content in what you're writing.

May I suggest that you that you examine and take to heart a copy of Strunk's"Elements of Style"? It would help your work be more legible.

the thesis goes into all of those style issues in some detail ... in addition to providing linquistic analysis of the styles ... if you are really interested ... read the thesis.

i spent a couple years with senior publication editor in san jose doing that sort of stuff for technical publications; turns out to be a different mode/style of operation ... some of it was also during the period that the material was being gathered for the phd research ... so some of those issues are also examined in some detail in the thesis.

ref:
https://www.garlic.com/~lynn/2006c.html#37 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Mon, 13 Mar 2006 10:06:31 -0700

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:
Doesn't the microcode and the VM implementation of some models have an optimization for the one possible V=R virtual machine, often running MVS? That shortcuts most of the necessary translation levels.

Amdahl introduced hardware hypervisor ... with V=R (and since there is virtual=real, there is no two level lookup necessary)
https://www.garlic.com/~lynn/2006b.html#38 blast from the past ... macrocode

3090 eventually responded with PR/SM ... PR/SM eventually evolved into the current LPARS (logical partitions; basically subset of virtual machine support built into the fabric of the hardware, isn't V=R, but supports small number of LPAR virtual machines) ... where many mainframes are run with logical partition support as a matter of standard production operation.

this abstract includes mention that z990 requires LPAR mode:

IBM Techdocs Technote: zSeries Performance: Determining the Logical CP Requirements for a Partition
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/032f6e163324983085256b79007f5aec/7eda0421b6d7af1586256db4001efbeb?OpenDocument

a few other references from around the web found with search engine

IBM: PR/SM for zSeries awarded certificate by German Fed Office for Tec Security
http://www-03.ibm.com/servers/eserver/zseries/news/pressreleases/2003/z900securityaward_03-14-03.html
IBM Techdocs Flash: LPAR Management Time Performance Update
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/fe582a1e48331b5585256de50062ae1c/bcbaeece31d0d9ff85256d8c000d4e4f?OpenDocument
IBM Redbooks | Modeling Host Environments using SNAP/SHOT
http://www.redbooks.ibm.com/abstracts/SG245314.html?Open

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

X.509 and ssh

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Mon, 13 Mar 2006 10:20:17 -0700

"Nico Kadel-Garcia" writes:
Along with the repeated references to some PhD paper for which there doesn't seem to be an actual link in the messages that repeatedly reference it. That's confusing at best.

actually there seems to be some additional semantic confusion. there was a question about "why" ... and i mentioned that there was a 9 month research project that studied how i communicated (person sat in the back of my office for 9 months, took notes on all my voice communication, also had copies of all my incoming and outgoing email as well as logs of all instant messages). this research project also resulted in a stanford phd thesis ... joint with language and comp. ai departments ... as well as material for several subsequent books and papers. in that literature, it goes into quite a bit of detail about "why" ... quite a bit more than i could possibly explain.

there was no subsequent request for the actual references ... so it appeared like the original question(s) were possible specious and there was no serious interest in investigating why.

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

X.509 and ssh

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Mon, 13 Mar 2006 10:42:12 -0700

Anne & Lynn Wheeler writes:
there was no subsequent request for the actual references ... so it appeared like the original question(s) were possible specious and there was no serious interest in investigating why.

the actual thesis isn't online ... possibly wait for the google book scanning project and/or have access to the stanford library.

a couple more recent references to some of the work by the prime researcher (found with search engine)
http://www.ncrel.literacy.smartlibrary.info/NewInterface/segment.cfm?segment=2369
http://llt.msu.edu/vol4num2/murray/

which includes the following items:
Denise E. Murray is Director of the National Centre for English Language Teaching and Research, Macquarie University, Sydney, Australia. She was founding Chair of the Department of Linguistics and Language Development at San Jose State University. She has been involved in ESL instruction and teacher education for more than 25 years. Her research interests include crosscultural literacy and the interaction between language, society and technology. Her publications include Knowledge machines: Language and information in a technological society, and Diversity as resource: Redefining cultural literacy.

Murray, D. E. (1988). The context of oral and written language: A framework for mode and medium switching. Language in Society, 17, 351-373.

Murray, D. E. (1991). Conversation for action: The computer terminal as medium of communication. Amsterdam: John Benjamins.

Murray, D. E. (1995). Knowledge machines: Language and information in a technological society. London: Longman.

Murray, D. E. (1999). Access to information technology: Considerations for language educators. Prospect, 14, 4-12.

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

X.509 and ssh

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Mon, 13 Mar 2006 11:06:13 -0700

ref:
https://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#14 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh

.... oh, and i did stumble across an old interim status report on the research project ... partial extract ...


COMPOSITION AS CONVERSATION:
The Computer Terminal as Medium of Communication
Fifth Research Report
April 16th, 1985
Denise E. Murray
San Jose CA

DATA ANALYSIS

In this reporting period, I have concentrated on developing a
theoretical framework, driven by the data. This has included:

An Operational Definition of 'Conversation'. This is a paper to
be presented at the Stanford University School of Education Forum
for Research on Language Issues.

.....

Defining 'problem-solving' discourse.  This genre indicates structures
which achieve object transmission, information transmission,
direction, description, and information development.

...

Channel of communication is not arbitrary; channel may be chosen from
available options. This choice is motivated by field, tenor and mode
of discourse.

Characteristics of discourse depend on choices made along three
clines:

involvement/detachment
planning/spontaneity
collaboration/isolation

....

I have tallied the amount of computer correspondence and conversation
the subject has been engaged in over the past 6 months.

I have asked for statistical help. xxxxx has suggested SPSS available
on the IBM PC.

Presentations

I have written the first draft of the paper, COMPUTER CONVERSATION:
Adapting the Composing Process to Conversation, to be presented at the
International Conference on Computers and the Humanities, Brigham
Young University, June 26-28, 1985

I have written the first draft of the paper, When is a Conversation
not a Conversation? Operationalizing a Definition of the Object of
Discourse Study, to be presented at the Stanford University School of
Education Forum for Research on Language Issues, May 11, 1985.

... snip ...

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Mon, 13 Mar 2006 15:14:57 -0700

"Eric P." writes:
Does VM limit the number of shadow PTEs that can be valid at once similar to the real TLB, to say 128?

It could keep a circular FIFO buffer of the last 128 shadow entries made valid, so that when a VM issues a PTLB there is just a small number of shadow PTEs to invalidate.

This would make it behave just like a 128 entry software managed TLB. To perform a PTLB it need only zap the 128 PTEs from the shadow table listed in the circular buffer.

the shadow table is called a shadow table because it is an exact set of hardware tables ... that correspond to the virtual tables ... but instead of having translation from virtual to virtual real ... takes any miss for the virtual address, extracts the virtual/real address from the virtual table ... and uses the virtual machine address tables to translate from the virtual/real address to the real/real address.

it follows the semantics of TLB but uses real tables for the implementation. in theory, if there is a valid entry in the virtual table (located in the virtual tables in the virtual machine) ... and the corresponding virtual/real page for the virtual machine is in real storage ... then the real/real page number populates the real page table.

the architecture was careful about not specifying how TLBs were implemented ... so that hardware engineers had great deal of latitude in how they could do TLB implementation. As a result, it also provided sufficient latitude to do shadow tables which were a full table set.

the original implementation didn't keep track of how many entries in the shadow table had been made valid ... so that when a purge type operation was required by the architecture of the hardware ... the software implementation just did a complete clear of all possible entries.

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch
Date: Mon, 13 Mar 2006 15:40:23 -0700

there was an (internal corporate) activity trace tool called REDCAP that used some virtual machine like technology to capture all I and D (including differentiating loads/stores) and spit out a instruction trace with storage references.

I got to modify that at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

in support of an internal tool ... that was eventually released in the mid-70s as a product called vs/repack.

modification was made instead of spitting out an actual instruction trace ... create a reference/use storage array representation for the application ... you could specify 16-byte, 32-byte, 64-byte, etc, increments ... and would spit out the array at specified intervals ... say every 1000 or 5000 or 10000 instructions.

the three arrays were for instruction fetch, data fetch, and data store ... with one bit indicating something had occurred in that storage line sometime during the specified instruction interval.

the application that eventually become vs/repack would take that information ... along with map of the application and attempt to do semi-automated program reorganization for optimal virtual memory operation.

one of the things the science center used this analysis for was the port of apl\360 from real-storage environment to cms\apl and a virtual memory operation (including requiring redo of the whole apl storage management and garbage collection). misc. postings mentioning apl, cms\apl, etc
https://www.garlic.com/~lynn/subtopic.html#hone

it was also used by a number of internal product development organizations ... not just for transition from real-storage paradigm to virtual-address-space operation ... but also for generalized execution characteristic operation analysis.

so it turned out that the full instruction emulation was somewhat time-consuming and provided much greater detail than was needed for a lot of application structure re-organization.

so i did a special modification of the kernel virtual address space manager. a victim virtual address space could be selected and specified as being monitored and not to ever have more than N PTEs valid at any moment (akin to your description). Everytime the N+1 PTE fault occurred ... the list of current valid virtual page numbers would be spit out ... and the existing N PTEs had their invalid flag turned on (leaving the real page number in the PTE for translation purposes, but indicating to the hardware that a page fault was to occur for that virtual page). Then the TLB was reset ... and the process would repeat. You sort of got a running indication of virtual pages that were members of active working set for any period. The level of detail was at a much grosser level than full instruction operation provided by REDCAP ... but at much high performance ... and frequently good enuf for the task at hand.

a few years later ... i did a similar kernel hack ... but instead of tracking virtual page use ... tracked all disk file record use. this was used against a number of different production environments as part of designing disk and controller caches ... as well as some filesystem design work. it was one of the first places where we started to see detailed information about bursty use of file collections (i.e. the same collection of files/records used once a day, or week, or month or some other periodic basis).

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

Debit Cards HACKED now

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Mon, 13 Mar 2006 19:34:14 -0700

"Ed Weir $ComCast$" writes:
..."Unlike credit cards, debit cards offer an additional level of security: the password-like Personal Identification Number, or PIN. That's the irony, the PIN was supposed to make debit cards secure," Litan said. "Up until this breach, everyone thought ATMS and PINs could never be compromised."

from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

... where magstripe cards have been a unique something you have authentication. multi-factor authentication are considered more secure when the different factors are subject to different/unique threats/compromises. one of the ways of viewing pin/passwords something you know (as part of multi-factor authentication ... in conjunction with magstripe cards) are that they are a countermeasure to lost/stolen cards (modulo the people that write their pins on their cards).

however skimming techniques have been around for quite some time, which could record both the magstripe information and entered pins at the same time. as a result, skimming created a common vulnerability to both the magstripe information and the pin information (undermining the benefits of having multi-factor authentication) ... aka the recorded magstripe information could be used to create an acceptable counterfeit card ... which then could be used in conjunction with recorded pins. this can also be viewed as relatively straight-forward analysis from the stand-point of replay attacks.

here is a reference looking into some aspects (modulo skimming technologies)

Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit Fraud
http://www.digitaltransactions.net/newsstory.cfm?newsid=738

from a a thread
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner

discussing various kinds of threats and vulnerabilities to multi-factor authentication.

awareness of various pin-debit skimming technologies are so well-known that you even see them used in some of the weekly (crime-oriented) TV dramas (and in some syndicated daily reruns) ... where they've shown in some detail, skimming implementations.

a few URLs found with simple search engine of atm, overlay, skimming
http://moneycentral.msn.com/content/Banking/P57803.asp
http://www.eubfn.com/arts/982_diebold.htm
http://www.csmonitor.com/2003/0721/p15s01-wmcn.html
http://www.atmmarketplace.com/news_story.htm?i=16235
http://www.ou.edu/oupd/idtheft3.htm
http://www.cknow.com/oldnewsletters/2002-01.html#atmskimming

the above search results even turns up some of my postings
https://www.garlic.com/~lynn/2005i.html#1

one of the countermeasures that have been used in conjunction with online credit/debit transactions is to invalidate the account number and issue a new card. this has tended to be more effective with lost/stolen cards ... since the missing card tends to be noticed. skimming (replay) attacks leave the original card in place ... and indications about fraudulent activity comes when somebody checks their statement (or possibly if they get a rejected transaction because all the money is gone).

a little more search engine use ... turns up reference to ABC 20/20 program from 11/8/1998 that looked at atm skimming
http://www.highbeam.com/doc/1P1:28890440/MONEY+MACHINE.html

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

Debit Cards HACKED now

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Mon, 13 Mar 2006 21:02:35 -0700

late breaking news:
http://news.zdnet.com/2100-1009_22-6049290.html
http://news.com.com/Prosecutor+Debit+card+crime+ring+busted/2100-1029_3-6049290.html

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

Debit Cards HACKED now

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Mon, 13 Mar 2006 21:09:38 -0700

and not quite so up to date
http://www.digitaltransactions.net/newsstory.cfm?newsid=880

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

Debit Cards HACKED now

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Tue, 14 Mar 2006 08:03:29 -0700

Anne & Lynn Wheeler writes:
Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit Fraud
http://www.digitaltransactions.net/newsstory.cfm?newsid=738

note, above article from last fall (2005) .... slight clarification ... "signature debit" and "pin debit" doesn't refer to different cards, the new generation of debit cards can be used in either mode. as in previous post
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now

multi-factor authentication somewhat presumes that different factors are vulnerable to different exploit/threats ... and that PIN has somewhat been considered countermeasure to lost/stolen card (or where the magstripe only has been skimmed).

the new generation of debit cards can be stolen (or counterfeited) ... and used for signature debit fraud w/o the pin (regardless of how the card owner has used the card in the past).

skimming and harvesting
https://www.garlic.com/~lynn/subintegrity.html#harvest

technologies are capable of acquiring both the magstripe and PIN in common operation ... underminning any presumed effectiveness of multi-factor authentication (and presumptions of independent vulnerabilities).

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

About TLB in lower-level caches

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: About TLB in lower-level caches
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 14 Mar 2006 10:58:48 -0700

Anne & Lynn Wheeler writes:
however, for some drift ... i had done an implementation in the early 70s that did something similar for a different reason.

ref:
https://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches

part of this was that the science center (4th flr, 545 tech sq)
https://www.garlic.com/~lynn/subtopic.html#545tech

had done a lot of pioneering work in monitoring, profiling, benchmarking, modeling, tuning, etc ... some minor drift
https://www.garlic.com/~lynn/submain.html#bench

that eventually evolved into such things as capacity planning.

that is besides having done the original virtual machine implementation ... Melinda's historical paper
https://www.leeandmelindavarian.com/Melinda/25paper.pdf

as well as having done the implementation used for the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

and, later, also for bitnet/earn
https://www.garlic.com/~lynn/subnetwork.html#bitnet

and lot of online/interactive stuff ... including invention of gml (you might think stands for generalized markup language ... but actually is initials of the inventor's last names) ... which later morphed into html, xml, etc
https://www.garlic.com/~lynn/submain.html#sgml

the compare&swap instruction was also invented at the science center ("CAS" comes from the inventor's initials):
https://www.garlic.com/~lynn/subtopic.html#smp

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

Debit Cards HACKED now

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Tue, 14 Mar 2006 14:08:34 -0700

shoppa writes:
Lots of outfits (including retail stores) use overhead video cameras now, that probably do have a look-see at the PIN pad, and the video is now stored digitally (don't want to put in a new tape every 6 hours?) presumably on a PC at the store.

If also on that network you have the transaction-processing equipment, this might be what they're talking about.

ref:
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#22 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#23 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now

regardless of the initial installation of any possible anti-fraud operation ... if there is any vector that can be used by crooks to get what they want ... then it also has to be maintained securely. This is compromise of anti-fraud equipment as precursor to the actual fraud .. common place is compromising the actual machines/infrastructure or substituting with counterfeit machines

old security proportional to risk posting that looks at a slightly different aspect of the situation. example is when the systemic risk is possibly $50m or more, $1b? ...
http://www.digitaltransactions.net/newsstory.cfm?newsid=880

(i.e. value to the crooks), then, can a retailer afford the necessary security? especially if the actual value to the retailer might possibly be only a couple thousand?
https://www.garlic.com/~lynn/2001h.html#61

aside from the above, there is study about card fees already accounting for over half of convenience store expenses (ahead of labor) ... last paragraph in last article:
http://www.transactionworld.com/articles/2005/September/fraudUpdate1.asp

note that there are also a number of studies that repeately highlight that the majority of fraud (even stuff that appears internet related) involve insiders. old post about survey highlighting insiders
https://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders

and, of course, a few comments about such infrastructures then requiring the whole planet to be buried miles deep in (data hiding) crypto (but if the hidden/sensitive information may also be required in numerous different business processes, then it is impossible to avoid leakage ... especially when insiders might somehow be involved).
https://www.garlic.com/~lynn/aadsm15.htm#21 Simple SSL/TLS - Some Questions
https://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
https://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
https://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"

a 2002 article

Phony Interac terminals steal PINs, personal info
http://www.thevarsity.ca/media/paper285/news/2002/11/04/News/Debit.Card.Scam.Hits.York-314427.shtml?norewrite&sourcedomain=www.thevarsity.ca

2004 article (talks about skimming issues)

Canada's First Debit Fraud Estimate Pegs Losses at $44m
http://www.digitaltransactions.net/newsstory.cfm?newsid=366

2005 article ... comparing phishing to skimming for obtaining information enabling account fraud

Turning Phishing into Cash: Criminal Convenience at the ATM?
http://www.securitymanagement.com/library/towergroup_phishing1105.pdf

the above article doesn't mention it, but a much more convenient avenue for phishing account fraud possibly is something like online banking ... as opposed to creating counterfeit cards for use at physical machines.

early magstripe counterfeiting involved using an algorithm to generate a valid appearing account number and then recording it on a magstripe. magstripe cvv technology was introduced as countermeasure to counterfeit magstripes generated from account number algorithms. this is also a countermeasure to magstripe counterfeiting using account numbers obtained from phishing. however, cvv technology wasn't a countermeasure to skimming technology that recorded a complete, valid magstripe.

collection of past risk, fraud, exploits, vulnerability postings
https://www.garlic.com/~lynn/subintegrity.html#fraud

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

X.509 and ssh

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Wed, 15 Mar 2006 11:22:10 -0700

"Nico Kadel-Garcia" writes:
Neither this nor your subsequent references actually names the paper nor provides any ability to view the paper's material. I'm sure it's very ego-gratifying to have a paper that mentions you, but since the content of the paper is unavailable and you've in fact failed to even describe what the paper said about your posting style, it's pretty much an entirely useless reference. Isn't it?

In other words, there's no confusion: you've failed to actually explain or justify your failure to use capitals, periods, or other punctuation correctly and continue meandering about irrelevant material.

I guess that the earlier statements weren't very clear that the phd thesis and subsequent papers and books were based on analysis of collected nine months of my communication. the communication examples in the thesis and subsequent books and papers were anonymized so my name never appeared (in addition a lot of technical content of what was actually being discussed in the communication was frequently obscured).

also from referenced status report mentioned here
https://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh

the data collection effort and analysis was done under an IBM contract managed out of the Los Angeles Scientific Center and resulted in a IBM research report as well as Stanford phd thesis. The dissertation topic was Composition as Conversation: The Computer Terminal as Medium of Communication (aka title of phd thesis). It was joint between language department and computer ai department (I believe terry winograd was thesis adviser on the computer side)

the earlier statements also reference that the collected material and analysis was used for subsequent papers and books.

for some drift, various collected posts about cmc, some mentioning the dissertation
https://www.garlic.com/~lynn/subnetwork.html#cmc

the only publication on the subject that i'm aware of from the period (in the early 80s) that actually mentioned my name was a Datamation article that had some references to my getting blamed for a lot of online stuff that happened during the 70s and early 80s.

some of the activity referenced in the Datamation article is also mentioned in various past postings about the internal network ... which was larger than the arpanet/internet from the beginning until approximately summer of 1985 ... when the number of nodes in the internet passed the number of nodes in the internal network.
https://www.garlic.com/~lynn/subnetwork.html#internalnet

note the internal network size doesn't include the academic bitnet (in the US) and earn (in europe) which used the same technology as the internal network (bitnet/earn was also larger than internet in the early 80s)
https://www.garlic.com/~lynn/subnetwork.html#bitnet

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

MCTS

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MCTS
Newsgroups: alt.folklore.computers
Date: Thu, 16 Mar 2006 10:51:48 -0700

Brian Inglis writes:
Is there available any old graphics software using 2250s? AFAIR that was expensive proprietary or commercial CAD software.

Lincoln Labs. had written some fortran 2250 library stuff for cms ... and it was on cp67/cms that some people from cambridge came out and installed in '68.

I adapted the lincoln labs fortran 2250 library stuff as device driver for cms edit ... for a full screen editor (the univ. had 2250m1 ... i.e. direct channel attach).

boeing hunstville had some sort of big 2250 operation ... they had a two-processor 360/67 smp for driving 2250. they were running it with specially modified os/mvt release 13 ... that didn't do any paging ... but used the 360/67 virtual memory hardware to get around os/mvt storage fragmentation problems with the long running 2250 applications.

cambridge had a 2250m4 .... i.e. a 1130 as a controller/processor in lieu of the 2250m1 channel controller box. somebody had ported spacewars to the machine ... and my kids would play ... the keyboard layout was split in half with keys dedicated for movement, firing, commands, etc ... for two-player operation.

later, some other vendor's display was remarketed as a 3250 (upgrade for 2250).

later replacement for 3250s were 5080s.

less expensive was the 3277ga ... which was tektronics graphics display hooked into side of 3277. recent reference
https://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"

catia (still around) was widely used cad software for 2250.
http://www.3ds.com/index.php
http://www.3ds.com/fr/products-solutions/3d-for-all/virtools-dev-35/
http://www-306.ibm.com/software/applications/plm/catiav5/

somebody's cad "history" (from search engine)
http://joelorr.home.mindspring.com/id55.htm

another cad history (also mentions lincoln labs)
http://www.memagazine.org/backissues/april00/features/push/push.html

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

X.509 and ssh

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X.509 and ssh
Newsgroups: comp.security.ssh
Date: Thu, 16 Mar 2006 13:03:04 -0700

Chuck writes:
You really should consider shorter responses. One or two sentences will usually do.

past refs in thread:
https://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#14 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#18 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#27 X.509 and ssh

well then, two search engines URLs
http://www.google.com/search?as_q=&num=100&hl=en&btnG=Google+Search&as_epq=The+computer+terminal+as+medium&as_oq=&as_eq=&lr=lang_en&as_ft=i&as_filetype=&as_qdr=all&as_occt=any&as_dt=i&as_sitesearch=&as_rights=&safe=images
http://search.yahoo.com/search?_adv_prop=web&x=op&ei=UTF-8&fr=FP-pull-web-t&va_vt=any&vp=The+computer+terminal+as+medium&vp_vt=any&vo_vt=any&ve_vt=any&vd=all&vf=all&vm=i&fl=0&n=100

the long responses were also something cited in the detailed analysis (in fact this is relatviely brief compared to the recent discussion in comp.arch on TLBs).

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

Debit Cards HACKED now

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Debit Cards HACKED now
Newsgroups: sci.crypt
Date: Thu, 16 Mar 2006 13:38:04 -0700

late breaking?
http://www.expertclick.com/NewsReleaseWire/default.cfm?Action=ReleaseDetail&ID=12021

from above:
(BOSTON, Mass. - March 16, 2006 - IDTheftSecurity.com) Last week high-tech thieves hacked the computer systems at Citibank and made off with countless ATM cards PIN numbers, four-digit consumer security codes previously considered impervious to attacks. According to Robert Siciliano, president of IDTheftSecurity.com, no system of security is foolproof.

... snip ...

pin-debit is just two-factor authentication,
https://www.garlic.com/~lynn/subintegrity.html#3factor

magstripe card as something you have and pin as something you know (i.e. for a long time, pin has somewhat been countermeasure to lost/stolen cards ... modulo the people that write pins on their cards).

however, static data mechanisms (both magstripe and pin information) have been subject to replay attacks ... subject to various kinds of MITM, phishing, evesdropping, skimming, and/or data breach exploits.

magstripe can be evesdropping, skimming, data breach, etc ... with the harvested information being used to produce a counterfeit magstripe (something you have).

pin can be evesdropping, skimming, data breach, etc ... with the harvested information being entered at later time (something you know)

as previously noted, multi-factor authentication has presumed different vulnerabilities and exploits for the different authentication factors. however, various skimming, evesdropping, data breach, etc. exploits have been able to acquire all authentication factors (negating the assumption about independent vulnerabilities).

rest of thread:
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#22 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#23 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now

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

MCTS

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MCTS
Newsgroups: alt.folklore.computers
Date: Fri, 17 Mar 2006 10:07:34 -0700

sarr@umich.edu (Sarr J. Blumson) writes:
A few years later (early 80s?) I met someone who was doing solid modeling work at GM. The stuff was running on a 370/something running TSS/360 (because it was the only IBM OS that did full 32 bit - not just 31 bit - addressing).

I have no idea whether this is on topic or not.

GMR (gm research) was one of the major tss/360 users ... for years after it was decommuted. 360/67 had support for virtual 24-bit and 32-bit addressing modes ... and GMR made big deal about having application that laid out everything in flat, one-level store allowed by tss/360 32-bit support (straight-foward page-mapped stuff stuff w/o having to resort to typical filesystem semantics in the application).

when virtual memory was announced for 370 ... only 24-bit virtual addressing was available ... and there was a port of tss/360 to tss/370 (although w/o any 32-bit virtual addressing support).

when 370-xa support was announced for 3081 in the early 80s, it only had provision for 31-bit virtual addressing ... not the 32-bit virtual addressing that had been available on 360/67.

one of the major users of tss/370 was at&t ... a custom, stripped down version of the tss/370 kernel was done called sss/370 ... which had unix api interface layered on top. I spent some time in the 80s looking at doing a merge of sss/370 underlying kernel with virtual machine support.

someplace I have some old detailed analysis comparing sss/370 stripped down kernel with vm/370 kernel from the era. part of the issue was that since tss/370{360} had been decommuted, it only had a very small group of dedicated professionals supporting the kernel. The issue with vm/370 was that it became more and more popular, there were lots of people with traditional operating system backgrounds assigned to work on it. As a result, the original vm/370 kernel philosiphy was severely compromised with lots of stuff being dropped into the kernel layer that should have been better done in another way (with vm/370 kernel starting to look more like the original bloated tss/360 kernel and sss/360 starting to look more like the original cp/67 kernel).

reference to multics being one-level store ... and large multics application at gmr ... and listed some of the other systems that had implemented one-level store (including tss/360)
http://web.mit.edu/afs/athena.mit.edu/user/other/a/Saltzer/www/multics.html

note while the above claimed that the listed systems had picked up one-level store from multics, tss/360 and multics were going on concurrently. for lots more history of the period (ctss, tss/360, project mac, multics, science center, virtual machines, etc) see melinda's historical paper
https://www.leeandmelindavarian.com/Melinda/25paper.pdf

various other multics references talk about multics and one-level store being used at gm long after tss/360 was gone ... this references multics GM (same GM?) shutdown in the fall of 98:
http://ftp.stratus.com/vos/multics/tvv/chrono.html

search engine even coughed up an old posting of mine about GM claiming enormous productivity increases for their programmers developing 32bit (one-level store) applications
https://www.garlic.com/~lynn/2004o.html#2 Integer types for 128-bit addressing

this paper mentions that GM had developed the first operating system in the mid-50s and the idea had caught IBM's attention (which led to IBM investing in the new concept)
http://www.computinghistorymuseum.org/teaching/papers/research/cetiner.pdf

umich also had written MTS for 360/67 that supported 24-bit virtual addressing
http://www.umich.edu/~bhl/bhl/exhibits/mtstime/mtstime.htm
http://www.umich.edu/news/index.html?Releases/2004/Sep04/r090704b
http://www.umich.edu/~urecord/9596/Sep25_95/7.htm

the series of MTS historical references that used to be here
... seemed to have gone 404
http://www.itd.umich.edu/~doc/Digest/

minor drift from long ago and far away ... (making references to a traditional low-level unix kernel was even drastically more simpler than sss/370).

Date: 84/01/09 16:35:00
To: wheeler

Dear Lynn,

I got the full scoop on the Amdahl UNIX benchmark. I called in a marker on a UNIX system type at Bell Labs. (I had help him prove that system crashes were due to a bug in the Amdahl hardware.)

The benchmark was a full system test on the new UTS software. It is unfortunate that the number 1.8 got out. Bell ran several benckmarks. The best of them was 1.8. The overall average was around 1.5. This was a comparason of UTS to SSS/370 on the same hardware. I beleive it was a 3081 running as a uniprocessor. Remember, UTS does not run MP.

The 5860 uniprocessor runs at about 80% of the combined 3081 multi- processors. Since his software does not run MP, if you compare his hardware/software to the IBM hardware/software, the throughput difference is 1.25 (1.5 times .80).

Bell claims not to know when Amdahl will put MP support in UTS. Bell says that they have no idea what it will cost (in performance) to implement MP (semaphores, etc.)

For the current set of UNIX benchmarks (all jobs fit in memory, no paging, no contention, etc.), it does not do much good to have a high-powered supervisor. The current SSS/370 systems at Bell do almost no paging (over 90% of I/O is data access) and almost no scehuling (all jobs currently active fit in memory). Until the typical UNIX workload changes, a complicated high-powered supervior has too much overhead.

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

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

transputers again was: The demise of Commodore

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: transputers again was: The demise of Commodore
Newsgroups: alt.folklore.computers
Date: Sat, 18 Mar 2006 07:45:07 -0700

jmfbahciv writes:
That was an aspect of a grad student who came from India; he refused to consult with me because I was a female and incapable of thought. He could not leave program control to a mere DO loop and had to do the loop count by hand. It's an interesting thinking style to study.

How in the hell do they debug 57 levels of IFs?

I think I'd assigned graduated problem where the first one has 57 choices and the next one has 1000 choices. See if they like wasting all their time typing.

i wrote this pli program in the early 70s to analyze assembler source, among other things it would do path flow analysis, looking for dead code, register use (look for use before load), and attempt to spit out higher level psuedo code with if/then/else/when/until/case/etc structures.

some stuff that appeared to be relatively compact branch instruction structures turned into really ugly if/then/else nesting. I eventually got around to limiting nesting to the 10-15 range ... and then forcing GOTOs. this was much more common in highly optimized kernel code (some stuff that followed relatively straight-forward with branch/goto semantics didn't translate well to if/then/else).

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

MCTS

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MCTS
Newsgroups: alt.folklore.computers
Date: Sat, 18 Mar 2006 08:30:44 -0700

Anne & Lynn Wheeler writes:
someplace I have some old detailed analysis comparing sss/370 stripped down kernel with vm/370 kernel from the era. part of the issue was that since tss/370{360} had been decommuted, it only had a very small group of dedicated professionals supporting the kernel. The issue with vm/370 was that it became more and more popular, there were lots of people with traditional operating system backgrounds assigned to work on it. As a result, the original vm/370 kernel philosiphy was severely compromised with lots of stuff being dropped into the kernel layer that should have been better done in another way (with vm/370 kernel starting to look more like the original bloated tss/360 kernel and sss/360 starting to look more like the original cp/67 kernel).

minor drift from someplace in spring 1985:


TSS     VM/SP
modules 109     261
LOC     51k     232k

aka LOC ... lines of (assembler) code.

misc. past sss/370 references:
https://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
https://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
https://www.garlic.com/~lynn/2005b.html#13 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#61 Virtual Machine Hardware
https://www.garlic.com/~lynn/2005s.html#34 Power5 and Cell, new issue of IBM Journal of R&D

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

CJ Date on Missing Information

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CJ Date on Missing Information
Newsgroups: comp.databases.theory
Date: Sat, 18 Mar 2006 13:41:34 -0700

"Paul Mansour" writes:
I've just read "The Default Values Approach to Missing Information" in Date's Database Writings 1989-1991. I've also noted that in the 8th edition of Date's main textbook, he refers to the "special values scheme" for handling missing information, and points to an article in Database Writings 1994-1997. I don't have the 94-97 book, though I am trying to track down a copy, and I'm curious to know if Date's view on handling missing information has changed since the 89-91 writings, or is it more or less the same. Any comments on this would be appreciated.

old posting that references a dec92 article in database programming and design by date on dealing with unknown values titled "An Explanation of why three-valued logic is a mistake (Why Accept Wrong Answers?)"
https://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
https://www.garlic.com/~lynn/2003g.html#41 How to cope with missing values - NULLS?

... aka it isn't so much that 3-valued logic is wrong or incorrect ... it might be considered more of a human factors issue where people are much more prone to making mistakes (and therefor getting unexpected or wrong results) in 3-valued logic.

boolean searches of large databases have seen something analogous ... when you might have billions of items and there are 5-8 search terms ... people frequently inverted the meaning of boolean ANDs and ORs (I think that NLM started seeing this by the early 80s, but it became more wide-spread with growth of internet search engines).

a similar but different occurance was some number of the firewall rule specification languages from the mid-90s ... where a frequent and common mistake for people writing firewall rules would be specifications that inverted what they had actually intended (denying things that they wanted to permit and permitting things that they wanted to deny).

it might be considered analogous to road design ... you might have a perfectly good road ... but if people are having a lot of accidents ... they will frequently attempt to change the road (after they give up on trying to change human nature), possibly just attempting to mitigate what ever human factors issues that are actually resulting in the accidents.

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

The Pankian Metaphor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.lang.asm,alt.folklore.computers,rec.arts.int-fiction
Date: Sat, 18 Mar 2006 14:15:47 -0700

stevendaryl3016@yahoo.com (Daryl McCullough) writes:
Actually, it's been downhill for the internet ever since they stopped calling it the "ARPANET".

ARPANET required dedicated 56kbit links, expensive IMPs, homogeneous operation (based on the IMP boxes) and lots of inter-IMP chatter (I remember some joke in the late 70s about the IMPs required 56kbit links because as the number of nodes were scaling over 200, majority of the bandwidth could be going for inter-IMP control traffic).

in some respects ISO OSI networking standard homogeneous operation and ARPANET homogeneous operation were similar. the big change was the switch-over to internetworking protocol on 1/1/83 (internets, gateways, etc). i've frequently contended that the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

was larger than the arpanet/internet (from just about the beginning until sometime mid-85) was because internal network nodes had something akin to gateway technology from the beginning (making heterogeneous interoperability a lot easier). at the time of the big switch-over the arpanet was approx. 250 nodes. By comparison, later that same year, the internal network celebrated its 1000th node
https://www.garlic.com/~lynn/internet.htm#22

various collected networking postings, many referencing how OSI homogeneous operation and lack of internetworking severely limited ISO networking standards
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

the other big change wasn't so much protocol technology (that enabled gateways and backbone for inter-networking) ... but the actual deployment of an operational backbone for inter-networking with nsfnet1. minor comment about not being allowed to bid on nsfnet1
https://www.garlic.com/~lynn/internet.htm#0

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

The Pankian Metaphor

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.lang.asm,alt.folklore.computers,rec.arts.int-fiction
Date: Sat, 18 Mar 2006 14:30:52 -0700

Anne & Lynn Wheeler writes:
the other big change wasn't so much protocol technology (that enabled gateways and backbone for inter-networking) ... but the actual deployment of an operational backbone for inter-networking with nsfnet1. minor comment about not being allowed to bid on nsfnet1
https://www.garlic.com/~lynn/internet.htm#0

for lots more drift ...

in this period i was into high availability, fault isolation ... in part having helped with the clustering and availability stuff for hone
https://www.garlic.com/~lynn/subtopic.html#hone

as well as having rewritten major portions of the kernel for use by the disk engineering lab for multiple concurrent engineering testcell testing (previous attempts with MVS had found 15 minute MTBF with a single testcell).
https://www.garlic.com/~lynn/subtopic.html#disk

as well as high performance processor operation and high performance networking. one of the projects was something I named high-speed data transport (HSDT)
https://www.garlic.com/~lynn/subnetwork.html#hsdt

and we had a high-speed backbone ... with both terrestrial and sat. links ... slowest speed link was T1 (1.5mbits) full-duplex.

the original internal network technology implementation resided in a virtual address space and relied on the vm spool-file system for file store&forward at each node.
https://www.garlic.com/~lynn/subnetwork.html#internalnet

it simplified the code and facilitated deployment ... but it had a thruput constraint. the spool-file semantics provided serialized, synchronous 4k-byte block local transfer. with limited number of disk arms for spool files, serialized synchronous transfers and other processes contending for the same service ... a network node might have max. sustained thruput of five to ten 4k-byte blocks per second. in the early days with 9600baud half-duplex lines, 20k to 40k byte/sec aggregate thruput probably seemed sufficient. however, a single hsdt, slow-speed full-duplex T1 link needed a little over 300k-byte/sec sustained (each hsdt link could require a minimum of ten times the standard aggregate thruput).

so for the heck of it, i undertook to move the vm spool file system out of the kernel into a virtual address space, rewrite it from scratch in vs/pascal (rather than assembler), and optimize it so hsdt (internal network) node might be able to see several mbytes/sec sustained thruput. part of the issue of getting high thruput was supporting multi-block asynchronous transfer semantics (including read-ahead and write-behind). the other part was taking the kernel assembler code and cutting the pathlength in the virtual address space pascal implementation. some of this was the kernel implementation had some number of linear list searches. this is analogous but different to recent mention of tcp finwait list implementation
https://www.garlic.com/~lynn/2006d.html#21 IBM 610 workstation computer

for some context of the period, we were contracting for some equipment built to order in the far east. on the friday before leaving for a trip across the pacific, the communication devision announced a new discussion group on the subject of high-speed communication with the following definitions:


low-speed               <9.6kbits
medium-speed            19.2kbits
high-speed              56kbits
very high-speed         1.5mbits

Monday morning in a conference room on the other side of the pacific, there were plaques on the wall with the following definitions


low-speed               <20mbits
medium-speed            100mbits
high-speed              200-300mbits
very high-speed         >600mbits

this was also in the period when the mainframe tcp/ip product (running in virtual address space and implemented in pascal) got about 44kbytes/sec sustained thruput consuming cpu cycles of approx. full 3090 processor. I added rfc 1044 support to the implementation and in some testing at cray research between a cray and a 4341-clone ... was getting 1mbyte/sec sustained using about 20 percent of the 4341-clone processor. misc. past posts mentioning rfc 1044 implementation:
https://www.garlic.com/~lynn/subnetwork.html#1044

as an aside ... although we weren't permitted to bid on nsfnet ... we did go to the director of nsf and got a technical audit of the backbone we were operating. one of the statements was that what we had running was at least five years ahead of all nsfnet bid responses (to build something new). minor reference to the original nsfnet backbone program announcement and original nsfnet backbone award announcement
https://www.garlic.com/~lynn/internet.htm#nsfnet

misc. other internet historical references from my rfc index
https://www.garlic.com/~lynn/rfcietff.htm

and click on "misc. historical references" (in the 1st paragraph).

misc. pasts posts mentioning juxtaposition of the communication divisions high-speed newsgroup
https://www.garlic.com/~lynn/94.html#33b High Speed Data Transport (HSDT)
https://www.garlic.com/~lynn/2000b.html#69 oddly portable machines
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2003m.html#59 SR 15,15
https://www.garlic.com/~lynn/2004g.html#12 network history
https://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005j.html#59 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005n.html#25 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design

misc. past posts mentioning spool file system rewrite in pascal
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
https://www.garlic.com/~lynn/2003b.html#46 internal network drift (was filesystem structure)
https://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
https://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
https://www.garlic.com/~lynn/2004m.html#33 Shipwrecks
https://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
https://www.garlic.com/~lynn/2005s.html#46 Various kinds of System reloads
https://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloads

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

The Pankian Metaphor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.lang.asm,alt.folklore.computers,rec.arts.int-fiction
Date: Sun, 19 Mar 2006 08:49:52 -0700

note that during the period, the internal network wasn't exactly public/commercial network ... it was purely the internal corporate network that interconnected internal corporate sites around the world. the number of nodes were purely internal corporate operations.

it was after the nsfnet backbone period and the actual deployment of internetworking interconnections that commercial ISPs were starting to appear.

something else that the internal network had to deal with ... compared to arpanet/internet ... besides having to deal with a lot larger scale-up ... was that all the links that left corporate premises had to be encrypted. at one time, somebody claimed that the internal network had over half of all the link encryptors in the world.

there were these little things like gov. regulations. all sorts of problems with links from one corporate location in one country to a corporate location in another country ... and the link had to be fully encrypted (there were some real pains trying to get encrypted link between, say a lab in germany and a lab in france and trying to get the respective country PTTs to cooperate).

hsdt pushed this even harder because the links were at least T1 (1.5mbit in US and 2mbit in europe, rather than 9.6kbit or possibly 56kbit that were common at the time) ... and there weren't a whole lot of full-speed link encryptors on the market at that time ... as well as I didn't like paying the price of what they were charging for such full-speed link encryptors. as a result, one of the hsdt activities was to design some hardware that could run a heck of a lot faster encryption, have more function and be significantly lower cost (my target was to be able to build the boards for under $100).

the other thing that was going on in the period ... was the bitnet academic network (and earn in europe)
https://www.garlic.com/~lynn/subnetwork.html#bitnet

which used the same technology as the internal network .. but was a totally different network.

old email reference from the person being pulled into to start and run EARN
https://www.garlic.com/~lynn/2001h.html#65

for some drift, the same person earlier had been on assignment to cambridge (from the grenoble science center) and was responsible for adding the additional virtualized virtual memory architecture to the base cp/67 virtual machine support (original shadow table stuff). recent thread in comp.arch on TLB that drifted into early virtual machine infrastructure
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches

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

The Pankian Metaphor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.lang.asm,alt.folklore.computers,rec.arts.int-fiction
Date: Sun, 19 Mar 2006 09:12:42 -0700

Morten Reistad writes:
Let's face it; before around 1985 there was no point in throwing money at communications for internet-like services. Noone were ready for it. X.25/ISO sure wasn't; they had severe problems with filling 2 megabit lines. The Arpanet-IP transition had to be finished, and commercial equipment be available.

nsfnet-1 backbone called for T1 links (which hsdt was already running). the winning nsfnet-1 bid actually used full-speed T1 links into a multiplexor that split the T1 bandwidth down to multiple 440kbits links which then were supported by IP-routers that could support 440kbit (at the time, hsdt was using ip-routers that supported full T1 links). I made a joke that you could probably find 56kbit links somewhere in the world that had been multiplexed by telco thru a T5 trunk at some point and therefor could call it a T5 network)

nsfnet-2 backbone called for full-speed T3 links.

the blue team for nsfnet-2 was made up of something like 20 people from 7 labs around the world. I was allowed to be the red-team. At the review, I presented first (with full-speed T3 support). Then somebody from the blue team started presenting. About five minutes into the blue team presentation, the person running the review interrupted and said that he would lay down in front of a garbage truck before he allowed anything but the blue team proposal to go forward (by five minutes into the blue team presentation, there were already mutterings in the audience about how poorly the blue team proposal compared to the red team proposal).

misc. hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt

ref:
https://www.garlic.com/~lynn/2006e.html#35 The Pankian Metaphor
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
https://www.garlic.com/~lynn/2006e.html#37 The Pankian Metaphor

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

The Pankian Metaphor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Pankian Metaphor
Newsgroups: alt.lang.asm,alt.folklore.computers,rec.arts.int-fiction
Date: Sun, 19 Mar 2006 09:28:47 -0700

Anne & Lynn Wheeler writes:
nsfnet-2 backbone called for full-speed T3 links.

the previous post
https://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor

mentioning RFC 1044 support
https://www.garlic.com/~lynn/subnetwork.html#1044

had commercial hardware that included ip-router capable of T3.

The specific mention was about doing enhancements for rfc 1044 support for getting 1mbyte/sec (say 8-10mbits/sec) sustained out of a single 4341-clone (and a cray) ... compared to the base support that would burn nearly a full 3090 cpu getting 44kbytes/sec sustained (say 400kbits/sec).

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

transputers again was: The demise of Commodore

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: transputers again was: The demise of Commodore
Newsgroups: alt.folklore.computers
Date: Sun, 19 Mar 2006 15:31:05 -0700

scott@slp53.sl.home (Scott Lurndal) writes:
Burroughs V-Series had two instructions with less than politically correct pronunciations: Write Hardware Register (WHR) and Search Linked lisT (SLT).

Lincoln Labs also did SLT rpq instruction for the 360/67. It got the most heaviest use in internal kernel storage allocation mechanism ... searching list of available storage for best/first fit allocation ... and searching list of available storage on deallocation for fit (i.e. looking for contiguous storage for coalescing). The instruction even shows up on the standard 360/67 "blue" reference card.

however, searching linked list of any kind turned out to be a major scale-up problem for cp67 ... partially as other areas of kernel became more optimized ... internal kernel storage management became a major bottleneck as systems grew larger.

finally, in the early 70s, there was finally a change-over to "subpool" storage management mechanism that drastically cut the kernel overhead for maintenance of internal kernel storage.

random past posts mentioning 360/67 SLT instruction (and 1970 switch-over to subpool logic in release 3 of cp67 ... the push/pop subpools were also trivial to manage in multiprocessor environment with the compare&swap instruction which had been invented at the science center ... in addition to having created virtual machines, cp67 operating system and the subpool work):
https://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
https://www.garlic.com/~lynn/98.html#19 S/360 operating systems geneaology
https://www.garlic.com/~lynn/98.html#20 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2000d.html#47 Charging for time-share CPU time
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
https://www.garlic.com/~lynn/2001d.html#23 why the machine word size is in radix 8??
https://www.garlic.com/~lynn/2001d.html#33 Very CISC Instuctions (Was: why the machine word size ...)
https://www.garlic.com/~lynn/2001h.html#71 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2001i.html#15 IBM 9020 FAA/ATC Systems from 1960's
https://www.garlic.com/~lynn/2002.html#14 index searching
https://www.garlic.com/~lynn/2002.html#48 Microcode?
https://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
https://www.garlic.com/~lynn/2002h.html#87 Atomic operations redux
https://www.garlic.com/~lynn/2003m.html#35 SR 15,15 was: IEFBR14 Problems
https://www.garlic.com/~lynn/2004l.html#17 IBM 3090 : Was (and fek that) : Re: new computer kits
https://www.garlic.com/~lynn/2004m.html#22 Lock-free algorithms
https://www.garlic.com/~lynn/2004n.html#36 Shipwrecks (dynamic linking)
https://www.garlic.com/~lynn/2005b.html#28 Relocating application architecture and compiler support
https://www.garlic.com/~lynn/2005c.html#35 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005k.html#4 IBM/Watson autobiography--thoughts on?
https://www.garlic.com/~lynn/2005l.html#9 Jack Kilby dead

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

CJ Date on Missing Information

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CJ Date on Missing Information
Newsgroups: comp.databases.theory
Date: Mon, 20 Mar 2006 07:41:27 -0700

Jonathan Leffler writes:
Getting 404 errors on those - can you confirm or correct them?

ref:
https://www.garlic.com/~lynn/2006e.html#34 CJ Date on Missing Information

sorry, finger check transcribing
https://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
https://www.garlic.com/~lynn/2003g.html#41 How to cope with missing values - NULLS?

q->g

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

SSL Certificate Signing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SSL Certificate Signing
Newsgroups: bit.listserv.ibm-main
Date: Mon, 20 Mar 2006 12:48:54 -0700

John S. Giltner, Jr. wrote:
Not sure why, but we have had problems ftp'ing certificates to import.

What we end up doing is cut'ing from the PC and pasting into the TSO.

I was just recenlty made aware of this, the security people new but did not tell any of the networking people. Here the mainframe network sysprogs do all truly network functions (firewalls, switches, routers).

I was told that it has something to do with trailing blanks on the end of the lines. That ftp was adding them, and something did not like them. I want to do some testing, I think that using recfm VB should work but I have not tried it yet.

digital signatures are applied to data ... then the digital signature is later verified to check that 1) no bits in the data have changed and 2) authenticate the entity generating the digital signature

digital certificates are a specialized standards format that are digitally signed. any bit change in the body of the digital certificate will result in the verification of the certificate's digital signature to fail (and treating the result as a bad digital certificate).

a similar but different issue that happened with the XML digital signature standard was that the base XML wasn't defining a deterministic encoding standard.

FSTC finally came up with FSML deterministic encoding standard for (digitally signed) financial transactions. Part of the issue was that standard encoding process results in quite a bit of payload bloat for financial transactions. Their solution was to take a financial transaction, encode it for digital signing and then transmit the original unencoded financial transaction (rather than the bloated encoded version) along with appended digital signature. The recipient would then re-encode the transaction and verify the digital signature. Unless all the encoding processes produced exactly the same bits ... the digital signature verification would fail.

misc. past postings about SSL certification and digital certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

transputers again was: The demise of Commodore

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: transputers again was: The demise of Commodore
Newsgroups: alt.folklore.computers
Date: Tue, 21 Mar 2006 07:36:07 -0700

jmfbahciv writes:
It's very easy. A lot of my bit gods never thought in English. They actually thought bits. TW was a bit programmer. Cutler was an extreme bit programmer. They did not think in English when they were coding.

... slightly related posting about being able to trivially switch-back and forth between fortran/apl operations research style and low-level kernel state/bit style ... even when doing low-level kernel machine language programming
https://www.garlic.com/~lynn/2006d.html#11 IBM 610 workstation computer

one of the observations from a 9-month research study of how i communicated, was english didn't even appear to be my native language (this by a professional esl teacher). recent postings about the research, which also became a stanford phd thesis and the material for subsequent papers and books.
https://www.garlic.com/~lynn/2006e.html#13 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#16 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#17 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#27 X.509 and ssh
https://www.garlic.com/~lynn/2006e.html#29 X.509 and ssh

general collected postings related to cmc
https://www.garlic.com/~lynn/subnetwork.html#cmc

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

Does the Data Protection Act of 2005 Make Sense

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Does the Data Protection Act of 2005 Make Sense
Newsgroups: alt.computer.security
Date: Tue, 21 Mar 2006 17:19:36 -0700

"aioe.cjb.net" writes:
GLBA has similar requirements, yet encryption of sensitive data on mobile devices is still not required

when we were called in to help word smith cal. electronic signature bil (and later the federal legislation) there were a couple of the industry organizations also working on a number of the privacy issues. one of the industry organizations had done a survey of driving factors behind privacy legislation and found that the two main driving factors behind privacy regulation and legislation were

• identity theft • (individual) denial-of-service (by institutions)

cal. was also in the middle of passing opt-in legislation regarding sharing of privacy information (i.e. organizations had to have your permission before they were allowed to share individual personal information), when it was pre-emted by GLBA with "opt-out" (institutions had to send individuals descriptions of how they were sharing personal information and give individuals a mechanism for opting out ... as opposed to the pending cal. legislation that would have precluded in any information sharing unless the individual specifically directed). misc. past mention of electronic signature stuff
https://www.garlic.com/~lynn/subpubkey.html#signature

we were co-authors of the x9 financial industry standard for privacy x9.99 ... and we spent a lot of time looking at HIPAA, GLBA as well as EU-DPD (even tho x9 is US standards organization, we spent some time considering international issues anticipating x9.99 might go to ISO). As part of x9.99 effort, i did take a privacy subset of my merged security taxonomy and glossary and merged it with stuff from HIPAA, GLBA, FTC, and EU-DPD
https://www.garlic.com/~lynn/index.html#glosnote

one of the considerations was regarding privacy breaches (cal. passed one of the earliest bills requiring notification in cases of privacy breaches).

part of the issue here is a lot of stuff has been lumped into the category of identity theft/fraud ... and there has been some recent effort to break out "account" fraud as a separate category (especially since a lot of the breaches making it into the press have tended to be account fraud oriented).

in the mid-90s, the x9a10 working group was giving the requirement to preserve the integrity of the financial infrastructure for ALL retail transactions ... for the work being done on x9.59 retail payment standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

the issue here was that the majority of payment security work had been around lost/stolen cards. PINs (for debit cards) are part of multi-factor authentication and can be considered a countermeasure for lost/stolen cards (modulo the people that write PINs on the cards or the debit cards that have logos and can be used w/o requiring a PIN). Reporting lost/stolen card would result in account being turned off ... possibly before any fraud could be done (again a countermeasure to lost/stolen card).

a problem (studied by x9a10) was that starting with online, electronic transactions (by at least the early 70s), skimming and harvesting of electronic information became a threat (that could result in counterfeit cards, fraudulent transactions, etc).

partially because of skimming and harvesting threats
https://www.garlic.com/~lynn/subintegrity.html#harvest

there has been periodic efforts to institute massive secrecy-based countermeasures protecting account numbers (as well as the rest of the magstripe information). this created some diametrically opposing objectives ... since account numbers are required in numerous business processes related to the payment business (and therefor has to be readily available). On the other hand, the heavily secrecy-based security paradigm would require that the account number is never available.

An additional side issue is security proportional to risk thread ... looking at the potentially massive discrepancy in value of the data breach to the crook ... vis-a-vis the value to the merchant
https://www.garlic.com/~lynn/2001h.html#61

PINs, in theory represent multi-factor authentication when used in conjunction with a card ... i.e. from 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor

• something you have
• something you know
• something you are

a PIN is something you know and a card is something you have ... with a PIN being considered a countermeasure for lost/stolen card.

however, implicit in multi-factor authentication is that the different factors are vulnerable to different threats. the advent of online, electronic transactions by at least the early 70s ... really opened up the skimming & harvest compromises. An issue in skimming compromises ... is that both the PIN (something you know) and the card magstripe (something you have) could be BOTH skimmed at the same time ... invalidating assumptions about the value of multi-factor authentication and vulnerability to different compromises and threats. The skimmed magstripe information was sufficient for easily producing a counterfeit card.

part of the x9.59 work was to drastically change the heavy secrecy-based security paradigm ... by eliminating divulging account number as fraud threat, as well as changing the card. a chip-card was required as something you have, but it wasn't "skimmable". A PIN could still be used as countermeasure for lost/stolen card. And the card would actually be a countemeasure to "skimming" (the PIN) ... none of the data-breaches, skimming, and/or harvesting vulnerabilities were sufficient for enabling fraudulent transactions.

So the new kind of physical card became a strong countermeasure to the skimming, harvesting, and data breach vulnerabilities that had been around since at least the advent of online, electronic transactions in the early 70s (meeting assumptions about multi-factor authentication being vulnerable to different threats and exploits).

Part of this is my observation that even burying the planet under miles of (information hiding) cryptography is not sufficient to prevent leakage of account numbers ... in part because there are so many business processes that the account numbers are required for (current situation creates diametrically opposing objectives of total secrecy about the account number and at the same time requiring the account number to be widely available).

Now, reporting lost/stolen card and turning off the account number is still a countermeasure. One of the issues with reporting and account number deactivation with skimming, harvesting and data breach vulnerabilities ... is that typically a lost/stolen card is noticed and reporting may deactivate the account even before any fraud has occurred. The first notice of skimming, harvesting and data breach exploits is likely to be after some fraud has actually occurred (noticing them on a monthly statement or when all the money is gone).

The heavy, secrecy-based security paradigm was further at risk because for ages, it has been well known that the majority of fraud and things like data breach compromises involve insiders (not only does the heavily-secrecy based security paradigm account numbers have to be available ... they have to be available to the group of individuals that are responsible for the majority of the compromises). So a major x9.59 standards objective was to eliminate divulging account numbers as a security and fraud threat (enormous secrecy-based security was no longer required for preventing account fraud).

part of the secrecy vis-a-vis authentication issue was raised in an old thread. the security PAIN taxonomy
P ... privacy (sometimes CAIN, confidentiality, aka secrecy)
A ... authentication
I ... integrity
N ... non-repudiation

and it was raised that to provide "good" security, both "Privacy" and "Authentication" was necessary at equivalent strength. The x9.59 counter-argument was that existing payment environment requires enormous secrecy (privacy) to achieve security (eliminate fraud), in part because of poor authentication (and therefor it is rather trivial to skim or harvest information and perform fraudulent transactions).

THe x9.59 scenario is if there is sufficiently strong authentication, then it is no longer necessary to require secrecy as mechanism for preventing fraudulent transactions (and meet the original X9A10 working group requirement to preserve the integrity of the financial infrastructure for ALL retail payments).

Privacy, confidentiality, and secrecy might be required for other reasons ... but the X9.59 financial standard objective no longer required enormous secrecy-based security paradigm in order to eliminate the most common forms of account fraud.

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

using 3390 mod-9s

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: using 3390 mod-9s
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 21 Mar 2006 21:17:59 -0700

Ron and Jenny Hawkins wrote:
Ted,

It was actually cache that caused the rethink on VTOC and dataset positioning, not volume size. First did this on a 3880-23 (SYSRES), but I'm sure it was just as smart a move on 3880-13.

For HDS it doesn't really matter if you put this stuff at the start, middle, end or track 60000 - it is up to you (but I recommend the front). If this stuff is active it usually lives in cache.

If you have a volume where the VYTOC/VTOXIX/VVDS are busy enough to be a real problem and cache algorithms are not favourable then you just use FlashAcess* to turn it into a set of Solid State files - problem solved.

the other view is that caches were required because careful positioning was no longer sufficient.

starting with os/360 release 11 ... i began very careful stage2 sysgens to place datasets and order pds members to optimize disk arm motion. i would take the stage1 punched output (stage2) deck. i would reorganize the stage2 cards to result in carefully places system data. for a lot of the university workload, i got nearly three times the system thruput (compared to an out-of-the-box sysgen).

a problem was that thruput would degrade nearly in half over six month period as APARs were applied ... and careful PDS member ordering was disturbed (and i would have to rebuild systems).

i gave a number of presentations at share about the effort applied to both release 11 and 14 sysgens ... pointing out that if i could place the vtoc in the middle of the volume ... then i could order high activity system data on both sides of the vtoc (which was one of the highest activity system areas on disk). the next release was combined "15/16" and contained support for specifying vtoc cylinder location (able to place vtoc in the middle of the volume and then carefully order all the rest of the system data).

during that period i also rewrote much of the cp67 paging system, dynamic page allocation and disk i/o (including implementing ordered seek queuing).

following is post of part of presentation i gave at fall '68 share meeting in boston on both some of the os mft/14 work and cp67 work.
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14

much, much later there was a project that did extensive gathering of real-live disk data usage ... it was implemented in vm370 kernel ... but was used to gather data from not only cms interative workloads ... but also from heavy production mvs systems (running in virtual machines). the gathered data was heavily analyzed including a detailed electronic cache model that looked at various infrastructure trade-offs ... like comparing ddevice, controller, channel, and system based caching strategies.
https://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#25 About TLB in lower-level caches

i had also done a report that claimed that disk relative system thruput had declined by a factor of ten over the years (i.e. systems had gotten 50 times faster ... but disk had only gotten 5 times faster). initially the disk division was upset and assigned their modeling/performance group to refute the observation. however, after a couple months they came back with a report that effectively said that i had slightly understated the problem. this was turned around and the disk division used it for presentations at user group meetings about disk considerations for optimal system thruput. recent post mentioning the disk access cache modeling work (along with discussing a bunch of paging modeling work).

one of the strategies was to leverage the drastic increase in the amount of electronic memories for procedures to compensate for the trend in decreasing disk relative system performance (analogous to use of cpu caches to compensate for electronic memory speeds not keeping up with the increase in cpu speeds). misc. past posts mentioning the observations about declining disk relative system performance:
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
https://www.garlic.com/~lynn/98.html#46 The god old days(???)
https://www.garlic.com/~lynn/99.html#4 IBM S/360
https://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
https://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
https://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
https://www.garlic.com/~lynn/2002.html#5 index searching
https://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?

not too long after that, the disk division introduced the 3880-11 and 3880-13 disk caches. these were only 8mbytes ... so didn't make a lot of sense ... it you were running any sort of paging/caching mechanism based on system storage (typical 3081 configuration had 32mbytes ... so system storage tended to be a superset of what was in the controller cache. if it hadn't yet been brought into system memory, then it likely wasn't also in controller cache and would have to be fetched off (real) disk ... at which time it populated both the disk cache and system memory (i've done a number of posts about dynamically switching from "duplicate" and "no duplicate" caching strategies.

the specific thing that showed up in the 3880-13 marketing literature was showing that 3880-13 8mbyte cache obtained a 90precent hit rate in a large system heavy load environment. How, you might ask? The scenario was sequential single record read of a file formated with 10 4k records per 3880 track. The read of the first record on the track would be a miss and automatically transfer the whole track to the 3880-13 (full-track) cache. The next 9 sequential reads would be for records fetched with the record read on the track .. which would be in the cache. one might have been tempted to specify full-track blocking ... in which case the 3880-13 strategy would have gone from 90percent hit rate to zero percent hit rate.

3880-21 and 3880-23 increased the controller cache sizes from 8mbytes to 32mbytes (offering slightly improved chance ... that if you had a system using its own system level caching strategy ... that not every piece of data in the controller cache was simultaneously in main system memory.

by the late 70s, you were starting to see more and more systems heavily leveraging main processor store as caches to compensate for lagging improvements in disk thruput ... for any and all arbitrary system data. one might be tempted to observe that it would be a deficiency in MVS organization that it couldn't use system memory to cache more of its highest referenced disk data areas ... like VTOCs ... and would have to wait until the availability of controller caches to mitigate disk-access related system thruput problems with respect to VTOCs.

another issue is that in the mid-60s there was a trade-off of (disk) i/o thruput and real storage. real storage was severely limited ... and many file system designs from the era would cache very limited amounts of heavily used system data. 360s used CKD search strategies to basically trade-off the relatively abundant/excess i/o capacity against the extremely limited real storage. However, by the late 70s the resource characteristics were reversing the trade-off ... however mvs was still using ckd multi-track searches for vtoc and pds directories (type of information that by this time, other systems were regularly caching in real storage). lots of past postings about being brought into customer shops to look at severe (multi-)system thruput problems being cause by multi-track searches (primarily with VTOCs and PDS directories).
https://www.garlic.com/~lynn/submain.html#dasd

lots of past posts discussing "dup" and "no-dup" (duplicate and no-duplicate) cache strategies (where you have multi-level caching where different levels are similar in aggregate size).
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?
https://www.garlic.com/~lynn/2003o.html#62 1teraflops cell processor possible?
https://www.garlic.com/~lynn/2004g.html#17 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#18 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004g.html#20 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004h.html#19 fast check for binary zeroes in memory
https://www.garlic.com/~lynn/2004i.html#1 Hard disk architecture: are outer cylinders still faster than inner cylinders?
https://www.garlic.com/~lynn/2005c.html#27 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005m.html#28 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer

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

using 3390 mod-9s

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: using 3390 mod-9s
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 22 Mar 2006 08:25:49 -0700

Ron and Jenny Hawkins wrote:
I think that this is too true. Two observations support this:

1) The growing market for Solid State Disk (SSD) prior to the 3880-13 - HDS, EMC and STK (Amdahl?) were all shipping these boxes, and AFAIK at enormous margins.

2) The quick decline in SSD sales after the 3880-13, followed by a fatal blow with the introduction of the 3990-3 (and PCM equivalents).

ref:
https://www.garlic.com/~lynn/2006e.html#45 using 3390 mod-9s

there were also the electronic memory "1655" that emulated 2305, several hundred were made available for internal installations.

i was somewhat caught by the explanation for the vendor's 1655s. supposedly the internal memory manufacturing process had been perfected so that there was very high yield (that and/or the internal mental process was that any chips that failed test were automatically scrapped). the vendor doing the 1655 had quite a bit of memory chips that failed test. however, the requirements for electronic disk operation was totally different than the requirements for processor memory operation. glitches that couldn't be tolerated in processor memory could be used in electronic disk application where the embedded device controller could compensate for numerous types of memory chip glitches ... and take advantage of chips that were otherwise heading for scrap.

another thing that happened in the 80s was the market uptake of relational databases. the original relational/sql was system/r that had been done in the 70s at sjr. misc. past posts on relational, sql, system/r, etc
https://www.garlic.com/~lynn/submain.html#systemr

during this period there were ongoing arguments between the "60s" database people at Santa Teresa (bldg. 90) and the system/r people at sjr (bldg. 28).

sort of the summary was STL forces claimed that relational substantially increased the disk space requirements (indexes typically doubled the required physical disk space) and significantly increased the i/o (working the way thru indexes to get to a specific record). The relational forces claimed that exposing record pointers as database abstraction significantly increased the people manual effort in dealing with databases. the relational abstraction eliminated people having to deal directly with record pointer constructs ... and significantly reduced people effort for managing and operating a database.

by the early 80s, hardware was becoming significantly less expensive, people were becoming more expensive (and both electronic memory and disk space was becoming significantly more plentiful). Inexpensive, plentiful disk space muted the argument about doubling disk space for the relational indexes (trade-off between hardware cost and people cost). Furthermore, increases in electronic storage allowed significant amount of relational indexes to be cached ... mitigating the I/O performance penalty for using indexes vis-a-vis direct record pointers (this was independent of additional electronic storage for general caching that would improve overall thruput of all kinds of databases).

for some topic drift, reference in previous post about simulation and modeling of various paging and caching ... discussed in this post
https://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches

vs/repack was used by some number of corporate software products ... not only in helping with program organization in the transition from real memory operation to virtual memory operation .... but also just generalized program optimization. One such operation that made use vs/repack was the IMS organization in STL.

for additional drift ... when my wife did her stint in POK, in charge of loosely-coupled architecture ... she had come up with peer-coupled shared data architecture (sort of the foundation for lot of multi-CEC operation and today's parallel sysplex). However, at the time, there was a lot of corporate in-fighting. the communication division wanted SNA-based communication not only for all terminal management but also for all processor-to-processor operation. One of the few organizations at the time that picked up on her architecture was the group doing IMS hot-standby.
https://www.garlic.com/~lynn/submain.html#shareddata

sci.crypt

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sci.crypt
Newsgroups: alt.folklore.computers
Date: Wed, 22 Mar 2006 08:31:56 -0700

greymaus writes:
Funny thing happened today.. I download messages with slrnpull, and get some from sci.crypt, to sometimes try to keep up with that subject. Now, today, there were thousands of new messages (usually, 20-30, its an serious newsgroup), so I start to check through them and find that most consist of paragraphs of semi-sensible text, but in a bizarre mixup.. I know that there are programs that do this, but this is the biggest attack like this I've seen.

there was a posting in the newsgroup late last night summarizing it as a denial-of-service attack and some of the countermeasures being taken.

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

previous, next, index - home