Re: mother's maiden names...

[J]

--- Dan Kaminsky <[EMAIL PROTECTED]> wrote:

> Bank Of America put my photo on my ATM card back in '97.  They're 
> shipping me a new one right now, so I assume they kept it in the DB.

My local bank asked me apply for a Visa photo credit card back in 1998.
There were two problems though:

1.) Their request really was just that, a request. They told me that I
was free to get a regular card if I was in any way uncomfortable with
the photo card. In retrospect, it seemed more like a "we'd appreciate
it if you could do us a big favor" thing, and not so much like "look,
we're doing this for your own protection". 

The manager I talked to about this also informed me that they were only
asking customers with "high credit lines" (whatever that's supposed to
mean) to get credit cards with pictures since they were more expensive
(apparently, the bank had to eat the majority of the cost; I recall
only paying a $5 one-time fee).

2.) Secondly, checkout clerks just don't care. Well, they actually did
notice the picture on the back of the credit card and asked what it was
about maybe 6 out of 10 times. In most cases, the question resulted in
very pleasant but pointless chit-chat. Noone ever asked me why I didn't
look like the guy in the picture (I had since grown a beard and the
picture was really grainy and low-quality). Noone ever called a manager
to verify my identity despite the fact that it clearly said "Please
verify cardholder's picture." on the back. (I still have one photo
credit card and it no longer says that and has a more up-to-date
picture.)

The problem here was that most check out clerks these days are
teenagers making minimum wage. They care about getting paid, not
getting robbed and not getting hassled. And, frankly, I can understand
that attitude because I felt the same way when I was in high school. 

Having too little cash in the register at the end of the shift stands
out and is likely to get a cashier in trouble. Having a credit card
purchase flagged as fraudulant a week after the fact doesn't cause as
much trouble. That's why there's no incentive to check CCs. It's also
why the Zug.com credit card prank worked so well back in the day.

My gym(!) has quite a different policy - they take a picture of every
member when apply. You may bring a guest but the member has to be
authenticated first and the guest has to sign in. If you forget your
RFID card, they just check the database (or, most likely, they will
recognize you). Any employee who lets people in withot an ID check or
without signing in, gets a warning. Employees get fired after three
warnings. Draconian? Yes. But it does work. And it wouldn't be too hard
for the credit card companies to print "MUST VERIFY ID" onto the back
of new credit cards.

These days, I am on a first name basis with most of the cashiers at the
local grocery stores (which is due to the fact that I'm friends with
their parents who pretty much all live in the same neighborhood as we
do - suburbia and all). But I do remember when we moved here and back
then cashiers really noticed the credit card I had written "PLEASE ASK
FOR ID. THANK YOU." onto. At that time, it was mostly a social
experiment. And, frankly, it didn't work. They noticed (as in "huh,
that's weird") but they never bothered to ask me for ID (as "huh,
that's weird, may I see your ID please, Sir?").


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

Blind Signature Patent Expiration Party this Saturday

[Perry E. Metzger]

Forwarded at Lucky's request:

Date: Thu, 14 Jul 2005 18:28:40 +0200
From: Lucky Green <[EMAIL PROTECTED]>
Subject: Blind Signature Patent Expiration Party this Saturday


Friends, colleagues, and co-conspirators,

It has been 17 long years and now the time is finally here to celebrate at
the:

BLIND SIGNATURE PATENT EXPIRATION PARTY
===

WHAT:
A party to celebrate the expiration of the Blind Signature patent.

WHY:
U.S. Patent 4,759,063 ("Blind Signature Systems") to David Chaum is the
core invention enabling privacy-protecting electronic payment systems and
credentials.  It was a truly ingenious, ground-breaking contribution.
Unfortunately the existence of the corresponding patent, which was
notoriously difficult to license, prevented this great invention from
receiving the wide use that it so very much deserved. For a copy of the
patent, see http://www.pat2pdf.org/pat2pdf/foo.pl?number=4759063

Unlike copyrights these days, patents do expire.  The blind signature
patent will expire on July 19, 2005, next Tuesday.  Since weekends tend to
fit better with the schedules of potential party goers than weekdays, we
are holding the party this Saturday instead.

The 17 years that this patent has been in effect has been an awfully long
time for the many of us that hoped to make use of this technology to help
citizens to maintain privacy in the age of the Internet and the patent's
expiration is a much overdue reason for celebration.

WHO:
If you know what blind signatures are you are invited.

WHEN:
This Saturday, July 16, starting at 1:00 PM PDT

WHERE:
Since the number of inquiries I received in response to the party
pre-announcement exceed the maximum occupancy limit of my home and since
the weather promises to be excellent, we will hold the party in a beer
garden instead. Drinks are on me!

We will meet at the
Alpine Inn (aka Alpine Beer Garden)
3915 Alpine Road, Portola Valley, CA 94028 USA

AWARDS:
Those that can demonstrate that they have created a full system that makes
significant use of the blind signature patent by 4 PM on Saturday will be
invited to and receive a free dinner at the afterparty. So get coding!
(Pr0duct Cypher, where are you)? A team of judges will determine if a
particular system qualifies for the award.

AFTERPARTY:
A handful of us plan to have dinner at a swanky restaurant on patent-free
Tuesday. Email me or talk with me at the party if you are interested in
joining. Space is limited. You will have to pay for your own food at the
Tuesday dinner unless you qualify for the award above or your name is on
the blind signature patent.

Looking forward to see you all this Saturday,
-- Lucky Green <[EMAIL PROTECTED]> PGP encrypted email preferred.

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

Re: the limits of crypto and authentication

[Anne & Lynn Wheeler]

Pat Farrell wrote:
> As others have said, and in the spirit of the subject
> of this thread, SET failed for many reasons, many
> of them economic. There was little effort made
> to bribe the merchants, I think there was talk of
> a 26 basis point change in the discount rate,
> which the banks thought was huge and the merchants
> thought was noise. What really killed it
> was the billions it would have cost all
> the banks to issue and manage all the
> certificates.

this was some of the confusion between identification and
authentication. The SET effort was smart enuf to not do x.509 identity
certificates and instead do relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

and they even made comments about the enormous privacy and liability
issues raised with x.509 identity certificates.

They also avoided doing any sort of PKI infrastructure ... aka the
management and administration of the certificates. The effectively were
doing the same stuff as the original SSL domain name certificates ...
for which we coined the term "certificate manufactoring" (to
differentiate from a certificate administrative and management
operation). They basically said that the certificate only contained the
account number ... and the account number could be turned-off at the
issuing financial institution ... making it redundant and superfluous to
also have to have a separate infrastructure for invaliding the certifcate.

So they have an online infrastructure with real-time transactions and
real-time operation of the real information. It is an extremely trivial
additional step to show that then the certificates themselves are
redundant and superfluous.

The cost of the certificates only become an issue if you are talking
about having to pay a trusted third party, $100/annum for every certificate.

So we can take this in incremental steps.

1) you have the consumer's financial infrastructure register the public
key. they then can generate and issue a relying-party-only certificate
to the consumer (containing the consumer's public key and account number).

2) there was work started in X9 financial standards body on compressed
certificates. Even the SET relying-party-only certificate overhead ran
4k-12k bytes. The typical iso8583 financial message is on the order of
60-80 bytes. Even the trivial SET relying-party-only certificates
represented a payload bloat of one hundred times (besides the RSA-ops
inflating processing overhead by 3-4 orders of magnitude).

3) Because of the enormous payload bloat contributed by the
certificates, the digital signature processing was being truncated at
the internet boundary and a standard iso 8583 message was then generated
with a flag turned on indicating that the internet had validated the
digital signature. The merchants had an incentive to see that flag
turned on since that was the basis on which a lower discount was
calculated. At an ISO meeting in europe ... one of the association
network people presented statistics on the number of iso 8583 messages
that they found with the flag turned on and they could prove that no
digital signature technology could have been involved

4) I presented an argument that a valid compressing technology is to
eliminate all fields from the (certificate) contents that were known to
already be in possession of the relying party. Since it could be proved
that all fields in the SET relying-party-only certificate were already
on file with at the consumer's financial institutions ... it would be
possible to eliminate all fields from the relying-party-only
certificates. If they preferred, i would start describing the process of
appending zero byte digital certificates as an alternative to describing
certificateless digital signature operation
http://www.garlic.com/~lynn/subpubkey.html#certless

5) The consumer's financial institution could effectively use the
existing business processes for registering PINs as a mechanism for
registering public keys. That is not known to be an expensive business
process. A consumer's financial institution then could set up a website
where the consumer could later retrieve their (redundant and superfluous
relying-party-only) digital certifcate. There is some integrity
constraints here ... but since the purpose of a digital certificate is
to spray it all over the world ... there isn't a lot of confidentiality
constraints (i.e. it doesn't hurt a lot if other people pick up your
digital certificate). However, since both the public key and the digital
certificate would already be on file ... you could require people to
perform digital signature authentication before picking up their
redundant and superfluous digital certificate. This does have an
unfortunate downside since it highlights that consumer digital
signatures can be validated by onfile public keys w/o needing digital
certificates

6) there were lots of comments that leaving all the PKI gorp in the
hands of trusted third parties was a trade-off of the
$100/

Re: the limits of crypto and authentication

[Anne & Lynn Wheeler]

Aram Perez wrote:
> While the SET protocol was complicated, it's failure had nothing to  do
> with that fact or the lack of USB on PCs. You could buy libraries  that
> implemented the protocol and the protocol did not require USB.  IMO, the
> failure had to do with time-to-market factors. In the late  90s, when
> ecommerce was just at it's infancy and you took the risk of  setting up
> a web store, were you going to wait you could integrate a  SET toolkit
> into you web site and until your customers had SET  wallets installed on
> their PCs before selling a product? Or were you  going to sell to anyone
> who used a web browser that supported SSL? It  was very simple
> economics, even if you had to pay VeriSign $400 for  your SSL
> certificate and pay Visa/MasterCard a higher fee.

can you say that that processing overhead was on the order of 20-30
seconds (on completely unloaded infrastrucutre ... demos at shows and
conferences ... can you imagine what a little bit of queuing load would
do to it?) ... if merchants thot SSL was onerous ... just imagine what
SET did to the infrastructure  and it provided effectively no
additional improvement over fraud vis-a-vis effectively only addressing
the confidentiality of account numbers as data-in-flight.

SSL was the encumbant, was significantly less complex and significantly
lighter weight (even tho most merchants decided that it was too heavy
except for the credit card portion) and provided effectively the same
amount of anti-fraud as SET.

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?

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

Re: ID "theft" -- so what?

[Perry E. Metzger]

Ian Grigg <[EMAIL PROTECTED]> writes:
>> This is not a "new realization" -- this goes back a long way.
>
> OK, so maybe this part is the new realisation:

No, it isn't a new realization either, Ian. We all knew from nearly
the start that the model we were using in browsers was wrong. I don't
know anyone who defends it. Netscape threw SSL together in a hurry --
so much of a hurry that the first version of the protocol wasn't even
any good -- and threw a bunch of certs right into the browser to
bootstrap it, and no one has particularly liked the situation ever
since.

That doesn't mean that people are interested in throwing the baby out
with the bathwater, either, as you have in suggesting that people
should just send credit card numbers in the clear because passive
interception is (you have claimed) not an issue.

> Too many words?  OK, here's the short version
> of why phising occurs:
>
> "Browsers implement SSL+PKI and SSL+PKI is
> secure so we don't need to worry about it."

I am unaware of real security professionals who hold that opinion or
ever held it, or even a variation on it. Perhaps there are a handful
out there, but it isn't the majority.

Again, you are telling people what they already know.


-- 
Perry E. Metzger[EMAIL PROTECTED]

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

Re: the limits of crypto and authentication

[Perry E. Metzger]

Aram Perez <[EMAIL PROTECTED]> writes:
> While the SET protocol was complicated, it's failure had nothing to
> do with that fact or the lack of USB on PCs. You could buy libraries
> that implemented the protocol and the protocol did not require USB.
> IMO, the failure had to do with time-to-market factors. In the late
> 90s, when ecommerce was just at it's infancy and you took the risk of
> setting up a web store, were you going to wait you could integrate a
> SET toolkit into you web site and until your customers had SET
> wallets installed on their PCs before selling a product? Or were you
> going to sell to anyone who used a web browser that supported SSL? It
> was very simple economics, even if you had to pay VeriSign $400 for
> your SSL certificate and pay Visa/MasterCard a higher fee.

You are perfectly right on this. I oversimplified and distorted.

Still, I suspect that while the time was not right for SET back then,
the time may nearly be right for better things now.

Perry

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

Strengthening quantum cryptography by putting on blinders

[Sean McGrath]

-- Forwarded message --
Date: Thu, 14 Jul 2005 11:11:59 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Physics News Update 737

PHYSICS NEWS UPDATE
The American Institute of Physics Bulletin of Physics News
Number 737 July 14, 2005  by Phillip F. Schewe, Ben Stein

[...]

STRENGTHENING QUANTUM CRYPTOGRAPHY BY PUTTING ON BLINDERS.  A
Korea-UK team (contact Myungshik Kim, Queen's University, Belfast,
[EMAIL PROTECTED] , or Chilmin Kim, Paichai University) has
introduced a method for preventing several clever attacks against
quantum cryptography, a form of message transmission that uses the
laws of quantum physics to make sure an eavesdropper does not
covertly intercept the transmission.  Making the message sender and
receiver a little blind to each other's actions, the researchers
have shown, can bolster their success against potential
eavesdroppers.
In quantum cryptography, a sender (denoted as Alice) transmits a
message to a receiver (called Bob) in the form of single photons
each representing the 0s and 1s of binary code. If an eavesdropper
(appropriately named Eve) attempts to intercept the message, she
will unavoidably disturb the photon through the Heisenberg
uncertainty principle, which says that even the gentlest observation
of the photon will perturb the particle. This will be instantly
detectable by Alice and Bob, who can stop the message and start
again.  Quantum cryptography is already being used in the real world
and is even available commercially as a way for companies to
transmit sensitive financial data.  But in its real-world
implementation, a weak pulse of light (rather than a perfect stream
of single photons) is sent down a transmission line that is "lossy,"
or absorbs photons.  So feasible attacks on quantum cryptography
include the pulse-splitting attack (in which Eve splits a
transmitted pulse into two pulses and examines one of them for
information), the pulse-cloning attack (in which a transmitted pulse
is copied to relatively high accuracy and then inspected for its
information), and the "man-in-middle" or impersonation attack, in
which Eve could impersonate Alice or Bob by intercepting the
transmission and acting as sender or receiver.
A new paper proposes a solution to these three attacks by proposing
a technique called "blind polarization."  In this technique, Alice
and Bob verify their identities to each other in a rather
paradoxical way, by performing some actions that is their own
private information. Yet these actions make the message completely
indecipherable to a third party. Alice creates a pair of pulses, but
with random polarizations (polarization indicates the direction or
angle in which each pulse's electric field points relative to some
reference, such as a horizontal line)  Alice sends the pulses to
Bob, who does not know the polarizations.  Nonetheless, without
measuring the polarization values, Bob is able to rotate the
polarization of one pulse by one amount and the other pulse by
another amount, but he doesn't tell Alice which pulses got which
treatment.  Alice receives the pulses, and then encodes them with a
message (representing the binary value 0 or 1, which could stand for
"no" or "yes), then blocks one of the pulses, without telling Bob
which one was blocked.  Bob then reverses the various polarizations
by a certain amount to get the desired message.  The various
polarization adjustments are designed in such a way that either
pulse Alice sends will yield the desired information.  According to
researcher Myungshik Kim, Alice has her own private information on
which pulse is blocked, while Bob has his own private information on
which pulse he rotated by a given amount.  Once Alice begins the
transmission, there is no way for Eve to have this private
information which makes their protocol effective against the
man-in-middle and other attacks. (Kye et al., Physical Review
Letters, upcoming article).  This paper is the latest in a wave that
plugs up potential vulnerabilities in quantum cryptography (for an
example of using
"quantum decoys" to thwart attacks, see Lo et al, Physical Review
Letters, 17 June 2005)

***
PHYSICS NEWS UPDATE is a digest of physics news items arising
from physics meetings, physics journals, newspapers and
magazines, and other news sources.  It is provided free of charge
as a way of broadly disseminating information about physics and
physicists. For that reason, you are free to post it, if you like,
where others can read it, providing only that you credit AIP.
Physics News Update appears approximately once a week.

AUTO-SUBSCRIPTION OR DELETION: By using the expression
"subscribe physnews" in your e-mail message, you
will have automatically added the address from which your
message was sent to the distribution list for Physics News Update.
If you use the "signoff physnews" expression in your e-mail message,
the address in your message header will be deleted from the
distribution list.  Please send y

Re: the limits of crypto and authentication

[Pat Farrell]

On Thu, 2005-07-14 at 18:43 +0200, Amir Herzberg wrote:
> Pat Farrell wrote:
> > 
> > As I recall, the goal of SET was to have a standard
> > that was not invented by CyberCash. (I may be biased, I
> > worked at CyberCash at the time).

> This is incorrect. The main politics around SET was the artificial 
> `merger` of iKP (from IBM & Mastercard) and STT (from Visa and MS). As 
> far as I remember, CyberCash were involved but choose not to. They also 
> did not disclose their protocol like the other proposals. I may be wrong 
> about the CyberCash role,

CyberCash protocols were defined in RFCs. The RFCs
are probably still out there, altho no longer in use.
The other two protocols were defensive against CyberCash
and it looked like there would be three non-interoperative
protocol suites. The invention of SET was a marriage of
convience. CyberCash had 15000 merchants, it isn't important now,
but I'd love to know the number of non-pilot SET merchants
in the wild.

I was the project manager for CyberCash's project implement
SET as a joint venture with Netscape, Toshiba and Visa.
And I wrote the crypto code.

At one of the early SET committee meetings, someone from
CyberCash proposed that SET simply use the RFC'd protocols.
I expect that the offer was not made with proper political
tact.

As others have said, and in the spirit of the subject
of this thread, SET failed for many reasons, many
of them economic. There was little effort made
to bribe the merchants, I think there was talk of
a 26 basis point change in the discount rate,
which the banks thought was huge and the merchants
thought was noise. What really killed it
was the billions it would have cost all
the banks to issue and manage all the
certificates.

The crypto in SET was fine. The use of
certificates was excessive but in line with
PKI thinking of the time.

The problem was that it was a very expensive sledge hammer
to kill a flea.

In retrospect, there was over reliance on crypto and
confusion of identity and authentication
contributed, but others were making the same
mistake.

We just have to be smarter now, nearly a decade later.
Crypto has to solve business problems that masses of
real people have.


-- 
Pat Farrell
http://www.pfarrell.com



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

Re: ID "theft" -- so what?

[John Kelsey]

>From: Aram Perez <[EMAIL PROTECTED]>
>Sent: Jul 14, 2005 10:45 AM
>To: Cryptography 
>Subject: Re: ID "theft" -- so what?

>Why do cryptography folks equate PKI with
>certificates and CAs? 

One nontrivial reason is that many organizations have spent
a lot of time and money building up elaborate rules for
using PKI, after long negotiations between legal and
technical people, many hours of writing and revising,
gazillions of dollars in consultants' time, etc.  So,
anytime you start doing anything involving public key
cryptography, all this machinery gets invoked, for
bureaucratic reasons.  That is, you've now trespassed on PKI
turf, and you'll have to comply with this enormous set of
rules.

I know of a couple cases where this led to really irritating
results.  In one, a friend of mine was using a digital
signature to verify some fairly trivial thing, but was told
it was against policy to use a digital signature without the
whole PKI.  (I believe he changed the documentation, so that
he was using a "modular arithmetic checksum" instead of a
signature verification.) 

As a consultant, I designed and evaluated a lot of systems
that used public key cryptography.  None of the successful
ones tried to use the whole X.509 + CRL + CPS + everything
else overhead--typically, they just used a one-deep
hierarchy, where the keypair was put into the device by the
manufacturer along with a copy of the top-level public key
used to sign all device public keys.  This works, because it
doesn't try to incorporate the output of 20 years of
make-work programs in cryptography (they weren't intended
that way, but that's largely how they turned out), and it
doesn't try to incorporate every idea that might be useful
anywhere in the world into some very limited and simple
application.

>Aram Perez

--John Kelsey

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

Re: the limits of crypto and authentication

[Amir Herzberg]

Pat Farrell wrote:

On Wed, 2005-07-13 at 23:43 -0400, Rich Salz wrote:


I think that by eliminating the need for a merchant to learn
information about your identity ...


Wasn't that a goal of SET?


As I recall, the goal of SET was to have a standard
that was not invented by CyberCash. (I may be biased, I
worked at CyberCash at the time).
This is incorrect. The main politics around SET was the artificial 
`merger` of iKP (from IBM & Mastercard) and STT (from Visa and MS). As 
far as I remember, CyberCash were involved but choose not to. They also 
did not disclose their protocol like the other proposals. I may be wrong 
about the CyberCash role, though, it was a while, and I don't think it 
matters so much...

--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: 
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame


-
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 6:23 AM, Perry E. Metzger wrote:


Rich Salz <[EMAIL PROTECTED]> writes:


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,


Wasn't that a goal of SET?


Some of it was, yah. I don't claim that any of this is original. The
problem with SET was that the protocol was far too complicated to
implement (hell, the spec was nearly too heavy to lift), and it was
proposed well before people even had USB connectors on their
computers, let alone cheap USB card interfaces. I think people threw
out the baby with the bathwater, though. The general idea was correct.


While the SET protocol was complicated, it's failure had nothing to  
do with that fact or the lack of USB on PCs. You could buy libraries  
that implemented the protocol and the protocol did not require USB.  
IMO, the failure had to do with time-to-market factors. In the late  
90s, when ecommerce was just at it's infancy and you took the risk of  
setting up a web store, were you going to wait you could integrate a  
SET toolkit into you web site and until your customers had SET  
wallets installed on their PCs before selling a product? Or were you  
going to sell to anyone who used a web browser that supported SSL? It  
was very simple economics, even if you had to pay VeriSign $400 for  
your SSL certificate and pay Visa/MasterCard a higher fee.


Respectfully,
Aram Perez


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

Re: ID "theft" -- so what?

[Aram Perez]

Why do cryptography folks equate PKI with  
certificates and CAs? 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). 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  
like in so many real life cases, the best technology does not always  
win and we are stuck with the system that garnered the most business/ 
economic support.


Respectfully,
Aram Perez

On Jul 14, 2005, at 6:19 AM, Perry E. Metzger wrote:


Ian Grigg <[EMAIL PROTECTED]> writes:


It's 2005, PKI doesn't work, the horse is dead.


He's not proposing PKI, but nymous accounts.  The
account is the asset, the key is the owner;


Actually, I wasn't proposing that. I was just proposing that a private
key be the authenticator for payment card transactions, instead of the
[name, card number, expiration date, CVV2] tuple -- hardly a
revolutionary idea. You are right, though, that I do not propose that
any PK_I_ be involved here -- no need for certs at all for this
application.

I don't claim this is a remotely original idea, by the way. I'm just
flogging it again.


But, thank the heavens that we now have reached
the point where people can honestly say that PKI
is the root cause of the problem.


"Root Cause of the Problem" isn't correct either. It is better to say
that PKI doesn't solve many of the hard problems we have, or, in some
cases, any problems -- it doesn't per se cause any problems, or at
least not many.

This is not a "new realization" -- this goes back a long way.

People were saying PKI was a bad idea a decade ago or more. A number
of the people here, including me, gave talks on that subject years
ago. I spoke against PKI during the debate I was invited to at the
Usenix Electronic Commerce Workshop in 1998 or so, and at many
opportunities before and since. Dan Geer has a pretty famous screed on
the subject. Peter Gutmann talks about the follies of X.509 so often
it is hard to keep up. I don't mean to single us out as visionaries --
we were just saying things lots of other people were also saying.

Honestly, where have you been?


Can you now tell the browser people?


I can smell the rest of this discussion right now, Ian. You'll
misunderstand the constraints the browser people are under, and start
claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm
not playing the game.

Perry

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





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

Re: ID "theft" -- so what?

[Ian Grigg]

(Dan, in answer to your question on certs, below.)


On Thursday 14 July 2005 14:19, Perry E. Metzger wrote:
> 
> Ian Grigg <[EMAIL PROTECTED]> writes:
> >> It's 2005, PKI doesn't work, the horse is dead.
> >
> > He's not proposing PKI, but nymous accounts.  The
> > account is the asset, the key is the owner;
> 
> Actually, I wasn't proposing that. I was just proposing that a private
> key be the authenticator for payment card transactions, instead of the
> [name, card number, expiration date, CVV2] tuple -- hardly a
> revolutionary idea. You are right, though, that I do not propose that
> any PK_I_ be involved here -- no need for certs at all for this
> application.
> 
> I don't claim this is a remotely original idea, by the way. I'm just
> flogging it again.

Well, that's helpful.  Having built one or two of
these things (and I know of 3 others on the list
that have done the same thing) it helps to know
we aren't starting from scratch.

> > But, thank the heavens that we now have reached
> > the point where people can honestly say that PKI
> > is the root cause of the problem.
> 
> "Root Cause of the Problem" isn't correct either. It is better to say 
> that PKI doesn't solve many of the hard problems we have, or, in some
> cases, any problems -- it doesn't per se cause any problems, or at
> least not many.
> 
> This is not a "new realization" -- this goes back a long way.


OK, so maybe this part is the new realisation:

The browser security model includes PKI for two
purposes - MITM protection and spoofing protection.
Ignoring MITM (today), the spoofing protection is
supposed to alert the user that the cert and the
site don't match.

Phishing is a spoof - the wrong site is used.  So
SSL+PKI should pick that up.  It isn't.  Why?
Simply put because the browser too easily lets
SSL's anti-spoofing protection not be seen.  It's
not being done properly.

Why is that?  Because the browser people are
under severe constraints - your words - and
nobody is correcting their missunderstandings.
No security folk, no security companies, no CAs,
just a few researchers (some lurking here...).

Too many words?  OK, here's the short version
of why phising occurs:

"Browsers implement SSL+PKI and SSL+PKI is
secure so we don't need to worry about it."

PKI+SSL *is* the root cause of the problem.  It's
just not the certificate level but the business and
architecture level.  The *people* equation.

> People were saying PKI was a bad idea a decade ago or more. A number
> of the people here, including me, gave talks on that subject years
> ago. I spoke against PKI during the debate I was invited to at the
> Usenix Electronic Commerce Workshop in 1998 or so, and at many
> opportunities before and since. Dan Geer has a pretty famous screed on
> the subject. Peter Gutmann talks about the follies of X.509 so often
> it is hard to keep up. I don't mean to single us out as visionaries --
> we were just saying things lots of other people were also saying.
> 
> Honestly, where have you been?

I've been over at Mozilla trying to tell them the PKI
isn't doing it's job.  Peter Gutmann and Amir Herzberg
have been there supporting this push.  They're not
visionaries either but at least they put their money
where their mouths are - trying to get Mozo people
to touch up the PKI + SSL code to deal with spoofing.

(Demos and code available on request )

We recently set up a new
group for all anti-phishing researchers so they could
congregate and cross-fertilise ideas in a scientific
fashion.  I'm proud to say that in less than one month
our understanding of phishing and the browser
security model has significantly advanced.

We've talked to dozens of programmers over on the
Mozilla camp, sadly without success and I think that's
because the crypto community has been relatively
silent on this issue.  Most over in the browser
community remain simply unaware and uneducated
on the reasoning behind the security model, and how
out of date it is.

So, where have you been, Perry?  If you wish to
patronize me (on a public list, with no right of reply!)
do so from a position of strength.

> > Can you now tell the browser people?
> 
> I can smell the rest of this discussion right now, Ian. You'll
> misunderstand the constraints the browser people are under, and start
> claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm
> not playing the game.

Perry, for the last few months or so the game
you have been playing is "disagree with Ian,
rag him in public, drop his posts."

I don't mind .. but as I showed above, you are
100% diametrically wrong about what it is I am
saying or likely to say.  Just so you're aware
that you're inventing the rest of the discussion
and disagreeing with your own invention...

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

--

Re: the limits of crypto and authentication

[Anne & Lynn Wheeler]

Rich Salz wrote:
> Wasn't that a goal of SET?

there was an observation that SET possibly wouldn't divulge your account
number until the merchant had been determined to be some entity
registered as a merchant (akin to the SSL domain name infrastructure
certificates ... if a spoofed site didn't use SSL until you hit the
pay/checkout button, what is the probability that the spoofed site
provide a URL that matched some valid certificate that they did have).

note, however, some of the participants even got confused about this issue.

note that there are a lot of merchant business processes that require
the account number ... and therefor you can't prevent the merchant from
possessing the account number. some might be tempted to observe that
there is a kind of conflict of interest ... using the same value for
authentication purposes as well as widely needed for a large number of
other purposes (akin to designing a system that widely uses your userid
a basis for normal functioning ... as well as making your userid also
your password).

some past posts where the SET issue of divulging account number was
disucssed.
http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re:
crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re:
crypto flaw in secure mail standards

I thot the goal of SET was to maximize the number of RSA-ops being
executed in the world.

When I first obtained a copy of the initial SET specification, I did a
RSA-ops profile and a business operation profile. An acquatance had done
some work on the BSAFE library and improved the performance by a factor
of four times. I got him to run timing tests on the SET RSA-ops profile
across a number of different machines. I then communicated the results
to a number of people that were part of the SET group. The reply from
various members of the SET group was that the numbers were obviously one
hundred times too slow (the correct answer should have been that the
numbers were four times too fast). Six months later when the first
prototype SET code was running ... their measured numbers were within a
couple percent of my earlier profile numbers (aka the BSAFE enhancements
had been given back to RSA).

One possible observation was that SSL work
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

was already providing account number confidentiality for
*data-in-flight*.  The significantly much more complex, and heavyweight
SET would have needed to provide countermeasures for significantly more
threats and vulnerabilities ... like security for *data-at-rest* (aka
data breaches) in order to make any headway against the (SSL) incumbant.

I also made a couple comments to the SET group about the heavy-weight
nature of SET (apparently the RSA-ops being one hundred times more
onerous than they had anticipated). Effectively, the SET RSA-op profile
was symmetrical  but the standard processing is quite asymmetrical.
In effect, the massive datacenters that are currently processing credit
card transactions would have needed their computational facilities
increased by at least one hundred times (SET RSA-op profile was looking
at tens of seconds per transaction while many of these datacenters
measure their thruput in thousands of transactions per second ... a four
orders of magnitude gap).

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

Re: mother's maiden names...

[Alexander Klimov]

On Wed, 13 Jul 2005, Perry E. Metzger wrote:
> 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?

While we are very good at recognizing somebody we know on a picture,
it is in fact very hard to answer the following question: is the
person in front of you is the same person who is depicted on the
photo? AFAIR there were experiments which show that if you just get a
random photo of a person with the same race, age, and gender as you
have you have very good probability to successfully pretend that you
are the person on the picture. As a result the criminal don't really
need to change the photo to be able to pretend that he is you.

-- 
Regards,
ASK

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

Re: EMV

[Enzo Michelangeli]

AFAIK, the cards are still the same (Sony FeliCa:
http://www.sony.net/Products/felica/): I never changed mine since I got it
several years ago. The same card was also adopted in 2002 by EZ-Link in
Singapore (http://www.ezlink.com.sg ).

Enzo

- Original Message - 
From: "Anne & Lynn Wheeler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "'Ben Laurie'" <[EMAIL PROTECTED]>; "'Peter Fairbrother'"
<[EMAIL PROTECTED]>; "'Florian Weimer'" <[EMAIL PROTECTED]>; "'David
Alexander Molnar'" <[EMAIL PROTECTED]>; "'? Schmidt'"
<[EMAIL PROTECTED]>; 
Sent: Wednesday, July 13, 2005 8:55 AM
Subject: Re: EMV


> ... the original introduction of HK octopus transit card used the
> "sony" flavor of iso 14443 with 10cm and transit requirements of
> transaction in 100ms. having it in the bottom of a bag and bringing the
> bag within 10cm of the reader does the trick.
>
> there was a transit meeting where the mondex people attended ... they
> claimed that they could also be used for transit ... just get a wireless
> sleave for the mondex card ... and build 14' long tunnels leading up to
> the transit gates ... and have the people walk slowly thru the tunnels.
>
> Gabriel Haythornthwaite wrote:
> > In Hong Kong a lot of people do little more than wave their bags at
the
> > turnstile.  Removing the wallet and revealing its size is unnecessary.
>
> -
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
[EMAIL PROTECTED]
>


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

Re: the limits of crypto and authentication

[Pat Farrell]

On Wed, 2005-07-13 at 23:43 -0400, Rich Salz wrote:
> > I think that by eliminating the need for a merchant to learn
> > information about your identity ...
> 
> Wasn't that a goal of SET?

As I recall, the goal of SET was to have a standard
that was not invented by CyberCash. (I may be biased, I
worked at CyberCash at the time).

Both SET and the CyberCash protocols did not allow the
merchant to have access to the purchasers's PAN/expry.
Everyone back then knew that since the PAN was considered
a secret, you couldn't be casual about passing it 
around. And merchant fraud was a much more realistic
problem that capturing data on the fly.

CyberCash was forced to change the system to allow
the merchant to have access to the PAN so that
merchants could back out transactions for returns
or defects. The change was made in the field by
a support engineer before the security folks in 
engineering had a chance to have a fit. I don't
remember why we accepted such a bad practice.

In all the discussion here, the thing that
strikes me is that we need to stop using secrets
as proof of anything. Seems that Chaum's
credentials without identities are a much better
approach, and I'd guess that his patents
are long expired.

Pat


-- 
Pat Farrell
http://www.pfarrell.com



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

Re: mother's maiden names...

[Ian Brown]

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.


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

Re: ID "theft" -- so what?

[Greg Troxel]

"Jörn" Schmidt <[EMAIL PROTECTED]> writes:

> The answer to this dilemma? I'm afraid this time it really is
> legislation. Frankly, I'm not even sure if that would work but, at this
> time, it's our best shot. Congress won't do anything about this unless
> a few representatives have their identities stolen and experience
> first-hand what a PITA it is to have to deal with the fallout.

I agree that legislative changes are necessary, but I think they are
fairly small.   Consider the following:

  Alice is a model citizen with a good credit history

  Bob "steals Alice's identity" by finding out semi-public static
  information

  Bob gets a loan from Charlie under Alice's identity, where Charlie
  transfers something of value to Bob and records a debt from Alice.

Here, Bob has committed a crime, and this being a crime isn't
controversial.  Until this point, Alice hasn't really been harmed
unless she tries to interact with Charlie herself.

  Charlie tries to collect from Alice, or
  Charlie reports that Alice owes a debt to a third party, or
  Charlie reports that Alice is in default to a third party.

In my view, _Charlie_ has comitted a tort against Alice because he has
been negligent (or at least incorrect) in issuing credit.  If Charlie
has decided to issue credit with minimal checks because the business
benefit of that is more than the fraud losses (similar to our credit
card system today), then it's only fair for Charlie to cover the full
burden to Alice, including all the effort of cleanup.  If Charlie
isn't being careful to the some degree, so that such incidents are
rare, triple damages are probably in order.  Even if Charlie is very
careful, actual damages should be paid.

A reasonable penalty for Charlie might be on the order of $1000
statutory damages plus $100/hr for any time over two hours Alice has
to spend dealing with the issue, plus any legal fees incurred if any
problems remain 30 days after the first report.  This puts the onus on
Charlie and the reporting systems will quickly adjust to enable
Charlie to withdraw the incorrect report completely and quickly.

Of course, Charlie should be able to recover all of his own costs, as
well as payments to Alice, in triplicate from Bob.
  
Many credit issuers willfully conduct their business with the
knowledge that this will occur.  So, as I see it the basic problem is
not one of security, but the fact that credit issuers etc. impose
costs on innocent third parties and get away with it.

-- 
Greg Troxel <[EMAIL PROTECTED]>

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

Re: the limits of crypto and authentication

[Perry E. Metzger]

Rich Salz <[EMAIL PROTECTED]> writes:
>> 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,
>
> Wasn't that a goal of SET?

Some of it was, yah. I don't claim that any of this is original. The
problem with SET was that the protocol was far too complicated to
implement (hell, the spec was nearly too heavy to lift), and it was
proposed well before people even had USB connectors on their
computers, let alone cheap USB card interfaces. I think people threw
out the baby with the bathwater, though. The general idea was correct.


Perry


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

Re: ID "theft" -- so what?

[Perry E. Metzger]

Ian Grigg <[EMAIL PROTECTED]> writes:
>> It's 2005, PKI doesn't work, the horse is dead.
>
> He's not proposing PKI, but nymous accounts.  The
> account is the asset, the key is the owner;

Actually, I wasn't proposing that. I was just proposing that a private
key be the authenticator for payment card transactions, instead of the
[name, card number, expiration date, CVV2] tuple -- hardly a
revolutionary idea. You are right, though, that I do not propose that
any PK_I_ be involved here -- no need for certs at all for this
application.

I don't claim this is a remotely original idea, by the way. I'm just
flogging it again.

> But, thank the heavens that we now have reached
> the point where people can honestly say that PKI
> is the root cause of the problem.

"Root Cause of the Problem" isn't correct either. It is better to say
that PKI doesn't solve many of the hard problems we have, or, in some
cases, any problems -- it doesn't per se cause any problems, or at
least not many.

This is not a "new realization" -- this goes back a long way.

People were saying PKI was a bad idea a decade ago or more. A number
of the people here, including me, gave talks on that subject years
ago. I spoke against PKI during the debate I was invited to at the
Usenix Electronic Commerce Workshop in 1998 or so, and at many
opportunities before and since. Dan Geer has a pretty famous screed on
the subject. Peter Gutmann talks about the follies of X.509 so often
it is hard to keep up. I don't mean to single us out as visionaries --
we were just saying things lots of other people were also saying.

Honestly, where have you been?

> Can you now tell the browser people?

I can smell the rest of this discussion right now, Ian. You'll
misunderstand the constraints the browser people are under, and start
claiming SSL is bad (or unnecessary) about 20 seconds after that. I'm
not playing the game.

Perry

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

Re: mother's maiden names...

[Perry E. Metzger]

[EMAIL PROTECTED] (Peter Gutmann) writes:
> "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.  Most banks are still using 3270-style interfaces, even if
> they have a screen-scraped GUI front-end.

That's true. Several banks I deal with in New York use displays that
are disturbingly 3270-like. That brings up another thing that has
always tickled the back of my mind -- I have never actually had a
professional opportunity to analyze any of the systems used by tellers
in commercial banks, and I always wonder at what is securing the links
between small branches and HQ, and how bad the protection of the user
passwords etc. might be...

> So using images (of any kind) isn't just a case of making an executive
> decision to do so, it would involve a massive, end-to-end infrastructure
> upgrade to implement.

Yah, true enough -- which also impedes things like letting branch
managers to look at check images, signatures, etc. Groan...


Perry

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

Re: mother's maiden names...

[Janusz A. Urbanowicz]

On Wed, Jul 13, 2005 at 12:26:52PM -0400, Perry E. Metzger wrote:
> 
> A quick question to anyone who might be in the banking industry.
> 
> Why do banks not collect simple biometric information like photographs
> of their customers yet?

Some, like Citibank do. I have a photo on my VISA from them, but I believe
the photo is not linked to the account nor taken into consideration when
doing identification at the bank. When I asked about it, the answer was
something about that the photo is stored only by the credit card issuing
center, and not in the main system. Random peeking on clerk's screen while
I'm at the bank seems to confirm this - no place for customer picture in the
account info.

Sometimes they aren't allowed to do so, data privacy policy here says that a
business may not request or store any personal information that is not
directly needed to conduct business with that person; a national ID card is
routinely xeroxed when establishing an account and the copy is kept at the
bank, then the photo is blackened out; when the regulation came live bank
staffs had working weekends sitting with black felt-tip pens, blacking
out photos and other unneeded info on the ID xerocopies.

Alex
-- 
mors ab alto 
0x46399138

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

Re: UK EU presidency aims for Europe-wide biometric ID card

[Stefan Kelm]

> when we were called into help word-smith the cal. state and later the
> fed. electronic signature law ... a lot of effort went into making the
> wording technology agnostic as well as trying to avoid confusing
> authentication and identification.

We've been discussing those very same topics within Europe for
many years now. When some EU Member States (Germany, Austria, ...)
already had very stringent signature laws the EU was kind of
forced to act. They tried to enact a signature directive which
they thought would be as technology neutral as possible. And
although that approach seemed to be a good one they failed:
they were overambitious wrt certain issues, what's more the
implementation of the directive into national legislation
lead to 20+ different EU signature laws:

http://www.pki-page.info/eu/

In 2003 we wrote a report for the European Commission,
trying to compare the situation throughout the Member States
as well as focussing on practical applications:

http://www.law.kuleuven.ac.be/icri/itl/elsig.php
http://www.secorvo.de/publikationen/electronic-sig-report.pdf

Cheers,

Stefan.
---
Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Ettlinger Straße 12-14, D-76137 Karlsruhe

Tel. +49 721 255171-304, Fax +49 721 255171-100
[EMAIL PROTECTED], http://www.secorvo.de/
---
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B



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

Re: mother's maiden names...

[Peter Gutmann]

"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.  Most banks are still using
3270-style interfaces, even if they have a screen-scraped GUI front-end.
There simply isn't any provision for handling anything other than basic text
records - the data-centre back-ends are text-record based (and in some cases
the text is EBCDIC), the communications channels send and receive text records
(often at a few kbps over leased lines, X.25, or PSTN dialup), and the branch
software processes text records.

So using images (of any kind) isn't just a case of making an executive
decision to do so, it would involve a massive, end-to-end infrastructure
upgrade to implement.

Peter.

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

Re: the limits of crypto and authentication

[Rich Salz]

> 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,

Wasn't that a goal of SET?

/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: ID "theft" -- so what?

[Ian Grigg]

On Wednesday 13 July 2005 23:31, Dan Kaminsky wrote:
> 
> >This is yet more reason why I propose that you authorize transactions
> >with public keys and not with the use of identity information. The
> >identity information is widely available and passes through too many
> >hands to be considered "secret" in any way, but a key on a token never
> >will pass through anyone's hands under ordinary circumstances.
> >
> >  
> >
> It's 2005, PKI doesn't work, the horse is dead.

He's not proposing PKI, but nymous accounts.  The
account is the asset, the key is the owner;  at the
simplest conceptual level it is the difference between
Paypal and e-gold.

But, thank the heavens that we now have reached
the point where people can honestly say that PKI
is the root cause of the problem.  Can you now tell
the browser people?

> The credit-card sized  
> number dispensers under development are likely to be what comes next.

Right, alongside nyms on a spectrum is big random
number-sized tokens.  If you want to get sexy, go
for the blinded ones.  It's all the same infrastructure,
we call it FC.

> Amusingly, your face is an asymmetric authenticator -- easy to 
> recognize, hard to spoof.

True, but also easy to copy and can be stolen.  For
some value, you don't want to go there.

https://www.financialcryptography.com/mt/archives/000440.html

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: mother's maiden names...

[Charles M. Hannum]

On Wednesday 13 July 2005 18:29, Mike Owen wrote:
> Back in 2000, I opened an account with BofA, and they took a photo of
> me, and added it to my debit/check card. Around that same time,
> American Express was doing the same with their Costco branded cards.
> I'm sure others are doing it, those are just the ones I have
> experience with.

FYI, that's a feature of Costco, not AmEx.  Costco requires a picture because 
the card is used in place of a normal Costco card to get admitted into the 
store.  They are somewhat ruthless about sharing cards for personal 
memberships.

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

Re: mother's maiden names...

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, "R.A. Hettinga" writes:
>At 12:26 PM -0400 7/13/05, Perry E. Metzger wrote:
>>Why do banks not collect simple biometric information like photographs
>>of their customers yet?
>
>Some do.
>
>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.)

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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