List of Archived Posts

2005 Newsgroup Postings (12/27 - 12/31)

DMV systems?
Is Mondex secure?
ABN Tape - Found
ABN Tape - Found
ABN Tape - Found
famous literature
DMV systems?
(at least smp) fc5 kernels after 1788 have excessive kernel overhead

DMV systems?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <>
Subject: Re: DMV systems?
Date: Tue, 27 Dec 2005 13:55:23 -0700
as400 wrote:
Well, thanks for this information..I really appreciate it...

And lastly, can Solaris (UNIX) be ran on a Mainframe or not? Because you said:

" would say that most of the systems were mainframe based (IBM and Unisys) and non-Unix based OS's:"

Please advise.

what you mean by mainframe?

previous thread ref: DMV systems?

i think sun talks about running on mainframe class machine.

original sun workstations was 68k before they produced risc sparc ... minor reference to 68020/68030 machines

sparc and i86 machines support ... this has minor reference to both platforms

i think that unisys logo'ed sequent's machine for a time ... as another "mainframe class" machine.

this minor reference has unisys starting logo'ing sequent machines even before the sequent NUMA-Q machines

in the 80s we participated in both fcs and sci standards activity. fci standards was somewhat the outgrowth of LLNL's work with a non-blocking copper-wire switch remapped to 1gbit/sec fiber-optics. SCI was some work out of SLAC to take fiber-optics and use it for asynchronous bus.

there had been this fiber-optic technology that had been kicking around pok since the 70s that was having hard time getting out. part of it appeared to be around the battle with communication division on who "owned" stuff that crossed the wall surrounding the glass-house. my wife was in the middle of this since she had done a stint in POK in charge of loosely-coupled architecture ... where she produced peer-coupled shared data architecture

... which didn't see much uptake until parallel sysplex ... except for some work hear-and-there ... like IMS hot-standby.

in any case, supposedly the jurisdictional resolution was that CPD's terminal controller paradigm (sna) supposedly owned anything that crossed the boundary of the glass house walls.

one of the austin interconnect engineers took the pok fiber technology ... and tweaked it here and there ... getting about ten percent higher thruput (220mbits/sec rather than 200mbits/sec for escon) and used optical drivers that were at least an order of magnitude less expensive (than escon). this was announced on rs/6000 as sla (serial link adapter).

he then wanted to go on and do an 800 mbit version of sla. we convinced him to move to working on FCS ... where he became editor of the FCS standards document. part of this was that rs/6000 was much more into the market segment that highly prized interoperability ... and it was difficult to have a lot of interoperability with proprietary interconnect. an issue with FCS was basically a fully asynchronous, full-duplex operation. Later there were some horrible battles when some POK channel engineers became involved with FCS and tried to do some unnatural acts layering mainframe half-duplex channel paradigm on an underlying infrastructure that is asynchronous full-duplex (or dual simplex as i periodically refer to it) ... which i believe may now be referred to as ficon.

so in parallel with all this was the "SLAC" effort to use similar fiber-optic technology for asynchronous bus operation rather than asynchronous link/io operation. sci reference:

one of the reasons that we round up producing ha/cmp

that was suppose to use fcs for scale-up ... minor reference

was that RIOS chips didn't support cache coherency ... i.e. and a major SCI effort was an asynchronous memory bus implementation.

for a little more digression ... i've periodically asserted that much of the 801/risc/romp/rios genre

was attempting to drastically simplify hardware after the disastrous experience of future systems

the other characteristic was that it seemed that the 801/risc had a scalded cat reation to the enormous multiprocessor cache consistency overhead exacted by the strong memory consistency paradigm of the highend mainframe 370s. not only did 801/risc go to the opposite extreme of future systems (regarding hardware complexity) ... but also the opposite extreme from highend 370s with regard to (multiprocessor) cache consistency. as a result, it was essentially impossible to build scale-up multiprocessor system with SCI and rios chips. essentially, the only scaleup fall-back was purely loosely-coupled (aka cluster) operatiion with high-speed (i/o) interconnect.

convex built 128-way exemplar with dual-processor board HP/RISC chips. SCI asynchronous memory operation standard allows for 64 memory ports. convex had dual-processor shared cache boards ... and 64 such boards allowed for maximum 128-way configuration.

both sequent and data general did something similar using 64-port SCI ... except they used intel quad-processor boards (four processors sharing cache that then used 64-port SCI to interface to memory).

this was the 256 processor Sequent numa-q machine that IBM inherited when they bought sequent. it was also the machine that unisys was logo'ing as a mainframe-class machine (but running a unix-derived operating system).

in this time-frame a separate, somewhat parallel effort was started to produce power/pc (as opposed to "power" which was the marketing name for the rios chipset) ... which would have support for cache consistency (and some number of other differences from original 801/risc/romp/rios/power).

misc. past fcs, sci, fiber, postings Does the word "mainframe" still have a meaning? John Mashey's greatest hits what makes a cpu fast Climate, US, Japan & supers query ESCON Data Transfer Rate What goes into a 3090? Future interconnects Itanium2 performance data from SGI Escon vs Ficon Cost Cost of Message Passing ? An entirely new proprietary hardware strategy bits, bytes, half-duplex, dual-simplex, etc FW: Is FICON good enough, or is it the only choice we get? something like a CTC on a PC something like a CTC on a PC shared memory programming on distributed memory model? Device and channel IBM 360 channel assignments ESCON to FICON conversion IBM's mini computers--lack thereof 54 Processors? Cache coherency protocols: Write-update versus write-invalidate What was new&important in computer architecture 10 years ago ? Numa-Q Information

Is Mondex secure?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <>
Subject: Re: Is Mondex secure?
Date: Tue, 27 Dec 2005 21:57:25 -0700
Tim Smith writes:
I don't know what these "Mondex" cards use, but I wonder if one could do a system like this where it is possible for the card to pre-compute much of the next transaction, before it exchanges anything with the other side?

Then a card with, say, $200 stored in it could pre-compute part of, say, a $5 transaction, to be used in situations like paying a mass transit fare. It would pay the fare from the pre-computed transaction, and then pre-compute another $5 transaction for use in the next small payment situation.

Result: the occasional small purchase would be fast. You'd only have to wait if you did a big transaction, or did small transactions back to back.

The pre-computed transaction would be less secure, but only $5 would be at risk.

transit tends to have both contactless as well as time-constraint (with contactless operation helping meet time-constraint). nominal contactless draw their operational power from RF energy in the air near reader (besides using RF for communication).

there were some mondex people at transit meeting in the mid to late 90s. they proposed mondex card in wireless sleeves and 15ft tunnels approaching transit turnstyle. if people walked slowly thru the tunnel, by the time they reached the turnstyle the communication would have completed. i don't remember whether they required the wireless sleaves to provide battery power to the mondex card ... or whether they were trying to power from RF energy in the tunnel. I also don't know if they proposed limiting one person at a time in a tunnel.

for some drift, starting 4-6 years ago, newer generation chips could handle contactless (power derived from RF energy near reader) doing ECC public key operations within transit time requirements.

for some of the non-ecc public key infrastructures ... elapsed time in contact cards has been achieved by driving a much larger number of circuits in parallel (elapsed time somewhat inversely proportional to peak power). you might get the necessary level of power draw with contact cards ... but it was much harder to provide that much peak power for contactless cards powered with RF energy thru the air.

some of the transit chip systems use symmetric master key contained in armored, secure turnstyle readers. they read some sort of chip serial and value, compute derived symmetric key based on combination of system master key and the chip serial, decrypt the value read, update the value, re-encrypt and rewrite the chip with the new value.

within past two years, i had transit chipcard in one of the systems go from something like positive $10 balance to negative $5 balance between the time i left transit system and the next time I tried to enter the transit system. somewhere in the time outside the transit system, the chip experienced some sort of glitch. not only did the glitch cause the card to loose value ... but the balance value went negative (something the transit people weren't able to explain).

Anne & Lynn Wheeler |

ABN Tape - Found

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <>
Subject: Re: ABN Tape - Found
Date: Wed, 28 Dec 2005 14:22:08 -0700
Jeffrey.Deaver@ibm-main.lst wrote:
Also remember that we now, unfortunately, have to protect data from possible internal threats as well. I read of one recent event where an ex-employee was attempting to extort money from his old employer by holding backup tapes with data on them and threatening to let it all go on the internet. So building your encryption systems such that the keys are either hidden from or split amongst multiple employees is important.

for a long time, insiders have been considered the major source of fraud. in the early 80s, sytems were evolving that required more than one person for performing an operation ... and one of the constant issues then involved countermeasures for collusion involving multiple authorized parties.

the internet has somewhat defocused attention from the major source of fraud (insiders) with the possibility that attacks might have originated by outsiders.

however, within the last two years or so, there was a study published finding at least 70percent of the data breach incidents (around identity theft) involved insiders.

misc. collected posts on subject of fraud, risks, vulnerabilities, etc

one of the issues that we faced in x9a10 working group ... that had been given the requirement to preserve the integrity of the financial infrastructure for all retail transactions ... was how to address the issue.

one of the major issues with retail transactions is the account number leakage resulting in fraudulent transactions

the work on the original payment gateway for e-commerce involved hiding account number transactions during transit on the internet using SSL

however, it was recognized that account numbers were required to be available (and therefor exposed) in a sizeable number of business processes (not just the original transaction). the conclusion was soemwhat that even if you buried the planet under miles of encryption, it still wouldn't prevent account number leakage.

the resulting x9a10 standard work for x9.59 transactions

resulted in following standard specification:

1) x9.59 transactions are strongly authenticated (using dynamic data) 2) information (including account number) used in x9.59 transactions could not be used in non-authenticated, non-x9.59 transactions.

a major threat in payment card retail transactions has been the account numbere leakage/harvesting and then using the information in a form of replay attack (using the same information to perform a fraudulent transaction). the replay attack vulnerability effectively forces the account number into being treated as a form of shared-secret (if it is known than it is possible to perform a fraudulent operation, akin to stealing passwords).

the x9.59 standard includes replay attack countermeasure ... none of the information from an x9.59 transactions can be harvested and then turned around to be used in fraudulent transaction. this eliminates knowledge of the account number as a vulnerability. evesdropping, data breaches, and/or havesting attacks involving (x9.59) account numbers no longer result in fraudulent transactions (i.e. no longer necessary to treat x9.59 account numbers as if they were shared-secrets/passwords)

this in turn gets back to the assertion about non-x9.59 account transactions, that even burying the whole planet under miles of encryption is not sufficient to prevent account number leakage ... in part because of the large number of different business processes requiring the account number (as well as the insider vulnerability issue).

for a little drift, recent thread regarding various SSL vulnerability issues X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies

ABN Tape - Found

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <>
Subject: Re: ABN Tape - Found
Date: 28 Dec 2005 21:56:15 -0800
Hal Merritt wrote:
Here is compelling evidence why auditors should never be permitted to make security 'requirements'. Never. Only see that due diligence is done.

in addition to working on x9.59 financial industry retail payment standard ...

was recently one of the co-authors of the financial industry x9.99 privacy impact assesement (PIA) standard ... basically defining a standard for auditing infrastructure. part of the challenge was to define an assesement standard that could accomodate a variety of different jurisdictional regulatory and legislative requirements. Part of it was keeping in mind that possibility of promoting x9.99 to international/ISO standard ... so the breadth and range of regulatory and legislative differences wouldn't just involve US jurisdictions ... but might span the whole world. the other issue was to attempt to avoid having PIA standard becoming obsolute not only with multi-jurisdiction but also changes that might occur over time.

we were asked to come in and do some work on the cal. state electronic signature legislation

and then later the fed. electronic signature legislation. one of the participating industry groups was also working on various privacy issues and had done a survey of the primary driving factors behind privacy regulation and legislation. they found one of the primary driving factors behind privacy regulation and legislation was id-theft.

for some topic drift ... there has been an attempt to differentiate id-theft where a crook harvests account numbers and uses the information for fraudulent transactions against existing accounts ... from identification theft where somebody uses personal information for opening new accounts.

the previously mentioned work on x9.59 was to use strong authentication and business rules to drastically reduce the vulnerability associated with account numbers.

there is a security model called PAIN

P - privacy (or confidentiality)
A - authentication
I - integrity
N - non-repudiation

in the case of account fraud, frequently knowledge from a previous transaction is sufficient to enable a future fraudulent transaction. This can somewhat be viewed as a from of replay attack. Account numbers effectively then have to be treated as a form of secret or password

a lot of attention has been focused on using privacy (hiding and/or encryption) as a countermeasure to account fraud ... by attempting to drastically limit means for obtaining knowledge of account numbers. the x9a10 standards work observed that the account number is needed in so many business processes that it practically impossible to prevent account number information leakage.

as a result, the x9.59 approach was to use strong authentication (instead of privacy) as a countermeasure to account fraud (knowledge of previous transactions and/or account numbers is no longer sufficient for performing fraudulent transactions). previous post ABN Tape - Found

minor digression, as part of doing the work on x9.99 PIA standard, I attempted to pull together a privacy merged taxonomy and glossary, drawing heavily on earlier work on payments, financial, security, etc

for even more topic drift ... the electronic signature legislation differed significantly from earlier work on digital signature legislation. there was some conjunction that semantic confusion arose because the term human signature and digital signature both contain the word signature. the issue is that digital signature business process is used for authentication (and integrity). human signature (and electornic signature) attempts to address the issue of human reading, understanding, agreeing, approvaing, and/or authorizing.

I've actually explored in some number of postings the issue of creating systemic risk when there is an attempt to use digital signatures for both authentication purposes and also confused with human signature.

some number of postings on dual-use attacks and/or what does a digital signature represent: dual-use digital signature vulnerability dual-use digital signature vulnerability dual-use digital signature vulnerability dual-use digital signature vulnerability dual-use digital signature vulnerability two-factor authentication problems massive data theft at MasterCard processor massive data theft at MasterCard processor the limits of crypto and authentication Is there any future for smartcards? Contactless payments and the security challenges Does Diffie-Hellman schema belong to Public Key schema family? very basic quextions: public key encryption New Method for Authenticated Public Key Exchange without Digital Certificates New Method for Authenticated Public Key Exchange without Digital Certificates Using smart cards for signing and authorization in applets [Lit.] Buffer overruns Public/Private key pair protection on Windows Actual difference between RSA public and private keys? Maximum RAM and ROM for smartcards Signing and bundling data using certificates PKI Crypto and VSAM RLS More Phishing scams, still no SSL being used Creating certs for others (without their private keys) Question about authentication protocols Course 2821; how this will help for CISSP exam ? S/MIME Certificates from External CA how do i encrypt outgoing email Digital ID X509 digital certificate for offline solution Uploading to Asimov The Chinese MD5 attack X509 digital certificate for offline solution Smart Cards? Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc Digital Singatures question IPSEC with non-domain Server Logon with Digital Siganture (PKI/OCES - or what else they're called) IPSEC wireless router ? feasibility of certificate based login (PKI) w/o real smart card P2P Authentication TTP and KCM RSA SecurID product PGP Lame question

ABN Tape - Found

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <>
Subject: Re: ABN Tape - Found
Date: Wed, 28 Dec 2005 23:24:43 -0700
Hal Merritt wrote:
Here is compelling evidence why auditors should never be permitted to make security 'requirements'. Never. Only see that due diligence is done.

recent news item on part of the issue

Merchants unsecure, poll

from above:
A poll released by Protegrity Corporation, a provider of data security management solutions, found that Payment Card Industry Data Security Standard (PCI) compliance is severely lagging at merchants of all levels despite a growing Internet fraud rate.

... snip ...

and discussion of a different part of the issue in this post that i frequently refer to as security proportional to risk

when we were originally talking about deploying what is now called e-commerce

we discussed a number of requirements for operation of web merchants ... including things like requiring FBI background checks on all merchant and merchant employees. a few past posts mentioning the subject E-commerce security???? Does "Strong Security" Mean Anything? Some thoughts on high-assurance certificates X.509 / PKI, PGP, and IBE Secure Email Technologies

famous literature

From: Anne & Lynn Wheeler <>
Subject: Re: famous literature
Newsgroups: sci.crypt
Date: Thu, 29 Dec 2005 00:57:02 -0700
"" writes:
hi this was cool stuff but if u know something about digital certificates i want to know how to extract the private key from certificate which is already in certificate store anywhere in personal or trusted publishers

comment about asymmetric key technology and some discussion of public/private key business process, digital signature business process, certification authority and digital certificate business processes. dual-use digital signature vulnerability ID "theft" -- so what? Does Diffie-Hellman schema belong to Public Key schema family? Two questions on HMACs and hashing Public key encryption Storing digital IDs on token for use with Outlook public key confusion TLS-certificates and interoperability-issues sendmail/Exchange/postfix private key encryption - doubts public key authentication feasibility of certificate based login (PKI) w/o real smart card phishing web sites using self-signed certs PGP Lame question

note the comments about public/private key business process where one key (of a asymmetric key pair) is identified as public and made generally/widely available ... the other key is identified as private and kept confidential and never divulged.

digital certificates provide binding between some information and a public key ... somewhat targeted as first time communication between strangers (the letters of credit/introduction paradigm from sailing ship days).

recent thread with discussion of some digital certificate (PKI) based and certificate-less (public key) infrastructures (some common features as well as differences) : X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies X.509 / PKI, PGP, and IBE Secure Email Technologies

general collected postings on certificate-less public key operation

Anne & Lynn Wheeler |

DMV systems?

From: Anne & Lynn Wheeler <>
Subject: Re: DMV systems?
Date: Fri, 30 Dec 2005 15:40:48 -0700
Bruce Black wrote:
One of my jobs at Univac/RCA was maintaining the error recovery routines for I/O devices, incluing the RACE. Luckily, the system was so flakey that it was easy to generate errors to test with. Unluckily, there was little you could do to recover from a card that got crunched going down the raceway.

i had a similar but different experience in the dasd engineering lab (bldg. 14) and dasd product test lab (bldg. 15). they had all these (dasd) "test cells" that periodically needed connection to mainframe channel/processor for various testing. note that test cells are not directly related to datacell/2321, test cells were security operation ... they were approx. 6-to-7ft cubes, steel wire mesh cages with special combination lock door (that housed equipment in development), located inside a secure machine room, inside a secure bldg, etc.

they had tried running mainframe under an operating system ... but found that MTBF for MVS was on the order of 15 minutes (i.e. single dasd testcell could generate more errors ... including all sorts of architecture violations ... in 15 minutes than most shops would experience in years).

as a result, they had to resort to doing all testing with dedicated, stand-alone processor time on a testcell by testcell basis.

as a fun exercise, i undertook to rewrite i/o supervisor (including error recovery and recording) so they could concurrently test multiple testcells in normal operating system environment (w/o having to take all the machines down for stand-alone, dedicated machine time) ... which drastically increased productivity (i/o supervisor was bullet proof and never failed)

misc. collected postings about bldg. 14 and 15 work

(at least smp) fc5 kernels after 1788 have excessive kernel overhead

From: Anne & Lynn Wheeler <>
Date: Fri, 30 Dec 2005 17:30:32 -0700
Subject: (at least smp) fc5 kernels after 1788 have excessive kernel overhead
Newsgroup: fedora-test-list
dell poweredge 2400 dual 1ghz processors. (at least smp) kernels after 1788 have enormous kernel processor overhead.

applications that are i/o bound on kernel 1788 or earlier ... are severely degraded on kernels after 1788 with 100% processor utilization .... almost all of it in kernel. when applications are idle ... the processor use goes idle (aka it isn't some sort of background looping process ... but seems to be some sort extra kernel overhead). an enet transfer that normally sustains 2.5mbytes/sec with maybe 20 percent cpu utilization only does 600kbytes/sec with 100precent cpu, almost all in the kernel (apporx. 20 times more processor executed per byte transferred)

this is machine that i had problems with scsi i/o hanging after fc4 smp kernel 1278 (non-smp kernel didn't have scsi i/o hang problem). smp kernel hanging problem cleared up with fresh fc5 install.

previous, next index - home