Re: CFP: PKI research workshop
On Thu, 27 Dec 2001 [EMAIL PROTECTED] wrote: >given that authentication is being performed as part of some business >process or function ... then it is normally trivial to show it is easier >to have authentication (even digital signature authentication) integrated >into such business processes and correspondingly easy to show that >certificate-based operations are redundant, superfulous and extraneous >(modulo the issue of toy demos are cheaper than modifying production >business operations). The only case in which the PKI solution is not redundant is in offline clearing. But getting your point-of-transaction online is easier than paying attention to PKI. I happen to like offline clearing -- it opens up the possibility of new transaction types and doing transactions in places you couldn't before. But the practical issue is, everybody who's interested in electronic transactions of any kind is also interested in getting online, and when PKI's were deployed in "developing" areas (south africa) they got dumped just as soon as the area was developed enough for communications to support online clearing. On the principle of people refusing to adopt something until it relieves pain, maybe we won't see a real PKI deployed until we need to serve markets where speed-of-light delays make online clearing impractical. Mars, for example, is 3 to 22 light-minutes away. I don't imagine someone using an ATM on Mars is going to want to wait 12 to 88 minutes for online clearing (more if the protocol is talky or the bandwidth is busy...). So a martian colony might be the first practical application of PKI and/or digital cash, assuming the colonists want to do business with Earth companies. But a colony looks pretty distant right now: we haven't even got an outpost there yet. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
On Wed, 26 Dec 2001, Matt Crawford wrote: >As I never tire of saying, "PKI is the ATM of security." > >Meaning that has a certain niche relevance, but is claimed by >proponents to be the answer to every need, and is the current magic >word for shaking the money tree. > In fact, that may be exactly it. PKI, as espoused by vendors, once established, will become an indispensable monopoly, like AT&T before the breakup. Investors love the fantasy of buying a kajillion shares for cheap today and then having them be shares in an indispensable monopoly next year, so they are inclined to believe. The problem is that none of the vendors are offering anything that someone who has significant volume (like a financial-services company might) cannot provide for themselves. The FS companies can easily wait to adopt, because the margins offered by PKI are fairly small and the initial investment required is fairly large. Perhaps the margins will remain too small until royalty payments can be eliminated entirely (until any patents expire) and the FS companies can roll their own. Whether or not the margins are too small, The FS companies can wait that long easily. But the PKI vendor cannot wait. S/he will be out of business in three or four years if nobody adopts. The patents will be for sale then much cheaper than the royalty payments s/he is offering, and the FS negotiator across the table knows it. The PKI vendor therefore is going to get the worst end of the deal every time s/he goes to financial services vendors, because s/he is not dealing from a position of strength, and had best learn the harsh lesson sooner rather than later. A PKI will happen, eventually, but nobody is going to get into a position where the financial-services sector depends on them and has to pay them. That's as fundamental in business as the second law of thermodynamics in physics, and chasing the dream of becoming an indispensable monopoly to the financial services sector promises to be as frustrating to the seekers as the quest for a perpetual motion device. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
On Wed, 26 Dec 2001, Carl Ellison wrote: >Ray, > > if you look at PKI as a financial mechanism (like credit cards), >then I see two major problems: > >1. the PKI vendors aren't financial institutions, so they aren't in a >position to assume risk and make money from that Yep. So far, that's true. Financial stuff is the only killer app in sight for a PKI, and the financial services sector is conservative and heavily regulated. There is a substantial barrier to entry: just try to imagine running off a few thousand PKI-backed credit cards and going into business competing against mastercard/visa/amex. Vendor acceptance is slow and the regulatory hurdles are high. >2. the current PKI thinking (e.g., with "rebuttable presumption of >non-repudiation") is anti-consumer, when viewed as a financial >mechanism, and I can't imagine that succeeding even if the vendors >were banks. Oh, I can. If it's any good, you ought to be able to offer cards with lower interest rates/fees, and people will go for that. The whole idea of PKI in financial services after all, is to reduce the amortized cost of transactions by reducing fraud. If there's a significant cost savings, you make more money even if you pass part of it on to the consumers. But nobody wants to be the first -- they all want to be able to look at the business case built by some "bleeding-edge" financial-services company that adopted and deployed PKI-based infrastructure in some market and got measurable results, and they all want any and all kinks in the technology to get worked out by someone else before they touch it. In financial services, they want mature technology that's cheap and reliable to produce and use -- and they will roll their own in order to make it cheaper instead of paying some "outside" PKI company. That's happening now, in fits and starts, with various products internationally and in various closed markets. If the business case is good, the financial services companies will be starting to pick it up for more mainstream use in a few years. Odds are, however, that each and every one of them is going to want their own PKI -- where P stands for Private, or Proprietary, rather than Public. A Public Key Infrastructure happens when the chaotic situation which that brings about gets consolidated and standardized, so don't look for that for at least a decade. Basically we have no chance of getting a Public Key Infrastructure in place right now because we don't have enough different Private Key Infrastructures in place for it to have started to hurt yet. People won't go for the PKI until they are in some kind of pain that it relieves. And if financial services businesses are involved, they will do it in such a way that no PKI vendor ever makes a profit they could possibly have made themselves. Look for them to be buying regulations that say PKI is part of financial services and can only be provided by licensed financial services corporations sometime in the next few years. Like I said, don't get too discouraged -- these things happen slowly and it's very much a matter of stages of development. People don't do things until the pain of not doing them gets worse than the pain of doing them. Public Key comes about when Private Keys have been common for several years and their multiplicity causes pain. That in itself will take several years after the Private Key structures are fully adopted. The Private Key structures get adopted several years after the profit margins, split between consumers, vendors, and financial institutions, each overcome the pain of changing infrastructure. That will take several years after the initial offering. The initial offerings are happening now in very restricted markets, but don't look for it to happen in domestic consumer markets until the results of the restricted-market offerings are several years old and the technology involved hasn't changed AT ALL for several years. They are looking for a technology that's been in use long enough to establish a baseline and get results that look stable and repeatable. That's when financial services companies will begin to take them seriously enough to consider that the pain of deploying new infrastructure may overcome the painof absorbing losses due to fraud. These are just network effects: PKI will trickle through at the end as surely as water runs downhill, because it's a better solution. It's just going to take a decade or two, or maybe four or five decades if there's a substantial monopoly somewhere in the industry. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: CFP: PKI research workshop
On Sat, 1 Dec 2001, Carl Ellison wrote: >To a large extent, the hoped-for public key infrastructure (PKI) has >not "happened yet." PKI for large, eclectic populations has not >materialized; PKI for smaller, less diverse "enterprise" populations >is beginning to emerge, but at a slower rate than many would like or >had expected. Why is this? Inherent conservatism of the financial business world. The only way you're going to get a PKI going fast is if people can use it to do financial transactions they couldn't do before. I mean, there are other uses for PKI, but money is the heart and soul of it because money is usually the only application people have where security is important to them personally. And you're not going to get people to use it for money unless you can do it while all the bankers and all the merchants get to do business with the same companies they're doing business with now, the relatively few "people" whom they trust with their money. So far, PKI's have been mostly advanced by new companies which don't have hooks into the infrastructure of financial services yet. So you get failure of interoperability, and a certain amount of FUD. The ones that have been advanced by the companies who are among the trusted elite, have been incomplete or flawed on technical grounds (although that may be less of a barrier to adoption than initially hoped). It's not like these barriers are going to last forever; they're getting used up, and companies like VISA are now trying to develop some kind of authentication scheme. But they're not used up yet. Hey, don't be too discouraged; have a little perspective. It's going a lot faster than the adoption of paper money went. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Stegdetect 0.4 released and results from USENET search available
On Fri, 21 Dec 2001, Harald Koch wrote: >How many images are posted to usenet every *day*, never mind the sheer >number of images stored on webservers everywhere. IANAS, but a mere one >million messages is too small a sample set to be statistically >significant. Actually, statistically significant sample sizes have more to do with the probability distribution than the sheer number of objects being analyzed. One million images has the same statistical significance whether it's one day of traffic or one year of traffic. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [FYI] Did Encryption Empower These Terrorists?
On Wed, 26 Sep 2001, Enzo Michelangeli wrote: >As Ben noted, it is not difficult to combine the following two >requirements: > >a) protection of PAN from any party different from cardholder or acquiring >bank >b) no special software installed on cardholder's PC besides an SSL-capable >browser > >For example, let's suppose that the acquirer run a stateful trusted and >well protected machine (gateway), and the merchant a simple secure web >server whose CGI scripts can act as SSL clients. The transaction protocol >could work this way: A few problems: 1) in a typical credit card transaction, the seller neither knows, nor cares, what bank issued the credit card. Thus, connecting to the correct gateway becomes a minor problem. 2) No provision for dispute resolution. What happens in a month and a half when george gets his credit card bill back and says "I've never been there and never done any business with this person"? The bank generates a chargeback and sends it to the merchant who, in the absence of knowledge about the buyer's identity, has no recourse. George may or may not be the person who made the transaction; but the merchant has no way to even begin to try to find out. In general, "anonymity" and "credit" are immiscible. If you want anonymous transactions, you absolutely cannot abide by the laws that require chargebacks, merchant and/or bank liability in case of fraud (instead of consumer liability), etc. Compliance with those laws requires the merchant and banks to have the very information that anonymity prohibits them from having. For anonymous transactions, you want something a whole lot more like cash, with the same failure modes (ie, no shift of liability in case of fraud) as cash. That requires infrastructure which will not be allowed to be built. > >1. At check-out time, the merchant server connects to the gateway with >SSL, authenticates itself (even simple username/password is OK) and passes >to the gateway the details of the transaction, minus the card number (that >it doesn't have). > >2. The gateway creates a record in an internal database, stores the data >there, and returns a unique and unguessable handle (a random-looking >string with a length of a few tens of characters). > >3. The merchant server redirects the buyer's browser to the gateway, >passing it the handle (e.g., appended to the URL as "get" parameter). Also >this HTTP session is over SSL. > >4. The gateway prompts the buyer for the card number and other personal >details, in a form also containing the handle as hidden field. > >5. The buyer enters the requested data, and submits. The gateway, through >the handle, retrieves the transaction record, combines its data with the >card number and other data entered by the buyer, processes the >authorization request through the card associations' network, gets back >the auth code, stores it in the database transaction record, and redirects >the browser to a URL on the merchant server, again appending the record's >handle as parameter. > >6. The merchant server gets the handle, opens another SSL connection (also >authenticated) to a URL on the gateway also passing it the handle, and >gets back a receipt confirming the authorization. It then displays a >"Thank you" page to the buyer's browser, and communicates all the data to >the division in charge for the order's fulfillment. The End. > >And lo: no fancy crypto (apart from SSL), which also helps performances; >no client certificates; and no bulky wallets that someone gotta pay for >(and have to be installed, and often crash Windows ;-) ). Also the >merchant server just needs very simple and inexpensive SSL client >software: cURL, CryptSSL+LWP, JSSE, whatever. > >The only piece still missing here is the cardholder authentication: the >gateway is managed by the acquiring bank, but only the issuing bank has >business relationships with the cardholder, and is in the position of >putting in place authentication mechanisms. That's where 3D Secure may >help. > >Cheers -- > >Enzo > > > > > >- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: "Pirate Utopia," FEED, February 20, 2001
On Mon, 24 Sep 2001, Nomen Nescio wrote: >The Stegdetect paper proceeded to further analyze the 2+ images by >looking for passwords that would produce meaningful messages from the >hypothesized hidden content, via dictionary attack. No valid passwords >were found, and the authors concluded therefore that these were all >false positives. This does not seem to be a fully supported conclusion. Actually, dictionary attacks reveal about sixty percent of passwords, so for every six passwords you find on a dictionary attack, you can infer ten actual stegotexts times the ratio between your analyzed and discovered (possibly-false) positives. While he has analyzed only two percent of his sample, that's a sufficient number that if even even a tenth of one percent of his positives were real he'd have discovered at least a few passwords. The paper is solid statistical methods; lack of any dictionary-yeilding passwords in that big a sample is very strong evidence that the sample is overwhelmingly made up of false positives. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SSSCA = Digital Rectal Thermometer Security Act ?
On Mon, 10 Sep 2001, Ian BROWN wrote: >Titles I and II of the draft are a truly bizarre mix. I provides the horrible >DMCA-on-crack that has mostly been discussed so far; but II is all >sweetness and light on encouraging the development of security systems and >training of personnel, including the appropriation of $135m annually by 2006 for >infosec R&D and training. Trying buy off certain industry and university sectors? >Somehow I think several magnitudes more pork would be required ;) You can also read title II as creating a "guild" of people who are allowed to know this stuff or practice it. I don't like that idea, myself. I think that any time you have a class of people who are the only ones allowed to make a living on certain information, you wind up in a situation where there is an effective prohibition on anyone else *knowing* the information. And, let's face it, if knowing how to program becomes a guilded profession, we're going to lose about 90% of our programming talent -- 'cause the really good ones are doing stuff a long time before they get actually trained. If they're not allowed to mess with computers when they're fifteen and manic, and if they're not allowed to get over, around, and all through the system software the way they do, they'll never develop the interest and become CS majors and then the really good programmers they become now. Reading title I as outlawing general-purpose computers, title II appears to outlaw members of the general non-guilded public knowing how to program them. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Outreach Volunteers Needed - Content Control is a Dead End
On Wed, 29 Aug 2001, Dan Geer wrote:
>
>> Content control is a dead end.
>
>Folks,
>
>You only get an even number of {privacy, copyright} -- either the
>owner of information controls how it is used or he does not. Either
>you embrace copyright-and-privacy, or you embrace neither.
>
>It really is time to be careful what you ask for.
This is not how I see things being developed. In fact, I'd say
you only get an odd number of {privacy, copyright} -- either I
control what happens on my machine, or someone else does.
Right now, the copyright technologies we've been seeing are
actively invasive of the information purchaser's privacy.
The whole "you can display it but you can't print even a little
bit of it" thing that Adobe is doing, for example, is damned
offensive: by what right do they take copyright to exclude fair
use? And while we're at it, let's look at the RIAA, the MPA,
etc. Does copyright allow them to control what software I can
and cannot run in the so-called "Privacy" of my own home? I
don't think so.
Shakespeare had a rich public domain to work with because there
were no copyright laws in his era. I'd say the world has been
enriched by the fact. So yes, even as a software author, writer
of short stories, musician, and several other things, I'll
cheerfully give up copyright in favor of privacy and think
the world is a better place for it. Copyright has gotten way
too oppressive lately, it's time to enrich the public domain
and allow creative people to do what they want with it.
Bear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Danish police: Not Safeguard Easy but passwords were weak
On Thu, 9 Aug 2001, [iso-8859-1] Bo Elkjær wrote: >It was reported in national media - including tv - that the police had >succesfully _broken_ the encryption. This, it seems, is not the case. The >police have managed to find the _passwords_ of the five encrypted computers. And we're back to the easy chunk of cryptanalysis. That 128-bit key doesn't do you a darn bit of good if it's derived from one of the two million most common words in your language. In Finnish and/or German, I believe the working vocabulary isn't even that large; even in English, which has a huge vocabulary, two million words will include words that have been out of style for centuries. There is no help for people who are not willing or able to store real entropy in their brains somehow. "Password: swordfish" just ain't gonna cut it when the rubber meets the road. And here is where we get to the cryptanalytic uses of those high-powered clusters some folk here have been admiring: The fact is that the ability to chew through about two million words plus forty million variations as possible passwords, will get you a substantial number of decrypts no matter how good the system is. No need for an exhaustive search of the huge keyspace until you've finished your exhaustive search of the relatively tiny vocabulary of the user's native language. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: moving Crypto?
On Wed, 1 Aug 2001, Ben Laurie wrote: >Richard Schroeppel wrote: >> >> It's time to consider moving the annual Crypto conference out of >> Santa Barbara. The obvious places are Vancouver, Toronto, or >> Mexico. I know zilch about these places as conference venues. >> Could someone knowledgable summarize the relative merits? > >How about London? > >Cheers, > >Ben. The Domestic Terrorism Act of 2000 makes London as dangerous for crypto researchers as the DMCA makes the USA. Remember, in England, you can be arrested for having "information useful to terrorists" Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: moving Crypto?
On 31 Jul 2001, Derek Atkins wrote: >Why do you say it's time to move the conference? AFAIK, it's ALWAYS >been in SB. Too bad I can't make it this year :( > >-derek It is time to move the conference because it is no longer safe for cryptography researchers to enter the USA. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
A pattern emerges...
Consider the DMCA (US law) as compared to the Terrorism Act of 2000 (UK law). Both make it effectively illegal for ordinary citizens to own, use, or distribute any software capable of performing decrypts by exploiting a weak cryptographic system. The US and UK, not coincidentally, are the two governments with the largest known investments in SIGINT -- the famous Echelon System. If people started using strong cryptographic systems, Echelon would be effectively useless. Therefore it is in the best interests of these two governments to make weak cryptographic systems the norm insofar as they are able. This is possible by providing an additional layer of legal protection to users of weak cryptographic systems -- with software capable of exploiting such weaknesses effectively illegal to own or use, the developers of such products have drastically reduced incentive to develop strong cryptographic systems to replace them. The DMCA and the Terrorism Act appear to provide exactly such laws. What has been passed recently by the other signatories to the UKUSA agreement that created Echelon? Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
pseudonymous decentralized marketplace
I've been attempting to design a decentralized auction/ exchange system that permits pseudonymous participants. By 'decentralized', I mean that NO central server, or subset of individual servers, controls access to any resource the system cannot work without; that there is no single point of failure. A consequence of this is that every ability that exists in any node, must exist in every node. So the whole problem of currency issue gets the slightly weird solution of "everybody has to be able to print their own money." The sticking point is that this basically means the system will be without any single universal "currency". A lot of E-cash techniques are usable, but what you wind up trading is certificates that represent goods or services offered by individuals in the system -- Alice the Farmer might issue certificates for bushels of wheat, while Bob the Carpenter might issue a bunch of certificates that say "collect a thousand of these and I'll redeem them for a new 10x10 meter deck on your house" and Carol the moneychanger might promise to redeem hers for one US dollar each, just for the amusement value of "redeeming" something in a system where hard currencies are the norm with a fiat currency. So these would be effectively a sort of digital merchants scrip, reducing back down to barter. Exchange rates between the currencies issued by different participants would fluctuate according to trust and commodity values, and I'm okay with that. Given the nature of the trust/reputation thing, I'd expect only a very small percentage of the participants to *actually* issue their own currency, as they wouldn't get good acceptance/exchange values until widely known, but everybody would have the ability. The problem I'm running into is that while all kinds of e-cash protocols exist that protect the anonymity of the buyer and a lot protect the anonymity of the seller, there are none that protect the anonymity of the currency issuer, which would be ideal in this circumstance. With the techniques I know of, the issuer can have only "Nym" protection. The basic problem with anonymizing the issuers (beyond technique alone) would be how the scrip gets redeemed when you don't necessarily know whom the issuer is. Can anybody recommend appropriate reading? Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: blocking chinese domains?
On Mon, 2 Jul 2001, Helger Lipmaa wrote: >to mirror interesting-to-them but sensible-in-content sites? My own >collection of cryptographic pointers, >http://.xxx.xx.xxx/x/crypto has been mirrored a while as >http://.xx.xx.cn//xcrypto/ When people are doing what they can do to evade censorship in a repressive state, it is best not to draw attention to them. Often their continued existence is largely a matter of how well they can maintain a low profile. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
