Re: Is cryptography where security took the wrong branch?

[Ian Grigg]

Eric Rescorla wrote:
> > b. we seem to be agreeing on 1% penetration of
> > the market, at least by server measurement (see
> > my other post where I upped that to 1.24% in the
> > most recent figures).
> This really depends on your definition of market.
> SSL was designed to protect credit card transactions, period.

We do have the problem that SSL can be considered
to be a channel security product, or it can be
considered to be a credit card protection product.

Part of the problem lies in the switching of arguments
from one purpose to another.  If one criticises the
credit card aspects, the answer is often that SSL is
a channel security product.  And v.v.  The result is
slippery, and it can only be done so many times before
one gains the impression that SSL is snake oil and
the real needs are elsewhere.

We need to decide.  If SSL is aimed at credit cards,
and HTTPS is only present for credit cards, then why
is it that OpenSSL spends so much time on it?  What's
their incentive?  I'm not sure I understand why Eric
and Tim and Ben and whoever does it these days spend
huge amounts of unpaid time developing code so that
other people could protect ... the credit card issuers'
risks?

And, isn't it about time we designed a new product
to protect against the threats that users face
today?  One that could be used by the rest of us?

I think it's fair to say that SSL was designed
because of credit cards.  But now, SSL/TLS is for
the purpose of a channel security requirement.  The
credit card thing is a forgotten issue, SSL can be
used to protect credit cards, but the protection
of credit cards no longer has anything to do with
the way SSL/TLS is designed, tested, measured or
implemented.

To rest any current requirements on credit cards
means that SSL should be oriented towards the
threat to credit cards, and it plainly isn't.
That's easy to see, in that if SSL was oriented
to credit cards, why did they do SET?  (And,
SHTTP seems much closer to that mission, on a
quick reading, at least.)



Having said all that, maybe we need to add to the
list of "market success measures" a part on success
at original target, and applicability for other
missions?



> For that, the market penetration is near 100%.

(OK.  My guess there would be well above 50%, probably
around 90%, by servers, of those taking credit cards.
I spent a little time googling, and found about 10%
of credit card sites had open forms.  I've also seen
a fair amount of anecdotal evidence that suggests
that any merchant who's less than 100k of revenue
probably won't be worrying too much about secured
delivery of credit cards.  Probably in terms of
number of transactions and total value dealt with,
the coverage is right up there above 99%...)

> > d.  subjective good.  For HTTPS, again, it's a
> > decidedly mixed score card.  When I go shopping
> > at Amazon, it makes little difference to me, because
> > the loss of info doesn't effect me as much as it
> > might - $50 limit on liability.
> That $50 limit is a funny thing.

Yup!  It is an extraordinarily interesting thing
from an economics pov.  It's a piece of market
interventionism that pleases few, except the
marketing folks that admire its beauty, or the
economists who admire its subsidy.

> I look at it this way:
> You don't PERSONALLY eat the cost of fraud on your own
> card but you eat the cost of fraud on other people's cards.
> Thus, as in many situations, it's in your interest for
> everyone else to practice good hygiene.

Right.  That might be a good argument if the issuers
of credit cards practiced good hygiene.  But, in
practice, they don't.  What they practice is risk
management.  That is, they figure out what the fraud
rate is, and charge percentages and penalties according
to the sector.

The issuers - the people that the browser and server
people are working so hard to protect - couldn't give
a flying f**k if the user has breached hygiene.  What
they are concerned about is that the costs are covered
by fees.  And, perversely, a little known finance
secret, the system works best if the fees are stabilised
at a high level.  See above, $50.

Reputedly, chargeback rates and fees in the fringe
industries - adult for example - can reach 50%.  But,
instead of denying those uses of the card - hygiene -
issuers have encouraged it (...until recently.  There is
now a movement, over the last year, to withdraw service
from the fringe industries, but, it is because of
additional risks being added, not the risks of fraud
or user loss.  Visa is doing it, Mastercard is "waiting
and seeing.")

It's all well and good that users are encouraged to
practice hygiene.  But, users should practice risk
management first.  Hygiene second.  In this case, the
merchant - a user - should be allowed to calculate his
risks.  With HTTPS, he is denied that opportunity.

(We all know where this is heading ...:-)

The other thing to be aware of is that ecommerce itself
is being stinted badly by the server and browser limits.
Th

Re: cryptographic ergodic sequence generators?

[John S. Denker]

On 09/06/2003 02:09 PM, Perry E. Metzger wrote:
> For making things like IP fragmentation ids and other similar
> protocol elements unpredictable,
OK, that more-or-less defines an objective.

> it would be useful to have what I'll call a cryptographic ergodic
> sequence generator
I'm not at all sure that is the best way to approach
the stated objective.
As usual, we need a clear idea of what threats we
are facing; we need more detail than is provided by
the objective mentioned above.  Also, as always, we
want to impose large costs on the bad guys and
small costs on the good guys, so we need to have
some sort of cost model.  In this case, the main
issues appear to be:
 a) some cost if try to re-use an ID prematurely.
 b) some cost if the bad guy guesses what ID we are
going to use in the near future.  (Presumably he
can replay IDs from the recent past as much as
he wants;  we can't stop that.)
 c) constraints on n, the number of bits in the ID.
 d) computation costs and communication costs.
 e) possibly it is important for our peer at the
receiving end to be able to treat our IDs as
being _sequential_ and well-ordered, as the
Subject: of this thread suggests, as opposed
to being merely distinct.
There's no point in designing something that works
well only when it is not under attack... so let's
assume it is under heavy attack.  The bad guy is
trying like crazy to guess IDs.  This means that
cost (b) must be taken very seriously.
In particular, suppose we have an ergodic design
with n=24.  Then the bad guy can just sit and watch
the first 16 million packets, and can then eat us
for lunch, predicting future IDs with 100% success.
In the long run (large numbers of packets), this is
outcome is as bad as anything could possibly be.
We can do better.

I recommend we consider schemes that are not
strictly ergodic, but instead incorporate some
degree of randomness.
To understand the effectiveness of my schemes, we
must understand item (c), the constraints on n.
Let us suppose that there can be at most 2^k IDs
"alive" in the system at any one time.
 -- Obviously we must have n>=k;  otherwise it
would be impossible to use the IDs reliably, even
in the absence of an attack.
 -- More interestingly, we need to assume n is
appreciably bigger than k, or the whole game is
not worth playing.  That's because the bad guy
has one chance in 2^(n-k) of guessing an ID that
corresponds to an "alive" ID, no matter how
cleverly we choose the IDs.
Therefore, without further ado:

Scheme #1:  Construct a n-bit-long plain-ID using
a k-bit counter concatenated with (n-k) bits of
randomness.  Then form the final crypto-ID by
encrypting the plain-ID.  (The encryption key is
randomly chosen at system boot time, and remains
secret.)
This guarantees that no ID will collide with any
of the 2^k most-recently-used IDs.  It also
guarantees that the bad guy's chance of guessing
the next ID is only 2^(n-k).  [After all, *we*
don't have any better chance of guessing our next
ID, because of the randomness.]
In the long run, this is better than the strictly
ergodic scheme by a factor of 2^(n-k).  This is
about as well as we can do, in a minimax sense,
based on the maximum success the bad guy can have.
NOTE:  If the IDs need to be sequential, as
mentioned in desideratum (e) above, then we need to
give the decryption key to our peer at the receiving
end.  The peer can recover the plain-ID, discard
the randomness, and use the counter for sequencing.
Scheme #2:  We could go to the extreme of having
no counter at all, just n bits of randomness.  To
prevent collisions, we use a content-addressable
memory sufficient to remember the last 2^k IDs we
sent.  We choose candidate IDs at random; if a candidate
would cause a collision, we discard the candidate and
try again.  This anti-collision step increases
computational costs by roughly one part in 2^(n-k)
and increases communications costs not at all.
About the only advantage this has over scheme #1 has
to do with whether you think k is an upper bound or
a typical value.  If the typical number of "alive"
IDs in the system is less than the maximum number,
scheme #2 introduces more randomness and therefore
makes life harder for the bad guy.
This of course totally sacrifices any notion of
sequencing.
Scheme #3:  This is a hybrid of scheme #1 and scheme
#2.  Keep a c-bit counter, where we allow c to be
less than k.  This absolutely guarantees no collisions
with the last 2^c IDs, and makes it highly likely
that there will be no collisions stretching back much
farther than that.  We take our chances, without
bothering to have a content-addressable memory.
This scheme exploits the tradeoff between cost (a)
and cost (b).  In the likely case that cost (b) is
much larger, it might pay to reduce the chance of
incurring cost (b) even if this means a slight risk
of incurring cost (a).
-
The Cryptography Mailing List
Unsubscribe 

Re: cryptographic ergodic sequence generators?

[David Wagner]

Perry E. Metzger wrote:
>I've noted to others on this before that for an application like
>the IP fragmentation id, it might be even better if no repeats
>occurred in any block of 2^31 (n being 32) but the sequence did not
>repeat itself (or at least could be harmlessly reseeded at very very
>long intervals).

Let E_k(.) be a secure block cipher on 31 bits with key k.
(For instance, E might be 16 rounds of Luby-Rackoff using
f(x) = AES_{AES_{k}(i)}(x) as the Feistel function in the ith round.)
Pick an unending sequence of keys k0, k1, k2, ... for E.

Then your desired sequence can be constructed by
  E_k0(0), E_k0(1), E_k0(2), ..., E_k0(2^31 - 1),
  2^31 + E_k1(0), 2^31 + E_k1(1), 2^31 + E_k1(2), ..., 2^31 + E_k1(2^31 - 1),
  E_k2(0), E_k2(1), E_k2(2), ..., E_k2(2^31 - 1),
  2^31 + E_k3(0), 2^31 + E_k3(1), 2^31 + E_k3(2), ..., 2^31 + E_k3(2^31 - 1),
  ...,

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

Re: Is cryptography where security took the wrong branch?

[Anne & Lynn Wheeler]

At 03:01 AM 9/7/2003 -0400, Ian Grigg wrote:
Reputedly, chargeback rates and fees in the fringe
industries - adult for example - can reach 50%.  But,
instead of denying those uses of the card - hygiene -
issuers have encouraged it (...until recently.  There is
now a movement, over the last year, to withdraw service
from the fringe industries, but, it is because of
additional risks being added, not the risks of fraud
or user loss.  Visa is doing it, Mastercard is "waiting
and seeing.")
a webhosting company presented some numbers at some standards meeting that 
they handled ten websites (all with monthly hits higher than the number one 
in the published monthly "hit" rankings) ... five were adult-type downloads 
and five were various kinds of (non-adult) software downloads. The 
adult-type charge backs were comparable to mainstream brick&mortar upscale 
retail outlets  while the mainstream software downloads was on the 
order of fifty percent. It seemed that the people that download software 
are much more "fringe" than the types that download adult material (i 
believe they threw in some snide comments about the character f people that 
download software).

as I've mentioned before  ipsec had been progressing very slowly in 
ietf for some time. in '94 ... you saw VPN being introduced at router 
working group (fall san jose meeting?) and introduction of SSL. both could 
be considered the domain of ipsec. Several of the router vendors didn't 
have processors capable of doing the crypto for VPN ... so you somewhat saw 
vaporware product announcements following the san jose meeting and VPN 
didn't make much progress until more router vendors had processors capable 
of handling the crypto load. the ipsec people seemed to evnetually come to 
terms with vpn by referring to it as lightweight ipsec (so the vpn people 
got to refer to ipsec as heavyweight ipsec). also in 94 you started to see 
SSL deployment  basically a transport level ipsec feature implemented 
by applications (could be considered because ipsec was having such a hard 
time progressing).

minor past refs:
http://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative 
to PKI?
http://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting 
Automatic Teller Machines
http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec

what i remember from the time was that SSL was thought as handling all of 
the shopping experience  not just the credit card part but the feedback 
was that doing everything thru SSL cut the thruput capacity by about a 
factor of five (or you could handle five times as much traffic on the same 
hardware not using SSL).. The result was rather than using SSL for all 
commercial activity ... it was cut back to just handling the credit card part.

Basically, SSL was being used for hiding the credit card number while in 
transit (over the internet). However, almost all the exploits have been 
from harvesting credit card files  even when it would be possible to 
"sniff" non-encrypted credit card transmission. That issue is somewhat that 
you can be very targeted and quickly get possibly hundred thousand credit 
card numbers  or you could put up a listening post and hope that you 
run across several a day (or maybe even an hour).

SET came out after SSL ... and made extensive use of public key operations. 
I reported a public key operation performance profile for SET within a 
couple weeks after the original specification ... which several people 
working on SET claimed to be one hundred times too slow. It was probably 
just wishful thinking on their part since when they had some running 
prototype ... the profile was within a couple percent of measured. An issue 
was that SET was at least an order of magnitude more resource intensive 
than SSL ... and the only thing it did was protect credit card information 
in transit; basically it was only addressing the same (credit card) threat 
model as SSL  but with significantly more overhead (having possibly 
hundred times more PKI didn't actually make things more secure).

lots of past comments about what SSL does for credit card transactions:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
lots of recent comments in sci.crypt about eliminating certificates from 
SSL by collapsing the public key stuff into DNS:
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#44 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At 
least I hope it's new)
http://www.garlic.com/~lynn

Re: Is cryptography where security took the wrong branch?

[Eric Rescorla]

Ian Grigg <[EMAIL PROTECTED]> writes:

> Eric Rescorla wrote:
> > > b. we seem to be agreeing on 1% penetration of
> > > the market, at least by server measurement (see
> > > my other post where I upped that to 1.24% in the
> > > most recent figures).
> > This really depends on your definition of market.
> > SSL was designed to protect credit card transactions, period.
> 
> We do have the problem that SSL can be considered
> to be a channel security product, or it can be
> considered to be a credit card protection product.
My view would be that SSL is a channel security product designed
to be used with HTTPS, which is pretty clearly a credit card
security product. But like I said, the people who designed it
weren't very sophisticated about such things. I remember Marca
or Jim saying that they just wanted to solve all security
problems in one shot.

There's also the issues of Kaufman's law, which is that
if you design something useful people will use it for
purposes other than what it was intended for and you'll be
criticized for being shortsighted. And as I've said,
Hickman wasn't very experienced.

[Note to people who just came in: the people who designed what
everyone thinks of as SSL, SSLv3, were relatively sophisticated, but
the security model comes from SSLv1 and SSLv2, which were designed by
amateurs.]

> To rest any current requirements on credit cards
> means that SSL should be oriented towards the
> threat to credit cards, and it plainly isn't.
See above. The Netscape philosophy was simplicity uber alles.
If you look at SHTTP you can see that that's clearly not
my philosophy. (Though if I were designing it today it would
be simpler). 

> > I look at it this way:
> > You don't PERSONALLY eat the cost of fraud on your own
> > card but you eat the cost of fraud on other people's cards.
> > Thus, as in many situations, it's in your interest for
> > everyone else to practice good hygiene.
> 
> Right.  That might be a good argument if the issuers
> of credit cards practiced good hygiene.  But, in
> practice, they don't.  What they practice is risk
> management.  That is, they figure out what the fraud
> rate is, and charge percentages and penalties according
> to the sector.
I don't think of hygiene as opposed to risk management.
It's a risk management tool. 

> The other thing to be aware of is that ecommerce itself
> is being stinted badly by the server and browser limits.
> There's little doubt that because servers and browsers
> made poorly contrived decisions on certificates, they
> increased the overall risks to the net by reducing the
> deployment, and probably reduced the revenue flow for
> certificate providers by a factor of 2-5.
I doubt that. Do you have any data to support this claim?

> > Vis a vis SHTTP, I'm not sure if that was the right design
> > or SSL was. However, they had relatively similar threat models.
> 
> hmm.  Are you saying that SHTTP didn't have a threat
> model (one interpretation of your "Hickman" post) or
> that SHTTP assumed the Internet Threat Model (ITM)
> in the same way that SSL did?
SHTTP assumed the Internet Threat Model. We did so explicitly
(though not in the document) whereas Hickman kind of stumbled
into it via a bunch of course corrections by more experienced people.

SHTTP, however, had a more generalized usage model than SSL.  Thus,
SHTTP did one really important thing that SSL is still struggling
with: it could protect passive content.  Say you want to provide
static content for download and provide security for it. If you use
SSL and your server gets hacked you're SOL. If you use SHTTP, however,
you can presign things and have your server immune to that attack by
keeping the key offline.  We were designing with more than credit
cards in mind.

Incidentally, when designing SHTTP we envisioned that credit
transactions would be done with signatures. I would say that
the Netscape guys were right in believing that confidentiality
for the CC number was good enough.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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

Re: Is cryptography where security took the wrong branch?

[Eric Rescorla]

Ian Grigg <[EMAIL PROTECTED]> writes:
> But, it's now a decade down the path, and its well
> time to re-assess whether SSL/HTTPS, etc, is using
> the right models to benefit us.  Or anybody, really.

To follow up on this line a little more, I don't see why you're so
hung up on SSL here. SSL is perfectly capable of supporting an
SSH-style "leap of faith" authentication model or an anonymous
model. In fact, this is pretty much exactly how it's 
used for SMTP over TLS. 

It seems to me that your issue is with the authentication
model enforced by browsers in the HTTPS context, not with
SSL proper.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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

Re: Is cryptography where security took the wrong branch?

[Ian Grigg]

Eric Rescorla wrote:
...
> > The other thing to be aware of is that ecommerce itself
> > is being stinted badly by the server and browser limits.
> > There's little doubt that because servers and browsers
> > made poorly contrived decisions on certificates, they
> > increased the overall risks to the net by reducing the
> > deployment, and probably reduced the revenue flow for
> > certificate providers by a factor of 2-5.
> I doubt that. Do you have any data to support this claim?

Sure.  SSH.

It's about take up models.  HTTPS'
model of take-up is almost deliberately designed
to reduce take-up.  It uses a double interlocking
enforcement on purchase of a certificate.  Because
both the browser and server insist on the cert
being correct and CA-signed and present, it places
a barrier of size X in front of users.

Instead, if there were two barriers, each of half-X,
being the setup of the SSL server (a properly set
up browser would have no barrier to using crypto),
and the upgrade to a CA-signed cert, then many more
users would clear the hurdles, one after the other.

How high can you jump?  When I was young we used
to do this high jump thing, where we'd get up to
5 feet or so.

I could never do 6 feet.  I couldn't even do 4 feet
these days, but, I could do any number of 3 feet jumps.
I could probably even do a few 3 feet jumps these days.

(In that youth, we called them by feet.  These days,
a one metre jump looks more imposing...)

I'm curious.  You really think that in order to sell
certificates, the best thing is to make them hard to
use?  Is this a "quality" argument?

iang

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

Re: Is cryptography where security took the wrong branch?

[James A. Donald]

--
On 7 Sep 2003 at 9:48, Eric Rescorla wrote:
> It seems to me that your issue is with the authentication 
> model enforced by browsers in the HTTPS context, not with SSL 
> proper.

To the extent that trust information is centrally handled, as 
it is handled by browsers, it will tend to be applied in ways 
that benefit the state and the central authority.  Observe for 
example that today all individual certificates must be linked 
to one's true name and social security number if it is to 
receive default acceptance, and analogously for corporate 
certificates.

To the extent that trust information is decentralized in end 
user databases, as it is handled by SSH clients it will tend to 
be applied in ways that benefit the end user.

Unsurprisingly, we observe greater end user utilization of SSH 
public keys.   The vast majority of people encounter the 
concept of a public key when they log on to an SSH server. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 +VOl3Vqd/2KPdwuRgmR7CoTexKy84DdSChLXr3rS
 4WcxJQwYP0cvPgTXK3Xq5OaTtELGHKXqra0DHd90x


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

Code breakers crack GSM cellphone encryption

[R. A. Hettinga]

Israel21c

Code breakers crack GSM cellphone encryption
By ISRAEL21c staffšššSeptember 07, 2003



The faults discovered in the 850 million cellphones could be used by
thieves or eavesdroppers to listen in on calls, steal calls and even to
impersonate phone owners.


Company develops unbreakable data encryption code

š

Israeli counter-terrorism experts teams up with U.S. cyber-security firm

š


Technion

š
š

Experts at the Technion in Haifa who specialize in cryptography have
discovered that mobile phone calls made on the popular GSM network are
vulnerable to break-ins.  The faults discovered in the 850 million
cellphones could be used by thieves or eavesdroppers to listen in on calls,
steal calls and even to impersonate phone owners.

The team of researchers in Haifa, including Professor Eli Biham and
doctoral students Elad Barkan and Natan Keller, presented their findings at
the Crypto 2003 conference held two weeks ago at the University of
California, Santa Barbara.

The 450 participants, many of whom are leaders in encryption research,
'were shocked and astounded' by their revelation that most cellphones are
susceptible to misuse.  'They were very interested in our work and
congratulatory,' Biham said.

If the cellphone companies in 197 countries want to correct the code errors
that expose them to trickery and abuse, they will have to call in each
customer to make a change in the cellphone's programming, or replace all of
the cellular phones used by their subscribers.

Biham,  Barkan, and Keller's discovery involved a basic flaw in the
encryption system of the GSM (global system for mobile communications)
network, which is used by 71 percent of all cellphones.

"Elad discovered a serious flaw in the network's security system,"
explained Biham. "He found that the GSM network does not work in the proper
order: First, it inflates the information passing through it in order to
correct for interference and noise and only then encrypts it."

At first,"I told him (Barkan) that it was impossible," Biham told Reuters.
"I said such a basic mistake would already have been noticed by someone
else. But he was right, the mistake was there."

In the wake of this discovery, the three Technion researchers developed a
method that enables cracking the GSM encryption system at the initial
ringing stage, even before the call begins, and later on, listening in on
the call. With the aid of a special device that can also broadcast, it is
possible to steal calls and even to impersonate phone owners, even in the
middle of an ongoing call.

"We can listen in to a call while it is still at the ringing stage and
within a fraction of a second know everything about the user," Biham said.
"Then we can listen in to the call.

"Using a special device it's possible to steal calls and impersonate
callers in the middle of a call as it's happening," he said. GSM code
writers made a mistake in giving high priority to call quality, correcting
for noise and interference, and only then encrypting, Biham said.

Recently, a new and modern encryption system was chosen as a response to
previous attacks on existing encryption system. But the Technion
researchers also succeeded in overcoming this improvement. The new method
works for all GSM networks worldwide, including the U.S. and Europe.

Four years ago, a number of articles were published by Israel researchers -
including
Biham - warning of the possibility of cracking the GSM code. An even
earlier study on this potential problem was conducted by Professor Adi
Shamir of the Weizmann Institute of Science, a world expert in cryptography
whose encryption system is widely used in the field of satellite television.

The cellular companies responded to these earlier publications by
explaining that it would be very difficult to implement these theoretical
scenarios. To crack the codes, a hacker would need to tap into a
conversation at the  precise moment it began and there is really no chance
of doing this, the cellular firm said.

Biham explained  that encryption ciphers were kept absolutely secret until
1999 when a researcher called Marc Briceno succeeded to reverse engineer
their algorithms. "Since then many attempts have been made to crack them,
but these attempts required knowing the call's content during its initial
minutes in order to decrypt its continuation, and afterwards, to decrypt
additional calls. Since there was no way of knowing call content, these
attempts never reached a practical stage. Our research shows the existence
of the possibility to crack the codes without knowing anything about call
content," he notes.

A copy of the research was sent to GSM authorities in order to correct the
problem, and the method is being patented so that in future it can be used
by the law enforcement agencies.

The GSM Association, representing vendors w

Re: Is cryptography where security took the wrong branch?

[Eric Rescorla]

Ian Grigg <[EMAIL PROTECTED]> writes:

> Eric Rescorla wrote:
> ...
> > > The other thing to be aware of is that ecommerce itself
> > > is being stinted badly by the server and browser limits.
> > > There's little doubt that because servers and browsers
> > > made poorly contrived decisions on certificates, they
> > > increased the overall risks to the net by reducing the
> > > deployment, and probably reduced the revenue flow for
> > > certificate providers by a factor of 2-5.
> > I doubt that. Do you have any data to support this claim?
> 
> Sure.  SSH.
That's not data, it's an anecdote--and not a very supportive one
at that. As far as I know, there isn't actually more total
SSH deployment than SSL, so you've got to do some kind of 
adjustment for the total potential size of the market, which
is a notoriously tricky calculation. Do you have any actual
data or did you just pull 2-5 out of the air?

> It's about take up models.  HTTPS'
> model of take-up is almost deliberately designed
> to reduce take-up.  It uses a double interlocking
> enforcement on purchase of a certificate.  Because
> both the browser and server insist on the cert
> being correct and CA-signed and present, it places
> a barrier of size X in front of users.
I don't know where you got the idea that the server insists on cert
correctness. Neither ApacheSSL nor mod_SSL does.

> Instead, if there were two barriers, each of half-X,
> being the setup of the SSL server (a properly set
> up browser would have no barrier to using crypto),
> and the upgrade to a CA-signed cert, then many more
> users would clear the hurdles, one after the other.
Maybe, maybe not. You've never heard of price inelasticity?

The fact of the matter is that we have no real idea how
elastic the demand for certs is, and we won't until someone
does some real econometrics on the topic. Unless you've
done that, you're just speculating.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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

Re: Is cryptography where security took the wrong branch?

[Ben Laurie]

Eric Rescorla wrote:
> Incidentally, when designing SHTTP we envisioned that credit
> transactions would be done with signatures. I would say that
> the Netscape guys were right in believing that confidentiality
> for the CC number was good enough.

I don't think so. One of the things I'm running into increasingly with
HTTPS is that you can't do an end-to-end check on a cert. That is, if I
have some guy logging into some site using a client cert, and that site
then makes a back-end connection to another site, there's no way it can
prove to the back-end site that it has the real guy online (without
playing nasty tricks with the guts of SSL, anyway), and there's
certainly no way to prove that some particular response came from him.
Signing stuff would deal with this trivially.

Cheers,

Ben.

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

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



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

Re: Is cryptography where security took the wrong branch?

[Ian Grigg]

Eric Rescorla wrote:
> 
> Ian Grigg <[EMAIL PROTECTED]> writes:
> 
> > Eric Rescorla wrote:
> > ...
> > > > The other thing to be aware of is that ecommerce itself
> > > > is being stinted badly by the server and browser limits.
> > > > There's little doubt that because servers and browsers
> > > > made poorly contrived decisions on certificates, they
> > > > increased the overall risks to the net by reducing the
> > > > deployment, and probably reduced the revenue flow for
> > > > certificate providers by a factor of 2-5.
> > > I doubt that. Do you have any data to support this claim?
> >
> > Sure.  SSH.
> That's not data, it's an anecdote--and not a very supportive one
> at that. As far as I know, there isn't actually more total
> SSH deployment than SSL, so you've got to do some kind of
> adjustment for the total potential size of the market, which
> is a notoriously tricky calculation.

It's more than an anecdote.  If I quote from your
slides, SSH has achieved an almost total domination
of where it can be deployed.  Wherever there are Unix
servers, we suspect the domination of SSH.

(I haven't got a good figure on that.  Some stats
have been done Neils Provos and Peter Honeyman in
a paper, but I can't interpret the results sufficiently
to show SSH server distribution, nor penetration [1].
It's now a hot topic, so I believe the figures will
become available in time.)

> Do you have any actual
> data or did you just pull 2-5 out of the air?


There is a middle ground between data and the air,
which is analysis.  I've been meaning to write it
up, but I'm working on the SSL threat model right
now.


> > It's about take up models.  HTTPS'
> > model of take-up is almost deliberately designed
> > to reduce take-up.  It uses a double interlocking
> > enforcement on purchase of a certificate.  Because
> > both the browser and server insist on the cert
> > being correct and CA-signed and present, it places
> > a barrier of size X in front of users.
> I don't know where you got the idea that the server insists on cert
> correctness. Neither ApacheSSL nor mod_SSL does.


I take the following approach here.  I think that
for Apache to promote the interests of the users,
it should configure automatically to run SSL, and
automatically generate a self-signed cert on install
(unless there is one there already).  I admit I
haven't looked to see whether that is reasonable
or possible, but I gather it does neither of those
things, and it certainly doesn't make doing self-
signed certs so easy.

Oh, and Apache does lead one astray by calling the
self-signed cert a "snake-oil" cert.  This misleads
the users into thinking there is something wrong
with a self-signed cert.  I'm not sure how easy
that is to correct.


> > Instead, if there were two barriers, each of half-X,
> > being the setup of the SSL server (a properly set
> > up browser would have no barrier to using crypto),
> > and the upgrade to a CA-signed cert, then many more
> > users would clear the hurdles, one after the other.
> Maybe, maybe not. You've never heard of price inelasticity?
> 
> The fact of the matter is that we have no real idea how
> elastic the demand for certs is, and we won't until someone
> does some real econometrics on the topic. Unless you've
> done that, you're just speculating.

The reason we have no idea how elastic the demand
for certs is, is because a) we've never tried it,
and b) we've not looked at the data that exists.

(Yes, those reasons are contradictory.  That's part
of the world that we want to change.)

It's nothing to do with whether the ivory tower
brigade does some econowhatsists on their models
and then speculates as to what this all means.

Have a look at the data that is available [2].  You
will see elasticity.  Have a look at the history
of a little company called Thawte.  There, you will
see how elasticity contributed to several hundred
millions of buyout money.

Mark S prays to the god of elasticity every night.

Check out the Utah digsig model.  If you can see
a better proof of cert elasticity, I'd like to know
about it.

iang

[1] http://www.citi.umich.edu/u/provos/ssh/
http://www.citi.umich.edu/techreports/reports/citi-tr-01-13.pdf

[2] http://www.securityspace.com/
http://www.securityspace.com/s_survey/sdata/200308/certca.html

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

Re: Is cryptography where security took the wrong branch?

[Ian Grigg]

Ed,

I've left your entire email here, because it needs to
be re-read several times.  Understanding it is key to
developing protocols for security.

Ed Gerck wrote:
> 
> Arguments such as "we don't want to reduce the fraud level because
> it would cost more to reduce the fraud than the fraud costs" are just a
> marketing way to say that a fraud has become a sale. Because fraud
> is an hemorrhage that adds up, while efforts to fix it -- if done correctly
> -- are mostly an up front cost that is incurred only once.  So, to accept
> fraud debits is to accept that there is also a credit that continuously
> compensates the debit. Which credit ultimately flows from the customer
> -- just like in car theft.

What you are talking about there is a misalignment
of interests.  That is, the car manufacturer has no
incentive to reduce the theft (by better locks, for
e.g.) if each theft results in a replacement sale.

Conventionally, this is dealt with by another interested
party, the insurer.  He arranges for the owner to have
more incentive to look after her car.  He also publishes
ratings and costs for different cars.  Eventually, the
car maker works out that there is a demand for a car
that doesn't incur so many follow-on costs for the owner.

This is what we call a "free market" solution to a
problem.  The alternative would be some form of
intervention into the marketplace, by some well-
meaning "authority."

The problem with the intervention is that it generally
fails to arise and align according to the underlying
problem.  That is, the authority is no such, and puts
in place some crock according to his own interests.

E.g., ordering all car manufacturers to fit NIST
standard locks (as lobbied for by NIST-standard
lock makers).  Or giving every car owner a free
steering lock.

And, that's more or less what we have with HTTPS.  A
security decision by the authority - the early designers
- that rides on a specious logical chain with no bearing
on the marketplace, and the result being a double block
against deployment.

(It's interesting to study these twin lock-ins, where
two parties are dependant on the other for their
mutual protocol.  For those interested, the longest
running commercial double cartel is about to come
crashing down:  DeBeers is now threatened by the the
advent of gem quality stones for throwaway prices,
its grip on the mines and retailers won't last out
the decade.  Understanding how DeBeers created its
twin interlocking cartels is perhaps the best single
path to understanding how cartels work.)

> Some 10 years ago I was officially discussing a national
> security system to hep prevent car theft. A lawyer representing
> a large car manufacturer told me that "a car stolen is a car sold"
> -- and that's why they did not have much incentive to reduce
> car theft. Having the car stolen was an "acceptable risk" for
> the consumer and a sure revenue for the manufacturer. In fact, a
> car stolen will need replacement that will be provided by insurance
> or by the customer working again to buy another car.  While the
> stolen car continues to generate revenue for the manufacturer in
> service and parts.
> 
> The "acceptable risk" concept is an euphemism for that business
> model that shifts the burden of fraud to the customer, and eventually
> penalizes us all with its costs.
> 
> Today, IT security hears the same argument over and over again.
> For example, the dirty little secret of the credit card industry is that
> they are very happy with +10% of credit card fraud over the Internet.
> In fact, if they would reduce fraud to zero today, their revenue
> would decrease as well as their profits.

Correct!  You've revealed it.  IMHO, not understanding
that fact has been at the root cause of more crypto biz
failures than almost any other issue.  My seat of the
pants view is that over a billion was lost in the late
eighties on payments ventures alone (I worked for a
project that lost about 250 million before it gave up
and let itself be swallowed up...).

In reality, the finance industry cares little about
reducing fraud.  This is easy to show, as you've done.

> There is really no incentive to reduce fraud. On the contrary, keeping
> the status quo is just fine.
> 
> This is so mostly because of a slanted use of insurance. Up to a certain
> level,  which is well within the operational boundaries, a fraudulent
> transaction does not go unpaid through VISA,  American Express or
> Mastercard servers.  The transaction is fully paid, with its insurance cost
> paid by the merchant and, ultimately, by the customer.
> 
> Thus, the credit card industry has successfully turned fraud into
> a sale.  This is the same attitude reported to me by that car manufacturer
> representative who said: "A car stolen is a car sold."
> 
> The important lesson here is that whenever we see continued fraud, we must
> be certain: the defrauded is profiting from it.  Because no company will accept
> a continued  loss ithout doing anythi

Re: Is cryptography where security took the wrong branch?

[Eric Rescorla]

Ian Grigg <[EMAIL PROTECTED]> writes:

> Eric Rescorla wrote:
> > 
> > Ian Grigg <[EMAIL PROTECTED]> writes:
> > 
> > > Eric Rescorla wrote:
> > > ...
> > > > > The other thing to be aware of is that ecommerce itself
> > > > > is being stinted badly by the server and browser limits.
> > > > > There's little doubt that because servers and browsers
> > > > > made poorly contrived decisions on certificates, they
> > > > > increased the overall risks to the net by reducing the
> > > > > deployment, and probably reduced the revenue flow for
> > > > > certificate providers by a factor of 2-5.
> > > > I doubt that. Do you have any data to support this claim?
> > >
> > > Sure.  SSH.
> > That's not data, it's an anecdote--and not a very supportive one
> > at that. As far as I know, there isn't actually more total
> > SSH deployment than SSL, so you've got to do some kind of
> > adjustment for the total potential size of the market, which
> > is a notoriously tricky calculation.
> 
> It's more than an anecdote.  If I quote from your
> slides, SSH has achieved an almost total domination
> of where it can be deployed.

No. There are lots of other things you CAN do with SSH
that people don't do that often. 


> > Do you have any actual
> > data or did you just pull 2-5 out of the air?
> 
> 
> There is a middle ground between data and the air,
> which is analysis. 

Data precedes analysis.

> It's nothing to do with whether the ivory tower
> brigade does some econowhatsists on their models
> and then speculates as to what this all means.
> 
> Have a look at the data that is available [2].  You
> will see elasticity.  Have a look at the history
> of a little company called Thawte.  There, you will
> see how elasticity contributed to several hundred
> millions of buyout money.

Nope.

Elasticity is about how much consumption changes when price
changes, not about what people who were already going to buy
choose to buy.

Look at it this way:
If Pepsi cut their price by 50%, it might affect their
market share but would have only a very small amount of
effect on how much fluid people consume overall. The 
market for beverages is competitive but not particularly
elastic. That could easily be happening here.

Ian, it's a major econometrics project to determine how 
elastic a given good has. To imagine that you can do
it with a little handwaving is simply naive.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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

Re: Is cryptography where security took the wrong branch?

[Eric Rescorla]

Ben Laurie <[EMAIL PROTECTED]> writes:

> Eric Rescorla wrote:
> > Incidentally, when designing SHTTP we envisioned that credit
> > transactions would be done with signatures. I would say that
> > the Netscape guys were right in believing that confidentiality
> > for the CC number was good enough.
> 
> I don't think so. One of the things I'm running into increasingly with
> HTTPS is that you can't do an end-to-end check on a cert. That is, if I
> have some guy logging into some site using a client cert, and that site
> then makes a back-end connection to another site, there's no way it can
> prove to the back-end site that it has the real guy online (without
> playing nasty tricks with the guts of SSL, anyway), and there's
> certainly no way to prove that some particular response came from him.
> Signing stuff would deal with this trivially.

Well, I'd certainly like to believe that this is true, since
it would mean that Allan and I were right all along. :)

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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

Re: Is cryptography where security took the wrong branch?

[Eric Rescorla]

"James A. Donald" <[EMAIL PROTECTED]> writes:

> --
> On 7 Sep 2003 at 9:48, Eric Rescorla wrote:
> > It seems to me that your issue is with the authentication 
> > model enforced by browsers in the HTTPS context, not with SSL 
> > proper.
> 
> To the extent that trust information is centrally handled, as 
> it is handled by browsers, it will tend to be applied in ways 
> that benefit the state and the central authority.
Yeah, I'd noticed that being able to buy stuff at Amazon
really didn't benefit me at all.

-Ekr



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

Re: Code breakers crack GSM cellphone encryption

[John Doe Number Two]

It's nice to see someone 'discovering' what Lucky Green already figured-out
years ago.  I wonder if they'll cut him a check.

-JD, II

Also sprach R. A. Hettinga aka [EMAIL PROTECTED] on 07.9.03 14:32 :

>  t=object&enDispWho=Articles%5El496&enZone=Technology&enVersion=0&>
> 
> 
> Israel21c
> 
> Code breakers crack GSM cellphone encryption
> By ISRAEL21c staffšššSeptember 07, 2003
> 
> 
> 
> The faults discovered in the 850 million cellphones could be used by
> thieves or eavesdroppers to listen in on calls, steal calls and even to
> impersonate phone owners.
> 
> 
> Company develops unbreakable data encryption code
> 
> š
> 
> Israeli counter-terrorism experts teams up with U.S. cyber-security firm
> 
> š
> 
> 
> Technion
> 
> š
> š
> 
> Experts at the Technion in Haifa who specialize in cryptography have
> discovered that mobile phone calls made on the popular GSM network are
> vulnerable to break-ins.  The faults discovered in the 850 million
> cellphones could be used by thieves or eavesdroppers to listen in on calls,
> steal calls and even to impersonate phone owners.
> 
> The team of researchers in Haifa, including Professor Eli Biham and
> doctoral students Elad Barkan and Natan Keller, presented their findings at
> the Crypto 2003 conference held two weeks ago at the University of
> California, Santa Barbara.
> 
> The 450 participants, many of whom are leaders in encryption research,
> 'were shocked and astounded' by their revelation that most cellphones are
> susceptible to misuse.  'They were very interested in our work and
> congratulatory,' Biham said.
> 
> If the cellphone companies in 197 countries want to correct the code errors
> that expose them to trickery and abuse, they will have to call in each
> customer to make a change in the cellphone's programming, or replace all of
> the cellular phones used by their subscribers.
> 
> Biham,  Barkan, and Keller's discovery involved a basic flaw in the
> encryption system of the GSM (global system for mobile communications)
> network, which is used by 71 percent of all cellphones.
> 
> "Elad discovered a serious flaw in the network's security system,"
> explained Biham. "He found that the GSM network does not work in the proper
> order: First, it inflates the information passing through it in order to
> correct for interference and noise and only then encrypts it."
> 
> At first,"I told him (Barkan) that it was impossible," Biham told 
> Reuters-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Is cryptography where security took the wrong branch?

[Anne & Lynn Wheeler]

At 09:44 AM 9/7/2003 -0700, Eric Rescorla wrote:
Incidentally, when designing SHTTP we envisioned that credit
transactions would be done with signatures. I would say that
the Netscape guys were right in believing that confidentiality
for the CC number was good enough.
actually was supposedly no worse than the face-to-face world  aka make 
the transit part secure ... so that the rest became the same as the 
physical world  transactions go into big merchant file ... because 
there are several merchant related business processes that subsequently 
reference the transaction and number.

the problem was that their appear to be little or not fraud associated with 
threats against CC numbers in flight (with or w/o SSL), however the threat 
model was against the merchant credit card file and the numbers in the 
clear; it wasn't that the process was any different than the physical 
world, but the web merchants allowed the file to be access able from the 
network (which didn't exist in the physical world).

the requirement given the x9a10 working group was to preserve the integrity 
of the financial infrastructure for all electronic retail payments (debit, 
credit, stored-value, ach, internet, non-internet, point-of-sale, 
etc).  Turns out the internet threat profile wasn't so much data-in-flight 
 but having the operation connected to the internet at all.  X9.59 
addressed most of that ... which neither ssl or set did  and did it 
with just a single digital signaturee. misc. x9.59
http://www.garlic.com/~lynn/index.html#x959

--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Is cryptography where security took the wrong branch?

[Anne & Lynn Wheeler]

At 12:30 PM 9/7/2003 -0700, James A. Donald wrote:
To the extent that trust information is centrally handled, as
it is handled by browsers, it will tend to be applied in ways
that benefit the state and the central authority.  Observe for
example that today all individual certificates must be linked
to one's true name and social security number if it is to
receive default acceptance, and analogously for corporate
certificates.
in the case of SSL domain name certificate  for both domain name 
infrastructure and CA/PKI  it is is a case of authenticating that the 
the web site you think you are talking to is really the web site you are 
talking to. The business issue is that the domain name registration and the 
CA/PKI are disjoint business operations and the domain name registration 
didn't provide for a really good authentication mechanism. As a result when 
getting a certificate request, the CA/PKI has to check with the domain name 
infrastructure  map their information out to an external world 
identification, and then map the entity making the certificate request out 
to the same external world identification.

Out of all this, there is somewhat a request from the CA/PKI industry that 
a public key be registered as part of domain name registration (no 
certificate, just a public key registration). Then SSL domain name 
certificate requests coming into a CA/PKI can be digitally signed, the 
CA/PKI can retrieve the authoritative authentication public key (for the 
domain name ownership) from the domain name infrastructure and authenticate 
the request  eliminating all the identification gorp (and also done w/o 
the use of certificates).

misc. additional recent musings:
http://www.garlic.com/~lynn/2003l.html#60  Proposal for a new PKI model (At 
least I hope it's new)
--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

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

Re: Code breakers crack GSM cellphone encryption

[David Honig]

At 03:32 PM 9/7/03 -0400, R. A. Hettinga wrote:
>If the cellphone companies in 197 countries want to correct the code errors
>that expose them to trickery and abuse, they will have to call in each
>customer to make a change in the cellphone's programming, or replace all of
>the cellular phones used by their subscribers.

I've read that the lifecycle of a cell phone is about 2 years, 
FWIW.

During a kids-channel TV show, I saw that if you buy 4 dolls
you get a prepaid phone free.  Took me a while to get over
that future-shock.

>A copy of the research was sent to GSM authorities in order to correct the
>problem, and the method is being patented so that in future it can be used
>by the law enforcement agencies.

"Laughing my ass off."  Since when do governments care about patents? 
How would this help/harm them from exploiting it?   Not that
high-end LEOs haven't already had this capacity ---Biham et al
are only the first *open* researchers to reveal this.









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

Re: Is cryptography where security took the wrong branch?

[Bill Stewart]

Ian Grigg wrote:
Pretty much.  "Trust" in the certificate world means that
a CA has authorised a web server to conduct crypto stuff.
and James Donald and Lynn Wheeler also brought up the issues
of who's certifying what, True Names, etc.
SSL certs are really addressing (I won't say "solving", exactly)
two different problems -
- Whether the communication session you're setting up with
example.com is really set up with them and not a MITM
- Whether Example.com is slightly more likely to be run by Example Inc.,
and not some impostor like Example-Nigeria Ltd
or Bad Example Spa Resort, GMBH, both of whom
happily accept all major credit cards.
DNSSEC (or something like it) takes care of the first problem,
without the intervening step of requiring True Names.
It doesn't help the second problem, and DNS doesn't either,
which is one reason that ICANN is so insistent on getting True Names
for whois records and forcing registrars to get them as well.
It's possible to get some uncertified human-readable information
about a domain name from its whois records.
It's possible to get more human-readable information from SSL certs,
and in some cases that information might be certified in a meaningful way,
but in other cases it's not, and browsers aren't typically very good at
telling you that information unless you try hard to get it,
and when they do nag users about it, users usually ignore it.
But it's not always even useful information - Bad Example might have
a cert from trustcenter.de because they take Visa cards at their spa,
but you may be on their _other_ web site that's selling cheap knockoffs of 
whatever the Example Inc. you were trying to deal with sells.
Your browser isn't smart enough to know that.

While DNSSEC mostly follows a hierarchical model, that doesn't mean
that you couldn't get some user-friendly or browser-friendly
certification model that does provide multi-homed values for
rating information about web sites - Consumer Reports or the
Better Business Bureau or whatever could do signed statements
about domain names without building it into DNS or SSL.






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

Re: Is cryptography where security took the wrong branch?

[Ian Grigg]

Eric Rescorla wrote:

> Elasticity is about how much consumption changes when price
> changes, not about what people who were already going to buy
> choose to buy.

Sorry, Eric, I'm not quite with you on this...

You said:
> > Maybe, maybe not. You've never heard of price inelasticity?


You haven't established anything beyond some apparent
intention to consider inelasticity, as if it is some
superior magic property we have to do battle with.


Then, you said:
> The fact of the matter is that we have no real idea how
> elastic the demand for certs is


Firstly, most goods are elastic.  The natural
order of things is that if you want to establish
that your particular claimed good is otherwise,
then you might want to show it?  Please?

So, let's call this bluff:  please show why and
how the demand for certs is inelastic!

Secondly, I'm proposing self-signed certs.  What
does price inelasticity mean when the price is
zero?


> Ian, it's a major econometrics project to determine how
> elastic a given good has. To imagine that you can do
> it with a little handwaving is simply naive.


Thirdly, after we have established the inelasticity
of the certs in question - a tough call - and we've
also established that it means something even when
the price is zero...

...we now want to establish how useful a tool is that
won't measure it, as you assert, without such a "major
econometrics project?"

I'm curious, why did you bring econometrics up if it
is too hard to use?

And, why should *I* use it?  The certs are elastic,
until I see something to the contrary.

Fourthly, econometrics delivers explanatory power.
I.e., the past.  It is weak on predictive power.
I.e., the future.

That's because the assumptions are arbitrary.  And,
that's why marketeers don't use econometrics:  they
prefer to change the assumptions, which takes us out
of the data set.

Which is where I am:  the assumptions.

First step, examine the assumptions of the past.
That's what we on this list have been doing for the
last 6 months.

Second step, change them.

iang

PS: I'm curious, is there some URL that talks about
application of inelasticity and econometrics to crypto?
Somebody who's selling the notion?

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

Re: Is cryptography where security took the wrong branch?

[Eric Rescorla]

Ian Grigg <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
> > > Maybe, maybe not. You've never heard of price inelasticity?
> 
> 
> You haven't established anything beyond some apparent
> intention to consider inelasticity, as if it is some
> superior magic property we have to do battle with.

Ian, The situation is really simple:

You wrote:

"The other thing to be aware of is that ecommerce itself
is being stinted badly by the server and browser limits.
There's little doubt that because servers and browsers
made poorly contrived decisions on certificates, they
increased the overall risks to the net by reducing the
deployment, and probably reduced the revenue flow for
certificate providers by a factor of 2-5."

I asked you where you got the factor of 2-5 and you waved your hands a
lot and didn't really provide any real answer. As it happens, I'm
extremely familiar with the set of techniques that one would use in order
to derive a number like this and it's quite apparent that you
haven't used any of them. As a consequence, there's no reason to take
your estimate as anything other than some number that you pulled out
of the air.

None of this is to say that it's not potentially worth trying to
change things and see if it makes a difference.  What I object to,
however, is quantitative claims made without evidence, which is what
you have been doing here.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

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

Re: Is cryptography where security took the wrong branch?

[James A. Donald]

--
At 12:30 PM 9/7/2003 -0700, James A. Donald wrote:
> > To the extent that trust information is centrally handled,
> > as it is handled by browsers, it will tend to be applied in
> > ways that benefit the state and the central authority

On 7 Sep 2003 at 17:19, Anne & Lynn Wheeler wrote:
> Out of all this, there is somewhat a request from the CA/PKI
> industry that a public key be registered as part of domain
> name registration (no certificate, just a public key
> registration). Then SSL domain name certificate requests
> coming into a CA/PKI can be digitally signed, the CA/PKI can
> retrieve the authoritative authentication public key (for the
> domain name ownership) from the domain name infrastructure
> and authenticate the request  eliminating all the
> identification gorp (and also done w/o the use of
> certificates).

I seem to recollect that request, or a request very like it,
from some years back. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 HwFde4LnTv0p3hXtAQB7k2SuW04BmKJDrrnyzvRr
 4d+oWUHfpousTBWRKiFyUmAecGZRIK1gitZ4NELNp


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