Re: cryptographic ergodic sequence generators?
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?
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
http://www.israel21c.org/bin/en.jsp?enPage=BlankPageenDisplay=viewenDispWhat=objectenDispWho=Articles%5El496enZone=TechnologyenVersion=0; Israel21c Code breakers crack GSM cellphone encryption By ISRAEL21c staffSeptember 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?
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?
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?
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?
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?
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
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?
-- 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]