massive data theft at MasterCard processor

[Anne & Lynn Wheeler]

James A. Donald wrote:
> Rather the server should send out some encrypted random
> data which the end user decrypts.  End user should then
> prove knowledge of that encrypted data. 

so the random data is sent encrypted with the person's public key ...
they can decrypt it with their private key. so the random data could
contain someting like a session key. they send back the random data
encrypted with the random session key. this demonstrates possesion of
the private (aka "something you have" authentication). this avoids
having to perform digital signatures on perported random data for pure
authentication operations (never digital sign random data ... only
digital sign what, you, yourself have personally created).

For pure authentication operations ... this model eliminates the whole
digtital certificate paradigm ... since the model assumes that the
originator of the authentication request already has the recipients
public key recorded someplace.
http://www.garlic.com/~lynn/subpubkey.html#certless

this has also been the suggestion for optimized SSL modification to use
public keys registered with the domain name infrastructure. public key
and SSL options are registered with the domain name infrastructure. An
optimized DNS call returns the ip-address and any public key and SSL
options as optional piggyback on the same transaction. the client
generates the random session key ... and on the initial packet,
transmits the random session key encoded with the server's registered
public key ... along with the initial packet of data encrypted with the
generated random session key. the server returns the response encrypted
with the generated random session key. For real transaction oriented
operations, you could even do this with UDP and a single send followed
by single response (plus the DNS send/reponse).

the SSL domain name certificate infrastructure was targeted as
countermeasure for perceived integrity issues with the domain name
infrastructure. somebody would apply to CA for SSL domain name
infrastructure, they would check with the domain name infrastructure if
the applicant was the valid owner of the domain name ... and then issue
the SSL domain name infrastructure. the problem of course, is that the
domain name infrastructure then is still the trust root as to who gets
issued SSL domain name infrastructure ... the very same domain name
infrastructure that was perceived to have integrity problems generating
the requirement for SSL domain name infrastructure.

So somewhat from the CA industry to help close various vulnerabilities
in the domain name infrastructure, there has been suggestion that domain
name owners register their public key. this helps with using the domain
name infrastructure as the "trust root" for the CA industry related to
domain name ownership and valid applicants for SSL domain name
infrastructure. this also helps the CA industry, where they can change
an expensive, time-consuming and error prone identification matching
operation (checking the applicant's identification against the
identification on file for the domain name owner with the domain name
infrastructure) to a much simpler and reliably authentication operation
(have the applicant digitally sign the SSL domain name application,
retrieve the on-file public key and validate the digital signature).

this, then creates the catch-22 for the CA industry for SSL domain name
certificates (aka if the CA industry can use certificateless, onfile
public keys for their purposes ... why can't the rest of the world).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com