Commerce On The Web
Commerce On The WebThanks for the for leads. I just gave the lecture on internet commerce and used some of your leads. I spent several more hours on the web and downloaded the MasterCard? / Visa standards SET, also found an IBM Redbook on it on the web as well as a term report on it at the VirtualUniversity?. Found Wells Fargo, the proposed joint venture between 93B$ WalMart and Microsoft (does that scare you or excite you?) and a couple of neat scams that illustrate how easy it is to entice people to download rogue software onto their PCs and let it siphon money out of their pockets. One would dial Moldova, Ukraine and the web site owners would split the phone profits (you sure you're not interested in this, Ward..? dang we could make a mint before they hauled us off to jail). The other would simply tell your bank to send them money (even faster than the phone scam).
Also found that the DES was broken through a web-coordinated search involving 70,000 computers and 14 quadrillion keys tried (25% of the total key search space was used), and other interesting trivia on which I am now a very short-term expert.
Anyway, got the lecture and thanks for the help.
Personally, I think the key to Electronic Commerce on the Web is data exchange. There needs to be some magic way to avoid the bureaucracy and rigidity of Electronic Data Interchange, where every data item is supposed to be rigidly defined, and total chaos. Worse, EDI leaves many of the specific field values and the contractual requirements for filling out the fields to each pair of companies using it - every EDI partnership is custom-created. Standard terms and conditions would go a long way to solving this problem, although then you would be standardizing business relationships as well as data....
Fundamentally, EDI is a standard for data interchange. It's supposed to define all the possible transactions completely. It's also relatively transport-independent if you have a reliable transport system (*not* SMTP email). A CORBA system would improve the transport, but it would still leave the data undefined from a business sense. The XML/SGML model is to define an EDI-like transaction document that is both human and machine readable - this is supposed to make things more robust and durable, although I have my doubts.
There's the Open Buying Initiative (http://www.supplyworks.com/obi), there's the CommerceNet? (http://www.commerce.net) and their Electronic Commerce Framework, there's the XML and EDI hybrid group (http://www.xmledi.net), etc. At their core, data exchange is the common element.
On the academic side, you could look at Matthew Fuchs (http://cs.nyu.edu/phd_students/fuchs/), who has some excellent papers about expanding the definition of a document to support EDI-like transactions.
In my personal heaven, XML/SGML would be used to provide a clear, validated audit trail for all commerce transactions (the transaction syntax would be XML-compliant, so the form and content of each transaction could be validated against a document type definition), and the associated data elements (e.g. data, confirmation numbers, business cards, etc.) would follow Internet standards or other mutually agreed upon standards to allow for complete integration.
Scenario: Buy an airline ticket. Browser supplies credit card number (encrypted) to airline. Airline requests certain personal information for their records, and browser responds at the appropriate privacy level. Airline confirms with a ticket issued confirmation number and a calendar entry for the flight and associated itinerary. Browser saves confirmation number for Quicken 00 and stores calendar entry in Organizer 00.
Scenario 2: Same as above, plus a hotel reservation. Hotel needs to be changed. Browser supplies confirmation number to travel agency. Travel agency passes confirmation code to hotel, receives cancellation confirmation number. Cancellation confirmation number is sent to browser and stored with financial information. When credit card is received, statement is balanced against stored transaction confirmations.
Other examples that might be more germane to your lecture would include Amazon.com, which uses EDI to send book sale transactions to a really big book wholesaler, the Internet Shopping Network, which used to do the same (I don't know if they still use EDI between the order taking computer and the wholesaler), etc. Microsoft uses an Intranet system internally for most of its vendors, and Oracle sells a Web application that generates material requests for its purchasing application and database to send out to vendors, either by mail, fax, or EDI.
Sorry for the brain dump, KenMeltsner
Ken's overview is excellent. An idea from much further out on the fringe is the StoneSociety, which may not fall within Alistair's purview, but you never know ...
-- PeterMerel
the DES was broken
Some would say this is over-simplified. It would be more accurate to say "one particular DES key was broken in 22 hours".
Every encryption algorithm that uses 56 bit keys (or smaller) is just as vulnerable. Triple-DES with 3 independent keys is considered secure, at least for the moment.
...As the matter of fact, Tripple DES uses 2 DES keys (one of them twice), and thus Tripple DES offers mere 112 bit of security. Not too much in the 21st century...
easy-reading explanation:
more technical explanation: "Has DES been broken? No easy attack on DES has been discovered ... a DES cracking machine was used to recover a DES key in 22 hours ... no feasible way to break DES faster than exhaustive search ... has been discovered. The cost of a specialized computer to perform exhaustive search (requiring 3.5 hours on average) has been estimated by Wiener at one million dollars [Wie94]. This estimate was recently updated by Wiener [Wie98] to give an average time of 35 minutes for the same cost machine. ... DES is not secure, simply because 56 bit keys are vulnerable to exhaustive search. In fact, DES is no longer allowed for U.S. government use; triple-DES (see Question 3.2.6) is the encryption standard."http://www.rsasecurity.com/rsalabs/faq/3-2-2.html
Related
EditText of this page
(last edited November 5, 2014)
or FindPage with title or text search