Re: Rijndael Hitachi
Arnold G. Reinhold [EMAIL PROTECTED] asked: What is the licensing status of the other finalists? For example, I seem to recall reading that RC6 would be licensed to the public at no charge if it won the competition. What now? Since April, RC6 has being commercially licensed as part of RSA's BSAFE Crypto-C 5.0 and BSAFE Crypto-J 3.0 software developer toolkits. I don't expect that will change. (RSA said, however, that by the end of the year its regular support and maintenance procedures will add Rijndael to both of those SDKs. RSA also said it will adopt the AES as "a baseline encryption algorithm" for its Keon family of digital cert products.) Given RSA's market share, the eight BSAFE toolkits could be a major channel for distributing AES code to the developer community, particularly among OEMs. http://www.rsasecurity.com/products/bsafe/ Of the other three who made the finals in this "Crypto Olympics." MARS, while patented, is available world-wide under a royalty-free license from Tivoli Systems, an IBM subsidiary. (See http://www.tivoli.com, although the Tivoli site doesn't seem to have anything but the press release.) Serpent is public domain, now under the GNU PUBLIC LICENSE (GPL), although Serpent website warns that "some comments in the code still say otherwise." http://www.cl.cam.ac.uk/~rja14/serpent.html Twofish is "unpatented, and the source code is uncopyrighted and license-free; it is free for all uses." http://www.counterpane.com/twofish.html Suerte, _Vin
RE: GPS integrity
For more info on "Cyberlocator" (not SmartLocator), try: http://www.cyberlocator.com/technical.html Cyberlocator, a corporation, has two US patents on the use of GPS for location-based authentication. One patent (US 5,757,916) describes the use of satellites in location-based authentication and the other (US 4,797,677) covers their "unique processing" of GPS signals. 4,797,677: http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1; u=/netahtml/srchnum.htmr=1f=Gl=50s1='4797677'.WKU.OS=PN/4797677RS=PN/4 797677 5,757,916; http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1; u=/netahtml/srchnum.htmr=1f=Gl=50s1='5,757,916'.WKU.OS=PN/5,757,916RS= PN/5,757,916 Suerte, _Vin Amir Herzberg [EMAIL PROTECTED] wrote: snip SmartLocator is/was a product/prototype of International Series Research Inc., around 1996; I haven't found any more info about it (further to Denning's note) and suspect it doesn't exist anymore. In any case, based on what I've read in Denning's article, I think SmartLocator does not claim to secure GPS integrity. SmartLocator claims to provide a `location signature` using GPS, that is, a way to prove that the sender of a message has a GPS receiver in a particular position in space and time. Actually, this could indeed be quite useful, if this works, so one wonders how it worked and why one (me) never heard of it so far. Maybe someone on the list knows better? Or maybe we should look for a patent. Frankly: my expectations are low, I will be surprised if this was really done securely. Best Regards, Amir Herzberg IBM Research Lab in Haifa (Tel Aviv Office) http://www.hrl.il.ibm.com Eugene Leitl [EMAIL PROTECTED] on 05/09/2000 12:10:27 AM Please respond to Eugene Leitl [EMAIL PROTECTED] To: Ian BROWN [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Amir Herzberg/Haifa/IBM) Subject: Re: GPS integrity I presume the paper in question is http://www.cs.georgetown.edu/~denning/infosec/Grounding.txt Ian BROWN writes: Dorothy Denning wrote an interesting paper on authenticating location using GPS signals... I think it's reachable from her home page as well as the following citation: D. E. Denning and P. F. MacDoran, "Location-Based Authentication: Grounding Cyberspace for Better Security," Computer Fraud and Security, Feb. 1996 Ian :)
ECC2K-108 Cracked (Certicom Challenge)
At 03:28 PM 4/17/00 -0400, Perry E. Metzger wrote: Anyone know anything about this? Hi Perry, This brief compilation might help. This has been an impressive achievement. The comments of Harley and Morain in the InRIA press release, below, are striking, given Certicom's historic committment to particular (as opposed to random) Elliptic Curves. Other vendors (e.g., my friends at RSA) sell ECC with random Elliptic Curves only, and have long argued that ECC with particular curves is an unnecessarily risk. Individual critics like Len Adleman have been even more pointed in their remarks. Surete, _Vin - From the Elliptic Curve Discrete Logrithm (ECDL) Project webpage: http://cristal.inria.fr/~harley/ecdl/ The biggest public-key crypto crack ever has just finished! Certicom have confirmed that the solution is correct. There is press coverage by Slashdot, National Post, ZDNet, Impress (Japanese), Developer.com, Yahoo, Crypto-News (French), Punto Informatico (Italian). [Links off the ECDL Project Website] More soon! A useful fact-sheet. http://cristal.inria.fr/~harley/ecdl7/factsheet.html A technical FAQ. http://cristal.inria.fr/~harley/ecdl7/FAQ.html Index 1. Why is this interesting? Is it all about cracking a code? 2. What is a discrete logarithm? 3. Remind me what a finite group is. 4. What is an elliptic curve and what is the group of points on it? 5. What is a finite field? 6. What is the ECC2K-108 problem? 7. What algorithm can we use to solve ECDL problems like ECC2K-108? 8. What are the iterations in "iterations per second"? 9. What are distinguished points? 10. What are the initial and current expectations? 11. How hard is the ECC2K-108 problem anyway? 12. How can I participate? From the 4K Associates Press Release http://www.4K-Associates.com/Press.html PARIS -- 13th April 2000 -- Irish mathematician Robert Harley and three colleagues at INRIA, the French National Institute for Research in Computer Science and Control, announced the solution to the most difficult public key cryptographic challenge ever solved after a huge calculation on close to 1 computers throughout the Internet. The challenge, called ECC2K-108, was set by Canadian cryptographic company Certicom in 1997 to encourage researchers to test the security of cryptography based on elliptic curves. This extraordinary achievement demonstrates the high level of security that ECC (elliptic-curve cryptography) can offer with much shorter keys than RSA. It also highlights the relative weakness of some curves with special properties and confirms that for optimal security one should pick random curves with no special characteristics. snip From the InRIA press release at: http://www.inria.fr/Presse/pre67-eng.html snip Arjen Lenstra, vice president at Citibank's Corporate Technology Office in New York and a participant in the project, noted "The amount of computation we did is more than what is needed to crack a secret-key system like DES and enough to crack a public-key system like RSA of at least 600 bits". Harley remarked "Even so, it was only about one tenth of what should normally be required for a 109-bit curve. That's because Certicom chose a particular curve with some useful properties but we used those same properties to speed up our algorithm". He went on to say "This underlines the danger in adopting particular curves and the need to pick random ones with no special characteristics. I'm concerned about Koblitz curves and complex-multiplication curves, which some people advocate using in order to avoid the point-counting problem". François Morain, Professor of Computer Science at École Polytechnique, explained: "To use a curve for ECC one first has to calculate the number of points on it, which is quite a difficult task. To improve security one should use arbitrary curves picked at random and change them frequently, but currently most cryptosystems use fixed curves chosen to have particular properties which make it easy to compute the cardinality. These very properties could one day endanger them, as happened with super-singular curves. There have been dramatic improvements in point-counting algorithms and good implementations are now becoming available. Recent progress should soon undermine any remaining argument in favour of special curves". snip From the Cericom Press Release at: http://www.certicom.com/news/00/apr1700.html Hayward, Calif., April 17, 2000 - Dr. Scott Vanstone, Chief Cryptographer for Certicom Corp., is pleased to announce that a team of researchers led by Robert Harley, Damien Doligez, Daniel
Re: legal status of RC4
Arnold G. Reinhold [EMAIL PROTECTED] asked:
Are you sure RC4 is a registered trademark? I've never seen anything
that would indicate that.
RSADSI first filed for a US trademark on "RC4" in 1993.
RSA has used RC4 (R) since 1988 in "trade and commerce" (as the
phrase goes) to refer to the RSA-branded stream cipher Ron Rivest had
created for RSADSI. (RC4, I suppose, became a common law trademark -- in
the US and elsewhere -- sometime thereafter.)
The "RC4" trademark was formally Registered by the US Patent and
Trademark Office on August 15, 1995.
The USPTO registration number for RC4 is: 1911168.
The USPTO Trademark Database citation for RC4 is on the Web at:
http://trademarks.uspto.gov/cgi-bin/ifetch4?ENG+REG+3+953890+0+0+370981+F+2
+3+1+MS%2f%22RC4%22
Surely a RC4 TM is no surprise. Over the years, RSA has routinely
noted that "RC4" is a registered trademark trademark.
In the US and elsewhere, a trademark is intended to prevent
confusion among buyers by clearly indicating who is providing a given
product to the market. The basic idea is that a consumer should not have to
open a package (or do an MD5 hash on a digital product;-) to be confident
that his TM-based assumptions about the _source_ of a product -- and any
prior knowledge he has about vendor's support, QA, warranties,
compatability, business practices, etc., etc. -- are valid.
By the latter half of the 1990s, of course, almost everyone with a
computer had it loaded with a SSL ciphersuite -- which included a
clearly-labelled, RSA-coded, RC4 crypto module. (RSADSI's willingness to
gamble on Netscape and SSL and accept a fabled one percent of Netscape's
equity in return for permitting Netscape access to RSA's BSAFE ciphers,
including RC4, paid off ahem handsomely.)
I'm don't mean to be disingenuous. I acknowledge that there are many
who claim that the various independently-coded ARC4 ("Apparently RC4")
ciphers are functionally and otherwise equivalent to the RC4 implementation
found in RSA's BSAFE. Whether that is (or is not;-) the case -- it is
also clearly and incontestably true that none of the various ARC4-like
ciphers are actually coded, QAed, or sold by RSA Security.
Last year, Kalle Kaukonen of SSH and Rodney Thayer of Counterpane
even wrote an Internet Draft RFC --
http://search.ietf.org/internet-drafts/draft-kaukonen-cipher-arcfour-03.txt
-- to offer yet another version of "Arcfour." The RFC explains that they
hoped their Arcfour would smooth the transition to IETF-endorsed standards
from the earlier generation of defacto compsec standards (hich had the ill
but entreprenurial grace to be based on proprietary RSA ciphers, RC4
prominent among them;-)
These days, most people in the Craft would conceed that it would take
a humungous amount of gall for some individual, company, or committee --
anyone *other than* RSA or MIT Prof. Ron Rivest -- to publish a new cipher
labelled, say, "RC7." Which is not to say that it won't happen, of course.
(In response to a query in private e-mail for evidence off the RSA
website that RSA publicizes the RC4 trademark), I just did a quick search
of www.rsasecurity.com and pulled up three notable references to the RC4
trademark. See:
1. Specs for RSA's newest version of BSAFE Crypto-C toolkit:
URL: http://www.rsasecurity.com/products/bsafe/cryptoc.html
"Crypto-C includes all popular secret- and public-key encryption algorithms,
including the RC4® stream cipher, the high performance RC5"
2. The 1998 announcement of BSAFE 4.0:
URL: http://www.rsasecurity.com/news/pr/980608.html
"RC2® and RC4® are registered trademarks and BSAFE is a trademark of RSA
Data Security, Inc."
3. The 1994 announcement of BSAFE 2.1:
URL: http://www.rsasecurity.com/news/pr/940721.html
"The RSA logo, BSAFE, RSA Public Key Cryptosystem, RSA Digital Signature,
RSA Digital Envelope, RC2, RC4, MD, MD2 and MD5 are trademarks of RSA Data
Security, Inc. [...]"
Surete,
_Vin
Personally, I believe that Trust -- a value might be consistently
associated with a specific trademark -- is the critical factor in any
intelligent purchase of a cryptographic cipher or product. It doesn't seem
to matter much whether the buyer is an individual consumer, a corporate PO,
or a globe-girdling OEM. To the extent that Trust matters to end-users --
and many OEMs act like they believe that it matters a lot -- RSA's
trademarks come into play.
Re: legal status of RC4
Eric Murray [EMAIL PROTECTED] queried the Listocracy:
Does anyone know the legal status of RC4 in the US?
I know that a cipher purporting to be RC4 was published on
Cypherpunks by Anonymous, and that various crypto packages
have RC4 or "EC4". My question is, has RSA taken anyone to
court in the US for using RC4 without buying a license from RSA?
To my knowledge, neither RSADSI, nor the new firm formed by the
combination of RSADSI and Security Dynamics last year -- RSA Security, Inc.
-- has ever dragged any individual or enterprise into court for using an
unlicensed implementation of RC4.
I may have missed something over the years, but there are today an
abundance of commercial products on the market which use ARC4, "Apparently
RC4," or some similar independent implementation of Rivest's RC4 -- with no
tithe to RSA, and no kickback that I can see. (There was a fascinating
discussion of all this a year or two ago, on either Cypherpunks or here on
C2's Cryptography. Search for an evocative subject-line: "None Dare Speak
its Name," or "The Cipher None Dare Name.")
RSA is reportedly far more conscientious in defending its trademark
on the label "RC4." RC2, RC4, RC5, RC6 -- and probably MD2, MD4, and MD5,
Rivest's freeware message digests or hashs -- are registered trademarks.
("RC," Rivest once told me, simply stands for "Ron's Code" -- a workbench
label for crypto in development that somehow escaped into the hands of the
RSA marketing guys.)
I suspect that RSA did send out more than a few nastygrams to OEMs
or other mass marketeers about "illicit use" of RC4, but -- at least in
recent years -- its complaints probably went to commercial enterprises which
both (a) sought to resell the algorithm in the US, and (b) blatently used
the RC4 label in a way that is likely to confuse many people as to the
source of the RC4 implementation code. In the real world, RC4 is today
almost exclusively associated with the implementation of RC4 in the RSA
BSAFE toolkits, which have been licensed to some 700 OEMs, designed into
thousands of products, and installed in a half *billion* user machines.
[Gothic legend to the contrary, I have also never heard of RSA
rousting _any_ US firm or individual who used their own unlicensed
implemention of RSApkc (and RC2 and RC4) in various homebrew SSL grafts, or
in the famous freeware SSL kits: SSLeay or OpenSSL. The elegant design of
RC4 has been widely studied and discussed in academia.]
[Vendors of commercial products which include various ARC4
implementations putz along untouched. The IETF also has several RFCs which
document and refer to various independent and equivalent ACR4
implementations. Indeed, in order to market Eric Young's BSAFE SSL-C
toolkit out of RSA-Australia, Young -- the "eay" of SSLeay in a previous
life, now the CTO of RSA-Australia -- had to prove to both the Australian
and US export control mavens that Young's implementation of RC4 for SSL-C
was based on wholly non-RSADSI and non-American sources.]
Of course, back in the early-90s when the reverse-engineered RC4
code was first anonymously posted to the Net, it immediately became clear
that the old combination of software license, trade secret status,
copyright, and trademark IP with which RSADSI had tried to protect and
control access to Rivest's RC4 algorithm was an utter failure.
As I think the insightful Greg Boiles, Esq., has pointed out
elsewhere, the possibility of unattributed global publication guts many of
the traditional IP defenses for commercial know-how or technical savvy in
commercial products.
Anyone who can deconstruct or reverse-engineer a proprietary and
secret design or formula -- be it the Coca Cola formula or Ron Rivest's RC4
-- can use the Net to duck the retribution that was at the heart of most
traditional IP defenses. (Ya gotta have a 16 year-old's sense of
invulnerability to sign your name to the deed, be you a DVD devil, an angel,
a curious teen scientist, or just a guy who doesn't like to pay royalties to
artists or inventors;-)
The fate of RC4 -- the anonymous post to the Net has led to the
widespread use of unlicensed "ARC4" in hundreds of commercial software
products today -- led RSADSI (and many other corporations) to conclude than
only patents could effectively protect software IP.
In 199o, there were 1,300 US patents issued for software
innovations. In 1999, there were 22,500 software patents issued. sigh I
have always believed the rogue publication of RC4 was a major accelerator in
this trend.
With the threat of anonymous publication of trade secrets on the
Net, it seems inevitable, at least in hindsight, that patents were to become
more important; more broaded applied; and more broadly construed.
Ain't nothin' else, folks, which can define and defend an
intellectual property claim for a novel and non-obvious invention --
Re: PGP Granted Worldwide Export License
Unless I missed something big in D.C., I presume this is simply the announcement of a pro-forma bulk export license for PGP (and the repackaged PGP Enterprise Security Suite?) for Business. And, although it is difficult to discert amid all the self-congratulatory hoopla, I also presume that NAI's "flagship technology" will only be exported outside the US with the "option" for what NAI often obliquely refers to as "additional encryption keys" -- third-party ( i.e., government and management) access to all encrypted communications -- irreversibly locked ON in a binary-only format. Much ado about nothing for consumers and most corporate buyers, right? (Which is not to deny that such a license might speed up and make shipping shedules more predictable for those ordering these products and or shipping these packages overseas. I think NAI's earlier blanket license for shipping key-recovery-ON versions of PGP for Business to US overseas branch offices and subsidiaries did just that two years ago.) Fine for folks who want, or need, or are required to build third party access into their infrastructure for handling encrypted employee email, files, or SSL and VPN sessions -- but somewhat too MAKed and GAKed for most of the rest of us. Corrections (and appropriate chastisement for my bantering tone) will be gratefully accepted. In this, I'd love to be wrong. Suerte, _Vin At 06:36 PM 12/13/99 -0500, R. A. Hettinga offered: Monday December 13, 8:30 am Eastern Time Company Press Release http://biz.yahoo.com/prnews/991213/ca_network_1.html SOURCE: Network Associates, Inc. PGP Encryption Software Granted Worldwide Export License As Part of Landmark Decision Effective Immediately, U.S. Government Grants License for International Sales Of World's Most Widely Deployed Encryption Products SANTA CLARA, Calif., Dec. 13 /PRNewswire/ -- Network Associates, Inc. (Nasdaq: NETA - news) today announced that it has been granted a full license by the U.S. Government to export its market-leading PGP encryption software, ending a decades-old ban on the export of strong encryption products. The license, effective immediately, allows Network Associates, the world's largest security software company (IDC Research, 1999) to export its full strength PGP encryption software to virtually all countries worldwide without restriction. Worldwide availability of strong encryption is widely seen as a necessity for enabling trusted e-business transactions over the Internet. ``PGP encryption has always been a flagship technology -- the first mass-distributed encryption software, the first to be sold by an overseas subsidiary, and now the first to be available for sale from the U.S. directly to overseas customers,'' said Kelly Blough, director of government relations for Network Associates. ``We are pleased with the U.S. Government's decision to grant this license independently of the new crypto regulations, so Network Associates can point the way for other American companies in the drive to help shape e-commerce worldwide.'' Network Associates acquired Phil Zimmermann's PGP, Inc. in 1997 and offers the company's PGP encryption and authentication technology today in several consumer and enterprise-class products. PGP Data Security secures all email, disk, file and network communications between businesses. The standalone PGP VPN application offers a fully standards-compliant virtual private network client that enables remote users to securely access corporate networks over the public Internet, saving companies as much as 80 percent on remote dial-up costs. IDC Research recently named Network Associates as the world's leading encryption software vendor, as well as the largest overall security software vendor (including firewall, antivirus, and VPN). As demand for seamless security to enable trusted e-business relationships grows, the worldwide market for security software is projected to grow to $8.3 billion in 2003. This relaxation of export regulations allows U.S. based companies for the first time to compete globally in the race to secure the planet with easy-to-use, deploy, and manage encryption software to enable trusted transactions. ``This decision further establishes the PGP product line as a true worldwide standard for enabling secure e-business,'' said Mona Doss, senior product manager for PGP. ``Thanks to this export license, the PGP product line can now be easily used to secure data both within and between businesses almost anywhere in the world.'' With headquarters in Santa Clara, Calif., Network Associates, Inc. is a leading supplier of enterprise network security and management software. Network Associates' Net Tools Secure and Net Tools Manager offer best-of-breed, suite-based network security and management solutions. Net Tools Secure and Net Tools Manager
Re: cracking GSM A5/1
Talking about timely and untimely comments. Check out Newsweek's credulous, confused, and tech-ignorant report about the (pre-oversight-hearing) moaning and and weeping at Fort Meade. Consider, with Newsweek, the momentous challenge the NSA confronts in e-mail and Internet phone calls (both "almost impossible to intercept," sez Newsweek); and the agony with which the NSA views the insidious spread of dangerous European cellular-phone crypto (which I presume means GSM;-) ROFL! If there were a hall of fame for incompetent and misleading journalism about crypto, this is a contenda! Consider one timely one-liner: The NSA, for instance, wanted the CIA to do more black-bag jobs illegal break-ins to steal European technology for encrypting mobile phones. The embarrassment of the full text: http://www.msnbc.com/news/342480.asp#BODY Adi Shamir [EMAIL PROTECTED] wrote: snip Real-Time Cryptanalysis of GSM's A5/1 on a PC Alex Biryukov and Adi Shamir Computer Science Department The Weizmann Institute Rehovot 76100, Israel Abstract: A5/1 is the strong version of the encryption algorithm used by about 100 million GSM customers in Europe to protect the over-the-air privacy of their cellular voice and data communication. The best published attacks against it require between 2^40 and 2^45 steps. This level of security makes it vulnerable to hardware-based attacks by large organizations, but not to software-based attacks on multiple targets by hackers. In this paper we describe a new attack on A5/1, which is based on subtle flaws in the tap structure of the registers, their noninvertible clocking mechanism, and their frequent resets. The attack can find the key in less than a second on a single PC with 128 MB RAM and two 73 GB hard disks, by analysing the output of the A5/1 algorithm in the first two minutes of the conversation. The attack requires a one time parallelizable data preparation stage whose complexity can be traded-off between 2^37 and 2^48 steps. The attack was verified with an actual implementation, except for the preprocessing stage which was extensively sampled rather than completely executed. Remark: The attack is based on the unofficial description of the A5/1 algorithm at http://www.scard.org. Discrepancies between this description and the real algorithm may affect the validity or performance of our attack. snip
Re: a smartcard of a different color
Dan Geer [EMAIL PROTECTED] reported: Yesterday I saw a smartcard of a different color. In particular, it is the smartcard chip but in a key-ring thing that is more or less identical to the Mobil SpeedPass except that it has a USB connector on one end and a keyring hole on the other. Total length circa 1.25"; color purple; maker Rainbow Technologies. As my pal Peter Honeyman said in showing it to me, "There are already all the USB ports we'll ever need." I'd point out that without the 7816 requirement for flex a whole lot more memory is a trivial add-on and that USB is not a bandwidth bottleneck. ref: http://www.rainbow.com/ikey/graphics/iKey_DS.pdf Steve Bellovin [EMAIL PROTECTED] commented: Folks I've talked to about products like that say that USB ports aren't designed for that many insertion/removal cycles. (We'll ignore, for now, all of the PCs that have their USB ports in the back, where you can't get at them easily. One could always add on a hub.) To which I add, wistfully: Same problem that the PCMCIA cards had (in a notable contrast to any smartcard reader.) I presume that it would have cost more to design these ports to withstand multitiple daily insertions, and the cost/benefits ratio just weren't there (or this sort of use didn't seem lucrative enough to factor into the equation.) Suerte, _Vin
Re: BXA
Unless, of course, this quiet announcement (in the Bernstein court papers filed by the US Govt) that the source code issue is currently being reviewed within the Executive Branch -- despite White House assurances to the contrary to leading Congressional figures -- was a purposely misleading representation, intended only to further stall and delay the Berstein hearing before the full appelate court. Of course, it is probably just because I'm a cynical Child of the SiXties that I view the DoJ posture with a skeptical and jaundiced eye. sigh Suerte, _Vin At 03:13 PM 10/19/99 -0700, Greg Broiles wrote: On Wed, Sep 29, 1999 at 07:41:34PM -0700, I wrote: At 04:49 AM 9/29/99 , Donald Ramsbottom wrote: What really intrigues me is the end of your post relating to the distinction between object code and source code. So if I understand you correctly, you will still require the old style regime and restrictions on source code. If so does that not mean that there is effectively no liberalisation? [...] Specifically of interest are general question #18, which indicates that technical assistance, APIs, and source code will continue to be controlled under the old regime; technical question #7, illustrating a new detailed approach to API regulation; and technical question #8, reiterating that only object code will be subject to the new policies. It appears that this may no longer be correct. John Young has made available on his website a document http://cryptome.org/bernstein-mot.htm filed by the US Government with respect to the en banc rehearing of the Ninth Circuit's decision in the _Bernstein_ case. In short, the US Government is asking the court to postpone oral argument in the case until the US Government has revealed the new regulations, promised for release on December 15 1999. As the filing states - "It is possible that the revised regulations will not materially change the treatment of source code. But it is also possible that the revised regulations will alter the treatment of source code in ways that could have a bearing on the constitutional issues before this Court.[1]" where footnote 1 says that the BXA's question and answer document "does not reflect the review that is taking place." Thus, reliance on that document may no longer be appropriate. BXA's website does not reflect that change in status. -- Greg Broiles [EMAIL PROTECTED]
Re: Almost-Everywhere Superiority for Quantum Computing
Russell Nelson [EMAIL PROTECTED] wrote:
Okay, then can I ask a silly question (I prefer to contribute good
answers, but in this case hopefully the question is good enough)? If
quantum computers make brute-force cryptanalysis tasks easier, don't
they also make brute-force cryptographic tasks easier as well? Put
another way, is there something special about quantum computers that
is different from Intel's next process shrink? That is, apart from
the havoc it plays with key lifetime expectations?
bram [EMAIL PROTECTED] responded:
I very strongly suspect that if the encrypter and decrypter are given the
same oracle, then the encrypter can always force the decrypter to have to
use vastly more operation of the oracle to do break a cipher than are
required to encrypt it, even with essentially normal key lengths.
The problem to worry about, of course, is that maybe not everyone is
going to have access to the same oracle.
There is no guarrantee that quantum computing will be as accessible
or as widely used as today's digital computers are. The scale and type of
technology required to isolate, manage, and manipulate the qubit (the
quantum analogue to the digital bit) seems a little daunting, but it is
probably still too early to make any big generalizations like this.
(Any intrusion of an electromagnetic field, even light, can reduce
the multi-state quantum circus to a merely digital platform.)
Consider what was involved when the NIST lab at Boulder created a
qubit a couple of years ago. As I recall, to get their qubit they had to
trap a single atom with missing electrons (an ion) and two energy levels by
nailing it down with an array magnetic and electric fields at minus 273
degrees C.
I figure that I'm not likely to have the wherewithall to manage that
on my desktop anytime soon -- but then, I don't know much about the
alternative designs for ion traps either.
Just using the reports on qubit management out of NIST, Los Alamos,
and the California Institute of Technology for scale, however, you can see
why the cognoscenti had such a belly laugh over the report in the Sunday
Times (UK) a couple weeks ago that the Weizmann Institute in Israel had
developed a hand-held quantum computing device for cryptanalysis.
Suerte,
_Vin
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and
ill... yet basically an intellectual construct, an idea, which by its nature
will
resist efforts to restrict it to bureaucrats and others who deem only themselves
worthy of such Privilege." _A Thinking Man's Creed for Crypto _vbm
*Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]*
RSA Security, Inc.
nse to ---
Russell Nelson [EMAIL PROTECTED], president of Crynwr Software, and
the Czar for the multiple Computer Newsgroups in Usenet II, rewrote the
announcement that SDTI and it's subsidiary, RSADSI, have merged into "RSA
Security" to read:
For almost two decades, More than 450
million copies
businesses have had no choiceof our RSA BSAFE(r) encryption
but to purchase public-key technology are installed in
cryptography from RSA Data today's most successful
Security. Because we've applications and devices. And
gotten so much money, we've why shouldn't it be that way?
purchased another company, All other software is illegal,
Security Dynamicsand we like it like that. To
Technologies, Inc. Today, the try to keep you using our
companies have unified under software, we have a new RSA
one name, RSA Security, Inc. Keon(tm) product line,
Our new name and look reflects providing companies with a
our desperate desire for you complete digital certificate
to continue to purchase system, known as "PKI," to
products from us, even after enable and manage security for
our patents run out. We knowe-commerce applications.
you have almost no idea who we Thousands of customers have
are, but you should. Chanceschosen RSA Security, including
are pretty close to 100% Cisco, Compaq, Ericsson,
you've had to rely on one or Fidelity, IBM, and Lucent.
more of our products to They haven't had any other
purchase something over the choice, and neither do you.
Internet, securely send email, Now that we have to persuade
safely connect to your you to purchase from us, we're
network, or do you banking now trying to build a brand
online. As a combined name before it's too late. To
company, we are the premier learn how we might serve your
monopoly in e-security -- at e-security needs, please visit
least until our patents run us at
www.rsasecurity.com, or
out. contact us at
[EMAIL PROTECTED] or
1-877-RSA-4900
Your Only Choice in e-Security
--
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for good
and ill... yet basically an intellectual construct, an idea, which by its
nature will resist efforts to restrict it to bureaucrats and others who deem
only themselves worthy of such Privilege."
_A Thinking Man's Creed for Crypto _vbm
*Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]*
RE: NPR story on crypto...
Nice article in USAToday, Will! You might find it useful to note -- and I'm open for correction on this from anyone -- that the US Government's Bernstein brief is, I believe, the first time the Govt has openly acknowledged that the export control issue is all about sigint -- listening to the legal communications of citizens and officials of other national, allied and friendly. Repeatedly, in the past, the US Govt. has reduced the public policy debate to absurdity by claiming that only by severely limiting the strength of the crypto available to legitimate commercial buyers of American (and Wassenaar) computer and communications technology could the we safeguard children, womenfolk, and the home hearth from blood-thirsty terrorists and ravening pornographers. _Vin At 05:06 PM 6/25/99 -0400, Rodger, William wrote: All of which begs a question: why has the crypto debate been so quiet this year? Perhaps the govt. is nearing its end game. One highly placed LEA source told me he expects crypto liberalization to pass _this year_ -- in all likelihood something like McCain's PROTECT Act which would do away with essentially all controls once the Advanced Encryption Standard is done. That, BTW, is supposed to happen no later than 1/1/2002, the bill says flatly. Of course, Clinton still won't sign it. For years I thought it would be 2005 or later before we saw the end of controls. What's happening now seemed almost impossible just a year ago... My story: http://www.usatoday.com/life/cyber/tech/ctf452.htm Will Rodger USAToday.com "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _A Thinking Man's Creed for Crypto _vbm * Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]* 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548
RSA's BSAFE Baldwin's RFC (FW)
From: [EMAIL PROTECTED] Subject: I-D ACTION:draft-baldwin-bsafe-00.txt Date: Thu, 13 May 1999 08:49:55 -0400 Sender: [EMAIL PROTECTED] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title: BSAFE CRYPTOGRAPHIC SECURITY COMPONENTS Author(s) : B. Baldwin, A. Wilson, S. Nishimura, M. Yurovitsky Filename: draft-baldwin-bsafe-00.txt Pages: 270 Date: 12-May-99 This Internet-Draft describes protocols, procedures, and conventions to be employed by peers implementing a generic cryptographic application program interface. Version 4.0 of this API was implemented inside RSA Data Security, Inc.'s BSAFE product. The API provides a model for implementing symmetric ciphers, message digests, message authentication, random number generation, public-key algorithms, digital signatures, and secret sharing. The API is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of security applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baldwin-bsafe-00.txt snip
Re: SecurID/ACE cryptanalysis
. Extent of endorsement.) Mr. Shostack had used my SecurID FAQ and his own creative efforts at reverse engineering of the ACE client/server protocol to suggest a potential spoof attack on the client server interaction in circa 1994 (v. 1.2) ACE authentication servers. The flaw was real, but it had been spotted nearly two years earlier by SDTI Engineering VP Jim Kotanchik and quietly fixed with a modification of the client/server interaction in ACE/Server v. 1.3 -- a "mandatory" (and I think free) 1994 upgrade of the ACE authentication server. Mr. Shostack has a copy of his paper online at: http://www.homeport.org/~adam/dimacs.html Adam also has a copy of John Brainard's pre-publication comment on his draft paper posted at the same website: http://www.homeport.org/~adam/brainard.html An earlier and more hyperkenetic attempt to analyze the ACE protocol for weaknesses was the NIS/Network Associates white paper, "Weaknesses in SecurID," by PeiterZ and a handful of other hopeful giant killers with abbreviated handles. See: http://web1.nai.com/products/security/advisory/papers/index.asp I've always been a bit mystified at the fact that my response to the PeiterZ paper is among the most widely distributed articles I've ever posted online. It seems to have been translated into more languages than the NIS white paper itself was. You can pick it up (in English) at: http://www.njh.com/latest/9609/960910-03.html Jim Kotanchik of SDTI also wrote a response to the PeiterZ "white paper." The SDTI webmistress tried to take it down a couple of times because she felt it, and the PeiterZ attack, were both dated -- but it keeps being put back on the web by popular demand. Read another articulate engineer at: http://www.securitydynamics.com/products/whitepapers/2897.html I've been a consultant to SDTI for many years, so I'm reasonable well informed, if not particularly objective. My old 1995 SecurID FAQ is a little dated, but you might find it useful. See: http://www.oga.co.th/syncom/securid/Resources/FAQs/sdfaq.html Feel free to follow up with questions, publicly or privately. I'm going to copy this over to the Firewalls and Cryptography mailing lists where you will find well-informed communities with expertise in handling these issues, and many with experience administering ACE/SecurID security systems. They will know if I've overlooked anything important. Surete, _Vin "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _A Thinking Man's Creed for Crypto _vbm * Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]* 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548 - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
Re: Starium announces STU-III for the masses
Vin McLellan [EMAIL PROTECTED] noted: Last I heard the FIREFLY family of protocols used in STU-III remain classified. A finicky fellow, Anonymous [EMAIL PROTECTED], stepped in to briskly correct me: The FIREFLY protocol is specified in RFC 1217. Nope. Gotta watch those quick greps. Search Engine results can be misleading. RFC 1217 was issued 1 April 1991 in the name of V. Cerf. It was titled: "Memo from the Consortium for Slow Commotion Research (CSCR)." The reference to "Firefly" crypto in 1217 is informative, and -- given that the NSA's internal development of the FIREFLY protocols goes way back -- may have actually been intended as a comment on the Agency's design effort. It was, however, something less than the treasonous publication of classified type-1 crypto by that noted revolutionary author. RFC 1217: (c) Firefly cryptography. A random signal (mason jar full of fireflies) is used to encipher the transmitted signal by optical combining. At the receiving site, another jar of fireflies is used to decipher the message. Since the correlation between the transmitting and receiving firefly jars is essentially nil, the probability of successful decipherment is quite low, yielding a very low effective transmission rate. Slow commotion research, indeed. Watch out for IETF pubs dated April 1, any year, Anon. The stellar pattern of the cosmos on that date realligns and reignites the adolescent hormones of American academics in such a way to make documents issued on that date by either Global Governments or wannabe volunteer groups highly suspect. On any other day, of course, you can be certain that behind every Request for Comment is an IEFT Work Group eager for your critical feedback -- even if it is not nearly as informed by special interests, studied biases, and exotic politics as their published opinion is certain to be. Suerte, _Vin "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _A Thinking Man's Creed for Crypto _vbm * Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]* 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548
Hiding cyphertext in cyphertext (FW)
From: "Jonathan Kennedy" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Hiding cyphertext in cyphertext Date: Sun, 18 Apr 1999 12:47:27 - I'm a beginner when it comes to cryptography but I after reading the Isreali Spy example in Schneier's Book, Applied Cryptography, I began thinking about a better way to hide cyphertext inside of cyphertext. I decided to post this somewhere so I could recieve some peer-review. If this is the wrong place for technical discussion, I apologize. The problem with the Isreali Spy method is that the authorities would have to actually believe that you used a simple XOR for encrypting your data. If you've been under investigation they probably won't buy the excuse that you're some amateur cryptographer just experimenting. So after a few hours of thought this is what I came up with. E(P) XOR D = K send the recipient S(E(D), K) while hiding K in the signature. The recipeint then does as follows. D(E(D)) XOR K = E(P) D(E(P)) = P Where E() and D() is the encryption/decryption routines, P is the plaintext, D is the dummy text and K is the secret key. Upon request for the key by the authorities, the cryptographers can give them k for E() and the intercepted message will decrypt to D, the dummy message. The authorities would then have no reason to be suspicious because E() can be any advanced encryption process you choose. Better still, if the authorities try to crack the intercepted message, E(D), they will just end up with D, the dummy message. The whole process hinders upon the cryptographer's ability to send K secretly. Since only a limited amount of data can be sent via digital signature, would this prevent the sender from sending K in this way? -JKennedy "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _A Thinking Man's Creed for Crypto _vbm * Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]* 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548
Aussies Lead in Legitimizing LEA Hacking
quot;remote access" - commonly referred to as hacking. The change appears to give ASIO very broad powers to hack into any computer system. An explanatory memorandum issued by the Government about the changes says: "The effect is to provide the minister with the power to authorise ASIO to access and copy computer data where unauthorised access is otherwise prohibited by Commonwealth or State or Territory law." For the first time ASIO will have the powers to install tracking devices on vehicles or even people - the devices are small beacons which transmit signals to other locations. Mr Williams told Parliament the devices were necessary for the more efficient use of ASIO's resources. The Walsh report had strongly urged that ASIO be allowed to use tracking devices, saying "the absence of this investigative tool is a privation for the Australian Federal Police, the National Crime Authority and ASIO". Other changes will allow ASIO to expand its foreign intelligence gathering within Australia by dispensing with the present need for it to obtain a special warrant for each case. According to the Government the change will allow ASIO to supplement foreign intelligence gathered by other agencies, such as ASIS. ASIO will be able to use information from the Australian Transaction Reports and Analysis Centre (AUSTRAC) to follow money trails. The changes also mean ASIO will be permitted to carry out security assessments during the Olympics. -- - Vin McLellan + The Privacy Guild + [EMAIL PROTECTED] 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548 -- @@ --
Re: Gently nurturing the misguided hacker with baseball bats
[I've been censoring this thread since it wasn't purely cryptography related and since I had heavy skepticism about the original report (which made it through to "Cryptography" some months ago. However, this particular message is sufficiently interesting as a followup that I'm letting it -- and only it -- through. --pm] Winn Schwartau reported the comments of "Lou Cipher" (a pseudonym of Mr. Cipher's choice), whom he identified as a "senior security manager at one of the country's largest financial institutions." "We have actually gotten on a plane and visited the physical location where the attacks began. We've broken in, stolen the computers and left a note: 'See how it feels?' " On one occasion, he says: "We had to resort to baseball bats. That's what these punks will understand. Then word gets around, and we're left alone. That's all we want, to be left alone." I growled about this on another list when it was first published, expressing great skepticism about the report. I was subsequently contacted by a friend -- a old pro in computer security -- who told me he had met "Mr. Cipher" and confirmed that the gentleman did indeed hold the type of position Mr. Schwartau described. He also confirmed that "Mr. Cipher" did indeed claim to have taken this sort of direct (and overtly illegal) action -- as unrealistic as it seemed to me and others of similar bourgeois bent. What seemed unlikely to me was that a reputable institution would place itself at risk by condoning such actions, or that a guy bred to corporate CYA ethics would place his job on the line by ordering such actions. OTOH, I and many others have seen "competitive analysis" ops in major US corporations turned loose with little in the way of operational guidance but a requirement that a team of freshly-suited ex-spooks produce results. I've also seen major computer companies offer lucrative consulting assignments to almost anyone who could obtain for them closely guarded technical information (from or about competitors.) I'm also familar with corporate security ops in a variety of industries (Big Oil, aerospace, defense procurement) which seemed to routinely run amuck. I'm also of the informed opinion that maybe one in five of the telephone taps set up by US police are actually legal. So _why not_ a network manager who thinks like a wildman? Where is it written that understanding RADIUS or network topology confers common sense, or good judgement? Where management rewards results -- and makes a point of not knowing how results are obtained -- I'm can easily see free-lance rent-a-cops being given such a vigilante assignment against a hacker. Given the horrendous cost of cleanup after an acknowledged hacker intrusion (even when no overt damage is done!) it could easily be cost-effective. I'm almost more surprised that it apparently works, at least according to "Mr. Cipher." I don't know why I expect a vandal, thief, virus writer, or hacker to have "courage of convictions" -- or some equivalent source of courage and constancy -- when he is physically hurt, confronted with tangible and costly losses, or faced with believable physical and economic threats. These guys are, in fact, creatures of the shadows, likely to suffer severe shock if they are just identified and confronted -- maybe all the more so, if they go nose to nose with someone who is not constrained by the niceties of the Law. The truth is, smart anti-hacker vigilantes are probably no more likely to be identified or caught than the typical car thief or other street-savvy crook. Good odds -- maybe even the basis for a viable business plan. The automated Payback software that Winn's article seemed to tout as locked and loaded in the IT armory of many major corporations would seem to be far more risky, given the quality of authentication on the Net today. The executive who issues a contract for such a physical attack would seems to be most at risk from his hired vigilantes, or anyone else who could finger him and his firm. I'll bet, however, there are spook protocols in some CIA manual for getting this sort of business done at arm's length. No direct contact. No proof as to the source of funds. The vigilantes would not even have to know who they are working for to get the message across with a certain air of self-righteousness. Surete, _Vin - Vin McLellan + The Privacy Guild + [EMAIL PROTECTED] 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548 -- @@ --
Georgoudis on AES2, Day 2, Rome (FW)
to imagine the main AES chosen by NIST for the US government could be a foreign cipher. (By the way, this makes another point in favor of more than one winner. Jaques Stern did mention something rather cryptical about a possible European cipher competition.) Who will make to the second round? I do feel there is some general consensus. Here are my choices: RC6 and MARS will make it for their pedigree not to mention the fact that they are fine ciphers with probably a lot of work invested in them. Rijndael should make on merit alone. After that, things become somehow less clear. Serpent is a favorite. It is considered a very conservative design and everybody agrees that security is indeed the preeminent concern. Its designers have some of the sharpest minds in the field and I think NIST will choose Serpent just for keeping Shamir and Biham in the competition, not to mention motivate them to attack everybody else. Twofish is all over the place; it would be cruel to kill it off so soon. Also it is a very valiant effort and certainly it is a fine cipher. Extracting the full key out a smart card with Twofish is widely considered an implementation issue rather than a weakness of the cipher itself. If you really want to be logical here, this makes no sense. On the other hand if you would kick Twofish out for this reason alone then there would a blood bath with most of the well considered candidates being thrown overboard too. Twofish does have some good pedigree (it came out of Blowfish), is fast and flexible on many platforms and appears to be strong (results to date are not really significant). Finally, as a nod to Asia, I think NIST will pick E2 too. It is certainly a very fine cipher considering its analysis, its theoretical underpinning and its speed. The Japanese presenters are probably the most sympathetic and choosing E2 would include some ladies in the finalist makeup. Also nobody wants to miss the nice accents. So here is my guess: MARS, RC6, Serpent and Twofish from the US, Rijndael from the EU and E2 from Japan. -30- -- First Response on sci.crypt Subject: Re: Live from the Second AES Conference Date: 24 Mar 1999 16:14:17 + From: Alan Braggins [EMAIL PROTECTED] Organization: nCipher Corporation Newsgroups:sci.crypt [EMAIL PROTECTED] writes: it appears that the very fastest code is self-modifying - this may look "unpure" to some but I think that it is a valid optimization technique). [...] improvement. As expected the answer is no, because one of the easiest things to read from a card is the "signature" of the instructions being executed. Any ideas whether self-modifying code would make reading instruction signatures easier or more difficult? - Vin McLellan + The Privacy Guild + [EMAIL PROTECTED] 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548 -- @@ --
Re: RSA Test
Hani Almansour [EMAIL PROTECTED] queried the Listocracy: I have implementation for RSA, SHA, MD5 and I want to test it. is there a fast way to test the output of any one of these encryption or if there is a program that test the output. Eric Rescorla [EMAIL PROTECTED] and Jim Gillogly [EMAIL PROTECTED] referred Hani to SHA and MD5 test vectors in the respective standards. EKR's comments may have also left the unfortunate impression that there are no available tests for implementations of RSA public key cryptosystems. RSA itself is one source for such tests. See RSA's PKCS reference page at: http://www.rsa.com/rsalabs/pubs/PKCS/ [Let me also suggest that RSA implementers, both neophytes and grizzled veterans, should review the recent RSA Labs Bulletin, available in PS and PDF formats at http://www.rsa.com/rsalabs/html/bulletins.html. [In "A Note on the Security of the OAEP-Enhanced RSA Public-Key Encryption Scheme," Matthew Robshaw and Jessica Staddon offer a surprisingly accessible discussion of the benefits of the Optimal Asymmetric Encryption Padding (OAEP) and the "random oracle" paradigm -- in the context of the "provable security" crypto model developed by Goldwasser and Macali 15 years ago.] RSA's Public-Key Cryptography Standards (PKCS) will be familiar to most readers of these Lists as a series of often defacto (and sometimes dejure) standards developed by RSA -- for which I am a consultant -- often in conjunction with other vendors, developers, and major users. PKCS #1 defines mechanisms for encrypting and signing with RSA public-key crypto. For the traditional RSAPKC format -- as described in PKCS #1 v.1.5 -- there are useful test vectors in a doc entitled "Some Examples of the PKCS Standard." Pull down ftp://ftp.rsa.com/pub/pkcs/ascii/examples.asc. For PKCS #1 v.2.0 -- in which the security of the traditional RSA PK crypto is enhanced by formatting or pre-processing the message with OAEP -- there are test vectors for two different OAEP/RSAPKC schemes. See: http://www.rsa.com/rsalabs/pubs/PKCS/html/pkcs-1.html. Suerte, _Vin - "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _ A Thinking Man's Creed for Crypto _vbm. * Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]* 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548
RSA Down Under
and corporate and commercial entities.
RSA's first Challenge contest, launched in January, 1997, saw grad
student Ian Goldberg use an UCLA network of a couple hundred PCs to crack a
40-bit cipher in three and a half hours. At the time, a 40-bit ciphers was
the strongest cryptographic security software the US government would allow
sold overseas without a sale-specific license approved by the NSA.
US export regulations were subsequently changed to allow for the
export of 56-bit DES in commercial products -- but only by those vendors
who promised to design a "key recovery" mechanism into their products, so
as to allow surreptitous third party access to encrypted stored data or
communication links by appropriate, and duely authorized, government agents.
The DES itself was first cracked in June, 1997, by the DESCHALL
network organized by Rocke Verser of Loveland, Colorado. DESCHALL used the
Internet to tap the spare cycles of some 70,000 computers (mostly desktop
PCs) over four months. DESCHALL won a $10,000 award from RSA by decrypting
the message: "Strong cryptography makes the world a safer place."
However, the very scale of the effort involved was used by senior
US intelligence officials to reassure Congress and corporate users that
56-bit crypto was still robust enough for civilian use. Some thought those
officals had missed the point. Last year, to better drive home the
"marginal security" of 56-bit DES, RSA organized another series of 6-month
DES Challenge contests in which participants would race the clock to crack
DES -- still, even now, the mainstay of corporate security in the US, and
in much of rest of the world..
After the Electronic Frontiers Foundation (EFF) built its $220,000
special-purpose DES Cracker ("Deep Blue") and decrypted a DES-enciphered
message in only 56 hours in the July '98 RSA Challenge, the statements of
top NSA and Justice officials to the US Congress and US businessmen --
assuring them that the DES was still robust enough that industry and much
of government could depend upon it -- looked absurd, even deliberately
misleading.
(See, for example, Cowell and Freeh; June '97 Congressional Testimony. at:
http://jya.com/hir-hear.htm)
The Wassenaar recommendations were again modernized to catch up. In
the US, however, even with the most recent updates -- new special
exemptions for powerful industry sectors like banking and insurance; and
(finally!) an end to the extortionate demands that US vendors build
key-recovery "backdoors" into their products to get DES export permits --
US export regulators continue to restrict US hardware and software exports
to crypto no stronger than 56-bit DES.
In what is still probably the most irksome aspect of the current US
system to American firms which are potential exporters, the Commerce
Dept.'s export licensing procedures for crypto, and crypto-enhanced
computer and communications products, remains inherently subjective,
enormously time-consuming, and largely unpredictable.
With American products freely shipped overseas only with broken or
"marginal" DES security, many non-American firms -- most, but not all, from
the Wassenaar nations -- have actively and very successfully sought to
expoit the overseas market opportunities created by US export controls and
US crypto politics.
Now, RSA-Australia -- fair dinkum RSA, for all the new blokes --
can get a piece of the pie.
Suerte,
_Vin
-
"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and ill... yet basically an intellectual construct, an idea, which by
its nature will resist efforts to restrict it to bureaucrats and others who
deem only themselves worthy of such Privilege."
_ A Thinking Man's Creed for Crypto _vbm.
* Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]*
53 Nichols St., Chelsea, MA 02150 USA 617 884-5548
NAI Partners with Xcert for Open-Standards PKI, Active Security
and management software. Network Associates' Net Tools Secure and Net Tools Manager offer best-of-breed, suite-based network security and management solutions. Net Tools Secure and Net Tools Manager suites combine to create Net Tools, which centralizes these point solutions within an easy-to-use integrated systems management environment. For more information, Network Associates can be reached at (408) 988-3832 or on the Internet at http://www.nai.com. Based in Walnut Creek, California, Xcert International Inc. is the premier developer of Public Key Infrastructure technology. Xcert's products provide privacy and authenticity for conducting secure Internet business transactions. Xcert develops, manufactures and distributes Certificate Authority and public key infrastructure solutions that use secure directory services to provide organizations and individuals with a ubiquitous and secure method of communicating with each other over the Internet. Xcert also licenses its underlying PKI technology to selected service providers and third party developers worldwide. Xcert can be reached on the World Wide Web at http://www.xcert.com. - Vin McLellan + The Privacy Guild + [EMAIL PROTECTED] 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548 -- @@ --
