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?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DMV systems?
Date: Tue, 27 Dec 2005 13:55:23 -0700
Newsgroups: bit.listserv.ibm-main

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:
http://www.garlic.com/~lynn/2005u.html#61 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
http://www.obsolyte.com/sun380/

sparc and i86 machines support ... this has minor reference to
both platforms
http://www.sun.com/software/security/securitycert/

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
http://lists.freebsd.org/pipermail/freebsd-smp/2003-July/000247.html

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
http://www.garlic.com/~lynn/submain.html#shareddata

... 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:
http://www.scizzl.com/

one of the reasons that we round up producing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

that was suppose to use fcs for scale-up ... minor reference
http://www.garlic.com/~lynn/95.html#13

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
http://www.garlic.com/~lynn/subtopic.html#801

was attempting to drastically simplify hardware after the disastrous
experience of future systems
http://www.garlic.com/~lynn/submain.html#futuresys

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
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001b.html#39 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
http://www.garlic.com/~lynn/2001f.html#11 Climate, US, Japan & supers query
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002e.html#32 What goes into a 3090?
http://www.garlic.com/~lynn/2002j.html#78 Future interconnects
http://www.garlic.com/~lynn/2002l.html#52 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2003h.html#0 Escon vs Ficon Cost
http://www.garlic.com/~lynn/2003j.html#65 Cost of Message Passing ?
http://www.garlic.com/~lynn/2003p.html#1 An entirely new proprietary hardware strategy
http://www.garlic.com/~lynn/2004d.html#68 bits, bytes, half-duplex, dual-simplex, etc
http://www.garlic.com/~lynn/2004p.html#29 FW: Is FICON good enough, or is it the only choice we get?
http://www.garlic.com/~lynn/2005.html#38 something like a CTC on a PC
http://www.garlic.com/~lynn/2005.html#50 something like a CTC on a PC
http://www.garlic.com/~lynn/2005d.html#20 shared memory programming on distributed memory model?
http://www.garlic.com/~lynn/2005e.html#12 Device and channel
http://www.garlic.com/~lynn/2005h.html#7 IBM 360 channel assignments
http://www.garlic.com/~lynn/2005l.html#26 ESCON to FICON conversion
http://www.garlic.com/~lynn/2005m.html#46 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#55 54 Processors?
http://www.garlic.com/~lynn/2005n.html#6 Cache coherency protocols: Write-update versus write-invalidate
http://www.garlic.com/~lynn/2005n.html#37 What was new&important in computer architecture 10 years ago ?
http://www.garlic.com/~lynn/2005r.html#43 Numa-Q Information

Is Mondex secure?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is Mondex secure?
Newsgroups: uk.legal,sci.crypt
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 | http://www.garlic.com/~lynn/

ABN Tape - Found

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ABN Tape - Found
Date: Wed, 28 Dec 2005 14:22:08 -0700
Newsgroups: bit.listserv.ibm-main

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
http://www.garlic.com/~lynn/subintegrity.html#fraud

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
http://www.garlic.com/~lynn/subintegrity.html#harvest

the work on the original payment gateway for e-commerce involved hiding
account number transactions during transit on the internet using SSL
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

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
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

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
http://www.garlic.com/~lynn/aadsm21.htm#41 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies

ABN Tape - Found

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ABN Tape - Found
Newsgroups: bit.listserv.ibm-main
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 ...
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

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
http://www.garlic.com/~lynn/subpubkey.html#signature

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
http://www.garlic.com/~lynn/subintegrity.html#secret

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.
http://www.garlic.com/~lynn/subintegrity.html#harvest

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
http://www.garlic.com/~lynn/2005v.html#2 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
http://www.garlic.com/~lynn/index.html#glosnote

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, aggreeing, 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:
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman  schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2004h.html#47 very basic quextions: public key encryption
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
http://www.garlic.com/~lynn/2005e.html#43 Actual difference between RSA public and private keys?
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005m.html#27 how do i encrypt outgoing email
http://www.garlic.com/~lynn/2005m.html#45 Digital ID
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005n.html#39 Uploading to Asimov
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#17 Smart Cards?
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005p.html#33 Digital Singatures question
http://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
http://www.garlic.com/~lynn/2005q.html#29 IPSEC wireless router ?
http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card
http://www.garlic.com/~lynn/2005s.html#43 P2P Authentication
http://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
http://www.garlic.com/~lynn/2005t.html#32 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#52 PGP Lame question

ABN Tape - Found

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ABN Tape - Found
Date: Wed, 28 Dec 2005 23:24:43 -0700
Newsgroups: bit.listserv.ibm-main

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
http://www.crime-research.org/news/28.12.2005/1723/

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
http://www.garlic.com/~lynn/2001h.html#61

when we were originally talking about deploying what is now called
e-commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

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
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
http://www.garlic.com/~lynn/aadsm21.htm#34 X.509 / PKI, PGP, and IBE Secure Email Technologies

famous literature

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: famous literature
Newsgroups: sci.crypt
Date: Thu, 29 Dec 2005 00:57:02 -0700

"jay25dec@gmail.com" 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.
http://www.garlic.com/~lynn/aadsm18.htm#12 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm20.htm#13 ID "theft" -- so what?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman  schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
http://www.garlic.com/~lynn/2003b.html#30 Public key encryption
http://www.garlic.com/~lynn/2003b.html#64 Storing digital IDs on token for use with Outlook
http://www.garlic.com/~lynn/2003j.html#53 public key confusion
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005j.html#0 private key encryption - doubts
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card
http://www.garlic.com/~lynn/2005s.html#51 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2005t.html#52 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) :
http://www.garlic.com/~lynn/aadsm21.htm#26 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#27 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#28 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#29 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#30 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#31 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#33 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#34 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#40 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm21.htm#41 X.509 / PKI, PGP, and IBE Secure Email Technologies

general collected postings on certificate-less public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless

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

DMV systems?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DMV systems?
Date: Fri, 30 Dec 2005 15:40:48 -0700
Newsgroups: bit.listserv.ibm-main

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
http://www.garlic.com/~lynn/subtopic.html#disk

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
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.