Re: cryptographic ergodic sequence generators?

2003-09-07 Thread 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?

2003-09-07 Thread 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 brickmortar 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)

Code breakers crack GSM cellphone encryption

2003-09-07 Thread R. A. Hettinga
http://www.israel21c.org/bin/en.jsp?enPage=BlankPageenDisplay=viewenDispWhat=objectenDispWho=Articles%5El496enZone=TechnologyenVersion=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.
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 who sell the world's 

Re: Is cryptography where security took the wrong branch?

2003-09-07 Thread 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?

2003-09-07 Thread 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?

2003-09-07 Thread 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 anything to reduce it.

It'e perverse, because as you say, the 

Re: Is cryptography where security took the wrong branch?

2003-09-07 Thread 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: Is cryptography where security took the wrong branch?

2003-09-07 Thread 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: Code breakers crack GSM cellphone encryption

2003-09-07 Thread 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?

2003-09-07 Thread 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]