List of Archived Posts

2004 Newsgroup Postings (08/09 - 08/21)

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

Authenticated Public Key Exchange without Digital Certificates?

New Method for Authenticated Public Key Exchange without Digital Certificates

Authenticated Public Key Exchange without Digital Certificates?

Authenticated Public Key Exchange without Digital Certificates?

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

New Method for Authenticated Public Key Exchange without Digital Certificates

Smart card Authentification

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

Wars against bad things

Wars against bad things

Wars against bad things

The Reincarnation of Virtual Machines

Methods of payment

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

Wars against bad things

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

Wars against bad things

Losing colonies

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father

Vintage computers are better than modern crap !

Vintage computers are better than modern crap !

Many engineers lack even a four-year degree

Many engineers lack even a four-year degree

Vintage computers are better than modern crap !

A quote from Crypto-Gram

Vintage computers are better than modern crap !

A quote from Crypto-Gram

A quote from Crypto-Gram

Vintage computers are better than modern crap !

Vintage computers are better than modern crap !

Methods of payment

Many engineers lack even a four-year degree

Vintage computers are better than modern crap !

Vintage computers are better than modern crap !

Methods of payment

Methods of payment

A quote from Crypto-Gram

Vintage computers are better than modern crap !

Vintage computers are better than modern crap !

Losing colonies

Losing colonies

SSL question 128bit, 1024,2048 key lengths?

Looking for pointers to get started with e-signature

Losing colonies

history books on the development of capacity planning (SMF and RMF)

Losing colonies

history books on the development of capacity planning (SMF and RMF)

RFCs that reference MD5

Monster(ous) sig (was Re: Vintage computers are better

Vintage computers are better than modern crap !

New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 07:42:58 -0600

amicrypt@amishare.com (Allen Pulsifer) writes:

Fourth, if an attacker does happen to miss a communication using the
public keys, the parties might perceive this simply as a communication
failure.  It does not necessarily mean the attacker's subterfuge will
be detected, as you seem to assume.

sorry, i was making short-hand reference to the chance also that some
sort of key validation information come via some non-standard text
route ... or out-of-band process; not only does the MITM need to
maintain logical consistency of the actual text communication
with the substituted keys ... but also being able to manage all
other communication that might indicate a key substitution had
taken place ....

• keys eventually exchanged out of band
• key fingerprint eventually transmitted out of band
• transmission of key fingerprint in band ... but difficult
  for MTIM to detect ... non-standard encoding for
  key fingerprint .. key fingerprint encoded in audio transmission,
  key fingerprint encoded in graphics

i've been to websites that have graphic obfuscating technigues as
countermeasures for automated web harvesters ... some text is
presented in an obfuscated graphics and a request for the human to
type in the repeated text.

however, w/o a great deal of trouble, you have countermeasures to key
substitution that can defeat most automated technigues and increase
the effort for human-based operations.

so the majority of the situations we are talking about ... are running
extremely weakly secured machines. the people that would have strongly
secured machines ... would also be using stronger out-of-band
processes for key exchange already.

so for the remaining set ... that would tend to be sloppy about their
key exchange technologies which might be susceptible to key
substitution, they would also tend to have relatively insecure
machines.

so the assertion is that for this set, the incremental cost for
catching even relatively trivial key fingerprint obfuscation
techniques would be more expensive than direct attack on their
end-point machines ... having a virus/trojan horse installed so they
control the end-point machines. I've seen some reference yesterday
stating that the number of zombie machines out there now is on the
order of 40 million.

this is somewhat security proportional to risk ... as well as the
attacker typically goes for the weakest link. i'm not suggesting that
trivial obfuscation techniques aren't impossible for an attacker to
deal with ... just that the cost of dealing with even trivial
obfuscation will make other targets/mechanisms more attractive.  Say,
in addition ... i publish a picture on my website where i'm standing
beside a sign of my key fingerprint. I'm no longer limited to the
text-based email environment from the 60s.

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

New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 08:00:07 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

A graphologist also can only testify whether a handwritten name on a
piece of paper stems from a particular person and nothing
more. What's the difference from the case of digital signature? I
don't yet see any. The motivation of the said German law is to
render the two cases equivalent in the legal sense, thus enabling
better practical exploitation of modern communication technologies
(in particular for e-commerce, though that law as such certainly has
general applications).

the ca & fed electronic signature laws actually had some contract
lawyers involved .... the issue isn't whether or not the signatures
are forgeable (either electronic or digital) ... the issue is whether
there was clear intent as to agrees, approves, and/or authorizes what
is being signed.

digital signatures weren't designed to be legal signatures ...
digital signatures were designed to provide strong authentication and
indicate whether or not the bits have been modified.

the important part in legal signatures isn't whether or not the
person's signatures can be forged ... even large X is acceptable as
legal signature ... as long as human intent was demonstrated.

The issue isn't whether or not a digital signature can be considered a
legal signature ... and/or whether it can be easier to forge or not
forge a digital signature. The issue is does the application of a
digital signature show intent that the human agrees, approves, and/or
authorizes the contents.

digital signatures were designed for strong authentication ... and
there are lots of protocols floating around which use digital
signatures in just that way ... where digital signatures are applied
to stuff where the human has never seen the bits. If there is a
convential use of a human's private key for applying digital
signatures to things that a human has never read ... then you can be
compromising the use of the same private key for applying digital
signatures to things which are to be treated as legal signatures.

doesn't really have a whole lot to do with technology ... it has to do
with expectations ... and does a human believe that every time some
specific thing happens does it involve them demonstrating intent,
agrees, approves, and/or authorizes.

it is one of the reasons for the point-of-sale and the EU FINREAD
standard treating the device generating a digital signature as an
authentication event and that there is a separate sequence/process
used for demonstrating intent, agrees, approves, and/or authorizes.


The act of
pressing the YES button is trivially comparable to a person writing an
X. It isn't an issue of the form that it takes ... it is an issue that
it requires a human to demonstrate intent, agrees, approves, and/or authorizes.

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

Authenticated Public Key Exchange without Digital Certificates?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authenticated Public Key Exchange without Digital Certificates?
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 08:45:06 -0600

Guy Macon <http://www.guymacon.com> writes:

I do not share your confidence that "it is practically impossible for
the private key to ever leave the hardware token."  If I have physical
access to your hardware token, it is very likely that I can extract
anything that you have inside of it with an Atomic Force Microscope
- technology that can be found in any CD replication plant.  With an
AFM, I can measure electrostatic, magnetic, capillary, ionic repulsion
and Van der Waals forces on the surface of the die, scanning back and
forth and mapping the bits of information.

http://www.cl.cam.ac.uk/~rnc1/descrack/ documents the extracting of a
3DES key from an IBM 4758. Do you know of a hardware token that is
believed to be more secure than an IBM 4758?

To have a secure key, you must have a physically secure location where
the key is stored.  An EAL4-high hardware token won't help you if the
attacker has physical access.

absolutely ... there is a 5-6 year old thread on this ... all i've got
to do is make the security proporitional to the risk.

so the original story was i wanted to take a $500 (at the time)
milspec part, cost reduce it so that it was both more secure and still
cost effective to deploy on all magstripe cards ... and all i needed
was that it would

a) cost the attacker more to extract the key than they could ever
benefit from having the key

b) take the attacker longer to extract the key than it typically takes
to process a lost/stolen card report and deactivate the registered
public key

some number of chipcards have had infrastructure shared-secret keys
...  and therefor extracting the shared-secret key places the whole
infrastructure under attack.

this was targeted at being deployed in the magstripe enhancement
scenario ... i had to make it cheap enuf that it was deployable in
magstripe ... and still be more secure than the original $500
milspec part.

so the issue is that targeting it for an online authentication mode
paradigm ... so we start with the card being lost/stolen and the clock
starts ticking.

first issue is does the attacker get the key extracted before the
public key has been deactivated in the account record ...  and
therefor having the private key is of no value.

second issue is even if the attacker marginally wins the race
and is able to possibly execute a single $100 atm financial
transaction before the public key is deactivated ... would the
attacking organization believe it is worthwhile to them.

so in the security world you have threats and countermeasures and is
the possible cost of the attack worth the possible return.

in the financial world you have risks and risk management/mitigation.

risk mitigation is not having any sort of infrastructure shared-secret
... the scope of any compromise is strictly bounded w/o impacting
the whole infrastructure

risk mitigation is having a something you have authentication device
that is relatively difficult to compromise/counterfeit.

risk mitigation is online authentication mode infrastructure ...
so that as soon as device is reported lost/stolen ... all transactions
for that specific public key is immediately deactivated.

risk mitigation is online authentication mode infrastructure ...
where it is possible to make the bounds on the possible total value of
active transactions strictly proportional to the assurance level of
the specific device ... where the assurance of any specific device
includes whether it is lost or stolen and/or whether there is
real-time knowledge of emerging technology exploits that will
immediately downgrade the assurance level of subject devices in real
time (possibly change from a $100k credit limit to a $1k credit limit
in real time based on all real time knowledge about assurance level of
the specific devices and/or classes of devices).

one i had to select the different chip pieces that met a broad range
of cost and benefit requirements ... and architect an infrastructure
where there was real-time control over the risk (financial exposure)
proportional to assurance. For instance, having a card lost/stolen
significantly lowered its assurance. Also architect an infrastructure
that eliminated systemic risks .... things like system-wide
infrastructure shared-secrets that would put the whole infrastructure
at risk

note that the chip chosen for $300 credit limit accounts ... might not
be the same one chose for $1million credit limit accounts ... or that
the credit limit associated with a specific chip could change in
real-time as circumstances changed.

how many ibm 4758s would you be willing to carry around in your wallet
...  especially if you could only do $300 transactions.

the original AADS chip strawman posting from 98
http://www.garlic.com/~lynn/aadsm2.htm#straw

somebody cross-posted and it ran concurrently on some list in the UK
that involved people actively doing attacks.

actually i have another problem with eal4-high ... the problem is that
most chips with eal5/eal6 evaluations have it done on the bare-bones
infrastructure and the crypto loaded later. the problem if you burn in
the crypto as part of silicon manufacturing and have a chip where the
programming can't be changed, then the evaluation has to be done
against the complete chip ... including the burned in crypto. you may
otherwise have a chip that has been evaluated at eal5 or eal6 ... but
if you have a chip that can't be changed and the crypto has been
burned it as part of silicon manufacturing (i.e. before the wafer has
been sliced and diced) ... then the crypto has to be part of the chip
evaluation. just try finding semi-formal or formal evaluation criteria
for fips186-2, ecdsa in order to do an eal5/eal6 evaluation. there was
a conformance specification that existing momentarily but was almost
immediately withdrawn and they've been promising a replacement any day
now.

also if you look at the published protection profile for smartcards,
almost the while thing is about how do you provide assurance for
loading programming on the chip. if the programming is hardwired and
can't be changed the majority of the protection profile becomes N/A.

random AADS chip strawman pieces:
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in Canada
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm1 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm2 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm4 AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech10 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
http://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#46 Giuliani: ID cards won't curb freedoms
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm16.htm#10 Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was:   example: secure computing kernel needed)<
http://www.garlic.com/~lynn/aepay10.htm#40 AADS Chip Strawman & aSuretee
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
http://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#46 Giuliani: ID cards won't curb freedoms
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm16.htm#10 Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was:   example: secure computing kernel needed)<
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay10.htm#40 AADS Chip Strawman & aSuretee
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working

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

New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 09:12:44 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

Whether digital signatures were originally designed to be legal
signatures or not, at least in Germany the FACT is that digital
signatures have become legal signatures (the two are equivalent, if
the digital signature scheme satisfies certain quality
requirements). So what would you say (in the face of that fact) of
the utility/value of digital signatures and (in connection with
that) of CAs for e-commerce and other potential applications of
digital signatures? Thanks.

countries can make all sorts of laws ... i have very little control
over that.

 "so what would i say the utility/value of digital signatures"

... i will append URLs of what i've already said in this thread

 "and CAs for e-commerce and other potential applications of digital
 signatures"

what i've continuing been saying.

we help put together the business process that utilizes the SSL domain
name server certificates ... for what is now being called ecommerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

so i've described what we did originally, how it actually works and what
it actually accomplishes
http://www.garlic.com/~lynn/subpubkey.html#sslcert

i've also described various things that it doesn't accomplish and work
to address some of those things. some number of the improvements to
accomplish what SSL domain name server certificates don't address
... turns out to make the use of certificates redundant and
superfluous. Its like if you had a bank with piles of money in the
middle of the floor and scores of armed guards constantly running
around. Someday you installed a bank vault with six foot thick walls
and six foot thick door. It might occur to you that you might not need
all of those armed guards.

lots of people seem to automatically equate digital signatures and
public keys with certificates and CAs.

my assertion has simply been that digital signatures and public keys
aren't the same as certificates and CAs ... and there are lots of
environments where digital signatures and public keys could be used
and for those environments, certificates are redundant and superfluous.

there are reams and reams of things written by hundreds of people
regarding the uses of certificates and CAs. furthermore, my wife and I
were instrumental in making many of the current CAs viable by helping
create the stuff now called ecommerce.

so rather than ad nauseum repeating the same points ... here is a URL
with pointers to collection of posts on naked public key and/or
certificate-less operation
http://www.garlic.com/~lynn/subpubkey.html#certless

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

Authenticated Public Key Exchange without Digital Certificates?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authenticated Public Key Exchange without Digital Certificates?
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 10:18:43 -0600

there was also some amount of process engineering. as a young innocent
i got indoctrinated in every additional step in the manufacturing
process increases costs.

keygen is integrated with original chip power on/test while it is
still in the wafer. public key is appended to the results of the
initial power on/test results that is already being exported ... and
is carried as part of the existing chip q/a infrastructure (i.e.
public key in some sense is integrated into the power on/test results
as an indication of valid chip).

other issue was making sure that the power requirements were such that
it could function in a iso 14443 proximity environment ... so there
were some close power consumption requirements ... and the possibility
of using it in transit applications with turnstyles, etc ... also
created some time constraints (couldn't make a lot of power/time
trade-offs).

recent posting in this n.g. on some of the other issues
http://www.garlic.com/~lynn/2004h.html#30 ECC Encryption

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

Authenticated Public Key Exchange without Digital Certificates?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Authenticated Public Key Exchange without Digital Certificates?
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 13:29:47 -0600

... also ... if you don't have a CA-oriented trust hierarchy ... there
is no system risk issues with some keys needing more protection than
others because it would could bring the whole infrastructure tumbling
down.  there was once some government financial infrastructure
statement that they would never use CA-oriented trust hierarchies
because the possibility root key vulnerabilities simply represented an
excessive systemic risk problem.

you compartmentalize each key pair ... and therefor you bound systemic
risk issues. also if you are talking about online authentication based
model .... where the verification of digital signature is used to
functionally imply something you have authentication ... then by
definition if you loose physical control of the token ... then you
have already violated the something you have authentication
infrastucture and you have to disable the associated public key.

if you have to take physical control to extract the private key ...
the infrastructure countermeasure is actually no different whether or
not you can extract the private key once physical control has been
lost. the infrastructure is oriented towards something you have
authentication and simple loss of physical control activates the
countermeasures ... and we no longer actually care whether you can
physical extract the private key ... or can use the stolen token w/o
extracting the private key ... or whatever.

The obvious threat to a something you have infrastructure is loss of
physical control ... and the countermeasures are in place to handle
that.

the real threat to the infrastructure is can the private key be
duplicated/extracted w/o anybody realizing there has been loss of
physical control (and/or there not need to be loss of physical control
in order to duplicate the private key).

this is effective the exploit and vulnerabilities that the existing
magstripe infrastructure is dealing with. there can be duplicate
something you have authentication w/o the card owner realizing it
(at least until they see the statement or the fraud detection
recognizes some pattern violation).

in fact, that turns out to be another argument against the offline
credential based model ... with the online authentication based model,
some responsible party is seeing the transactions/events ... and be
able to detect additional kinds of fraud patterns and security
violations ....  that is not possible in the offline credential
scenario.

Of course the fraud risk needs to be high enough to support not only
the cost of online authentication based model ... but the additional
real-time fraud detection. However, as online and data processing in
general turns into commodity ... the threshold trade-off for that has
been dropping.

this continues to relegate the offline credential based model to
smaller and smaller, as well as lower and lower value niche
applications.

as the nich market value continues to decline for the offline
credential based model ... there can be a severe downward pressure on
what can be charge/invested for the credentials, with extreme downward
pressure on what can be charged for credentials ... it would tend to
also create a cash-flow problem for the certification authority
operator to maintain high integrity and high assurance operation.  Any
cutback in the level of integrity of the certification authority
operation would also place extreme downward pressure on the going
price for the credential .... since any integrity reduction in a
certification authority operation would also tend to preclude higher
value market niches requiring high integrity operations.

at some point, you may reach discontinuity where online authentication
based model has become so ubiquitous and the cost has declined to the
point where there are no viable market niches left to support various
kinds of commercial certification authority operation.

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

New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 15:54:01 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

If you want really to establish your opinion that digital
signatures and CAs are redundant, I sincerely suggest
that instead of having bunch of pointers on your web page
you propagate your opinion with clearly formulated papers
in the crypto conferences and have an effective debate
with the many real experts there. For our group, like all
internet groups, is apparently not in a position to deliver
any significant influences to the diverse professions
or practices in real-life (unfortunate but a fact in my
humble view).

i continue to be totally amazed at the number of times that you can
repeatedly misquote me ... and the number of times that it needs
correcting.

i repeatedly stated that when the relying party has direct access to
the real information ... then certificates are redundant and
superfluous.

i've NEVER said that digital signatures are redundant.

I have observed that there are some people who seem to believe that
CAs and certificates are equavalent and identical to asymmetric
cryptography, digital signatures, public keys, etc. In such situations,
there seems to be an extremely noisy channel that any mention of
certificates being redundant and superfluous comes out as digital
signatures are such.

I'm co-author of x9.59 financial standard that uses digital signatues
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#privacy
which is some path on its way to ISO

in this scenario not only can certificates be redundant and
superfluous ... but they can actually represent a payload bloat of a
factor of one hundred times.

There is an alternative explanation that I sometime have to resort
to which some people seem to find more palatable.

It derives from the X9F standards work on certificate compression;
attempting to address the horrible payload bloat that standard
certificates cause. The two standard compression techniques

1) take the bit patterns and looks to see if there is redundant
information and use a much more efficient encoding mechanism to
represent the bit pattern

2) analyse the logical information content and determine if the
relying party already has a copy of particular field values.  if the
relying party is known to always have a copy of the specific field
value, then the field can be removed from the certificate, aka it is
redundant and superfluous to transmit to the relying party fields of
information that the relying party already possessed.

so as part of the detailed investigation of payment infrastructures as
part of the x9.59 standards work ... was that the relying parties
(consumer's financial institution that would be receiving the
digitally signed payment instruction) would already have all fields
that were part of the certificate.

as a result we could eliminate all fields from the certificate and
were left with extremely efficient zero-byte certificates to append to
x9.59 transactions for transmission to the relying party.

In this case, the zero-byte certificates weren't redundant and
superfluous, it was just that every field in the certificates were
redundant and superfluous. We faithly manage the zero-byte
certificates and made sure that the zero-byte certificates are
appended to every x9.59 transaction.

we had made the remarkable accomplishment of infinite compression for
certificates.

random past discussion of our remarkable achievement for infinite compression:
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#13 A challenge
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards

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

New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 17:22:35 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

But would be trivial, wouldn't it? If I know (by some other
means) that some 'real information' is authentic, then I
don't need 'any' signature (whether digital or conventional),
neither even PK itself. So what's your point? I don't yet
understand, sorry.

maybe repeat for the 10th time ...

consumer goes to their bank and registers their public key.

the public key is stored in account record (this is even specified in
the definition for PKI CA registration authorities).

the bank issues them a relying-party-only certificate ....
http://www.garlic.com/~lynn/subpubkey.html#rpo

even german banks started doing this in the mid-90s when it was
realized the privacy issues with an identity certificate. there was
presentation by somebody from one of the big german banks on the issue
at conference in 1998:
http://csrc.nist.gov/nissc/1998/index.html

the purpose of the certificate is for digitally signed communication
and digitally signed transactions with the consumer's bank. however,
we subsequently were doing some payload bloat studies about the
serious payload bloat of certifications on the standard payment
infrastructure. as part of the study on compressing certificates we
formulated the information theory that it was redundant and
superfluous for a bank customer to be repeatedly transmitting fields
in an relying-party-only certificate back to their financial
institution which involved fields that the their financial institution
already possessed. that was when we realized that all fields in a
relying-party-only certificate could be compressed from a
relying-party-only certificate resulting in the infinitly compressed
zero-byte relying-party-only certificate.

if it makes you feel better ... we haven't gotten rid of the
certificates as being redundant and superfluous ... we have just
eliminated all redundant and superfluous fields in a
relying-party-only certificate, resulting in an infinitly compressed
zero-byte relying-party-only certificates; and in fact we faithfully
attach zero-byte relying-party-only certificates to all of our
communication with the relying-party ... the consumer's financial
institution.

we made the discovery of the astounding infinite compression technique
and the benefits of zero-byte relying-party-only certificates when we
were investigating the severe payload bloat the standard certificates
placed on the payment infrastructure with digitally signed payment
transactions.

we got the idea of the infinitly compressed zero-byte
relying-party-only compression from the relying-party-only certificate
presentation that was given at the referenced conference by member(s)
of the german banking community describing what they were doing with
relying-party-only certificates.

so I actually misspoke, we haven't gotten rid of redundant and
superfluous relying-party-only certificates ... we have just infinitly
compressed the relying-party-only certificates to zero-bytes by
eliminating all fields that are redundant and superfluous.

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

New Method for Authenticated Public Key Exchange without Digital Certificates

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: New Method for Authenticated Public Key Exchange without Digital Certificates
Newsgroups: sci.crypt
Date: Mon, 09 Aug 2004 17:58:42 -0600

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:

O.k. The bank is then a CA, isn't it? Are CAs then
redundant/useless (which you seemed to argue)?

you repeatedly misquote me ... which continue to find absolutely
amazing ... to constantly and repeatedly the same things wrong time
and time again is extremely remarkable. maybe we can get in the
guiness book of records.

i've said that in situations where the relying party already has all
the information (either directly or via online connectivity) then the
certificate is redundant and superfluous.

however if it makes you feel better ... the certificate isn't actually
redundant and superfluous to the relying party ...  it is just all the
fields in the certificate are redundant and superfluous that are
redundant to the relying party ... and therefor we are actually using
these infinitly compressed, zero-byte certificates.

however, for you to understand when a relying party already has access
to all the fields that might be contained in a certificate ... you
might actually also have to understand something about the business
process.

i'm making an assertion that if somebody possesses a piece of
information ... then it is redundant and superfluous to send the same
information to that person.

now you repeatedly stated numerous times that you know absolutely
nothing about the subject and therefore you have no basis on which to
make any judgement about what fields any particular relying party in
any particular business operation might already possess.

so given that you don't know anything at all about the subject ...
will you at least acknowledge there might be some situations where if
I already know something, then it might just be possible for it to be
redundant and superfluous to keep sending me the same information over
and over again.

is there any general situation at all that you can conceive of where
if somebody might possibly know and/or learn something .... would it
then be redundant and superfluous to repeatedly provide them with that
same identical information again and again?

lets make a hypothetical assumption that you might have learned the
alphabet in grade school ... and possibly might even still remember
what the alphabet is. Would it possibly be redundant and superfluous
to make you go back and repeat grade school .... lets say the same
grade for the next 12 years ... in order that you could repeatedly
relearn the alphabet.

in any case, and while you possibly still can't comprehend the concept
that somebody might just possibly have some piece of information
and that it would be redundant and superfluous to repeatedly send
them the same information over and over again ...

i assert that we've actually made a study of some number of situations
and made lists of information that specific types of relying parties
have access to in various business operations. We've also been able to
match of several of these pieces of information ... with types of
information that might be found in a certificate. We've been able to
design optimally compressed certificates for specific business
environments ... by eliminating the fields in certificates that
relying parties would already possess.

so based on you repeatedly statements that you actually have no
knowledge at all of the subject ... i'm simple making the assertion
that there can be situations where if somebody already has some piece
of information ... then it can be redundant and superfluous to
repeatedly provide them with the same information over and over again.

it doesn't actually matter who the CA is ... what matters is whether
the relying-party already has access to information (directly or via
any other means) to information in a certificate ... in which case
... for that specific business operations ... and for those
certificates such pieces of information can be eliminated from
certificates used in those business operations. Furthermore, if some
relying parties have access to all information in a certificate
... then all information can be eliminated from such certificates used
in those business operations ... achieving infinitly compressed, zero-byte
certificates.

i don't know whether you can't comprehend the concept that relying
parties might have information via means other than certificates
... or you can't comprehend the concept that it is possible to do
business process analysis of information on certificates and figure
out if there is actually usefull for any specific business operation.

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

Smart card Authentification

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Smart card Authentification
Newsgroups: sci.crypt
Date: Tue, 10 Aug 2004 07:50:59 -0600

"lyal" writes:

Finally, there are several certificate transfers occuring here. With a
guaranteed speed of 2400 bits/sec, usually 9600 bps, and sometimes 115kbps,
each 5-10kbyte cert transfer may take several seconds, plus processing time.
I, for one have better things to do than wait more than a couple of seconds
for machines to trust each other.  Custom-specifc readers and smartcards
will guarantee higher transfer (i.e smartcard I/O) speeds, but they may no
long conform to all requirements of, say the ISO 7816 smartcard spec.

 ... if any of the certificate gorp has to leave the local terminal
there is real issues.  they have tested some number of normal dial-up
point-of-sale terminals at higher than 2400 baud ... and found that
the nominal modem synch times greatly exceeded any benefit of having
higher transfer rate (for stuff not having heavy payload bloat from
certificate stuff) ... and in fact there were several places where the
nominal modem synch times (for higher rates) exceeded current average
total elapsed time.

so the whole design point of the original offline credential based
model stuff ... assumes that the operation doesn't have to propagate
past the local environment. however, in the point-of-sale ... you even
get into circular logic ... if you are using certificate based
paradigm ... it can't leave the local environment w/o causing enormous
payload bloat and elapsed time impact on overall processing.

another issue then at the point-of-sale is that any mutual
authentication ... has the chipcard doing public key operations on the
certificate from the point-of-sale terminal ... because/since it is
going to be offline, the chipcard has to also trust the point-of-sale
terminal before it does some of its operations.

it is possible to beef up chipcards to do RSA public key operations to
get the elapsed time within acceptable bounds ... but it involves
putting in lot more circuts and drawing a lot more power.  the power
profile are within the acceptable bounds of 7816/contact
infrastructures ....  but the transition to 14443 contactless
represents a real challenge since it significantly exceeds available
power/time specifications.

as long as you have (7816) physical contact ... there is a lot more
latitude in protocols .... but the transition to 14443 puts a lot of
limitations on the amount of power/time that is drawn from the air as
well as the bits/time that can be transferred.

this changes in the online scenario ... having both the chipcard and
the terminal simply digitally sign the transaction and send it up to
the relying party (the consumer's financial institution) using an
online authentication based model operation ... the relying party can
verify the pair of the digital signatures (terminal and card) before
approving the transactions. there is no issue of the card or the
terminal having to trust the other .... since the transaction isn't
offline.

There is a significant reduction in the chatter that has to occur in
the local point-of-sale environment ... and effectively all of the
authentication checking operations are pushed up to the relying party
(the consumer's financial institution). There is not the requirement
that the chipcard and the terminal have to establish trust in each
other as a condition of performing an offline transactions. With
simple digital signature going on at point-of-sale ... it is possible
to get the power/time and elapsed time profile well within what is
available in a proximity/14443 environment (at least if you are
talking fips186-2, ecdsa).

You also get out of the circular logic with the offline credential
based model of it having to be offline because the infrastructure
can't tolerate the payload bloat of the certificates. Going to online
authentication based model, the payload bloat of normal certificates
disappears (i.e. it is possible to use infinite compression and
achieve zero-byte certificates).

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Wed, 11 Aug 2004 10:15:25 -0600

Alan Balmer writes:

The current MIT Technology Review has an article about the Japanese
cellphone industry. They are adding what sounds like "smart card"
technology to their i-mode phones. A rep from the DoCoMo company says
most of their customers will not be carrying wallets in five years.
Not just their money, but all their personal information, pictures of
the grandkids, etc., will be on this personal appliance.

they are adding more like virtual wallets ... slightly related
thread(s) from sci.crypt
http://www.garlic.com/~lynn/2004h.html#30 ECC Encryption
http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#9 smart card authentication

there was some effort mapping virtual wellets from the 1980s-era into
smart cards because they were the availble consumer convenient
portable computing state-of-the-art.

a big issue in the 80s ... was that the technology wasn't there for
portable input/output to go along with the consumer convenient
portable computing state-of-the-art ... and as a result there was big
push in ISO 7816 standards so that you could have ubiquitous fixed
input/output stations that would (physical) interoperate with the
available portable computing (smartcard) technology.

starting in the early 90s, you started to see emerging portable
input/output technology penetrate the market with PDAs and cellphones.

as consumer convenient portable computing devices with their own,
builtin input/output capability, you should start to see the shift
from physical format specific interoperability ... to primarily
communication protocol interoperationaly.

you've already seen the shift away from the purely physical format
interoperability of iso 7816 "smartcards" .... to a variety of
physical formats that utilize USB for the physical connections.

also, once you have broken with iso 7816 for physical
interoperability, ... like iso 14443 proximity ... you also have
opened up numerous physical format operation.

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Wed, 11 Aug 2004 12:02:19 -0600

Alan Balmer writes:

While there are still card readers that phone for verification,
they're becoming rare. Both credit and debit transactions are handled
over always-on high-speed networks, LAN, WAN, or Internet.

(It happens that I'm working at a company which makes the readers and
the software to process the transactions.)

sales of new dial-up terminals may be rare ... but about 1/3rd of my
card transactions in the past two weeks were at shops that you could
actually listen to the modem sync.

however, majority of total transactions are done by high-volume
merchants ... who tend to have concentrators ...  and in fact, there
was some number from two years ago that a single merchant accounted
for 1/4 to 1/3rd of all retail store transactions in the us.

... there are same terminals handling credit, debit, pre-paid, gift,
loyalty, etc. part of the problem is somewhat chicken and egg and
trying to roll any kind of infrastructure change that requires
physical swap at lot of different locations.

slightly related post concerning point-of-sale technology
in at least this same titled subject ... if not the actual
subthread
http://www.garlic.com/~lynn/2004j.html#10

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Thu, 12 Aug 2004 08:05:37 -0600

"Helmut P. Einfalt" writes:

Such a thing is known as "Electronic Cash" or "Electronic Purse"
over here and it is incorporated in any Maestro Card, which is the
card your bank will issue to you to access account balance printers,
cash dispensers, etc.

Besides stores accepting the Maestro card (known as "EC-Card" in
Germany or "Bankomat" in Austria), there are quite a few appliances
where you can pay with "Electronic Cash", such as parking lots; bus,
tram or underground tickets, phone boxes etc.  It is a pretty
convenient way to avoid not having change when you park your car in
the city...

there was a lot of work on chipcards for doing offline electronic cash
... basically offline transaction between chipcard and point-of-sale
terminal ... basically the introduction of chipcards were cost/benefit
to the high cost (and/or non-availability) of online connectivity.

in the US, in the early 90s ... it was realized that with the rapidly
declining cost & ubiquitous availability of online support
... they could deploy online electronic cash much less expensively
than what was done in other parts of the world (the expense of
chipcards was being viewed as overcoming the higher cost .. and/or
lack of online connectivity). I believe the first one was in '95 by a
company called first financial and the first customer was blockbuster.

basically it has been the same magstripe technology and leverages the
existing massive deployment of magstripe point-of-sale and ubiquitous
online network. the relationship between the merchant, the merchant
terminal, the merchant connectivity to the merchant financial
institution processor stays effectively the same ... but at the
merchant financial institution processor ... the magstripe info gets
routed to a different backend transaction processor.

these are the gift/stored-value cards that you see at many check-out
places like starbucks, major department stores, grocery stores, etc.

a big component of all the gift/stored-value cards have always been
the float.

one business analysis of the mondex electronic chip stored-value card
was that it was almost all float. you could see that when mondex
international began picking up licensees in different countries once
they offered to split the float. also at one point, several european
central banks told mondex international that they would be given a
couple years grace on the float ... effectively in order to help
subsidize deployment ... but if by an off-chance they ever become
successful ... they would have to start crediting client accounts with
the interest on unspent balances.

a couple random refs ... quickly pulled from search engine using
"mondex" and "float"
http://www.aci.net/kalliste/smartcards.htm
http://www.dreamscape.co.in/kb-ips.html

mondex international was based on an infrastructure-wide
shared-secret(s) (relying on the chips to guarentee that the
secret was never exposed) ... but they sponsored an internet standards
payment group ... which eventually morphed into the current ietf
working group doing ECML (electronic commerce markup language)
... currently with RFCs 3505, 3106, and 2706.

having a chip-based protection of infrastructure-wide shared-secrets
is the basis for at least some of the publicity for chipcard exploits
... the effort to attack any specific chip ... results in having the
means for compromising the whole infrastructure.

other more recent payment chipcard attacks are what has been descriped
in the UK press as YES card. couple past refs to yes cards
http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Thu, 12 Aug 2004 10:10:36 -0600

Alan Balmer writes:

For mag-stripe type cards, (as apposed to "smart cards" with info on
card) the main function of the card is to identify itself, or itself
and you if there's a PIN number. The database is actually still at
the bank, the card provides only an index into that database.

That's one of the objections to "smart cards." Actual information
and monetary value is embedded in the card itself.

chipcards

1) may be much harder to counterfeit than magstripe for authentication
2) can be used for offline transactions

the second/#2 was somewhat viewed that the increased cost of chipcards
(vis-a-vis magstripe) to address #1, could be offset by eliminating
the need for an online infrastructure.

however, if exploits do occur in #1 (like counterfeits) ... they may
be much more difficult to deal with in a #2 (offline) environment.
this became an issue with the (counterfeit) yes cards.

it isn't actually necessary to use chipcards for (#2) offline
transactions ...  but it was one way of justifying the cost for #1. as
the cost of online infrastructures and online processing has come down
... this becomes less & less of an issue.

as other forms of consumer convenient portable computing devices
become more pervasive (PDAs, cellphones) ... wireless based protocols
for point-of-sale are becoming more attractive as alternatives (and
can also be designed to address #1, since to some extent, a similar
counterfeiting issue already exists for cellphones).

the issue of offline/online for chipcards is somewhat orthogonal to
their use as purely strong authentication (difficult to counterfeit)
device ... other than the issue of it being intrastructure cost offset
(which is being significantly mitigated by dropping costs of
ubiquitous online infrastructures).

a debit card at point-of-sale basically is two-factor authentication

• something you have (card)
• something you know (pin)

there has been a number of recent UK news stories about confusion that
may showup with the pending switchover to chip&pin for credit

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Thu, 12 Aug 2004 14:28:25 -0600

... in the debit/matstripe case, the magstripe value and the pin are
transmitted to online infrastructure and both verified ... achieving
two-factor authentication:

• something you have
• something you know

the pin is basically first level countermeasure for lost/stolen card.

in the chip&pin case ... with offline operation ... there is no
outside entity to verify the pin ... so business rules are installed
in the chip and certified. the chip is certified as not working as it
should w/o the correct pin ... that based on the response from a
trusted chip, something you know authentication can be inferred.

in the yes card scenario ... the chip has the online banking
business rules installed regarding correct pin, credit limit and some
number of other characteristics. the offline terminals ... once they
believe they have verified a valid banking chip ... then rely on the
consumer specific business rules in each chip.

sometime in 1999 or 2000, the first yes card appeared in nice
(france, basically a chip&pin application for more secure credit card
operation), and then spread thru the rest of europe. the yes card
reference comes from the fact that once the yes card has convinced
the terminal that it is a valid bank card with valid business rules
... then it always answers yes to

• was the correct pin entered (yes card will say yes regardless of
PIN entered)

• is the purchase within the consumer's credit limit

• should this be an offline transaction

so once yes cards exist ... they are difficult to make go away
... becuase they are all offline transactions and won't be discovered
until much later.

now in the following post:
http://www.garlic.com/~lynn/2004j.html#2

there is reference that one of ibm's top of the line, most secure
security device could be compromised with relatively modest amount of
effort.

the systemic risk in something like the mondex scenario .... is once
you have extracted the infrastructure shared-secret ... you can
manufacture a large number of counterfeit cards ... with basically
unlimited values.

in the original yes card scenario ... it simply required skimming
the terminal for card transactions ... and injecting the skimmed
value in the counterfeit cards.

the newer generation of chip&pin cards are going to challenge/response
type communication .... but the chips are still susceptable to
extracting secrets ... as per the above mention of attacks on truely
high-end crypto hardware.

so lets say that it costs as much as $50k to attack a chip card and
extract its information (compared to possibly even more expensive
attacks on high end devices).

a criminal organization extracts the necessary information to convince
infrastructure point-of-sale terminals that they have a valid card
... inject the information into 5000 yes cards and sell them on the
black market for $100 each. They'll still clear over $400k.

the issue is that the systemic risks have shifted from infrastructure
shared-secrets (as in the mondex case) to all the point-of-sale
terminals in the world being programmed for offline transactions and
to trust that chip cards correctly implement the banking
infrastructure business rules (the systemic risk is all those
point-of-sale terminals trusting chips to correctly implement the bank
infrastructure business rules).

the countermeasure for counterfeit yes cards with trusted
business rules is to go to online, checking if the card has been
deactivated. however, if you go to online transactions ... then you
can simply utilize business rules in the backend banking system
.... and any programming and business rules in the chip card become
redundant and superfluous.

recent related posts in this thread:
http://www.garlic.com/~lynn/2004j.html#10
http://www.garlic.com/~lynn/2004j.html#11
http://www.garlic.com/~lynn/2004j.html#12
http://www.garlic.com/~lynn/2004j.html#13

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Thu, 12 Aug 2004 14:44:27 -0600

Alan Balmer writes:

Our security system works nicely off-line, but we have a restricted
set of users (university environments). An individual reader can
hold schedules and access parameters for some tens of thousands of
users, and the database is updated whenever it's online. POS is
another matter, of course.

a lot of the door badge systems are migrating to online .... in part
because the technology costs have come done.

basically it is security proportional to risk issue ... and
cost/beneift of risk mitigation.

if the value of what is at risk is low enuf ... then it is harder to
justify more expensive online door badge systems .... however, the
online door badge system can mitigate a lot of risks that offline
systems have trouble with.

Many of the door badge systems at higher value commercial
infrastructures were purely offline in the 60s & 70s ... but you
started seeing migration to online door badge systems in the 80s ...
including things like extremely detailed audit activity being securely
recorded (possibly integrated with online surveilllance cameras).
This is comparedwith some number of the low-value infrastructures that
were still possibly key-based in the 60s (or had nothing) ... moving
up to offline door badge systems.

one of the things you started to see starting in the early 80s was
serious insider and collusion countermeasures (i.e. it isn't a matter
of only letting the insiders in and keeping the outsiders out). The
90s somewhat defocused that with lots of concern in the press about
outsider attacks (via the internet). However, even at that, a recent
study found that at least 77 percent of possibly internet related
fraud involved an insider somehow.

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Thu, 12 Aug 2004 15:22:04 -0600

Anne & Lynn Wheeler writes:

now in the following post:
http://www.garlic.com/~lynn/2004j.html#2

random trivia related the above reference which eventually references
discussion of various techniques used to attack chips and other
crypto devices.

for some time, i had half dozen offices, a lab and other stuff in the
los gatos lab ... which was primarily a chip design and chip design
tool operation. one of its claims to fame was to have been the first
to use scanning electronic microscope on a live running chip. in their
case the technique was used as part of chip debugging and development.
it was also responsible for the LSM logic simulator.

at one time it was considered the most beautiful lab in the company
... you could have deer or possibly wild boar outside your window.  in
the 90s they finally closed the lab, tore down the building and sold
off the grounds (couple hundred acres) for housing development.

random lsg past references:
http://www.garlic.com/~lynn/2000.html#16 Computer of the century
http://www.garlic.com/~lynn/2000b.html#57 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2002d.html#3 Chip Emulators - was How does a chip get designed?
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2002j.html#26 LSM, YSE, & EVE
http://www.garlic.com/~lynn/2002m.html#45 Wanted: the SOUNDS of classic computing
http://www.garlic.com/~lynn/2003.html#31 asynchronous CPUs
http://www.garlic.com/~lynn/2003k.html#3 Ping:  Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#14 Ping: Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2004c.html#25 More complex operations now a better choice?

Wars against bad things

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wars against bad things
Newsgroups: alt.folklore.computers
Date: Sat, 14 Aug 2004 09:26:52 -0600

"Gary A. Gorgen" writes:

That was the only advantage that Interdata had over most vendors.
Had to find a customer that had a specific problem, then the sale
was easy. If all the customer wanted, was a computer, they usually
bought DEC.

as an undergraduate, i worked on project with interdata/3 ... i had
stumbled across something that I wanted to do with mainframe terminal
controller and it wouldn't do it. the project involved reverse
engineering the ibm channel interface and building a mainframe channel
adapter board for the interdata/3 and programming the interdata/3 to
emulate the mainframe controller. it was later enhanced to use a
interdata/4 as controller emulation interface with a collection of
interdata/3s as dedicated line scanners

there were some write-ups blaming the project for starting the
plug compatible manufacture controller business.
http://www.garlic.com/~lynn/subtopic.html#360pcm

which, in turn, supposedly spawed the (aborted) FS project:
http://www.garlic.com/~lynn/subtopic.html#futuresys

which in turn was supposedly one of the reasons Amdahl left and
started plug compatable processor business.

i ran into somebody 6-7 years ago who said they had been selling the
p/e boxes into NASA in the 80s (they had been bought by perkin-elmer
by then) ... but claimed that the wire-wrap channel adapter board was
possibly the original design. there was some comment that they never
saw any justification that any redesign would result in incremental
sales that would justify the redesign.

In the late 90s, i ran across one such box still handling large
communication load in a big mainframe datacenter.

random past mention of interdata
http://www.garlic.com/~lynn/96.html#30 interdata and perkin/elmer
http://www.garlic.com/~lynn/96.html#37 interdata & perkin/elmer machines
http://www.garlic.com/~lynn/96.html#39 Mainframes & Unix
http://www.garlic.com/~lynn/99.html#12 Old Computers
http://www.garlic.com/~lynn/99.html#234 Computer of the century
http://www.garlic.com/~lynn/2000b.html#49 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#36 Interdata, Perkin-Elmer, et al.
http://www.garlic.com/~lynn/2000c.html#37 Interdata, Perkin-Elmer, et al.
http://www.garlic.com/~lynn/2000c.html#48 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000c.html#51 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000c.html#54 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2000c.html#80 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000c.html#81 Unisys vs IBM mainframe comparisons
http://www.garlic.com/~lynn/2000f.html#6 History of ASCII (was Re: Why Not! Why not???)
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001.html#5 Sv: First video terminal?
http://www.garlic.com/~lynn/2001.html#17 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001b.html#75 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001d.html#34 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001d.html#35 Imitation...
http://www.garlic.com/~lynn/2001e.html#53 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001f.html#44 Golden Era of Compilers
http://www.garlic.com/~lynn/2001f.html#48 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001g.html#30 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#32 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#50 Flip the bits in a byte
http://www.garlic.com/~lynn/2001l.html#8 mainframe question
http://www.garlic.com/~lynn/2001l.html#43 QTAM (was: MVS History)
http://www.garlic.com/~lynn/2001l.html#44 QTAM (was: MVS History)
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic:  facts vs. FUD
http://www.garlic.com/~lynn/2002f.html#37 Playing Cards was Re: looking for information on the IBM 7090
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002f.html#52 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2002h.html#44 50 years ago (1952)?
http://www.garlic.com/~lynn/2002i.html#68 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#36 Difference between Unix and Linux?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2002l.html#2 What is microcode?
http://www.garlic.com/~lynn/2002m.html#21 Original K & R C Compilers
http://www.garlic.com/~lynn/2002n.html#32 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#33 why does wait state exist?
http://www.garlic.com/~lynn/2002q.html#39 HASP:
http://www.garlic.com/~lynn/2003.html#73 Card Columns
http://www.garlic.com/~lynn/2003c.html#15 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#28 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#70 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#76 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#44 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003e.html#8 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003e.html#13 unix
http://www.garlic.com/~lynn/2003k.html#30 IBM channels, was Re: Microkernels are not "all or nothing"
http://www.garlic.com/~lynn/2003m.html#53 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2003n.html#50 Call-gate-like mechanism
http://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
http://www.garlic.com/~lynn/2004.html#35 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004b.html#47 new to mainframe asm
http://www.garlic.com/~lynn/2004c.html#40 Microprocessor History Site
http://www.garlic.com/~lynn/2004e.html#5 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004g.html#9 Need to understand difference between EBCDIC and EDCDIC
http://www.garlic.com/~lynn/2004g.html#12 network history

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

Wars against bad things

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wars against bad things
Newsgroups: alt.folklore.computers
Date: Sat, 14 Aug 2004 09:29:09 -0600

"Gary A. Gorgen" writes:

IIRC, that was called "R*" (R star) rounding.
When was it introduced?

there was also R* (R-star) which was the follow-on to system/r ... the
original relational database ... which was then followed by starburst
misc. past refs:
http://www.garlic.com/~lynn/subtopic.html#systemr

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

Wars against bad things

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wars against bad things
Newsgroups: alt.folklore.computers
Date: Sat, 14 Aug 2004 13:34:06 -0600

"Gary A. Gorgen" writes:

Oh great, 2 things with the same name, & nothing in common. :-)

there is also R-something? (which i think is star but may be plus) ...
an industry service that collects detailed erep logs from customers
and publishes detailed reliability and availability statistics for
various machines and configurations.

i had done this software support for channel extender ... allowing
local controllers & devices to operate at the end of some telco
link. for various reasons, i had chosen to simulate "channel check"
when various telco errors occured ... in order to kick-off various
operating system recovery/retry routines.

along came the 3090 ... which was designed to have something like 3-5
channel check errors per annum (not per annum per machine ... but per
annum across all machines).

After 3090s had been out a year ... R-something? was reporting that
there had been an aggregate of something like 15-20 channel check
errors in the first year across all machines .... which launched a
detailed audit of what had gone wrong.

they finally found me ... and after a little bit additional
investigation, i decided that for all intents and purposes, simulating
an IFCC (interface control check) instead of a CC (channel check)
would do as well from the standpoint of the error retry/recovery
procedures activated.

random past posts on channel extender support:
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
http://www.garlic.com/~lynn/2000.html#21 Computer of the century
http://www.garlic.com/~lynn/2000.html#22 Computer of the century
http://www.garlic.com/~lynn/2000b.html#38 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#48 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2003.html#34 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003d.html#24 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003n.html#29 Architect Mainframe system - books/guidenance
http://www.garlic.com/~lynn/2004c.html#31 Moribund TSO/E
http://www.garlic.com/~lynn/2004e.html#28 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004e.html#33 The attack of the killer mainframes

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

The Reincarnation of Virtual Machines

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: The Reincarnation of Virtual Machines
Newsgroups: alt.folklore.computers
Date: Sat, 14 Aug 2004 14:26:16 -0600

ACM Queue - The Reincarnation of Virtual Machines - Like the best of
the 1970s and 1980s, VMs have returned to the scene -- and they're a
lot cooler than polyester pants.
http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=168

i was still an undergraduate but I got to go to the spring '68 Houston
share meeting announcement of cp/67. three people from the science
center
http://www.garlic.com/~lynn/subtopic.html#545tech

had come out to the university at the end of jan. '68 to install
cp/67. posting on 35th anniversary announcement of cp/67
http://www.garlic.com/~lynn/2003d.html#72

photo from the 30th b'day party for vm/370 at share 99 in san fran:
http://www.garlic.com/~lynn/LynnWheeler023.jpg

it was one of the main stays of personal computing in the '70s ...
not only being offerred from corporate datacenters .... including
the majority of the computers on the internal network ... minor reference
http://www.garlic.com/~lynn/99.html#112
other references to the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

but was also offerred as timesharing platform by a number of commercial
timesharing companies
http://www.garlic.com/~lynn/subtopic.html#timeshare

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

Methods of payment

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Methods of payment
Newsgroups: alt.folklore.computers
Date: Sun, 15 Aug 2004 08:28:47 -0600

rogblake10@iname10.com (Roger Blake) writes:

So they won't do business with anyone who does not have a bank account?

one solution ...  it was either commerce or treasury that pioneered
for 2000 census workers ... the objective was electronic funds
transfer and the worker could acess it like an ATM debit (but
w/o the fees and other infrastructure costs)

some overview
http://www.eta-find.gov/ETADepositHow.cfm
faq
http://www.eta-find.gov/ETAFactsPage1.cfm
home page
http://www.eta-find.gov/Index.htm

overview of some of the issues:
http://www.fdic.gov/consumers/community/unbanked/tum05.html

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
 ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Sun, 15 Aug 2004 08:40:11 -0600

jmfbahciv writes:

You can do that?!  So cash registers are turning into bank
terminals?  I'll have to think about this one.  I don't think I'd
like to be one of those clerks; they still do have to balance their
cash drawer at the end of shift...don't they?  HEH.  That job ain't
as simple-minded as it looks.

one of the issues is that banks charge commercial entities a service
fee for handling cash. cash-back can minimize the night's deposits.

in theory the debit fee discount payed by the retailer (on the cash
back amount) is less than overhead costs for managing the actual cash
(in part, since the customer is already doing the debit transaction,
the merchant is already taking the hit on the per transaction fee).

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

Wars against bad things

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wars against bad things
Newsgroups: alt.folklore.computers
Date: Sun, 15 Aug 2004 09:45:28 -0600

"Gary A. Gorgen" writes:

What we called loosely-coupled, were machines connected together via
an I/O device, (much like ethernet or hyper-channel).
Tightly-coupled, were machines connected together via shared-memory,
with an inter-processor interupt system. Each system could be
independant, or dependant depending on the configuration.  There was
no requirement that each machine even ran the same monitor. The
largest system I did was 9 processors, with dual redundant
shared-memory.  One 4 processor system I did made a 2 second
appearance in the movie, "Top Gun". My 2 seconds of fame. :-)

anne was con'ed into going to POK to serve stint where she was
responsible for loosely-coupled architecture. while there she
originated peer-coupled shared data
http://www.garlic.com/~lynn/subtopic.html#shareddata

possibly the largest production loosely-coupled operation in the late
70s was the HONE system.
http://www.garlic.com/~lynn/subtopic.html#hone

HONE was originally deployed in the US as support vehicle for all the
sales, field, and customer support people. It was then replicated at
numerous places around the world ... and in the late '70s the US HONE
datacenters were consolidated in california ... where we got to put
together a massive single-system operation configuration (single site
loosely coupled, load balancing and fall-over) with a large disk
farm. As possibly the largest vm-based time-sharing service
http://www.garlic.com/~lynn/subtopic.html#timeshare

... it was pushing 40,000 userids (US sales, field, and customer
support people).

in the early 80s, partially as a result of earthquake disaster
scenarios, it had replicated operations installed in Dallas and
Boulder ... with load-balancing and fall-over across the three site
complex.

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of
 ASCII,Invento
Newsgroups: alt.folklore.computers
Date: Sun, 15 Aug 2004 21:42:43 -0600

magstripe gift/pre-paid news (from the future: 16th):
http://www.heraldsun.news.com.au/common/story_page/0,5478,10459001%255E462,00.html

mentions the current US giftcard market is worth $90b ($125b aust)

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

Wars against bad things

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Wars against bad things
Newsgroups: alt.folklore.computers
Date: Mon, 16 Aug 2004 07:45:28 -0600

jmfbahciv writes:

This was something that JMF and CDO wrote an architect spec for.
I'm assuming that HONE was transaction processing in addition
to an information provider.?

a lot of HONE use was packaged APL environment that delivered various
services & applications written in APL (APL was used to implement a
lot of things you see today delivered in spreadsheets).

A major HONE/APL application was the configurators .... you entered in
what the customer wanted .... it might ask some additional questions
... and it came back with the exact specifications that the salesman
were to put in the order form (there are an enormous number of
detailed feature codes, co-dependency features, inter-dependency
features, mutually exclusive features, etc).

Some number of the configurators frequently also had some level of
performance specification (& even analytical models) ... messages per
second, etc.

360s were starting to get complex enough for the salesman to correctly
specify all the appropriate feature codes for a customer
order. starting with 370s, it was requirement that HONE configurators
be run for order preparation.

in part because of the APL environment ... a lot of HONE use was
extremely CPU intensive operation.

another major use was customer proposals, bid responses, etc
... basicly document edit and preperation. originally HONE was cp/67
with CMS (and cms\apl) ... and then transitioned to VM/370 and CMS
(with the various flavors of apl\cms, apl\sv, apl2, etc). Original CMS
had SCRIPT ... with run-off like commands for document formating
(soemwhat dating back to common heritage with CTSS).  "G", "M", and
"L" had invented GML (precursor to SGML, HTML, XML, etc) and early in
vm/370 time-frame, script was extended with GML document formating
capability (you could actually intermix GML tags and "dot" commands in
the same document).

for the most part, hone
http://www.garlic.com/~lynn/subtopic.html#hone
was a personal computing, time-sharing, application delivery platform
http://www.garlic.com/~lynn/subtopic.html#timeshare

in part because of the cpu intensive APL operation ... the merged HONE
cluster in cal. might only have a couple thousand
simultaneous/concurrent users at any moment in time. during the 70s,
(typically smaller) clones of the US HONE operation were replicated in
many parts of the rest of the world.

in the early '80s, the marketing & sales division also started program
of installing 4341 vm/370 systems, first in regional and then larger
branch offices. this offloaded some amount of the more traditional
interactive work (and non-configurator stuff) .... email, document
editing, etc.

cp/67, cms, vm/370, internal network, cms\apl, GML, tightly-coupled
smp support, compare&swap instruction, a lof of HONE stuff, ... all
came out of 545 tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech

C&S instruction is the initial of the inventor at 545tech. misc. c&s and/or
smp references:
http://www.garlic.com/~lynn/subtopic.html#smp

GML are the initials of the inventors at 545tech. misc. posts on
invention of GML at 545tech sq:
http://www.garlic.com/~lynn/subtopic.html#sgml

internal network refs
http://www.garlic.com/~lynn/subnetwork#internalnet

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

Losing colonies

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Losing colonies
Newsgroups: alt.folklore.computers
Date: Mon, 16 Aug 2004 09:50:33 -0600

Bernd Felsche writes:

Far from being intrinsically useless, competence at a
native-language level is extremely useful; not only for interaction
with other people, research, etc; but also for being able to think
about things differently.

If you were only able to programme in COBOL, then you'd have to
solve all problems in COBOL.

If OTOH, you were very competent in half a dozen languages and had a
passing familiarity with a dozen others, then you'd be able to
choose the most-appropriate tool for the particular job.

Human languages are not entirely unlike that. Each language carries
with it idioms and nuances that do not translate directly to other
languages. Moreover, the power of terminology in specific languages
imposes a cultural under-current and makes some ideas easier to
"implement".

Indeed, being able to speak more than one language has the potential
to make one more understanding of the difficulty others may have in
expressing their ideas in any formal language; even their native
tongue.

slightly related is language literacy ... sometimes referred to as
thinking & dreaming in the language. a lot of people writing programs
and using programming languages are frequently still laboriously
translating .... i.e. they don't actually think & dream in the
programming language that they are using.

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

US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father
 ofASCII,Invento
Newsgroups: alt.folklore.computers
Date: Mon, 16 Aug 2004 13:18:36 -0600

Alan Balmer writes:

I'm also curious to know how you know that only some of the
overcharges were caught. If you know of more, you really should be a
good fellow and tell the GAO.

and the military/industrial complex issues from forever.

i remember being told tales about various financial activities in the
US during WW-II

boyd helped orchestrate an 18-page newsweek article in the early 80s
on military/industrial complex issues during the 60s & 70s
... misc boyd:
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

there was news article this morning about GAO evaluation of the new
armored, rapid deployment vehicle .... which may have weight issues
and problems being rapidly deployed.

does anybody remember the stories about $500 hammers and toilet seats?

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Mon, 16 Aug 2004 14:34:39 -0600

Morten Reistad writes:

neither Tops10 or Tops20 had any really good security; and wouldn't
have lasted long when connected to the Internet of today. Original
UNIX didn't have networking, but the versions that had it bolted
on didn't have adequate security.

cp/67 had partitioning ... which is also a security technique.
starting in the '70s there was an extensive network of the machines on
the internal network .... which doesn't exactly have the hostility and
adversary flavor that today's internet can represent.

however, the timesharing service at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

first with cp/67 and then morphing to vm/370 .... had significant
number of MIT, BU and other students with general logins ... and it
also started remote cms\apl service for people from corporate hdqtrs
where they loaded the most valuable and closely guarded corporate
secrets and used the data in all sorts of business modeling
applications. The student population were known for some number of
exploit attempts ... but I know of no situation where corporate
secrets leaked out via that avenue.

lots of the internet vulnerabilities have been

1) buffer related exploits specifically associated w/C-language
characteristics

2) some number of production services grew out of student/university
applications which were never designed from the standpoint of business
critical dataprocessing; including extremely simple & trivial
debug/testing features that allowed complete remote take-over of the
application.

there were a significant number of secure cp/67 and then vm/370
operations.  the platforms were used for general commercial
time-sharing service offerings ... where you might actually have
business competitors using the same platform with the possibility of
corporate secrets leaking if things weren't secure
http://www.garlic.com/~lynn/subtopic.html#timeshare

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Mon, 16 Aug 2004 17:45:02 -0600

Brian Inglis writes:

Poor programmers blame their tools, and poor programming practices
should not be blamed on the language, rather blame the programmers who
don't understand what they're doing, and the library functions they're
using.
I really don't understand how these problems can still occur, as they
were known about in the 1980s, and the functions that allow them were
strongly deprecated even then, although they are still around for
backward compatability.
If the code had been written in a different language, that language
would have been blamed, but it would be unlikely to happen, as most
other languages don't allow that level of functionality to be
developed.
Had the code been written in assembler, it would just be called a bug,
but I'm sure there would also have been plenty of other, bigger issues
to worry about.
If people have problems with a language, they shouldn't use that
language, they should switch to another one instead of complaining.

the multics scenario with PLI have substantiated claim of doing
operating system and not having any buffer exploits.

the issue wasn't so much the language per se ... but the language
conventions for length handling.

the PLI language supported length handling conventions that were
explicit ... and interfaces used them as such.

by comparison cp/67 and vm/370 was all assembler language .... but
they also had convention of everything having explicit lengths and
some number of the standard functions all did validity checking on the
explicit lengths as a matter of course. Explicit lengths were always
carried and always used.

It is as much a system convention as a language thing ... since it
would be possible to have assembler with totally different conventions.

in the 360 genre case ... it was carried into the hardware i/o
interface. all input/output operations involved explicit lengths ...
and completions indicated resididual counts (if any). the i/o routines
as a matter convention tended to consistently pass the original length
minus residual length as part of all input/output (i.e. input string
carried with it the actual length read .... buffers tended to have max
size of buffer and current actual length in buffer. in addition to
explicit programming that was validating all the lengths
appropriately, most of the library functions were also always
explicitly validating operations with respect to length.

so technically .... it isn't c language per se .... it is standard c
programming conventions, c programming libraries, c programming
practices. it is somewhat like saying that cars don't cause automobile
accidents ... people cause automobile accidents .... and if people
would stop driving ... we would stop having traffic fatalities.
however, I recently saw something about safer cars and possibly 40
some percent of traffic fatalities involve not having seatbelt on.  i
would assert that not having explicit lengths permeate the whole
infrastructure is a lot like not wearing seatbelt.

one of the things we did when we started ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

was detailed vulnerability analysis of whole lot off issues. one of
the things that we predicted was something like at least a two order
magnitude increase in buffer related exploits/vulnerabilities than
what we were use to in non-C-based implementations.

various postings related to the multics stuff
http://www.garlic.com/~lynn/2002e.html#47 Multics_Security
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#58 The next big things that weren't
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002p.html#6 unix permissions
http://www.garlic.com/~lynn/2002p.html#15 Multics on emulated systems?
http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
http://www.garlic.com/~lynn/2003j.html#4 A Dark Day
http://www.garlic.com/~lynn/2003k.html#3 Ping:  Anne & Lynn Wheeler
http://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#1 Password / access rights check
http://www.garlic.com/~lynn/2003o.html#5 perfomance vs. key size
http://www.garlic.com/~lynn/2004b.html#51 Using Old OS for Security
http://www.garlic.com/~lynn/2004f.html#20 Why does Windows allow Worms?
http://www.garlic.com/~lynn/2004h.html#2 Adventure game (was:PL/? History (was Hercules))

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

Many engineers lack even a four-year degree

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Many engineers lack even a four-year degree
Newsgroups: alt.folklore.computers
Date: Mon, 16 Aug 2004 20:56:49 -0600

More than one-fifth of U.S. science and engineering workers have less
than a bachelor's degree, according to a new report from the National
Science Foundation.
http://news.com.com/Many+engineers+lack+even+a+four-year+degree/2100-1022_3-5312309.html?tag=nefd.top

....  The number of science and engineering doctorate degrees produced
in the United States dropped from 27,300 in 1998 to 24,550 in 2002. And
that figure may decline further thanks to fewer educational visas
issued and fewer applications to graduate schools from international
candidates, who earn a large portion of tech-related doctorates at
U.S. schools

<snip>

some past related threads in this n.g.
http://www.garlic.com/~lynn/2002e.html#1 More on Aging Legacy Workforce
http://www.garlic.com/~lynn/2002k.html#41 How will current AI/robot stories play when AIs are real?
http://www.garlic.com/~lynn/2003g.html#48 Lisp Machines
http://www.garlic.com/~lynn/2003i.html#28 Offshore IT
http://www.garlic.com/~lynn/2003i.html#45 Offshore IT
http://www.garlic.com/~lynn/2003p.html#33 [IBM-MAIN] NY Times editorial on white collar jobs going
http://www.garlic.com/~lynn/2004b.html#2 The SOB that helped IT jobs move to India is dead!

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

Many engineers lack even a four-year degree

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Many engineers lack even a four-year degree
Newsgroups: alt.folklore.computers
Date: Mon, 16 Aug 2004 21:13:26 -0600

and a related article from last Dec.

What's up, Doc? Not the number of science Ph.D.s
http://news.com.com/What%27s+up%2C+Doc%3F+Not+the+number+of+science+Ph.D.s/2100-7337_3-5113634.html?tag=nl

A sizable chunk of the science and engineering doctorates went to
non-U.S. citizens, according to the NSF. Of 23,152 doctorates awarded
to students whose citizenship was known, 8,839 went to
non-U.S. citizens. In engineering alone, foreign-born persons
receiving doctoral degrees last year represented more than 60 percent
of the total, according to the NSF. Between 1993 and 2002, foreign
citizens earned just more than 57 percent of all engineering
doctorates, the NSF said.

<snip>

and ten days ago:

Brain drain in tech's future?
http://news.com.com/Brain+drain+in+tech%27s+future%3F/2100-1008_3-5299249.html?tag=st.rn

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Tue, 17 Aug 2004 07:34:25 -0600

Brian Inglis writes:

Change the local convention to only use the explicit length
interfaces, and disallow using the zero terminated interfaces.
Good C programming practices require honouring both interfaces, by
using explicit lengths, and also providing a nul character terminator
in text strings, to support legacy code that might be used by other
routines, until that code can be replaced.

various efforts to make that happen has been going on for possibly 15
years ... whole new generations of programmers have come on the scene
during that time ... and it is still happening.

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

A quote from Crypto-Gram

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A quote from Crypto-Gram
Newsgroups: sci.crypt
Date: Tue, 17 Aug 2004 07:56:36 -0600

Jeff Williams writes:

Back in the 70s and 80s, some computers (not so much micros as
mainframes, minis, and special purpose machines) had the microcode in
ROM, so microcode was modifiable.  Note that it was a serious,
hands-on process.  Modifications were typically done by the
designers/maintainers of the machines, not the users (having been both
a designer and a user, I distinguish between the two terms).

When I was in university (early 80s), I heard of machines (at Xerox
PARC, IIRC) that had downloadable microcode for the purpose of
modifying the instruction set on the fly.  Never saw such machines -
just heard about them from my profs.

lots of posts about designing and implementing various mcode, 60s,
70s, 80s
http://www.garlic.com/~lynn/subtopic.html#mcode

some number of the ones i worked on were designed as enhancements for
operating system performance assists. the low-end machines typically
had vertical mcode that typically is similar to familiar machine code
programming paradigm. the high-end machines frequently were horizontal
mcode ... wide words, where bits on/off activated specific machine
functions like fetch to register. single instruction might activate
several functions simulataneously ... although programming had to
explicitly know about latencies in various functions
.... i.e. fetching a value to register might take several machine word
cycles and from the start of the fetch to the actual use of the value
had to be separated by several instructions.

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Tue, 17 Aug 2004 09:56:39 -0600

Alan Balmer writes:

That's because there are good reasons to use zero-terminated strings.
They're only dangerous if not properly used.

this is like the line from somebody about

in theory, there is no difference between theory and practice, but in
practice there is.

in general .... implicit anything almost always results in some number
of glitches. i assert that there is fundamental threat model associated
with implicit lengths ... and the countermeasure is explicit lengths.

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

A quote from Crypto-Gram

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A quote from Crypto-Gram
Newsgroups: sci.crypt
Date: Tue, 17 Aug 2004 10:27:06 -0600

Michael Amling writes:

The nefarious aspect is that once the black hat has the microcode
in place, it would still work after the victim had run virus scans,
re-installed the OS, reformatted all disks, etc.
The microcode might be triggered by an instruction sequence that
occurs normally. Perhaps it could recognize when some authorization
routine is running and do something that would cause BH to be
authorized.

there is the famous story about hack on the c-compiler that would put
backdoor in unix logon (the compiler would recognize the module
and insert backdoor in the code).

a similar ... but different tale (from 30+ years ago)
http://www.garlic.com/~lynn/2004g.html#45

except i manually flipped a bit in instruction from the front panel
and voila no matter what you did ... it was treated as correctly
authenticated. this isn't unlike the counterfeit yes cards that have
started showing up (also referenced in above URL).

the trusted computing platform/module stuff had defined some number of
protected secure hash locations that can be initialized.  one is for
the bios ... and on boot the secure processor calculates the secure
hash on the bios and verifies against the saved value (to try and
catch corruption).

this isn't unlike the tripwire methodology for periodically checking
the integrity of files.

mainframes have tended to have various kinds of ECC (not the crypto
kind) for recognizing microcode corruption (regardless of the source).

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

A quote from Crypto-Gram

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A quote from Crypto-Gram
Newsgroups: sci.crypt
Date: Tue, 17 Aug 2004 10:52:20 -0600

remember shugart's original invention of the floppy disk was for
loading mcode into the 3830 disk controller. it was then also used
for mcode loading on a number of mainframe machines ... in addition
to other controllers

random shugart past posts
http://www.garlic.com/~lynn/2000.html#9 Computer of the century
http://www.garlic.com/~lynn/2002.html#17 index searching
http://www.garlic.com/~lynn/2002l.html#50 IBM 2311 disk drive actuator and head assembly
http://www.garlic.com/~lynn/2004.html#5 The BASIC Variations

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

Vintage computers are better than modern crap !

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Vintage computers are better than modern crap !
Newsgroups: alt.folklore.computers
Date: Wed, 18 Aug 2004 06:54:48 -0600

Steve O'Hara-Smith writes:

There are indeed such languages, however they are a lot less
efficient than C code that assumes the buffer will not be
overflowed.  In these days of processors with clocks running at
microwave frequencies this is less important than it used to be just
as in these days of script kiddies and widespread viral attacks
protecting against buffer overflow is more important than it used to
be.

in addition to reports that say there are other systems/infrastructures
that are almost buffer exploit free.

in the late 90s ... there was a report that said that the majority
of all exploit/vulnerabilities were buffer exploits (almost unique to
the c language programming environment).

last year, i was on panel discussion with some fbi cyber forensic guy
who said that exploit/vulnerabilities they had been seeing were 1/3rd
buffer overflow, 1/3rd virus/trojanhorse/email, 1/3rd social
engineering. the social engineering issue has always been around. lots
of exploit & vulnerability related posts
http://www.garlic.com/~lynn/subintegrity.html#fraud

to some extent the virus/email it taking something that was pretty
much infrastructures that had original design point of stand-alone
(say running games on kitchen table) or small departmental groups
... and hooking them up to the internet environment that involve large
numbers of people with very different and diverse objectives. somewhat
the closest similar environment from earlier ages with diverse groups
with different objectives were some of the large commercial time-sharing
systems ....
http://www.garlic.com/~lynn/subtopic.html#timeshare

also, note that to some extent the 1/3rd distribution numbers are
probably specifically with respect to outsider attacks. in the past
(before all the internet oriented attention) the frequent number was
that 90 percent of the fraud involved insiders (not specified whether
that was in terms of incidents or total dollar value). there is recent
study that for identity theft fraud ... at least 77 percent of the
incidents involved insiders.

as part of trying to add some more to the exploit & vulnerability
taxonomy that i've got in my merged security taxonomy & glossary ...
http://www.garlic.com/~lynn/index.html#glosnote

i've looked at the cve database to see what exploit & vulnerability
structural information i could pull out of it. the entries and notes
in the cve database are pretty free form ... so what i've mostly come
up with is word count & word-pair counts on the entries.

in any case, if you have some number of environments (that range from
machine language coding to very high level languages) where certain
kind of exploit & vulnerability has almost never been known to occur
...  and another specific environment ... where a specific kind of
exploit & vulnerability is extremely pervasive .... one might come to
believe that the difference is more than simply quality of the
programming.

at this point ... one might believe that the infrastructure costs
because of buffer exploit and vulnerability is significantly larger
than any possible programming productivity that might come from
implicit length paradigm ... which is somewhat unique characteristic
of the c language environment ... compared to some number of other
environments that have almost never seen a buffer
exploit/vulnerability.

misc. posts related to cve database analysis
http://www.garlic.com/~lynn/aadsm18.htm#10 E-commerce attack imminent; Sudden increase in port scanning for SSL doesn't look good
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE
http://www.garlic.com/~lynn/2004f.html#20 Why does Windows allow Worms?
http://www.garlic.com/~lynn/2004h.html#2 Adventure game (was:PL/? History (was Hercules))

misc. posts related to social engineering and other vulnerabilities
http://www.garlic.com/~lynn/aadsm14.htm#9 "Marginot Web" (SSL, payments, etc)
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm16.htm#2 Electronic Safety and Soundness: Securing Finance in a New Age
http://www.garlic.com/~lynn/aadsm16.htm#7 The Digital Insider: Backdoor Trojans ... fyi
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#58 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm3.htm#cstech10 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm8.htm#softpki3 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki7 Software for PKI
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/2002g.html#82 Future architecture
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
h