December 2003 - cypherpunks-legacy

Re: How might new GAK be enforced?
by Rick Smith 17 Dec '03

17 Dec '03

Tim May asks: : Any other ideas on how the government plans to enforce GAK, to make GAK the : overwhelmingly-preferred solution? The problem seems somewhat analogous to the software copy protection problem and maybe the enfocement will be similar: make "examples" of a few high profile offenders who are exchanging blatantly un-GAKed traffic with foreigners. This assumes they fine tune the law to make such behavior illegal without having to prove you yourself exported the stuff to them. Wonder what the Supremes will say to that. But that's not the end of the story. If there is lots of GAK encrypted traffic flowing about, then encrypted traffic in general is no longer noteworthy. So as long as your traffic looks like GAK, you won't be hassled until they try to read your traffic. So it's possible that products will appear that use pseudo-GAK protocols -- they look just like their GAKed cousins but the GAK fields contain plausiable garbage instead of keys. It could even turn out to be a vendor "quality control" thing -- oops, the GAK was supposed to work but... You couldn't do that with Clipper (except via Matt Blaze's brute forcing of the LEAF checksum) because the crypto wouldn't decrypt a packet with an invalid LEAF checksum. Since it was a sealed hardware module, implementers had no choice but to play by those rules. There's no such enforcable limitation on commercial software implementations. Rick.

1 0

Re: Export laws don't just affect crypto
by jim bell 17 Dec '03

17 Dec '03

At 12:32 PM 10/1/96 -0400, Perry E. Metzger wrote: > >Lucky Green writes: >> > Umm, so are you violating ITAR if you *use* these GPS-guided missiles >> >> No you aren't. A little known provision in the ITAR excempts exports >> by missile. Seriously. > >Well, not quite -- it exempts exports by space launch, but I think >thats intended for things like satelite launchings and not for things >like missile attacks against other countries... If ITAR exempts exports by missile, does that mean that we merely have to make a model rocket, put a floppy containing PGP in the payload compartment, and shoot the thing over the wall into Mexico, or into Canada? Jim Bell jimbell(a)pacifier.com

1 0

[SPAM] Timmy May has no life
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

I suppose one of the reasons why Americans are so stupid is that so many of them are of English origin. How does one donate to the IRA anyway? >Comments: Authenticated sender is <paul(a)fatmans.demon.co.uk> >From: paul(a)fatmans.demon.co.uk >To: "Dr.Dimitri Vulis KOTM" <dlv(a)bwalk.dm.com> >Date: Mon, 30 Sep 1996 17:40:49 +0000 >Mime-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7BIT >Subject: Re: [SPAM] More "fuckhead" fan mail from Timmy "peteur" May >Priority: normal >X-Mailer: Pegasus Mail for Windows (v2.31) >Message-Id: <844193577.12916.0(a)fatmans.demon.co.uk> > > >> berserk >> Timmy May has gone . Has he been eating speed? >> bananas > >What? speak English motherfucker. > >> >> What has Timmy been smoking? > >I assume you are referring to me here, my name is Paul Bradley and >you can go fuck a kokonut dude. > >> >> ]From paul(a)fatmans.demon.co.uk Sun Sep 29 19:03:40 1996 >> >> ]Received: by bwalk.dm.com (1.65/waf) >> >> ] via UUCP; Sun, 29 Sep 96 19:14:06 EDT >> >> ] for dlv >> >> ]Received: from disperse.demon.co.uk by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; >> >> ] id AA25790 for dlv(a)bwalk.dm.com; Sun, 29 Sep 96 19:03:40 -0400 >> >> ]Received: from post.demon.co.uk ([(null)]) by relay-2.mail.demon.net id ac16129; >> >> ] 29 Sep 96 15:59 BST >> >> ]Received: from fatmans.demon.co.uk ([158.152.120.223]) by relay-3.mail.demon.net >> >> ] id aa09441; 29 Sep 96 15:54 BST >> >> ]Received: from fatmans.demon.co.uk by fatmans.demon.co.uk with SMTP >> >> ] id AA843903697 ; Sat, 28 Sep 96 09:41:37 +0000 >> >> ]Comments: Authenticated sender is <paul(a)fatmans.demon.co.uk> >> >> ]From: paul(a)fatmans.demon.co.uk > >As you can see my sending is authenticated and the reply path is to >my host (fatmans.demon.co.uk) the message has passed through >post.demon.co.uk/disperse.demon.co.uk and on to psi.net, Tim May is >at got.net. > >> >> ]I am not Tim May, Check out the return path if you don`t believe me, >> >> ]if you still don`t here`s my PGP public key signed by the EFF, they >> >> ]don`t sign keys here and there without checking ID`s... > >>Fuckhead. > >Fraid not dude, this thread is getting distinctly boring, cut the >shit, if you have something to say say it, don`t keep spewing shit >without warning, but really it`s only to be expected from you. > > > > Datacomms Technologies web authoring and data security > Paul Bradley, Paul(a)fatmans.demon.co.uk > Paul(a)crypto.uk.eu.org, Paul(a)cryptography.uk.eu.org > Http://www.cryptography.home.ml.org/ > Email for PGP public key, ID: 5BBFAEB1 > "Don`t forget to mount a scratch monkey"

1 0

Press Release
by Peter D. Junger 17 Dec '03

17 Dec '03

Press Release Plaintiff Seeks Summary Judgment in Cleveland Case Challenging Licensing of ``Exports'' of Cryptographic Information Government Argues That Law Professor Cannot Challenge Regulation Requiring Him to Get Permission Before Teaching and Publishing Because He Did Not Apply for That Permission Oral Argument in Junger v. Christopher Set for Wednesday, November 20 Cleveland, Ohio, Tuesday, October 1, 1996 For Immediate Release For More Information Contact: Raymond Vasvari (216) 522-1925 Gino Scarselli (216) 291-8601 Or see URL: http://samsara.law.cwru.edu/comp_law/jvc/ Cleveland, Ohio, Oct. 1 -- Lawyers for Professor Peter D. Junger today filed a brief and a motion for summary judgment in Junger v. Christopher, the case challenging the licensing of the communication of ``cryptograhic software'' that is pending before Judge Donald C. Nugent in the Federal District Court here. Junger seeks an injunction against the enforcement of provisions of the International Traffic in Arms Regulations that require him to get the permission of the State Department's Office of Defense Trade Controls (the "ODTC") before he can communicate information about cryptographic software to foreign persons, ``whether in the United States or abroad.'' The penalty for failing to get such permission before disclosing the information can be as great as a fine of one million dollars and imprisonment for ten years. These provisions effectively prevent Junger from admitting foreign students to the course that he teaches about Computers and the Law at Case Western Reserve Law School in Cleveland, Ohio, and keep him from publishing his course materials and articles containing cryptographic software, or explaining what it does, how and where to get it, and how to use it. The challenged licensing scheme threatens the long-run viability of the United States software industry and, according to a blue-ribbon panel of the National Research Council, already costs that industry at least ``a few hundred million dollars per year ..., and all indications are that this figure will only grow in the future.'' The regulations have been extensively criticized by industry and bills to repeal or limit them are now pending in Congress. Junger's legal challenge is not based, however, on the economic damage that the ITAR's cryptographic licensing scheme imposes on the software industry and the nation's economy, but rather on the unconstitutional restraints that it imposes on anyone who wants to speak or write publically about any computer program that has, in the words of the ITAR, the ``capability of maintaining secrecy or confidentiality of information or information systems.'' Junger does not challenge the constitutionality of requiring one to get a license before exporting a physical cryptographic device: ``It isn't unconstitutional for the Office of Defense Trade Controls to damage the computer industry and our economy by requiring export licenses for cryptographic hardware, but information about cryptographic software is, as the National Research Council has pointed out, `pure knowledge that can be transported over national borders inside the heads of people or via letter.' Requiring the permission of the government before one can communicate knowledge is unconstitutional. Such a prior restraint is, in fact, the paradigmatic example of a violation of the First Amendment.'' THE GOVERNMENT ARGUES THAT PLAINTIFF MUST APPLY FOR PERMISSION TO SPEAK BEFORE HE CAN CHALLENGE THE REQUIREMENT THAT HE APPLY FOR SUCH PERMISSION In motions and briefs submitted August 21st, the government has asked the court to dismiss the lawsuit, or in the alternative, to grant the government judgment prior to trial. The government makes the initial argument that Junger lacks standing to claim that the provisions of the ITAR requiring him to get a formal license or other permission from the ODTC before he publically communicates information about cryptographic software, including the contents of the software itself, are unconstitutional. And it also argues that that claim is neither ``ripe'' nor ``colorable'', because Junger has not applied to the ODTC for such permission. Junger takes the position that as a law teacher who venerates the First Amendment it would be as improper for him to request the federal censors for permission to speak and publish as it would be for him openly violate the law. As he puts it: ``My duty is to challenge these unconstitutional regulations, not to give in to them nor to violate them in an act of civil disobedience.'' His lawyers point out in their briefs that few propositions of constitutional law are better established than the rule that a plaintiff does not have to submit to an unconstitutional restraint on speech and on the press before challenging it in court. ``Those arguments by the government are rather strange,'' says Gino J. Scarselli, one of Junger's lawyers, ``they seem to be based on their argument that cryptographic software is actually hardware because it is functional.'' And then he adds, ``Of course, that argument is also rather strange.'' THE GOVERNMENT ARGUES THAT SOME OF THE MATERIAL AT ISSUE IS EXEMPT UNDER THE ITAR The government also contends that some of the information at issue may be exempt from the ITAR's licensing requirements as technical data that is in the ``public domain'' because it is available to the public through ``fundamental research in science and engineering'' or through ``sales at newsstands and bookstores.'' ``That hardly is a defense,'' says Scarselli, ``since it is quite clear that the government will not concede that all of the information that Professor Junger wants to be able publish and discuss is in the public domain. And to make matters worse, the only way that Professor Junger can actually find out whether the government will treat particular information as being exempt from the formal licensing requirements is to apply to the ODTC for it calls a Commodity Jurisdiction Determination, which in reality is just another form of license.'' ``It is not as if I am engaged in fundamental research in science and engineering.'' Junger adds. ``What I want to publish and discuss has to do with the political and legal issues that are raised by computer technology, including, of course, cryptography. ``For just one example, since lawyers have a legal and ethical duty to protect the confidences of their clients, I am convinced that lawyers who use electronic mail or other computer technologies to communicate with their clients, or to store information supplied by their clients, are in some circumstances ethically, and perhaps even legally, required to use cryptography to maintain the confidentiality of that information. And yet I cannot publically explain to law students and lawyers--and lawyers cannot publically explain to their clients--how to obtain and use effective cryptographic software without first getting the government's permission to disclose that information. And, of course, if the cryptographic software really is effective, then there is little or no chance that the government will permit its disclosure.'' THE GOVERNMENT ARGUES THAT CRYPTOGRAPHIC SOFTWARE IS NOT PROTECTED BY THE FIRST AMENDMENT BECAUSE IT IS FUNCTIONAL There is no law in the United States that forbids or regulates the use of cryptography. Yet the government argues that the information in texts containing cryptographic software, including recipes for creating such software, can be used in a computer to preserve secrecy and confidentiality, and concludes that cryptographic software is ``conduct'' and ``functional'' and is thus not a text that is constitutionally protected as speech. Junger's lawyers, on the other hand, say that his claims do not relate to the conduct of running a cryptographic program on a computer--conduct that is not regulated by the ITAR, after all--and that he only challenges the restraints that the ITAR impose on the communication of information about how to carry on such legal conduct. ``Expressive conduct is exactly what is protected by the First Amendment,'' says Raymond Vasvari, another of Junger's lawyers. ``And if that expression were not functional, if it were not effective, there would be no need to protect it. The government's argument turns two hundred years of First Amendment jurisprudence on its head.'' ``The government's arguments about software being conduct and functional are striking examples of the sort of confusion that pervades the whole area of Computers and the Law,'' Junger says. ``Trying to clear up such confusion is my major goal in my course in Computers and the Law. In fact, when I started teaching that course in 1993, I wrote some cryptographic software to assist my students in grasping the distinction between software as a text that can be communicated, and that is protected by copyright law and the First Amendment, and software as a process that runs in a computer's central processor that can be protected by patents, but not by copyrights. If it weren't so frustrating, it would almost be funny that I cannot publish that software because of the prior restraints imposed by the defendants' interpretation of the ITAR, even though it is perfectly legal for me, or for any one else, including `foreign persons,' to actually run such software on a computer. The government's confusion is so extensive that an agent of the ODTC has actually told me that software, cryptographic software, is actually hardware.'' ``It is quite clear to me,'' Junger adds, ``that the State Department and the National Security Agency and other elements in the executive branch of the government are attempting to restrain the communication of information about cryptographic software not only abroad, but also within the United States, because they do not want us actually to be able to use cryptography to preserve the privacy of our thoughts and our communications. It is as if the government required one to get a license before explaining how to make or use an envelope, even though it did not forbid the use of envelopes themselves. After all, all that cryptographic software is is a way of making electronic envelopes.'' ORAL ARGUMENT SCHEDULED Junger v. Christopher has been placed on a fast track by Judge Nugent. On September 5 he established a briefing schedule: the plaintiff's brief was due and was filed today and the government's response is due on Friday, October 18. Oral argument is scheduled for Wednesday, November 20. Judge Nugent's decision is expected before the first of the year. BACKGROUND ON THE LITIGATION Litigation is expensive. Professor Junger and his volunteer lawyers were only able to bring the suit because of a generous gift by an anonymous donor of $5,000 that was used to create the ITAR Legal Attack Fund. Additional donations by Professor Junger and others have increased that fund to more than seven thousand dollars. Scarselli and Vasvari are lawyers in private practice in Cleveland who have dedicated much of their professional lives to the protection of First Amendment freedoms. The third lawyer on the team is Kevin O'Neill, a law professor at Cleveland State University and the former legal director of the Ohio Chapter of the American Civil Liberties Union. --30-- -- Peter D. Junger--Case Western Reserve University Law School--Cleveland, OH Internet: junger(a)pdj2-ra.f-remote.cwru.edu junger(a)samsara.law.cwru.edu URL: http://samsara.law.cwru.edu

1 0

SYN_not
by jya＠pipeline.com 17 Dec '03

17 Dec '03

10-1-96: "Check Point to Provide Safeguard Against TCP SYN Flooding." The new module, now available free of charge on Check Point's Web site (http://www.checkpoint.com) provides protection against this denial of service attack, which has crippled several ISPs in recent weeks. "Certicom Introduces Elliptic Curve Cryptosystem Instruction To Its Security Classroom." It has launched new information about its Elliptic Curve Cryptosystem on the Information Security Classroom section of its web site (www.certicom.ca) "IBM to herd cave-in cats for rat encryption." IBM will be joined by Digital, TIS but few others. An executive at TIS declined to comment on whether it is involved in the IBM cave-in. The company is in a quiet period before making an IPO based on government bribery. "Battle brewing over gov.crypto bribery." Last week, the DARPA announced it has awarded Trusted Information Systems, Inc. a two-year, $1.5 million contract to develop what it calls security wrappers for a Java Prototype System as well as one for the Unix operating system. ----- http://jya.com/synnot.txt (15 kb for 4) ftp://jya.com/pub/incoming/synnot.txt SYN_not

1 0

Re: Clipper III on the table
by Bill Stewart 17 Dec '03

17 Dec '03

At 02:44 PM 10/1/96 -0400, Perry wrote: >We really have to work on cracking DES at least once -- it would >substantially reduce the wind in the Administration's sails. 56 bits + GAK does generally mean DES/GAK, though RC4/56/GAK is also possible. One "56-bit" protocol that might be allowable under the new rules is "something strong with all but 56 key bits revealed", e.g. RC4/128 with 72 bits salt revealed (like the RC4/128 with 88 bits salt revealed that Netscape uses, or 3-DES with 112 bits salt revealed), which would be substantially stronger against cracking than raw 56-bit DES. A big advantage is that it makes pre-computation of lists less useful, since two cyphertexts with the same 56-bit key might be different in the top N-56 bits of key, and the key schedules are less reusable. The 3DES version, for instance, also gains because some of the big DES hooks that let you scrounge a few bits don't work. # Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts(a)ix.netcom.com America's Open Presidential Debate - Beyond Dole and Clinton! <A href="http://gate.net/~bdcollar/bbe/media.htm">Tuesday, Oct. 8th 8:00 PM EDT</a>

1 0

ITAR satellite provision
by azur＠netcom.com 17 Dec '03

17 Dec '03

Does anyone on the list have the exact ITAR reg. text relating to the exemption for space-launched crypto? -- Steve

1 0

[NEWS] Crypto-relevant wire clippings
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

American Banker: Monday, September 30, 1996 Microsoft Ups the PC Banking Ante with Money 97 By JENNIFER KINGSON BLOOM Launching a long-awaited assault on Intuit Inc. and its popular Quicken system, Microsoft Corp. today releases a new version of its Money personal financial management software, with new ways for banks to connect to it. Microsoft executives say Money 97 is easier to use than its predecessor and more widely available to banks. Banks can offer Money 97 services in various ways: through processors like Checkfree Corp., Intuit Services Corp., and Visa Interactive; or directly through Microsoft's "open financial connectivity" standard for on-line commerce. Microsoft also announced that 37 banks are offering Money 97 -- roughly the same number that today offer Quicken services -- and that at least 23 more will offer Money 97 by yearend. "We're here today with a lot of what Quicken is announcing they'll have a year from now," said Richard Bray, Money 97 product unit manager at Microsoft. "What this really means is more banks will be available through Money sooner than through Quicken." But Intuit officials said they did not feel threatened. "What they mostly did was add a few features we already had," said Matthew Glickman, Quicken group product manager. Bankers planning to offer Money 97 said Microsoft's open technology standard was a major benefit. "We will be able to provide our customers with the same service that they're used to, which is on-line, real-time balances," said Michael Papantoniou, a vice president in electronic commerce at Chase Manhattan Bank. "Microsoft Money and Quicken now have to go through Intuit Services Corp. - that's the big difference," he said. "ISC only has start-of-day balances." Bankers also praised Money 97 for giving prominence to bank brand names. Customers will see their banks' logo, Internet address, and whatever other information the bank chooses to provide. Henry Mounger, senior vice president of consumer product development at Deposit Guaranty National Bank in Jackson, Miss., said his own "road test" of Money 97 convinced him the bank should offer it. Deposit Guaranty had not previously offered Money or Quicken. "The overriding impression I had was its ease of use," Mr. Mounger said of Money 97. "I had never used Quicken or any other personal financial management software before, and I was banging out reports right and left." Mr. Mounger said the ability to offer Money 97 through Visa Interactive was also an attractive feature. "We're trying to maximize that vendor relationship," he said. "We obviously recognize the fact that Quicken is a very visible product in the marketplace, but we're not prepared at this point to go through all those operational issues to get up and connect." This month, Intuit announced the sale of its processing division to Checkfree. It also announced an alternative to Microsoft's technology specification that it dubbed OpenExchange. Mr. Bray of Microsoft said Intuit's standard is a late entry in the race. "They didn't announce anything new with OpenExchange -- what they were trying to do was slow down the market because they're a year behind," Mr. Bray said. "There's no reason for banks to wait another year, and the big banks aren't waiting," he said. "Why should they wait for an undocumented, unpublished format when there's one available today that they can work with?" Mr. Glickman at Intuit said his company's open standard does the same things as Microsoft's, "but in a much better way," offering a choice of processors plus "a broader range of connectivity." Mr. Papantoniou at Chase said he also viewed OpenExchange as a broader standard, but hoped the two specifications would converge. "That would benefit all banks," he said. Chase, like many of the larger banks, offers both Quicken and Money options for home banking. Some bankers who offer both products said they were pleased with the improvements to Money but are not taking sides in the Microsoft-Intuit rivalry. "The more they talk about each other, the more focus there will be on personal financial software, and the better for me," said S. Michael Woodward, a vice president in strategic marketing at Crestar Bank in Richmond, Va. "We don't come out and promote Quicken over Money or BankNow" -- Intuit's transaction-oriented offering with America Online. "I think both of them have done a very good job." Despite some bankers' neutrality, Money 97 is guaranteed to step up the competition for customer loyalty. "This is going to be a really interesting season for the personal finance software market," predicted Phoebe Simpson, an electronic commerce analyst at Jupiter Communications in New York. "The fact that you can download the Quicken data into Money 97 is going to be very interesting, and will ease the entrance of anyone who is looking to switch." Mr. Bray said Microsoft wanted to make switching from Quicken to Money "as easy as possible." Quicken users are being offered a $10 discount on the $34.95 retail price of Money 97, as well as the ability to instantly transfer all their existing Quicken files into Money 97. Microsoft also plans to offer all comers free 90-day trials of Money 97. Another new feature of Money 97, critical to banks and consumers, is Internet connectivity. Users will be able to connect not only to their banks but to a Web site Microsoft maintains that offers current stock quotations. Mr. Glickman of Intuit said Microsoft's previous efforts to make Money widely available had failed to dent Quicken's market share, and he predicted the same would hold for Money 97. "We've added over a million customers in the last year," Mr. Glickman said. Citing numbers compiled by PC Data of Reston, Va., Mr. Glickman said Quicken has 73% of personal financial software users, Money 23%; 4% use other types. "Microsoft has increased its market share, but it has come at the expense of the smaller players like (Meca Software's) Managing Your Money," Mr. Glickman said. Ms. Simpson of Jupiter Communications said the release of Money 97 reflected Microsoft's belief that high-function software could double as a mass market product. "Intuit sees the market splitting into transactors and trackers, and Microsoft does not buy into that, so they have worked with their product to get sort of a blend of the two," she said. "I think it's going to be a tight race." American Banker: Monday, September 30, 1996 Verifone Woos Banks with Personal ATM By JEFFREY KUTLER Verifone Inc. is claiming a breakthrough toward one of electronic banking's holy grails: an automated teller machine in the home -- or, for that matter, in the pocket. The Redwood City, Calif., company is introducing Personal ATM, a palm-size device with a smart card slot. Among other interactive capabilities, it allows value to be loaded onto the card via telephone. Accompanying Personal ATM, to be unveiled today at the American Bankers Association's bank card conference in Orlando, is Verismart, a system Verifone says will make smart cards more appealing to the banking, retailing, telecommunications, transportation, and utility industries. While Verifone is not the first to see the remote banking potential of plastic cards with built-in computer chips - for example, the Dutch company Philips makes screen telephones with smart card readers - Personal ATM may be more ready for the mass market. As purely a card reader -- lacking processing power, computer intelligence, or memory, but connectable through a phone jack -- Personal ATM is so cheap that banks ought to consider almost giving it away, said C. Lloyd Mahaffey, Verifone's vice president of global marketing. He would not discuss prices but said they are a stark contrast to the $100 or $200 that screen phone manufacturers are hoping will attract widespread acceptance, or the bare-bones $500 network computers that Oracle Corp. and others contend are the key to mainstream Internet use. "The consumer might pay $2 or $3 a month, not the $90 or $100 it takes to buy some devices that we see at technology trade shows," Mr. Mahaffey said in an interview last week. He predicted "volume deployments" of Personal ATM by mid-1997. He said the battery-powered device might be mailed out in a sturdy, compact box -- under the brand name of a bank or other provider -- along with two smart cards. The economics are such that if a defective machine arrives, and the customer calls to complain, the service representative will say, "Throw it away. We'll send a new one," said Mr. Mahaffey, architect of the Verifone consumer strategy typified by Personal ATM. In current parlance, Personal ATM is the ultimate "thin client." That means it is "intellectually challenged," Mr. Mahaffey said, relying on the smart card and on-line connections for what it needs to know. But Mr. Mahaffey said that is the key to the cost advantage through which Verifone hopes to dominate consumer automation as much as it does the point of sale terminal market, where its share is near 70%. The Verismart system is designed to embed the smart card capability in devices other than Personal ATM -- computer keyboards, telephones, television set-top boxes. Verifone has already forged alliances with manufacturers in such fields, including Keytronic, GTE, and Scientific Atlanta, as well as Mondex International and smart card maker Gemplus. At least 10 companies have signed to support Verismart, including American Express, MasterCard, Visa, and Wells Fargo Bank. Verifone says it is addressing some bankers' reluctance to commit to Mondex, Visa Cash, or a competing scheme: Verismart is "device independent," meaning a bank is not forever locked in to any smart card decision. News Release (VeriFone): Monday, September 30, 1996 VeriFone to Develop Smart Card Applications and Services VeriFone, Inc. (NYSE:VFI), the leading global provider of secure payment solutions, today announced plans to develop the VeriSmart System -- the first end-to-end system for creating smart card applications and services. VeriSmart pilot programs are planned with leading companies throughout the world, including American Express, GTE, MasterCard, Mondex International, Ltd., NIPSCO Industries, Inc., Sparbanken Bank (BABS), Sears Payment Systems (SPS), and Wells Fargo. The VeriSmart System will provide the applications, integration services and marketing support required to enable these companies to offer expanded smart card products and other services to their customers. The VeriSmart System was announced concurrently today at the ABA Bank Card Conference with a separate announcement from VeriFone and other leading companies for plans to develop personal devices and information appliances that will bring low-cost smart card capability directly to consumers. VeriSmart, a flexible, open, smart card system, is the first solution that will enable multiple consumer appliances, such as a personal/home ATM device, smart phone, personal computer or set-top-box, to access a variety of smart card applications, and seamlessly integrate with back end payment and transaction systems worldwide. VeriSmart, which will reside on various companies' host systems, is being designed to allow a customer to access and interact with their accounts to retrieve electronic cash, monitor services, pay bills, receive healthcare information, get updates on frequent flyer awards and other personal services. "VeriFone's Consumer Systems Division is developing the first realistic solution that is expected to stimulate the emerging smart card market, bringing consumers and providers together through robust, interactive products and services for everyday banking, health insurance, and utility transactions," said C. Lloyd Mahaffey, vice president of global marketing for VeriFone. "The wide range of industries that are looking to implement VeriSmart products and services indicates the enormous potential for smart card services we can expect in the future." The flexible design of the VeriSmart server and applications software, installed on the provider's host computer, will readily support additional applications and upgrades as they are developed. VeriSmart applications can allow these providers to offer new and unique products to broaden their customer base through value added smart card services. "The real value of smart card technology will not be realized until consumers have a compelling reason to change the way they conduct business today," said Thomas Kilcoyne, general manager, VeriFone's Consumer Systems Division. "The security, convenience and access to personal information they'll have through their telephone, home ATM, PC or television can dramatically enhance their relationships with providers who offer these services." Eight Major Companies Prepare Solutions VeriFone's Consumer Systems Division will begin working with leading providers to develop and deploy enhanced consumer smart card-based products and services. "We are enthusiastic about exploring business solutions that incorporate the VeriSmart System," said David L. Boyles, senior vice president of New Business Ventures for American Express' Stored Value Group. "These types of products have tremendous applicability to some of the products we will be launching in the future. VeriSmart's open system architecture is exactly the kind of technology that American Express is committed to applying to its global infrastructure, so that we may ensure maximum customer satisfaction and worldwide usability." Sparbanken Bank (BABS), is Sweden's largest savings bank. "The VeriSmart System will allow us to offer our customers a wide range of stored value card applications. We look forward to working with VeriFone on this exciting new program," said Jan Olof Brunila, vice president, Development, for Sparbanken. "GTE is the largest publicly held telecommunications company in the world with revenues of 20 billion dollars in 1995. It is also the largest U.S. based local telephone company with wire line and wireless operations covering about one third of these countries population. "GTE is interested in further exploring this exciting new technology," said Jim Palma, senior manager, New Product Markets. "MasterCard is eager to test this product and offer an early pilot to our members when it is ready," said Steve Mott, senior vice president, Electronic Commerce/New Ventures for MasterCard International. "We believe VeriSmart targets important emerging needs in the electronic commerce market." Mondex International Ltd., the leading chip-card based electronic cash payment system being introduced by institutions around the world, offers consumers a secure and convenient alternative to cash. "This announcement marks another important step forward for Mondex as a global electronic cash system. We are working with VeriFone and others to deliver e-commerce applications that will bring real benefits of convenience and security to consumers worldwide", said Mike Young, head of New Product Development, Mondex International Ltd. "We look forward to VeriSmart providing yet another secure path for offering Mondex transactions over the Internet." NIPSCO Industries, Inc., an energy-based holding company located in northern Indiana, intends to initially offer the VeriSmart system to the broad base of customers of its electric and natural gas utilities. "Through our strong customer relationships, we can help the VeriFone alliance build a two-way gateway to the home," said Barbara D. Haas, group vice president of Marketing and Communications. "We plan to concentrate our efforts on developing ways to use this two-way technology to read meters, automatically report electrical outages and supply energy usage information to the customer." SPS Payment Systems, Inc., is a provider of technology-based outsourcing services. Principal businesses include: point of sale credit card transaction processing; administration of consumer private label credit card programs; and customized operating services such as help desk support and customer service. "SPS Payment Systems has worked with VeriFone and utilized their hardware to meet the retail point-of-sale needs of many of the clients for whom we process credit and debit transactions. Their new VeriSmart System will represent an opportunity for us to provide electronic payment processing through a variety of consumer appliances such as personal/home ATM devices, smart phones or PCs," said Patrick A. Albright, director of Industry Marketing, for SPS Payment Systems. Wells Fargo, a leading force behind the development of Mondex in the United States, supports VeriFone's new technology. "The VeriSmart System is ground-breaking technology that will significantly reduce the cost and complexity of offering multiple applications to our Mondex customers," said Janet Hartung-Crane, senior vice president of Wells Fargo's Electronic Payments Division. Wells Fargo & Co., the 9th largest bank holding company in the United States, has assets of $108.6 billion following completion of its merger with First Interstate. News Release (CyberCash): Monday, September 30, 1996 CyberCash Launches CyberCoin Service Individuals can finally make small purchases on the Internet securely and instantaneously with CyberCash's revolutionary new electronic coin service. CyberCash, Inc. (Nasdaq: CYCH), today announced CyberCoin(TM), an innovative payment service that enables cash transactions, typically from $0.25 to $10.00, and can be used with funds drawn from a consumer's existing bank account. "CyberCoin fulfills a growing need for consumers to purchase lower-priced and 'impulse' items on the Internet -- especially digital goods and services that can be instantaneously downloaded to your computer, such as software, articles, research, games and music," said Bill Melton, CEO of CyberCash. "Internet merchants must offer consumers the ability to make spontaneous, small denomination payments on the Internet to take electronic commerce to the next level." CyberCoin Provides Merchants with New Opportunities "Shopping on the Internet for low-priced items will be as easy as pulling a coin out of your pocket at the store, newsstand, or video arcade," said Ray Speichert, CEO of Headgames, a Web merchant who will offer the online game Worbble, using the CyberCoin service. "With CyberCoin, players from around the world can compete against other players on the Internet on a pay-per-play basis." Until now, merchants have been unable to effectively sell low-priced, value-added products and services over the Web. CyberCoin removes this barrier, and opens up a new world of digital commerce opportunities. A broad range of soft goods and services can now be sold and delivered electronically, allowing merchants to drive incremental sales of items such as newsletters, graphic art, real-time stock quotes and virtual games. "As the premier provider of high quality financial information, Quote.COM's mission is to fulfill the sophisticated needs of serious investors," said Quote.COM President Chris Cooper. "CyberCoin will add a powerful pay-per view option for on demand purchase of financial information, giving our subscribers even greater flexibility to manage their portfolios." CyberCoin Opens Up the Internet for the Consumer Free, easy-to-use and secure, CyberCoin provides consumers with a revolutionary new way to shop online. CyberCoin can be used with any existing bank account or major credit card -- all that is needed is an Internet Wallet, which is free to consumers and can be downloaded from the CyberCash Web site at (http://www.cybercash.com) "There is undoubtedly a niche for coin payment on the Internet and CyberCash is ahead of the pack in developing a user-friendly option for small cash purchases online," said Parker Foley, Vice President and Director of Electronic Commerce, First Union National Bank. "We are pleased to be among the first to pilot this new service in 1996 and hope to offer its convenience to our Internet customers by early next year." Easy to download and install, the Internet Wallet is a password protected software program that enables encrypted transactions to move between the consumer, the merchant, and their banks. Just like an everyday wallet, the Internet Wallet offers several types of payment options and can be used with any major credit card in addition to the new CyberCoin payment service. Online Shopping Made Easy With CyberCoin CyberCoin provides the consumer with the ease and simplicity that has been missing from the Internet shopping experience. When an individual on the Web finds an item that he or she would like to purchase, the consumer simply clicks on the Coin icon next to the goods. It's that simple. The entire process takes only seconds. A complete transaction log of all purchases is kept in the Wallet. The consumer can easily, and at no cost, move money in and out of the Wallet to use the CyberCoin service. The user chooses the amount of money he or she wishes to move (in multiples of $20, up to $80), and selects whether to use funds from a bank account or credit card. Security is ensured since the money never leaves the bank-if the consumer's PC crashes, no funds are lost. Funds in the CyberCash system are FDIC-insured, giving an added measure of security. CyberCash Partners with Banks to Deliver CyberCoin Service CyberCash will work with banks to integrate the CyberCoin technology and services into the banks' Internet offerings for both their merchants and consumers. Participating banks will offer the CyberCoin service to online merchants and provide them with critical back-end processing capabilities and access to existing financial networks. Merchants will pay the banks a per-transaction fee, similar to a credit card transaction, to use the CyberCoin service. CyberCash receives a fee for each transaction from the banks. Pricing and Availability CyberCash's CyberCoin service is available now for banks, merchants and consumers. First Union, First USA Paymentech, First Data Corporation and its affiliated banks, and Michigan National Bank have already committed to offer or pilot the CyberCoin service to merchants and/or to consumers before the end of the year. Merchant server software is available immediately from CyberCash on the Windows NT, Solaris and BSDI platforms, with other platform versions available by the year-end. Consumer Internet Wallets can be downloaded for free from the CyberCash Web site at www.cybercash.com. --- Dr.Dimitri Vulis KOTM Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

1 0

[CRYPTO] Cryptography of a sort [FAQ]
by Dale Thorn 17 Dec '03

17 Dec '03

Attached is FAQ, source code, and documentation for a program I've arbitrarily called "Cryptography Of A Sort" (COAS). If anyone is using that acronym for something which could conflict, I guess I'd have to change it.... The FAQ is self-explanatory. The source code contains an unoptimized routine or two; the line comments should take care of that. Following the source code is the user documentation. FAQ: 132 lines Source: 349 lines User doc: 60 lines I've been programming since Feb. 2, 1975, when I bought my first HP-65. 21.66 years and 30 or so personal computers later, I have an HP-48GX, a Win95 laptop, and an HP-200LX with an 85 mb flash card STAC'd 170 mb. I've done several national articles, the last in Dr. Dobb's, June 1991. I prefer languages which offer medium-to-high-level calls along with direct OS/BIOS/etc. access, although the HP-48 RPL is kinda fun.... FAQ for Cryptography Of A Sort (COAS) Author : Dale Thorn <dthorn(a)gte.net> Revised : 29 Sep 1996 [Source code and documentation follow this FAQ] Q: Is COAS an actual product? A: COAS is an encryption engine supplied in source-code format, which calls some commonly-available (and replaceable) functions included with commercial computer-language libraries, which in turn perform some of the rudimentary tasks required by the program. Public Key features are not currently supported in COAS, therefore, messaging applications are not as well supported as is local file encryption. Q: What are the main differences between COAS and other non-messaging-oriented crypto products? A: 1. COAS repositions bits based on multiple encoding passes using one or more Pseudo-Random Number Generators (PRNG's). Since COAS is provided only in source code format, and since the source code calls the PRNG function in the compiler library(s), COAS is actually independent of specific PRNG's. NOTE: PRNG limitations, as described in the popular literature, do not necessarily apply when repositioning bits in multiple passes, as opposed to modifying bits as is normally done in other software. Think of "brute force encryption" (more on this below). 2. COAS does not use a "key" as such, and thus does not "encrypt" the bits in a text bitstream. Instead, it uses an input value (text or numeric) as an entry point into a common PRN sequence. Since the entry point is a secret, and since bits are moved using random block sizes, from their original bytes into unrelated destination bytes, cryptanalytic attempts must necessarily begin with brute-force guessing as to the entry points in the PRN sequences, in order to associate the correct bits with their original bytes of text. Multiple encoding passes raise the number of guesses exponentially. 3. COAS source code is extremely small, the primary intent for which was to provide a sample encoding engine for local/personal computer files. Due to its small size and simplicity, the source code can be easily modified by casual users, who may add in their own custom routines. NOTE: It cannot be overemphasized, that crypto programs which have a widely-respected reputation must also be held suspect when A) The very nature of those programs is to deceive, -and- B) The source code is either not available, or is so complex as to discourage ordinary people from working with it. Q: But if COAS uses a common, ordinary PRNG, how can it possibly be secure? A: I can think of two arguments against using PRNG's: 1. Encoded text is easy to decode by brute force on most computers, -and- 2. Encoded text can be seen as having regular patterns when "viewed" from the vantage point of programs employing higher-dimensional mathematics. Addressing the former, a single-pass encryption of a text file using the typical PRNG might be breakable in as little as .000001 second on one of the larger, faster computers available, however, the same approach might require as many as 10^24 years if the number of encoding passes reaches ten or more. To simplify: try to guess the number I'm thinking between zero and 32,000. You can make 16 billion guesses per second, so it will take only .000001 second (on average) to get the correct answer. If you had to guess ten numbers correctly (and sequentially), it would require roughly (16,000^10) / 16,000,000,000 seconds, approximately 10^24 years. Addressing the latter, the ability to "view" the text as a lattice in a higher dimension is likewise diminished by the discontinuities inherent in multi-pass encoding, when bit-group sizes are determined dynamically by PRN's following the secret entry points into the PRNG sequences. Q: What about the possibility that two or more encryption passes could be decrypted in a single pass, as in the scenario where a third key K3 is functionally equivalent to two separate encrypting keys K1 and K2? A: Since COAS encoding is controlled through entry points into a PRNG's number sequences (adjacent encryptions may also use different PRNG's and/or bit-move logic), searching for a "key" or algorithm which can unpack two or more layers of coding will prove futile when all entry points into the PRNG's are different, and different PRNG's are used. A couple of points to consider: One, the output of the PRNG (or any number series) does not describe the bit move-to locations; those are determined by sorting the PRN's then moving the bits according to the sequence of the original array positions of the PRN's prior to sorting. Since some of the PRN's are duplicates, the original array positions relative to each other will be determined by chance, i.e., the vagaries of the sort process, etc. Two, since the bits are moved rather than modified, and since groups of bits vary in size, an attempt to find particular bits that belong to specific bytes after multi-move shuffling, using any compound key or algorithm in a single decoding pass, will certainly prove futile. Q: Since the personal computer implementation of COAS uses 16-bit integers to initialize (set entry points into) the PRNG's, would ten encryption passes be somehow equivalent to the use of a 160-bit key in conventional programs? A: If the conventional program used a 160-bit key in a manner similar to COAS, it would still have to: 1) move bits, not change them. 2) use an indirect method for specifying move locations. 3) model the processes used in COAS quite closely, since there's no straightforward mathematical approach that can duplicate the conditions described in the previous question and answer. Q: What's the difference between the techniques used by COAS and the use of a One-Time Pad (OTP)? A: The theory behind the OTP assumes that (unlike the use of a Public/Private key) subsequent encryptions using the same OTP key would reveal the nature of the OTP, i.e., any newly-encoded files and messages would share certain common identifiable characteristics which could be exploited to facilitate the decryption of all files using that pad. COAS, on the other hand, doesn't alter any of a file's bits, and therefore does not "add" its PRNG entry points' characteristics to a file other than shuffling bits in accordance with the original physical positions of PRN's which have been sorted by size. Q: Is it possible for anyone to alter the contents of files encrypted by COAS so that a person performing the eventual decryption would not realize that the file(s) were indeed altered? A: Less likely than incidental or brute-force decryption. Each bit is moved once in each encryption pass, and if any bits were moved or changed, that many bytes (or nearly as many, since bits are not moved in byte-divisible groups, so most will end up in unrelated bytes after encryption) would be affected, and the resulting bytes would not likely pass even the simplest checksum test. Q: Is COAS a "weak" product (cryptographically speaking), either because of limitations in its own internal algorithms, or in the commercial library functions it calls? A: COAS can be used in ways that produce weak encryption, which is really an advantage in encouraging beginners to get started, given its simple user interface. Whether it can produce "strong" encryption or not is a matter of opinion, where said opinion is not so much a function of the product's alleged weaknesses, as it is the fact that cryptography grew up from a long history of hand-ciphering and the mathematics attending that growth, and the obvious resistance to new paradigms in this field. While mathematical proof of encryption strength is highly desirable in most applications (some would argue essential in certain applications), I see things this way: Computer software of any kind, which cannot be analyzed by common persons (average programmers), whose innards cannot be exposed to the masses for whatever reason, should not be used where it could effect control over the lives of those people. Looking at it a different way, it's wise for any individual or group to evaluate the software that's available, and make their own judgements independently of "expert opinion" in the field. ******************************************************************************* ******************************************************************************* ******************************************************************************* /* CCRP.C Encrypt/Decrypt a DOS file */ /* By: Dale Thorn */ /* Version 2.9 */ /* Rev. 03.07.1996 */ #include "stdlib.h" #include "string.h" #include "stdio.h" #include "dos.h" #include "io.h" #include "ccrp.h" V main(I argc, C **argv) { /* command-line arguments (input file/offset) */ C cmsg[23]; /* initialize the User message string */ U ibit = 0; /* initialize the bit offset in cbuf */ U ibuf = 2048; /* set maximum file buffer length */ U idot; /* initialize the filename extension separator */ I ieof = 0; /* initialize the EOF flag */ U ilen; /* initialize a temporary length variable */ U indx; /* initialize a temporary loop variable */ I iopr; /* initialize the operation code */ U irnd = 0; /* initialize the randomizer seed */ L lbyt; /* initialize the file pointer variable */ L llof; /* initialize the file length variable */ L lrnd = 0; /* initialize the randomizer accumulator */ U _far *uvadr = 0; /* video display pointer */ struct _iobuf *ebuf; /* source file access structure */ C *cbuf = (C *)malloc(2048); /* initialize the file buffer */ C *ctmp = (C *)malloc(2048); /* initialize the temp buffer */ I *int1 = (I *)malloc(3074); /* allocate the sort index array */ I *int2 = (I *)malloc(3074); /* allocate the sort random number array */ I *istk = (I *)malloc(3074); /* allocate the sort stack array */ if (argc == 1) { /* a command line was not supplied */ ifn_msgs("Usage: CCRP(v2.9) filename [/e /d] [key]", 4, 24, 79, 0, 1); } /* display the usage message [above] and exit */ if (argc < 3 || argc > 4) { /* no. of parameters should be one or two */ ifn_msgs("Invalid number of parameters", 4, 24, 79, 1, 1); } /* display no.-of-parameters message [above] and exit */ if (argv[2][0] != '/') { /* slash preceding parameter missing */ ifn_msgs("Invalid operation parameter", 4, 24, 79, 1, 1); } /* display invalid-parameter message [above] and exit */ strupr(argv[1]); /* uppercase the filename */ strupr(argv[2]); /* uppercase the operation code */ if (argv[2][1] != 'D' && argv[2][1] != 'E') { /* invalid parameter */ ifn_msgs("Invalid operation parameter", 4, 24, 79, 1, 1); } /* display invalid-parameter message [above] and exit */ idot = strcspn(argv[1], "."); /* position of filename extension separator */ ilen = strlen(argv[1]); /* length of filename */ if (idot == 0 || idot > 8 || ilen - idot > 4) { /* filename tests bad */ ifn_msgs("Invalid filename", 4, 24, 79, 1, 1); } /* display invalid-filename message [above] and exit */ if (idot < ilen) { /* filename extension separator found! */ if (strcspn(argv[1] + idot + 1, ".") < ilen - idot - 1) {/* 2nd found! */ ifn_msgs("Invalid filename", 4, 24, 79, 1, 1); } /* display invalid-filename message [above] and exit */ } strcpy(cmsg, argv[1]); /* copy filename to message */ strcat(cmsg, " not found"); /* add "not found" to message */ ebuf = fopen(argv[1], "rb+"); /* open the selected file */ llof = filelength(fileno(ebuf)); /* filelength of selected file */ if (ebuf == NULL || llof == -1L || llof == 0) {/* length=0 or call failed */ fclose(ebuf); /* close the file */ remove(argv[1]); /* kill the zero-length file */ ifn_msgs(cmsg, 4, 24, 79, 1, 1); /* display message and exit */ } iopr = argv[2][1] - 68; /* operation code (1=encrypt, 2=decrypt) */ if (argc == 4) { /* a seed key was supplied */ ilen = strlen(argv[3]); /* length of optional seed key */ for (indx = 0; indx < ilen; indx++) { /* loop through the seed key */ irnd = argv[3][indx]; /* character at byte position */ switch (indx % 3) { /* select on byte significance */ case 0: /* least significant byte */ lrnd += irnd; /* add to randomizer accum. */ break; case 1: /* 2nd least significant byte */ lrnd += (L)irnd * 256; /* add to randomizer accum. */ break; case 2: /* most significant byte */ lrnd += (L)irnd * 65536; /* add to randomizer accum. */ break; default: break; } } irnd = (U)(lrnd % 32640) + 1; /* mod randomizer seed to <= 32640 */ } ifn_msgs("Please standby", 4, 24, 79, 0, 0); /* standby message */ srand(irnd); /* initialize the random number generator */ for (lbyt = 0; lbyt < llof; lbyt += ibuf) {/* proc. file in ibuf segments */ if (lbyt + ibuf >= llof) { /* current file pointer + ibuf spans EOF */ ibuf = (U)(llof - lbyt); /* reset maximum file buffer length */ /* cbuf = "" /* deallocate file buffer */ /* cbuf = space$(ibuf) /* reallocate file buffer */ ieof = 1; /* set the EOF flag ON */ } fseek(ebuf, lbyt, SEEK_SET); /* set file-read position */ fread((V *)cbuf, 1, ibuf, ebuf); /* read data into the file buffer */ while (1) { /* loop to process bit groups in cbuf */ ilen = (rand() / 26) + 256;/* buffer seg. bit-len.: 256<=ilen<=1536 */ if (ibit + ilen > ibuf * 8) {/* current bit-pointer+ilen spans cbuf */ if (ieof) { /* EOF flag is ON */ ilen = ibuf * 8 - ibit; /* reset bit-length of buffer segment */ } else { /* EOF flag is OFF; adjust file pointer */ fseek(ebuf, lbyt, SEEK_SET); /* set file-write position */ fwrite((V *)cbuf, 1, ibuf, ebuf);/* save curr. buffer to file */ lbyt -= (ibuf - ibit / 8);/* set file ptr to reload from ibit */ ibit %= 8; /* set ibit to first byte of <new> cbuf */ break; /* exit loop to reload cbuf from lbyt */ } } /* encrypt or decrypt the current segment [below] */ ifn_cryp(int1, int2, istk, cbuf, ctmp, (I)ibit, ilen, iopr); ibit += ilen; /* increment ibit to next bit-segment */ if (ibit == ibuf * 8) { /* loop until ibit == length of cbuf */ fseek(ebuf, lbyt, SEEK_SET); /* set file-write position */ fwrite((V *)cbuf, 1, ibuf, ebuf);/* write current buffer to file */ ibit = 0; /* set ibit to first byte of <new> cbuf */ break; } } } ifn_msgs("Translation complete", 4, 24, 79, 0, 1);/* disp. message & exit */ } I bitget(C *cstr, I ibit) { /* get a bit-value from a string */ I ival; /* initialize the bit value */ switch (ibit % 8) { /* switch on bit# within character */ case 0: /* bit #0 in target character */ ival = 1; /* value of bit #0 */ break; case 1: /* bit #1 in target character */ ival = 2; /* value of bit #1 */ break; case 2: /* bit #2 in target character */ ival = 4; /* value of bit #2 */ break; case 3: /* bit #3 in target character */ ival = 8; /* value of bit #3 */ break; case 4: /* bit #4 in target character */ ival = 16; /* value of bit #4 */ break; case 5: /* bit #5 in target character */ ival = 32; /* value of bit #5 */ break; case 6: /* bit #6 in target character */ ival = 64; /* value of bit #6 */ break; case 7: /* bit #7 in target character */ ival = 128; /* value of bit #7 */ break; default: break; } return ((cstr[ibit / 8] & ival) != 0); /* return value of target bit */ } V bitput(C *cstr, I ibit, I iput) { /* put a bit-value to a string */ I ival; /* initialize the bit value */ I ipos = ibit / 8; /* position of 8-bit char. in cstr */ switch (ibit % 8) { /* switch on bit# within character */ case 0: /* bit #0 in target character */ ival = 1; /* value of bit #0 */ break; case 1: /* bit #1 in target character */ ival = 2; /* value of bit #1 */ break; case 2: /* bit #2 in target character */ ival = 4; /* value of bit #2 */ break; case 3: /* bit #3 in target character */ ival = 8; /* value of bit #3 */ break; case 4: /* bit #4 in target character */ ival = 16; /* value of bit #4 */ break; case 5: /* bit #5 in target character */ ival = 32; /* value of bit #5 */ break; case 6: /* bit #6 in target character */ ival = 64; /* value of bit #6 */ break; case 7: /* bit #7 in target character */ ival = 128; /* value of bit #7 */ break; default: break; } if (iput) { /* OK to set the bit ON */ if (!(cstr[ipos] & ival)) { /* bit is NOT already ON */ cstr[ipos] += ival; /* set bit ON by adding ival */ } } else { /* OK to set the bit OFF */ if (cstr[ipos] & ival) { /* bit is NOT already OFF */ cstr[ipos] -= ival; /* set bit OFF by subt. ival */ } } } V ifn_cryp(I *int1, I *int2, I *istk, C *cbuf, C *ctmp, I ibit, I ilen, I iopr) { I indx; /* initialize the for-next loop counter */ for (indx = 0; indx < ilen; indx++) { /* loop through ilen array elements */ int1[indx] = indx; /* bit offsets from current ibit offset */ int2[indx] = rand(); /* random number values for sort function */ } ifn_sort(int1, int2, istk, ilen - 1); /* Quicksort by random no. array */ memcpy(ctmp, cbuf, 2048); /* copy data buffer to temp destination buffer */ if (iopr) { /* encrypt operation */ for (indx = 0; indx < ilen; indx++) { /* loop thru ilen array elements */ bitput(ctmp, indx + ibit, bitget(cbuf, int1[indx] + ibit));/*encrypt*/ } } else { /* decrypt operation */ for (indx = 0; indx < ilen; indx++) { /* loop thru ilen array elements */ bitput(ctmp, int1[indx] + ibit, bitget(cbuf, indx + ibit));/*decrypt*/ } } memcpy(cbuf, ctmp, 2048); /* copy temp destination buffer to data buffer */ } V ifn_msgs(C *cmsg, I iofs, I irow, I icol, I ibrp, I iext) {/* display msgs */ io_vcls(7); /* clear the screen */ io_vdsp(cmsg, 4, iofs, 7); /* display the user message */ if (ibrp) { /* OK to sound user-alert (beep) */ printf("\a"); /* sound the user-alert */ } if (iext) { /* OK to exit the program */ io_vcsr(5, 0, 0); /* relocate the cursor */ fcloseall(); /* close all open files */ exit(0); /* return to DOS */ } else { /* do NOT exit the program */ io_vcsr(irow, icol, 0); /* 'hide' the cursor */ } } V ifn_sort(I *int1, I *int2, I *istk, I imax) { /* array Quicksort function */ I iext; /* initialize the outer-loop exit flag */ I ilow; /* initialize the low array pointer */ I irdx = 0; /* initialize the sort radix */ I isp1; /* initialize the low stack pointer */ I isp2; /* initialize the top stack pointer */ I itop; /* initialize the top array pointer */ I iva1; /* initialize array value from low stack pointer */ I iva2; /* initialize array value from low stack pointer */ istk[0] = 0; /* initialize the low array pointer */ istk[1] = imax; /* initialize the top array pointer */ while (irdx >= 0) { /* loop until sort radix < 0 */ isp1 = istk[irdx + irdx]; /* set the low stack pointer */ isp2 = istk[irdx + irdx + 1]; /* set the top stack pointer */ irdx--; /* decrement the sort radix */ iva1 = int1[isp1]; /* get array value from low stack pointer */ iva2 = int2[isp1]; /* get array value from low stack pointer */ itop = isp2 + 1; /* set the top array pointer */ ilow = isp1; /* set the low array pointer */ while (1) { /* loop to sort within the radix limit */ itop--; /* decrement the top array pointer */ if (itop == ilow) { /* top array pointer==low array pointer */ break; /* skip to next radix value */ } if (iva2 > int2[itop]) { /* value @low pointer>value @top pointer */ int1[ilow] = int1[itop]; /* swap low and top array values */ int2[ilow] = int2[itop]; /* swap low and top array values */ iext = 0; /* initialize outer-loop exit flag */ while (1) { /* loop to compare and swap array values */ ilow++; /* increment the low array pointer */ if (itop == ilow) { /* top array pointer==low array pointer */ iext = 1; /* set outer-loop exit flag ON */ break; /* skip to next radix value */ } if (iva2 < int2[ilow]) { /* value @low ptr.<value @low ptr. */ int1[itop] = int1[ilow]; /* swap top and low array values */ int2[itop] = int2[ilow]; /* swap top and low array values */ break; /* repeat sort within the radix limit */ } } if (iext) { /* outer-loop exit flag is ON */ break; /* skip to next radix value */ } } } int1[ilow] = iva1; /* put array value from low stack pointer */ int2[ilow] = iva2; /* put array value from low stack pointer */ if (isp2 - ilow > 1) { /* low segment-width is > 1 */ irdx++; /* increment the sort radix */ istk[irdx + irdx] = ilow + 1; /* reset low array pointer */ istk[irdx + irdx + 1] = isp2; /* reset top array pointer */ } if (itop - isp1 > 1) { /* top segment-width is > 1 */ irdx++; /* increment the sort radix */ istk[irdx + irdx] = isp1; /* reset low array pointer */ istk[irdx + irdx + 1] = itop - 1; /* reset top array pointer */ } } } U io_vadr(I inop) { /* get video address (color or b/w) */ rg.h.ah = 15; /* video-address function */ int86(0x10, &rg, &rg); /* call DOS for video address */ if (rg.h.al == 7) { /* register A-low is 7 */ return(0xb000); /* return b/w address */ } else { /* register A-low is NOT 7 */ return(0xb800); /* return color address */ } } V io_vcls(I iclr) { /* clear screen function */ I irow; /* initialize the row number variable */ C cdat[81]; /* initialize the row data buffer */ memset(cdat, ' ', 80); /* clear the row data buffer */ cdat[80] = '\0'; /* terminate the row data buffer */ for (irow = 0; irow < 25; irow++) { /* loop thru the screen rows */ io_vdsp(cdat, irow, 0, iclr); /* display each <blank> screen row */ } } V io_vcsr(I irow, I icol, I icsr) { /* set cursor position [and size] */ rg.h.ah = 2; /* cursor-position function */ rg.h.bh = 0; /* video page zero */ rg.h.dh = (C)irow; /* row number */ rg.h.dl = (C)icol; /* column number */ int86(0x10, &rg, &rg); /* call DOS to position cursor */ if (icsr) { /* cursor-size specified */ rg.h.ah = 1; /* cursor-size function */ rg.h.ch = (C)(13 - icsr); /* set cursor-begin line */ rg.h.cl = 12; /* set cursor-end line */ int86(0x10, &rg, &rg); /* call DOS to set cursor size */ } } V io_vdsp(C *cdat, I irow, I icol, I iclr) { /* display data on screen */ I ilen = strlen(cdat); /* length of string to be displayed */ I iptr; /* byte-counter for displayed string */ U uclr = iclr * 256; /* unsigned attribute high-byte value */ if (!uvadr) { /* video pointer segment not set */ FP_SEG(uvadr) = io_vadr(0); /* set video pointer segment */ } FP_OFF(uvadr) = irow * 160 + icol * 2; /* set video pointer offset */ for (iptr = 0; iptr < ilen; iptr ++) { /* loop thru displayed string */ *uvadr = uclr + (UC)cdat[iptr]; /* put data to video memory */ uvadr++; /* increment video display pointer */ } } ******************************************************************************* ******************************************************************************* ******************************************************************************* New CCRP documentation - changes as of 28.02.1996 ----------Command---------- ------------------Output------------------- CCRP Usage parameters. CCRP filename /e Encrypt each byte in 'filename' so that the data cannot be seen, or, if the file was an executable file, it cannot be executed. CCRP filename /d Decrypt (restore) each byte in 'filename'. CCRP filename /e key Encrypt or decrypt 'filename', but add an CCRP filename /d key additional factor (a key, or a password) to the encryption and decryption. NOTE 1: The key/password (if used) must be a contiguous string of characters with no blank spaces between any characters. NOTE 2: If a key is entered for encryption, the same key must be entered for decryption. NOTE 3: Encryption may be performed 2 or more times in sequence before decryption, using a different key each time, for additional encryption security. In such case, the decryption steps must be performed in the reverse order (last encryption/first decryption). NOTE 4: Encryption and decryption are mere complementary processes, so that if the decryption step were performed first, followed by encryption, the end effect would be the same. WARNING(!) Encryption changes the contents of a file, and if you cannot perform the decryption process properly, including the use of keys/passwords, you won't be able to recover the file at all. Normally, before making changes to a file, you are advised to make a backup copy of the file, but since the purpose of encryption is to make the file unreadable and unusable, to have a usable backup copy of the file on the same computer, or even in the same area that the computer is located in, wouldn't suit the primary purpose of encryption. NOTES: If maximum security is the objective, you might want to encrypt a file several times (in several passes) with a different encryption key each pass, using different programs, and mixing the encryption/decryption order (OK as long as different keys are used). Examples: ENCRYPT.BAT (encrypt the file; see Note 4 above concerning the /d switch) bcrp filename /d Little_Miss_Muffet_Sat_On_Her_Tuffet ccrp filename /e The_Quick_Brown_Fox_Jumped_Over_The_Lazy_Dog bcrp filename /e We_Have_Met_The_Enemy_And_They_Are_Us ccrp filename /d Let_Him_That_Hath_Understanding_Count_The_Number_Of_The_Beast DECRYPT.BAT (decrypt the file; see Note 4 above concerning the /e switch) ccrp filename /e Let_Him_That_Hath_Understanding_Count_The_Number_Of_The_Beast bcrp filename /d We_Have_Met_The_Enemy_And_They_Are_Us ccrp filename /d The_Quick_Brown_Fox_Jumped_Over_The_Lazy_Dog bcrp filename /e Little_Miss_Muffet_Sat_On_Her_Tuffet

2 1

Re: White House crypto proposal -- too little, too late
by jim bell 17 Dec '03

17 Dec '03

At 02:57 PM 10/1/96 -0700, Declan McCullagh wrote: > > >---------- Forwarded message ---------- >Date: Tue, 1 Oct 1996 14:56:21 -0700 (PDT) >From: Declan McCullagh <declan(a)well.com> >To: fight-censorship(a)vorlon.mit.edu >Subject: White House crypto proposal -- too little, too late [snip] >What's even more disturbing is what the administration might do >next. After the roundtable broke up, I chatted with Michael Vadis, one >of the assistant deputy attorneys general who oversees national >security issues. He said an international consensus is forming that >terrorists can use crypto; therefore crypto must be controlled. The >U.S. is certainly pushing this line at the OECD talks. > >"But it just takes one country to decide to export strong crypto," I said. >"You're missing something," said Vadis. >"What?" I asked. "Unless you're talking about import restrictions." >"Exactly," he said. >-Declan An import restriction would be even less effective than the current export restrictions. With an import restriction, a person need merely receive a given piece of software in the mail from an "unknown" benefactor, software that (surprise!) would have been illegal to import. (the software doesn't even have to be mailed from outside the US, merely trucked in by a wetback and anonymously mailed by tossing it into the ubiquitous USnail PO Box.) Redistribution of this software would have to be legal, if for no other reason than nobody could prove it was imported illegally. Nobody outside the US would have any standing to sue for copyright violation, because they couldn't import it and sell it without restrictions. Jim Bell jimbell(a)pacifier.com

5 4