Re: Blinky Rides Again: RCMP suspect al-Qaida messages

[Ian Grigg]

> It seems consistent that Al Qaeda prefers being 'fish in the sea' to
> standing out by use of crypto. Also, given the depth and breadth of
> conspiracies they believe in, it seems that they might see all us
> cryptographers as a massive deception technique to get them to use bad
> crypto. (And hey, they're almost right! We love that they use bad
> crypto.)

Right.  Although only based on very limited experiences,
where I've come across those in "interesting lines of
business", the strong impression I get is that they would
not touch any new or geeky tool that had some claimed
benefits that couldn't be proven on examination.

This was most forcefully put to me by a dealer of narcotics
in Amsterdam (I wasn't buying, just trying to be polite at
a party ;) who said that he and his like would not use any
of the payment systems that had supposed privacy built in,
as they assumed that the makers were lying about the privacy
provisions.  As far as 3 systems that the guy was aware of,
he was dead right twice, and for the third, I'd say he was
approximately right.

So, if this is a valid use case and we can extend from small
time narcotics payments to big time terrorism chitchat, we
could suggest that they will be using standard people tools,
and trying hard to stay unobservable in the mass of traffic.
In this sense, one could say they were using steganography,
but I think it is more useful to say they are simply staying
out of sight.

Either way, the public policy implication is to challenge
any specious claims of how we need to control XXX because
terrorists use it.  In the case of crypto, it would appear
they don't use much, and what's more, they shouldn't.

> And see the link there to Ian Grigg's
> http://www.financialcryptography.com/mt/archives/000246.html

I was hoping that the 'Terrorist Encyclopedia' had made its
way to somewhere like smoking gun or cryptome by now.

iang

L/Cs, e-gold and regulated banking

[Ian Grigg]

(Guys, this has drifted out of crypto into finance, so I
have a feeling that it will disappear of the crypto list.
But the topics that are raised are interesting and important
enough to carry on, I think.)


>> > [Hal:]
>> > Interesting.  In the e-gold case, both parties have the same bank,
>> > e-gold ltd.  The corresponding protocol would be for the buyer to
>> > instruct e-gold to set aside some money which would go to the
>> > seller once the seller supplied a certain receipt.  That receipt
>> > would be an email return receipt showing that the seller had sent
>> > the buyer the content with hash so-and-so, using a cryptographic
>> > email return-receipt protocol.
>> [iang:]
>> This is to mix up banking and payment systems.  Enzo's
>> description shows banks doing banking - lending money
>> on paper that eventually pays a rate of return.  In
>> contrast, in the DGC or digital gold currency world,
>> the issuers of gold like e-gold are payment systems and
>> not banks.  The distinction is that a payment system
>> does not issue credit.
> [enzo:]
> Actually, seeing issuance and acceptance of L/C's only as a money-lending
> activity is not 100% accurate. "Letter of credit" is a misnomer: an L/C
> _may_ be used by the seller to obtain credit, but if the documents are
> "sent for collection" rather than "negotiated", the payment to the seller
> is delayed until the opening bank will have debited the buyer's account
> and remitted the due amount to the negotiating bank. To be precise: when
> the documents are submitted to the negotiating bank by the seller, the
> latter also draws under the terms of the L/C a "bill of exchange" to be
> accepted by the buyer; that instrument, just like any draft, may be either
> sent for collection or negotiated immediately, subject, of course, to
> final settlement. Also, depending on the agreements between the seller and
> his bank, the received L/C may be considered as collateral to get further
> allocation of credit, e.g. to open a "back-to-back L/C" to a seller of raw
> materials.
>
> However, if the documents and the draft are sent for collection, and no
> other extension of credit are obtained by the buyer, the only advantage of
> an L/C for the seller is the certainty of being paid by _his_
> (negotiating) bank, which he trusts not to collude with the buyer to claim
> fictitious discrepancies between the actual documents submitted and what
> the L/C was requesting. (And even in case such discrepancies will turn out
> to be real, the opening bank will not surrender the Bill of Lading, and
> therefore the cargo, to the buyer until the latter will have accepted all
> the discrepancies: so in the worst case the cargo will remain under the
> seller's control, to be shipped back and/or sold to some other buyer.
> If it acted differently, the opening bank would go against the standard
> practice defined in the UCP ICC 500
> (http://internet.ggu.edu/~emilian/PUBL500.htm) and its reputation would be
> badly damaged). So, the L/C mechanism, independently from allocation of
> credit, _does_ provide a way out of the dilemma "which one should come
> first, payment or delivery?"; and this is achieved by leveraging on the
> reputation of parties separately trusted by the endpoints of the
> transaction.

An excellent description;  I was unaware that the system
could be used in a non-credit fashion.  Thanks for correcting
me.

> Generally speaking, it is debatable whether "doing banking" only means
> "accepting deposits and providing credit" or also "handling payments for a
> fee":

There are many definitions of "banking" and unfortunately
they are different enough that one will make mistakes
routinely.  Here are the most useful three that I know of:

1.  borrowing from the public as deposits and lending those
deposits to the public.  This is the favoured definition for
economists, because it concentrates on the specialness that
is banking, which is the foundation for its special regulatory
structure.

2.  Banking is what banks do, and banks do banking.  This is
the favoured definition of banks, and often times, regulators,
because it gives them a free hand to exploit their special
franchise / subsidy.  It was codified in law in many countries
as just this, but I believe it is out of favour to write it
down these days.  However, the Fed and other US regulators have
from time to time resorted to this definition, when convenient.

3.  Banking is what the regulator says is banking.  This is
the favoured definition of regulators, and sometimes of banks.
It means that there is little or no argument or discussion in
protecting the flock.  This is the much more prevalent in
smaller countries, where the notion of "sending in the lawyers"
is simply too expensive.

4.  There is a popular definition that says something like,
if it is to do with money it is banking.  That's not a very
useful one, but it's prevalent enough to need to be aware of
it.

> ... surely banks routinely do both, although 

Re: Your source code, for sale

[Ian Grigg]

> Enzo Michelangeli writes:
>> In the world of international trade, where mutual distrust between buyer
>> and seller is often the rule and there is no central authority to
>> enforce
>> the law, this is traditionally achieved by interposing not less than
>> three
>> trusted third parties: the shipping line, the opening bank and the
>> negotiating bank.
>
> Interesting.  In the e-gold case, both parties have the same bank,
> e-gold ltd.  The corresponding protocol would be for the buyer to instruct
> e-gold to set aside some money which would go to the seller once the
> seller supplied a certain receipt.  That receipt would be an email return
> receipt showing that the seller had sent the buyer the content with hash
> so-and-so, using a cryptographic email return-receipt protocol.

This is to mix up banking and payment systems.  Enzo's
description shows banks doing banking - lending money
on paper that eventually pays a rate of return.  In
contrast, in the DGC or digital gold currency world,
the issuers of gold like e-gold are payment systems and
not banks.  The distinction is that a payment system
does not issue credit.

So, in the e-gold scenario, there would need to be
similar third parties independent of the payment system
to provide the credit moving in the reverse direction to
the goods.  In the end it would be much like Enzo's
example, with a third party with the seller, a third
party with the buyer, and one or two third parties who
are dealing the physical goods.  There have been some
thoughts in the direction of credit creation in the
gold community, but nothing of any sustainability has
occurred as yet.

iang

Re: Are new passports [an] identity-theft risk?

[Ian Grigg]

R.A. Hettinga wrote:


 An engineer and RFID expert with Intel claims there is little danger of
unauthorized people reading the new passports. Roy Want told the newssite:
"It is actually quite hard to read RFID at a distance," saying a person's
keys, bag and body interfere with the radio waves.
Who was it that pointed out that radio waves don't
interfere, rather, receivers can't discriminate?
iang

Re: Printers betray document secrets

[Ian Grigg]

R.A. Hettinga wrote:


 US scientists have discovered that every desktop printer has a signature
style that it invisibly leaves on all the documents it produces.
I don't think this is new - I'm pretty sure it was
published about 6 or 7 years back as a technique.
iang

Re: potential new IETF WG on anonymous IPSec

[Ian Grigg]

Joe Touch wrote:
Ian Grigg wrote:

On the backbone, between BGP peers, one would have thought
that there are relatively few attackers, as the staff are
highly trusted and the wires are hard to access - hence no
active attacks going on and only some passive eavesdropping
attacks.  Also, anyone setting up BGP routing knows the other
party, so there is a prior relationship.

My understanding of the attacks this past spring is that:
a) they were indeed on the backbone BGP peers
b) that those peers had avoided setting up
   preshared keys or getting mutually-authenticatable
   certificates because of the configuration overhead
   (small on a per-pair basis, but may be large
   in aggregate)
While inspired by this issue, there may be other solutions (e.g., IMO 
IPsec) which are more appropriate for BGP peers.

Thanks for the clarification.  Re-reading (all) of
the above, I noticed that these are DOS attacks.
(That changes things - crypto protocols don't really
a priori stop or defeat DOS attacks.  They can help,
or they may not, it all depends.)
It's then important to examine the threat here.  Who is
the attacker and what motives and tools does he have
available?  It would be annoying to do all the work,
only to discover that he has other tools that are just
as easy...  (This is called what's-your-threat-model,
sometimes abbreviated to WYTM?)
The whole point of the CA model is that there is no prior
relationship and that the network is a wild wild west sort
of place

Except that certs need to be signed by authorities that are trusted.
Right, in that the CA model seeks to add trust
to the wild wild west by the provision of these
signed / trusted certs.  Whether it achieves that
depends on the details.  It is not wise to just
assume it succeeds because someone said so.
- both of these assumptions seem to be reversed
in the backbone world, no?  So one would think that using
opportunistic cryptography would be ideal for the BGP world?
iang

I wouldn't think that the encryption need be opportunistic; in the BGP 
backbone world, as you noted, peers are known a-priori, and should have 
certs that could be signed by well-known, trusted CAs.
Let's see if I can make these assumptions clearer, because
I still perceive that CAs have no place in BGP, and you seem
to be assuming that they do.
In the world of PKIs, there are some big assumptions.  Here's
two of them:
   Alice and Bob don't know each other, and don't necessarily
   trust each other.
   There exists a central stable party that *both* Alice and
   Bob know better than each other and can be trusted to pass
   the trust on.  Known as a trusted third party, TTP, or a
   certificate authority, CA, in particular.
This situation exists in large companies for example - the
company knows Alice and Bob better than they may know each
other.  (In theory.)
Now, whether it exists in any real world depends on which
world pertains.  In the world of browsing, it is .. assumed
to exist, but that can be challenged.  In the world of email,
it pretty clearly doesn't exist - almost all (desired) email
is done between known parties, and the two parties generally
have much better ways of establishing and bootstrapping a
crypto relationship than asking for some centralised party
to do it.  (Hence, the relative success of PGP over S/MIME.)
Ditto for the world of secure systems administration (SSH).
When we come to BGP, it seems that BGP routing parties have
a very high level of trust between them.  And this trust is
likely to exceed by orders of magnitude any trust that a third
party could generate.  Hence, adding certs signed by this TTP
(well known CA or not) is unlikely to add anything, and will
thus likely add costs for no benefit.
If anyone tried to impose a TTP for this purpose, I'd suspect
the BGP admins would ignore it.  Another way of thinking about
it is to ask who would the two BGP operators trust more than
each other?
In such a world, a CA-signed certificate is an encumberance
only, and seems to be matched by comments in the AnonSec
draft that they are unlikely to be deployed.
iang
PS: on the general issue of doing what you call anonSec,
I'd say, fantastic, definately overdue, could save IPSec
from an embarrassingly slow adoption!  I do concur with all
the other posts about how "anon" is the wrong word, but I'd
say that getting the right term is not so important as doing
the work!
On the point of what the right word is, that depends on
the technique chosen.  I haven't got that far in the draft
as yet.

Re: potential new IETF WG on anonymous IPSec

[Ian Grigg]

Bill Stewart wrote:
Also, the author's document discusses protecting BGP to prevent
some of the recent denial-of-service attacks,
and asks for confirmation about the assertion in a message
on the IPSEC mailing list suggesting
   "E.g., it is not feasible for BGP routers to be configured with the
   appropriate certificate authorities of hundreds of thousands of peers".
Routers typically use BGP to peer with a small number of partners,
though some big ISP gateway routers might peer with a few hundred.
(A typical enterprise router would have 2-3 peers if it does BGP.)
If a router wants to learn full internet routes from its peers,
it might learn 1-200,000, but that's not the number of direct connections
that it has - it's information it learns using those connections.
And the peers don't have to be configured "rapidly without external 
assistance" -
you typically set up the peering link when you're setting up the
connection between an ISP and a customer or a pair of ISPs,
and if you want to use a CA mechanism to certify X.509 certs,
you can set up that information at the same time.
On the backbone, between BGP peers, one would have thought
that there are relatively few attackers, as the staff are
highly trusted and the wires are hard to access - hence no
active attacks going on and only some passive eavesdropping
attacks.  Also, anyone setting up BGP routing knows the other
party, so there is a prior relationship.
The whole point of the CA model is that there is no prior
relationship and that the network is a wild wild west sort
of place - both of these assumptions seem to be reversed
in the backbone world, no?  So one would think that using
opportunistic cryptography would be ideal for the BGP world?
iang

Re: Firm invites experts to punch holes in ballot software

[Ian Grigg]

Brian McGroarty wrote:
On Wed, Apr 07, 2004 at 03:42:47PM -0400, Ian Grigg wrote:

It seems to me that the requirement for after-the-vote
verification ("to prove your vote was counted") clashes
rather directly with the requirement to protect voters
from coercion ("I can't prove I voted in a particular
way.") or other incentives-based attacks.
You can have one, or the other, but not both, right?


Suppose individual ballots weren't usable to verify a vote, but
instead confirming data was distributed across 2-3 future ballot
receipts such that all of them were needed to reconstruct another
ballot's vote.
It would then be possible to verify an election with reasonable
confidence if a large number of ballot receipts were collected, but
individual ballot receipts would be worthless.


If I'm happy to pervert the electoral
process, then I'm quite happy to do it
in busloads.  In fact, this is a common
approach, busses are paid for by a party
candidate, the 1st stop is the polling
booth, the 2nd stop is the party booth.
In the west, this is done with old people's
homes, so I hear.
Now, one could say that we'd distribute
the verifiability over a random set of
pollees, but that would make the verification
impractically expensive.
iang

Re: Digital cash and campaign finance reform

[Ian Grigg]

Steve Schear wrote:

> By combining a mandated digital cash system for contributions, a cap on the
> size of each individual contribution (perhaps as small as $100), randomized
> delays (perhaps up to a few weeks) in the "posting" of each transaction to
> the account of the counter party, it could create mix conditions which
> would thwart the ability of contributors to easily convince candidates and
> parties that they were the source of particular funds and therefore
> entitled to special treatment.

How would you audit such a system?  I'm not that up
on political cash, but I would have expected that there
would be a need to figure out where money was coming
from, by some interested third party at least.

Also there would be a need to prove that the funds
were getting there, otherwise, I'd be the first to
jump in there and run the mix.  Or, the mint.


iang

Re: Maybe It's Snake Oil All the Way Down

[Ian Grigg]

Derik asks the pertinant question:
> The question is:  how do we convince M$ and Netscape to include something
> else in their software?  If it's not supported in IE, then it wont be
> available to the vast majority of users out there.

My view, again, IMHO:  ignore Microsoft.  Concentrate
on the open source solutions:  KDE, Mozilla, Apache.

These groups will always lead in security, because
they are not twisted by institutional conflicts;
they can examine historical security model from the
point of view of interested professionals, rather
than commercial actors trying to preserve this or
that revenue stream.

The trick is to understand whether HTTPS as it
currently is can be improved.  If it can, then
those above guys can do it.

Once the improvements are shown to work, Microsoft
will follow along.  They are a follower company,
not an innovator, and they need to see it work in
practice before doing anything.  As Derik suggests,
the vast majority of users will have to wait.

Along those lines, there's one piece of excellent
news:

Eric Rescorla wrote:
> One can simply cache the certificate, exactly as
> one does with SSH. In fact, Mozilla at least does exactly
> this if you tell it to.

That's fantastic!  I never knew that.  How does one
set that option on Mozilla?  (I'm using 5.0 / 1.3.1.)

-- 
iang

Re: Maybe It's Snake Oil All the Way Down

[Ian Grigg]

John Kelsey wrote:

> So, what can I do about it, as an individual?  Make the cellphone companies
> build good crypto into their systems?  Any ideas how to do that?

Nope.  Cellphone companies are big slow moving
targets.  They get their franchise from the
government.  If the NSA wants weak crypto, they
do weak crypto.

There is literally no point in hoping the cell
phone company - or any large franchise holder -
will help you in your fight against big brother.

OTOH, what you can do is argue for reasonable
crypto.

(Similar to GSM's.  That is hard to attack,
there is AFAIR no 'trival' attack, you have to
get access to the SIM or you have to probe the
phone with another phone over a period of hours.
I.e., the attacker leaves tracks, and he does so
in a way that will move him on to another mode
of tapping, such as purchasing a straight listening
device.)

Now, it seems that the US standards didn't get
even that.  There's definately a case for arguing
for better crypto in the US.  And, market forces
and all that, one would think that this would
happen in due course.

But arguing for strong crypto end-to-end - save
your breath.

John Kelsey (paraphrased):
> The only way I can see getting decent security [in any application] is to do
> something that doesn't require the rest of the world's permission or
> assistance.

(I edited the above to broaden the assert!)

Opportunistic crypto - that which uses the tools
immediately available and delivers crypto that
is the best available right now - is the only
crypto that will work for *you* the user in any
application.  Anything that defers security off
to some external party has a result of slowing
or killing the application, or delivering less
or no security than if you'd gone ahead in the
first place.

This isn't saying anything new.  It's the Internet,
after all.  On the Internet, one doesn't ask for
permission to participate.  That's no accident,
it's a core reason for its arisal.  Any protocol
that has a step of "now ask for permission" is,
IMHO, breaking one of the major principles of the
Internet.

> ... I
> have an old Comsec 3DES phone at home.  It's nice technology.  I think I've
> used it twice.  If you're not a cryptographer or a cocaine smuggler, you
> probably don't know anyone who owns an encrypting phone or would
> particularly want to.  Even if you'd like to improve your own privacy, you
> can't buy an end-to-end encrypting phone and improve it much.  That's what
> I'd like to see change.

I guess there's no reason why you couldn't load
up speakfreely on a custom Unix box with a flashed
OS, put in the USB headset, and sell it as an end
to end encrypting phone.  The software's all free,
a cheap machine is $300 at Walmart, some enterprising
crypto guy could ship out a network appliance for
$500.

(Or, put it in a PDA that's got the right hooks?)

Half the price of your old Comsec, wasn't it selling
for $1000?

-- 
iang

Re: [OT] why was private gold ownership made illegal in the US?

[Ian Grigg]

> From: Anonymous <[EMAIL PROTECTED]>
> 
> > Just curious, but what was the rationale under which private posession
> > of gold was made illegal in the US?  It boggles the mind...
> 
> Roosevelt needed to in effect devalue the dollar during the Great
> Depression.  In a deflationary depression, this acts as an inflationary
> force to cancel the negative effects of the deflation.  Even libertarian
> monetarists such as Milton Friedman agree that this is the proper approach
> when dealing with a depression.  Roosevelt did not have the advantage
> of modern economics and he made many economic mistakes which prolonged
> the depression, but devaluing the dollar was not one of them.
>
> However doing a straight devaluation was politically unacceptable
> at the time.  Because the dollar was pegged to gold, devaluing the
> dollar meant in effect increasing the value of gold in terms of dollars.
> This would represent a tremendous windfall to holders of gold.  And gold,
> by and large, is owned by the rich.
> 
> At the time, the U.S. faced a significant chance of a Communist/Socialist
> revolution such as had been seen in several other countries.  Class
> warfare was widespread, with armed violence between workers and management
> a common occurance.  Transferring a huge bounty into the hands of the
> rich would have inflamed the working class and risked plunging the
> country into chaos and revolution.
> 
> By eliminating private gold ownership, Roosevelt was able to take a
> necessary step to invigorate the economy, devaluing the dollar, while
> reducing the risk of a civil war.  The rich protested, of course, but
> in practice they went along with the measure as they were terrified
> of a workers' revolution.
> 
> Looking back, since there was, in fact, no revolution, it is easy to
> forget today how perilous the state of the country was in those times.
> For all those who curse Roosevelt's name, the U.S. at least ended up
> the decade in better shape than many countries, and things could have
> been far worse.  Americans could be living in a People's Republic today.
> Confiscating gold was clearly the lesser of the evils.

One is troubled by this rather excellent post by
anonymous.

I accept at face value the comments made, and they
certainly seem to match the facts and circumstances
of the times (the arisal of Keynsianism from the
roots of the Great Depression).

What troubles me is the pressumption of modern
economics somehow presenting an advantage.  What
would that advantage be?

And if that advantage would somehow ease the pain
of the Great Depression, or not have started it in
the first place, why is it that the IMF (claimed by
some to be a body that dispenses American economic
thought and American loans), advised the Argentinian
government to peg the peso, and gave them lots of
loans to keep it there?

Argentina is now in its 1st Great Depression of this
century, and it's pretty clear that the IMF and the
fixed exchange rate together were responsible as the
external events.

The only way I can reconcile this is to negate the
advantage or benefit conferred by modern economics?

Any other takes?

-- 
iang

Making Veri$ign rich(er)

[Ian Grigg]

> Ian Grigg wrote:
> 
> > Costs are still way too high.  This won't change until
> > browsers are shipped that treat self-signed certs as being
> > valid.  Unfortunately, browser manufacturers believe in
> > cert-ware for a variety of non-security reasons.
> [...]
> 
> Jason Holt <[EMAIL PROTECTED]> wrote:
>
> Self signed certs defeat the purpose of the certificate chain mechanism, which
> is not just there to make Veri$ign rich.

I understand that we are all working to make Veri$ign rich by
pushing their cert-ware.  Let me offer you a way in which we
could make them richer.  Believe me, they need our help.

> Mallory can self-sign a cert for
> bob.com, and hack Alice's DNS to point bob.com at her own site.  But it's
> (theoretically, anyway) much more difficult for her to convince Verisign that
> she owns bob.com.  If we trust Verisign to do that, then we know we're really
> talking to Bob when we visit bob.com.

What you describe above is an arcane theoretical attack.
An MITM is an extraordinarily difficult thing to do.  In
practice, totally impractical in risk analysis terms.  Its
impracticality is because there are always easier pickings
out there than conducting this attack.

Consider the attack.  You have to be able to so some spoofing,
or some interception, or some hacking of critical infrastructures
to do this.  After all, you have to be able to insert yourself
where Mallory needs to be in some sense, which means perverting
the normal flow of packets.

This is generally highly risky.  It is also expensive and
hard to control.

Say you are attacking Amazon.  If you pervert the DNS, as
you suggest, you will have to be able to handle a lot of DNS
requests.  Also, there is a high chance that you will be
noticed.  Net techies and hackers and ISP people are looking
at this sort of thing all the time.

Now consider what you get:  you can sit in the middle and
manage some SSL traffic.  So you'll need some capacity to
sift through all the different sessions to snaffle the good
data.  At the end of the day, you'll be burning up a lot of
CPU cycles to manage that traffic.  (So you'll need access
to some good sized hardware if you are attacking Amazon.)

Finally, you manage to start farming those valuable CCs.
Depending on how much hardware you've got that is managing
the thousands of MITM sessions, you could pick up quite a
bunch.

But, if you do manage to get to the point of actually
harvesting some CCs, you will by now have laid out such
a road map that someone should be able to find you.  So,
you had better have a fast exit.

Here's the thing:  even if you get some, it wasn't worth it.

Think like a crook.  Any thing that you can do with SSL,
you can do easier just by hacking into some poor NT box and
accessing the database to read off the CCs.  Then you get
to walk away without leaving any tracks.  Then you get the
last month's takings, because the company already did the
harversting for you.

And, in practice this is how it goes.  No thief ever bothers
to do an MITM, even over *un*encrypted traffic.  They simply
hack into the machines and steal it all.  That's why there
has never been a case of CCs sniffed over the net and being
used to commit a fraud (at least, no recorded ones).

Change the analysis to small merchants, and it is even worse
(of course Amazon will have a cert, so even its rich bounty
is unavailable, you have to do this on small merchants).



So, how do we make Veri$ign richer?  Easy, switch browsers
to accepting self-signed certs.  To see this, we have to
have tried or heard about small enterprises who have tried
to set up their SSL certs.

It's very expensive.  Most don't do it.  If we had the money
we could ask Netcraft.com for the figures, but, last I checked,
only 1% of servers have proper setups with proper certs.  Why?
because it is so expensive to set up.

Most sites try and fail.  They give up when they realise it
isn't worth their time.  So Veri$ign fails to sell the cert.
And the site remains unencrypted, uncerted, unprotected only
by the fact that nobody is watching.  (Security by obscurity
is indeed the greatest friend that we have, by actual saved
amounts of money.)

Now, if there was a halfway house, the site could at least
be set up so that it is encrypted.  Right there, is a big
improvement in security.  If we could do that, if we could
encourage the browsers to accept the self-signed but
encrypted web sites, that would let all the poor people in
the world (the other 99% that can't afford all the hoo-haa
of dealing with VeriSign and techies and ISPs and ...) have
a go at setting up secure web sites.  Secure by encryption
that is.

My guess is that it would get the number up to 10%.  Why
would that make Veri$ign richer?  Because taking that 10%
of encrypted sites would be a much more powerful target
market.  Veri$ign kno

Re: When encryption is also authentication...

[Ian Grigg]

> SSL for commerce is readily in place without batting an eyelid these days.

Costs are still way too high.  This won't change until
browsers are shipped that treat self-signed certs as being
valid.  Unfortunately, browser manufacturers believe in
cert-ware for a variety of non-security reasons.

Hopefully, one day the independant browser manufacturers
will ship browsers that show a different icon for self-
certs, rather than annoy the user with mindless security
warnings.  Then, we can expect a massive increase in
secure browsing as sites start defaulting to self-signed
certs, and a consequent massive increase in security, as
well as a follow-on massive increase in the sale of certs.

Unfortunately, we probably won't see an enhanced market
for CA certs until Verisign goes broke.

> However, I'd be interested to know just how many users out there would enter
> their card details on an unprotected site, despite the unclosed padlocks
> and the
> alert boxes.

Huge numbers of them.  You won't see it in security
lists, but most of your average people out there do
not understand the significance of the padlock, and
when merchants request credit card numbers, they
quietly forget to tell them.

And, in a lot of cases, credit card details are
shipped over cleartext email rather than browsers.
Many of these merchants have card-holder-present
agreements, the restrictions of which, they just
ignore.  Commerce being what commerce is, it is
more important to get the sale than deal with some
obscure security nonsense that doesn't make sense.

> Have security fears and paranoia been abated by widespread crypto
> to the point whereby users will happily transmit private data, whether
> encrypted
> or nay, just because they *perceive* the threat to now be minimal? Now that the
> media has grown tired of yet-another-credit-card-hack story?

Much of today's body of (OECD) net users don't read
the news about the net and don't understand the debate,
nor can they make sense of how to protect themselves
from a site that is hacked...

Three or four years back, much of the body of the
net was still technically advanced and capable of
understanding the fallacious security arguments.

These days, perversely, the users are better able
to evaluate the security risks, because they don't
understand the arguments, so they look to the
actual experience, which provides no warnings.

> Pointers to any evidence/research into this much appreciated... ta.

Unfortunately, real data is being kept back by the
credit card majors.  It is my contention that there
has never been a case of sniffed-credit-card-abuse,
and nobody I've ever talked to in the credit card
world has ever been able to change that.

On the whole, all net-related credit card fraud is
to do with other factors:  mass thefts from hacked
databases, fraudulent merchant gatherings, fear-of-
wife revocations, etc.  Nothing, ever, to do with
on-the-wire security.

-- 
iang

Re: Edinburgh Financial Cryptography Engineering 2002 - CFP

[Ian Grigg]

"R. A. Hettinga" wrote:

> > The Third Edinburgh Financial Cryptography Engineering Conference
> 
> This is so fucking boring. No one gets laid any more for doing FC.

No, no, NO!!  You are talking about Financial Cryptography,
the conferences running on a bunch of Caribbean islands.

Very different animal :-)  The original goal for a mixed
business and law and accounting and a tad of crypto was
perverted into YACC - yet another crypto conference - and
became very academic, very mathematical, very crypto, very
junior, and very ignorable.

(Even if I do say so myself, having presented two papers
at FC. :-)

Nobody that I ever heard of got laid at FC.  That's why we
started EFCE.  Literally we, the waiting debutantes, got
bored of not getting any after our 3rd (4th?) attempt at
the prom.  How many dresses does a girl have to buy?  So
we rewrote the rules to be a. everything that FC doesn't
do, and b. nothing that FC does.

And it worked.  We got laid, or, at least, some of us did.

As programme chair for the first two EFCEs, I monitored
the mating patterns of FCers with interest.  I found that
one third of the presenters managed to close/advance/secure
deals that moved money into their pockets.

Not huge amounts, I grant you.  FC - the art - really does
suffer from the academic throw-more-formulas at yet-another-
hype-problem legacy of FC - the conference.  People simply
don't expect it to go anywhere because of that.

So when the money turns up (several banks, several regulatory
types, several settlement types) to EFCE, they get caught by
surprise.  Often times, nothing gets consumated because the
guys don't come in the appropriate dress, and have to ask us
ladies for phone numbers instead.

Which is why, when the *2nd* EFCE happened, another 1/3 of
the presenters walked around with knowing, self-satisfied
smiles.

> Who cares for Yet Another Implementation of Something That No One Will Ever
> Use ?

Nobody.  But, you *are* invited to present it at EFCE, and
there you get to tap into the combined market wisdom of
*why* no one will ever use that system.  You won't get that
anywhere else.

You certainly won't get it at FC, as they are mostly
interested in the crypto content, which is not compatible
with a business assessment at all.  Go to FC and you will
hear about voting (with crypto), content protection (with
crypto), cracking machines (of crypto).  Yet another
session on the unworkable CA model (another fine waste of
good crypto).  More crypto than you know what to do with.

Come to EFCE and find out why your business sucks. See how
transactions are done.  Measure them.  Watch them fail.
See how your competitors already thought of it and coded
it several years ago. Watch the presenters get courted by
the audience, with numbers (yes, we rated the presentations
with numbers)!

> We have credit cards. Nothing will ever replace them, in spite of 2%
> transaction fees.

Oh, you are assuming a retail application.  There are many
interesting applications in FC, and retail is only one of
them.  The systems that have succeeded have not done so
within retail.  For example, PayPal succeeded in e-bay
auction settlements.

PS: everything above is past history;  this year I probably
won't make EFCE, and Rodney Thayer is doing the programme
chair.  He might change the dress code somewhat, and other
elements of the courting protocol.  Up to him.

-- 
iang

Re: Bad guys vs. Good guys

[Ian Grigg]

"R. A. Hettinga" wrote:

> At 6:03 PM -0700 on 5/11/02, Eric Cordian wrote:
> 
> > The reason we have ready availability of credit in the first place
> > is because consumer debt is the most profitable business in the
> > United States.

What are the margins on consumer debt?  Isn't it
all securitized, thus efficient?

> I really wonder what component of this market is actually payment
> driven. After all, to easily buy *anything* over, say, $100 right
> now, you have to borrow money, use a credit card, to do it.

Well, all of it, if you are talking about costs of
doing the payment.

The problem with paying for anything over $100 is
having the money with you at that time.  Most
purchases are done at some random future time,
and without a credit payment, it would be necessary
to take huge amounts of cash with you at all times.

This results in costs:  forgone interest on ones
wealth, risk of seizure, and the mere cost of having
to wear clothing with big pockets.

A credit token allows you to bring the stored wealth
with you;  but it's not the only way.  If there was
pervasive FC, then you would have choice between
credit and accrued wealth.  You could flip out your
palmtop, access your stored stocks in MicroHard, flip
it in the market and pay with straight "now" cash.

Or you could chose credit.  But one could imagine
that if you can access your real wealth straight
away then a lot of rational people with palmtops
with financial modelling on them would calculate
the effective price of the two choices (credid v.
now-cash flipped from stored wealth t+3) quickly
enough to show you that paying with cash was
optimal in far more circumstances.

> If it were actually cheaper -- and safer -- to use some form of
> internet financial cryptography protocol like blind signatures, I
> wonder how much of that "consumer debt" market would go away. Not all
> of it, obviously, but I do wonder about how much of that number is
> purely consumer debt and not just "payment finance", for lack of a
> better term

Rational individuals pay with cash when they can.
They stop paying with cash when they run out, as
the cost of cash rises rapidly with volume.  CC
vendors exploit this by offering free credit for
a month, thus making one perceive that there is
no benefit to using credit, and then, it wins hands
down over cash.  Providing access to stored wealth
in t+3 would redress the balance and provide for a
more optimal solution.

OTOH, rational companies pay with debt when they
can.  So it's not as if the world will lose the
credit industry just because FC provides us with
now-cash.  And, I suspect people acting as corporate
actors would treat their credit requirements as
delivering cash and adding to their total credit
equation, as the spectrum between credit and wealth
becomes efficient.  That is, they might pay with
credit, but the credit is provided in cash, and
then passed on to the merchant, so the credit
provider is unlinked from the purchase.

PS: t+3 means trade settlement in 3 seconds.

-- 
iang