Re: the limits of crypto and authentication

[Anne & Lynn Wheeler]

Ram A Moskovitz wrote:
> Did you consult for First Data Corp. at the time?

some reference:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

little later, we got to review chaum and brand stuff. brand had done a
take-off on chaum's stuff so that if somebody double-spent (aka fraud)
... the financial institution could determine who did it (basically a
form of solving two equations in two unknowns).


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: the limits of crypto and authentication

[Anne & Lynn Wheeler]

Aram Perez wrote:
> One other point, SET did NOT require certs for the consumers. The 
> client-merchant protocol supported clients without certs.

there was a later "set-lite" w/o certs for clients ... but the original
specification had client certs as part of the core process.

note that the SET consumer certificate was *NOT* a x.509 identity
certificate ... because of stated reasons regarding privacy and
liability. It was a relying-party-only certificate that basically
contained the account number and the public key
http://www.garlic.com/~lynn/subpubkey.html#rpo

It was also, not a true PKI ... since it didn't have any certificate
administration and management infrastructure. It was purely a
*certificate manufactoring* process (a term we had coined to
differentiate the early SSL certificate operations from what had been
defined for a PKI operation). Further, the statement was that they could
get by w/o a PKI operation ... since it was purely a "certificate
manufactoring" process using relying-party-only certificates (containing
just the public key and account number), the business process could be
managed by deactivating the account number in the *real*, real-time,
online operation.

quicky search engine for set-lite:
http://iugsun.cs.uni-dortmund.de/lehre/datenschutz/material/folien/dsss2004-5-ecommerce.pdf
http://www.it.murdoch.edu.au/~smr/honours/admin/info/DavidsProposal.html
http://www.indiainfoline.com/bisc/ieps.html
http://www.networkworld.com/archive/1999/61423_03-22-1999.html

from above:

When MasterCard and Visa unveiled technology for secure Internet
electronic commerce transactions two years ago, they thought it would
take over the world.

But while Secure Electronic Transaction (SET) has made inroads in Europe
and Asia, it has faltered badly in the U.S. Faced with technical and
business obstacles to SET, MasterCard and Visa are now coming up with
alternatives to SET - SET Lite and Merchant-originated SET (MOSET).

But SET Lite and MOSET critically alter the SET 1.0 architecture and
soften SET's rock-hard security - all for the sake of convenience. For
example, the technologies abandon the idea that each online consumer is
going to have a bank-issued SET digital certificate for credit-card
encryption. This certificate was to be the main means of verifying the
consumer's real identity on the Internet.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: the limits of crypto and authentication

[Ram A Moskovitz]

On 7/14/05, Anne & Lynn Wheeler <[EMAIL PROTECTED]> wrote:

remember what Verisign was called before it was renamed Verisign?
Digital Certificates International, Inc. 

Did you consult for First Data Corp. at the time?

Re: EMV and Re: mother's maiden names...

[Ed Gerck]

Well, the "acceptable risk" concept  that appears in these two
threads has been for a long time an euphemism for that business
model that shifts the burden of fraud to the customer.

The dirty little secret of the credit card industry is that they
are very happy with 10% of credit card fraud, over the Internet or not.

In fact, if they would reduce fraud to _zero_ today, their revenue
would decrease as well as their profits. So, there is really no
incentive to reduce fraud. On the contrary, keeping the status
quo is just fine.

This is so because of insurance -- up to a certain level,
which is well  within the operational boundaries of course,
a fraudulent transaction does not go unpaid through VISA,
American Express or Mastercard servers.  The transaction is
fully paid, with its insurance cost paid by the merchant and,
ultimately, by the customer.

Thus, the credit card industry has successfully turned fraud into
a sale.  This is the same attitude reported to me by a car manufacturer
representative when I was talking to him about simple techniques
to reduce car theft -- to which he said: "A car stolen is a car sold."
In fact, a car stolen will need replacement that will be provided by
insurance or by the customer working again to buy another car.  While
the stolen car continues to generate revenue for the manufacturer
in service and parts.

Whenever we see continued fraud, we should be certain: the defrauded
is profiting from it.  Because no company will accept a continued  loss
without doing anything to reduce it. Arguments such as "we don't
want to reduce the fraud level because it would cost more to reduce the
fraud than the fraud costs" are just a marketing way to say that
a fraud has become a sale.

Because fraud is an hemorrage that adds up, while efforts to fix it --
if done correctly -- are mostly an up front cost that is incurred only
once.  So, to accept fraud debits is to accept that there is also a credit
that continuously compensates the debit. Which credit ultimately flows
from the customer -- just like in car theft.

What is to blame? Not only the twisted ethics behind this attitude but
also that traditional security school of thought which focus on risk,
surveillance and insurance as the solution to security problems.

There is no consideration of what trust really would mean in terms of
bits and machines[*], no  consideration that the insurance model of
security cannot scale in Internet volumes and cannot even be ethically
justifiable.

"A fraud is a sale" is the only outcome possible from using such security
school of thought.  Also sometimes referred to as "acceptable risk" --
acceptable indeed, because it is paid for.

Cheers,

Ed Gerck

[*] Unless the concept of trust in communication systems is defined in
terms of bits and machines, while also making sense for humans, it really
cannot be applied to e-commerce. And there are some who use trust as a
synonym for authorization. This may work in a network, where a trusted
user is a user authorized by management to use some resources. But it
does not work across trust boundaries, or in the Internet, with no
common reporting point possible.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: the limits of crypto and authentication

[Anne & Lynn Wheeler]

a harder problem for early stage web merchants was getting a merchant
financial institution  the merchant financial institution that
sponsors a merchant for payment transactions ... takes financial
responsibility for that merchant.

the standard procedure was to send somebody out to the retail
brick&morter and do an asset inventory ... to see if the merchant went
under ... that there would be enuf assets left to help cover the
merchant financial institutions losses.

retail web merchants might have nearly zero assets ... they leased time
with a webhosting and fulfillment was outsourced ... so there was no
onhand inventory and effectively no assets. if they were totally
unsuccesful ... then the merchant financial institution would have
little outstanding transaction financial liability.

there were cases where merchant financial institution would try and
cancel a merchant as it became succesful ... since the outstanding
transaction liability for the merchant financial institution could be
going way up ... with no increase in assets to cover the finanical
institution's outstanding liability.

for such "high risk" merchants ... the merchant financial institution
discount might actually be bigger than the MOTO discount ... or any
difference between MOTO and card-present.

early web merchants tended to be existing brick&morter operations where
web MOTO ("mail-order/telephone-order") transactions were not separated
out from non-web MOTO transactions.

there were all sorts of strategy meetings in the '95 time-frame, brain
storming about how to get a bank's financial risk department to even
approve purely web merchant signup (and MOTO vis-a-vis card-present
wasn't a primary issue).

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: mother's maiden names...

[Ben Laurie]

Peter Gutmann wrote:

"Perry E. Metzger" <[EMAIL PROTECTED]> writes:



Why is it, then, that banks are not taking digital photographs of customers
when they open their accounts so that the manager's computer can pop up a
picture for him, which the bank has had in possession the entire time and
which I could not have forged?



I don't know about photos specifically, but I know that signature imprints are
often still moved around by laborious manual means because the background
infrastructure to handle images doesn't exist.


My bank doesn't even bother to move them around, as I discovered when I 
had a chequebook stolen and cheques for large sums forged, and honoured.


When I spoke to a person who had found the cheque in their store I asked 
"is it my signature?" (yes, I am sufficiently absent-minded that I might 
have written a large cheque and forgotten about it). Their response was 
that they didn't know and had no way to find out. In the end they faxed 
me a copy so I could check it myself.


Cheers,

Ben.

--
>>>ApacheCon Europe<<<   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: the limits of crypto and authentication

[Ben Laurie]

Perry E. Metzger wrote:

Ben Laurie <[EMAIL PROTECTED]> writes:


Perry E. Metzger wrote:


Anonymity is a concern to me, too, but I suspect that it is hard to
get anonymity in a credit card transaction using current means, even
if the merchant isn't online. Pseudonymity, perhaps.


Can we not aim higher than merely doing as badly as current systems do?



I think that by eliminating the need for a merchant to learn
information about your identity I have aimed higher. Given that we're
talking about credit instruments, however, it may be difficult to
eliminate the need for the issuer to track transactions. However,
given the way I've described the protocol, it would be possible to use
a variant on it for digital cash purses without the merchant being
impacted. It isn't clear to me, though, who would issue such things in
the current environment.


You never know who might do stuff if its easy for them to do so. Make it 
hard, and you can be more confident they won't.


But I'm glad to hear we're not in opposition on this.

Cheers,

Ben.

--
>>>ApacheCon Europe<<<   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: mother's maiden names...

[Peter Gutmann]

Ian Brown <[EMAIL PROTECTED]> writes:
>Steven M. Bellovin wrote:
>>>Cambridge Trust puts your picture on the back of your VISA card, for
>>>instance. They have for more than a decade, maybe even two.
>>
>> One New York bank -- long since absorbed into some megabank -- did the
>> same thing about 30 years ago.  They gave up -- it was expensive then,
>> and may not have solved any real problems.  (Possibly, it simply didn't
>> fit their real purpose of attracting more customers.)
>
>They don't for example seem to reduce fraud -- shop staff don't compare
>the photo to the customer carefully enough:
>
>R. Kemp, N. Towell, G. Pike, "When seeing should not be believing:
>Photographs, credit cards and fraud," Applied Cognitive Psychology Vol
>11(3) (1997) pp 211-222.

For those who haven't seen this study, it's an important read (it's also been
re-published in a somewhat more accessible journal, perhaps it was CACM?).
What they did was send students into a supermarket with card photos of either
them, someone who looked vaguely like them, or someone who looked nothing like
them.  Both the FRR and FAR were found to be such that the photo IDs were more
or less worthless for fraud prevention.  Some banks over here started to
introduce photos on cards, but dropped the scheme based on this study and
other research which showed that it wasn't worth it: The photos were too small
to be useful, only customs & immigration staff and to a lesser extent police
have any formal training in matching faces to images, and your typical
minimum-wage checkout operator couldn't care less if the image matched or not,
their incentive was to move shoppers through quickly, not to check IDs.

Peter.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: the limits of crypto and authentication

[Anne & Lynn Wheeler]

Rich Salz wrote:

I was told that one of the reasons SSL took off was because Visa and/or MC
told merchants they would "for the time being" treat SSL as card-present,
in terms of fraud penalties, etc.  If this is true (anyone here verify?
My source is on the list if s/he wants to name themselves), then SSL/SET
is an interesting example of betting on both sides.


I only know of MOTO ... the original netscape e-store and merchants 
processed thru the original payment gateway.

http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

SSL originally just provided for webserver authentication. while we 
mandated mutual authentication for SSL between webservers and the 
payment gateway (before there was even a specification for mutual 
authentication). Information about the respective other end-point were 
preloaded in the respective servers ... so the use of digital 
certificates was purely an artificial artifact of the existing code base.


However, normal merchant webserver operation for SSL was purely 
one-sided authentication ... there was no form of client authentication 
that would provide any kind of basis for either cardholder-present or 
card-present.


There is something for being there first, starting late 94 ...
http://scout.wisc.edu/Projects/PastProjects/NH/95-03/95-03-27/0016.html

remember what Verisign was called before it was renamed Verisign?

SET prototype shows up early fall 96 with dedicated demo systems 
appearing at conferences late '96 (dedicated demo systems taking 30 
seconds elapsed time to perform transaction).


Two of the major risks and vulnerabilities that have been discussed are 
evesdropping on data-in-flight ... and data breaches at merchant 
databases ... old post on security proportional to risk

http://www.garlic.com/~lynn/2001h.html#61

both SSL and SET addressed confidentiality of data-in-flight. Neither 
SSL nor SET addressed data breaches at merchant databases.


Going on in parallel with webservers doing MOTO transactions thru the 
payment gateway  you also found some number of webservers doing 
emulated POS terminal dialup operations (also MOTO transactions). Some 
number of vendors were peddling software that was originally developed 
to run on PCs and autodial merchant processor (effectively emulated POS 
terminal dial) ... software originally targeted for hotels, casinos, etc.



... from long ago and far away:

Date: Sat, 24 Feb 1996 17:08:01 -0500 (EST)
From: H Morrow Long <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Draft SET Standard/specs now online at MC and Visa

The new SET (Secure Electronic Transaction) draft standard/
specs are now online at VISA and Mastercard for downloading.

The draft docs were just released yesterday (Feb 23).

The docs are available in Word and Postscript file formats
for Windows, Unix and the Mac.

Check out:

http://www.mastercard.com/set/set.htm
http://www.visa.com:80/cgi-bin/vee/sf/standard.html?2+0

The Web pages also have information on how to subscribe to
the set-discuss mailing list.

- Morrow


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: the limits of crypto and authentication

[Aram Perez]

On Jul 14, 2005, at 8:13 PM, Rich Salz wrote:


If you had two products ... both effectively performing the same
function, one you already had deployed, which was significantly  
cheaper,
significantly simpler, and significantly faster, which one would  
you choose?


I was told that one of the reasons SSL took off was because Visa  
and/or MC
told merchants they would "for the time being" treat SSL as card- 
present,
in terms of fraud penalties, etc.  If this is true (anyone here  
verify?
My source is on the list if s/he wants to name themselves), then  
SSL/SET

is an interesting example of betting on both sides.


On the contrary, merchants were (and maybe still are) being charged  
MOTO (mail order/telephone order) rates for using SSL. Even SET was  
going to charge MOTO rates until just before it was finalized. The  
payment card companies weren't getting enough interest for SET and  
decided to offer card-present rates to get more interest in SET. SSL  
took off because it was free, in over 90% of the browsers (Netscape  
own the browser market then), and it was easy to integrate into  
shopping carts. As a merchant, basically your only cost was your  
VeriSign cert.


But you are correct in that the payment card companies were in an  
interesting position: on one hand they charge higher rates for using  
SSL but on the other hand, the "perception" was that something more  
secure than SSL was needed.


One other point, SET did NOT require certs for the consumers. The  
client-merchant protocol supported clients without certs.


Respectfully,
Aram Perez


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: the limits of crypto and authentication

[Rich Salz]

> If you had two products ... both effectively performing the same
> function, one you already had deployed, which was significantly cheaper,
> significantly simpler, and significantly faster, which one would you choose?

I was told that one of the reasons SSL took off was because Visa and/or MC
told merchants they would "for the time being" treat SSL as card-present,
in terms of fraud penalties, etc.  If this is true (anyone here verify?
My source is on the list if s/he wants to name themselves), then SSL/SET
is an interesting example of betting on both sides.
/r$
-- 
Rich Salz  Chief Security Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: EMV [was: Re: Why Blockbuster looks at your ID.]

[Joseph Ashwood]

- Original Message - 
From: "Victor Duchovni" <[EMAIL PROTECTED]>

Subject: Re: EMV [was: Re: Why Blockbuster looks at your ID.]



Whose loses do these numbers measure?

- Issuer Bank?

- Merchant?

- Consumer?

- Total?


I'd say that you've fairly well hit the nail on the head. I've actually been 
meaning to reply to this for about a week now. The truth is that each credit 
card transaction actually has either 3 or 4 parties; User U, Merchant M, 
Credit Card Issuer CCI, and Merchant Insurer MI (this is simplified there 
are generally multiple parties under CCI).


Under legitimate circumstances the process is fairly simple; Legitimate User 
LU agrees to pay CCI, CCI already has an agreement to pay M, and M supplies 
the product/service to LU. During billing LU pays CCI, CCI pays M, everyone 
is happy.


Things are different in the case of False User FU. FU goes to M, FU agrees 
for LU to pay CCI, CCI (believing FU is LU) agrees to pay M, M supplies the 
product/service to FU. During billing is where things get strange. LU 
reports the bad transaction to CCI. CCI informs M and does not pay M. FU 
gets the product, M accepts the loss. In the normal case MI and M are the 
same entity so the buck stops there, if MI is seperate from M, then MI 
reimburses M for some portion.


It's important to understand exactly who loses what when FU is in the 
picture. CCI loses the commision, generally a small flat fee on the order of 
$0.35, and a percentage generally <2%, this is not a large amount to lose, 
and the phone call to report the problem actually costs more than is lost, 
followed by the filing and tracking of the correct paperwork, this is the 
ACTUAL loss for CCI. MI loses the cost of the product/service reimbursed. LU 
loses basically nothing except time. FU obviously gains.


The point being that expecting CCI to foot a multi-billion dollar bill to 
change the process so that MI doesn't lose the money doesn't make sense. CCI 
will only work to increase CCIs profits. It is up to MI to pay for the 
upgraded systems by working with CCI towards CCIs goals (fewer losses for MI 
also means fewer reports to CCI so fewer losses). LU may be willing to foot 
part of the bill for the perceived improvements, CCI will only foot the 
portion that is in CCIs favor, MI will have to foot the majority of the bill 
and will only do so when it is in MIs favor. With credit card fraud 
decreasing, it is not in MIs favor to examine it at this time.
   Joe 




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Jerrold Leichter]

| Date: Wed, 13 Jul 2005 16:08:20 -0400
| From: John Denker <[EMAIL PROTECTED]>
| To: Perry E. Metzger <[EMAIL PROTECTED]>
| Cc: cryptography@metzdowd.com
| Subject: Re: ID "theft" -- so what?
| ...
| Scenario:  I'm shopping online.  Using browser window #1, I
| have found a merchant who sells what I want.   in the checkout
| phase.
| 
| Now, in browser window #2, I open a secure connection to my
| bank.  The bank and I authenticate each other.  (This is
| two-way authentication;  one possible method is SSL certificate
| on the bank's part, and a password or some such on my part.)
| 
| ...
| As a refinement, I could ask the bank to issue a number that
| was not only restricted to a single use, but also restricted
| as to dollar amount.  As a further refinement, it could be
| restricted to a particular merchant.
| 
| Everything to this point is upward-compatible with existing
| systems.  The merchant doesn't even need to know there's
| anything special about this card number;  the charge moves
| through existing processing channels just like any other.
| 
| As a further refinement, once the system is established,
| the merchant could provide, on the checkout page, a number
| that encodes in some standard format various details of
| the transaction:  merchant ID, date, dollar amount, and
| maybe even a description of the goods sold.  I cut-and-paste
| this code from the merchant to the bank, and let the bank
| site decode it.  If it looks correct, I click OK and then
| the bank generates a response that the merchant will
| accept in payment.  If necessary I can cut-and-paste this
| from the bank to the merchant ... but it would make more
| sense for the bank to transmit it directly to the merchant.
| This further increases security, and also saves me from
| having to enter a lot of billing detail
In effect, what you've done is proposed a digital model of *checks* to
replace the digital model of *credit cards* that has been popular so far.
In the old days, paper checks were considered hard to forge and you were
supposed to keep yours from being stolen.  Your physical signature on the
check was considered hard to forge.  Checks were constructed in a way
that made made alteration difficult, binding the details of the transaction
(the payee, the amount being paid) and the signature to the physical
instrument.

There was a time when checks were accepted pretty freely, though often with
some additional identification to show that you really were the person whose
name was on the check.

Credit cards and credit card transactions never bound these various features
of the transaction nearly as tightly.  Stepping back and looking at the
two systems, it seems that using the check model as the starting point for
a digital payment system may well be better than using credit cards, whose
security model was never really as well developed.  When I handed a check to
a vendor, I had (and to this day have) excellent assurance that he could
not change the amount, and (in the old days) reasonable assurance that he
could not create another check against my account.  (Given digital scanners
on the one hand, and the "virtualization" of the check infrastructure, from
the ability to initiate checking transactions entirely over the phone to
check truncation at the merchant on the other, this is long gone.  It would be
nice to recover it.)
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[Ian Grigg]

On Thursday 14 July 2005 15:45, Aram Perez wrote:
> Why do cryptography folks equate PKI with  
> certificates and CAs?

Because it's the major example of what most would
agree is PKI, I'd guess.  When we talked to people
in the certs and CAs world, they call it PKI.  They
refer to lots of documents, which call it the PKI.  The
business model of PKI vendors used to at least be
partly based on selling certs.  It's an assumption
they make or made.

(John Kelsey answered this very well.)

> This fallacy is a major "root cause" of the   
> problem IHO. Why was the term "PKI" invented in the  late 70s/early  
> 80s (Kohnfelder's thesis?)?. Before the invention of asymmetric  
> cryptography, didn't those people who used symmetric cryptography  
> need an SKI (secret key infrastructure) to manage keys? But no one  
> uses the term SKI or talks about how to manage secret keys (a very  
> hard problem).

Exactly.

> Anytime you use any type of cryptography, you need an   
> "infrastructure" () to  
> manage your keys, whether secret or public. There are at least two  
> public key infrastructures that do NOT require CAs: PGP and SPKI. But


There is a sort of doublethink here - when people
look down their nose at PKI from the PGP side,
the PKI side is sometimes at pains to say that PGP's
WoT is a PKI.  Yet when the converse happens
and PGP pundits suggest using WoT with (e.g.,)
x.509 certs, the PKI people say "WoT is not PKI."

Personally, I call "what PGP does" a Web of Trust.
And I call what browsers do a PKI.  The fact that
there is "trust" in PKI and there is "infrastructure"
in WoT is an issue, yes, but we have to have some
sense of differentiation;  and those terms are what
the people in those fields tend to be comfortable
with.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: ID "theft" -- so what?

[James A. Donald]

--
> > This is yet more reason why I propose that you 
> > authorize transactions with public keys and not with 
> > the use of identity information.

Dan Kaminsky <[EMAIL PROTECTED]>
> It's 2005, PKI doesn't work, the horse is dead.

The PKI that was designed to serve no very useful 
function other than make everyone in the world pay $100 
a year to Verisign is dead.

Yet the technology is potent, and the problems of 
identity and authenticity are severe.  We shall, bye and 
bye, see reliance on public keys.  Other things just 
don't work.

At present, the overwhelming majority of money transfers 
take place over non internet networks, and rely on non 
internet identity.  Inevitably, this will change, and 
that change will both necessitate, and be based on, the 
use of public key cryptography. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 Pmf2aYMPVGY8UHBvEyuLghf0GsgeyEonN9O9Ljh+
 4j9GQPHtedEznyhC2w4YbCu38yJe2dOsSNGUyV3fL



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]