Bugtraq mailing list archives
Re: SecurID Token Emulator
From: Vin McLellan <vin () SHORE NET>
Date: Sun, 7 Jan 2001 23:55:46 -0500
In e-mail from Russia, I.C. Wiener <icwiener () MAILRU COM> recently posted to Bugtraq source code for an algorithm which he claimed to be the hash used in RSA's SecurID hand-held authentication token, and in RSA's various token-emulation SecurID software apps for PCs and Palm Pilots. >Sample SecurID Token Emulator with Token Secret Import (See: <http://www.securityfocus.com/archive/1/152525>) Mysterious gifts from the East are, of course, a Biblical Christmas tradition -- more so in the Orthodox cultures (and centered on this day, the Feast of the Three Kings!) than in the West. ("Pozdrevlyayu s prazdnikom Rozhdestva s Novim Godom," Mr. Wiener!) In the lore of Chanukah, Judah and the Maccabees were also no strangers to the brutal realpolitik of contested property rights, intellectual or otherwise. Tovarishch Wiener wrapped his gift in colorful taunts to the Borg at RSA; tacked on an utterly unsupported claim that the SecurID hash is "easily breakable" or reversible (which might put the data assets of some five million current SecurID token-holders at risk)... and added a playful suggestion that RSA should turn to Russian programmers (or, at least, hackers who know how to use Russian email relays) for more efficient code. Yikes, the joy of Geeks bearing gifts;-) Bugtraq's publication of the alleged SecurID hash tossed a little mud in the eye of RSA, the most prominent crypto vendor. It again highlighted the fact that actors on the global Internet can easily escape local accountability. Yet, withal, it seemed like a relatively harmless (and widely expected) revelation of the old algorithm used in the SecurID -- itself an old (time-tested and widely-trusted;-) security gadget that has dominated its market niche for a decade and a half. None of the more than 12,000 ACE/SecurID installations was placed at risk. The SecurID hash -- designed in 1985 by John Brainard, still at RSA Labs -- has been used, unchanged, to generate PRN token-codes (aka, "one-time passwords") in all of the more than 8 million SecurID hand-held authentication devices that RSA have been sold over the past 14 years. (RSA Security, once known as Security Dynamics, bought RSA Data Security in 1996 and subsequently renamed itself. RSA is today the dominant vendor in two major InfoSec markets with its BSAFE cryptographic toolkits, and SecurID authentication tokens. With its Keon Servers, RSA now bids to be the contender in yet a third: PKI software.) On Bugtraq, SecurID-savvy engineers quickly posted comments which affirmed that Wiener's code was indeed functionally identical to the fabled, but never previously published, SecurID hash. Fed proper data -- a 64-bit secret "seed" (usually shared by only a SecurID and the ACE/Server it authenticates to) and Current Time -- Wiener's code will apparently produce the same series of time-synchronized pseudo-random token-codes that a real SecurID (configured with the same seed and proper Time) would produce. This was independently confirmed in two Security Alerts mailed out last week by the US-based System Administration, Networking, and Security (SANS) Institute. Russian hackers have built up a certain reputation since Vladimir Levin's Citibank scam netted $10M in '95, but it should be clear that reverse engineering RSA's widely-distributed binaries to snag the SecurID hash is -- on the scale of Morriarty the master criminal -- more of a sophomoric prank. Reverse engineering compiled code is tedious, but when the target is a single isolated function, it doesn't (beg pardon, I.C.) take a humongous amount of talent. To judge by the code he posted, Mr. Wiener seems to have gone about retrieving the hash the hard way: reverse-engineering a portion of the compiled code from the multi-megabyte RSA authentication server, what RSA calls the ACE/Server. (Last summer, "2600," the Hackers' Quarterly, offered to send a hot copy of the ACE/Server binaries to anyone who was willing to analyze the code for weaknesses.) Over the past dozen or so years, I presume there were a hundred curious programmers among the employees at RSA's 12,000 ACE customer installations who did the same thing. (They just didn't publish it.) In recent years -- with over half a million SecurID-emulating software apps for PCs and Palm PDAs in circulation -- others have reportedly found much easier ways to isolate and study the SecurID hash. (They didn't publish it either;-) Even in the early years -- when Brainard's hash could be found only in the epoxy-sealed SecurID hardware tokens and an ACE access-control module for mainframes and minicomputers -- I know of crypto collectors (and competitors;-) who picked the hash out of the ACE binaries. "Code similar to this has been quietly available for quite some time," noted Adam Shostack <adam () homeport org> on Bugtraq. Shostack -- who in 1996 wrote a notable critique of an early (v.1.2) version of the ACE client/server protocol, and founded SDAdmin, a mailing list which focused on RSA's ACE authentication issues -- said he had been anonymously sent a copy of the SecurID hash in '96... with an explicit request that he not publish it. In 1996, for the first time, RSA had expanded its product line beyond hardware SecurID tokens to offer token-emulation software clients (then called "soft tokens," in the confusing idiom of the industry) for PCs. RSA -- which for years had preached a Gospel of a personal, physical, hand-held authenticator; paired with a PIN for "strong" two-factor authentication -- entered that market reluctantly, two years after SafeWord and DigiPass, and only at the insistent request of several large customers. Selling the ACE infrastructure (with PC client software to emulate the hardware SecurID), RSA hoped to bring stronger-than-password authentication to a huge new population of prospective customers which could not find the budget for hardware tokens. RSA recognized, however, that it could move into this new market only by accepting some significant new risk exposures. RSA's product planners were preoccupied with the array of new vulnerabilities their authentication service would confront in PCs with no protected memory -- but they were also very aware that putting tens of thousands of copies of the SecurID hash in circulation in PC software was going to make the Brainard hash vastly more accessible to any programmer who could get a copy of the "SoftID" client. As I explained in the SecurID FAQ I wrote for RSA in '96: .> No token-emulation software can ultimately resist being copied or .> counterfeited. While the secret key or seed can be protected .> cryptographically, when a program is executed in a PC it is in the .> clear and "readable" to other internal processes within the computer .> which hosts it. Various technical defenses can make this more .> difficult, but with sufficient time, skill, and special knowledge any .> program can be copied. In early 1999, the barriers were lowered yet again. In April, '99, RSA began distributing free SecurID (token-emulation) application code for the Palm OS PDAs from its website. Inevitably, due to constraints inherent in the Palm development platform, that 40K SecurID code module -- which obviously included the Brainard hash -- was less copy resistant, and generally more accessible, to a much larger community of users, crypto hobbyists, PDA enthusiasts. To any Palm hacker with the skill, curiosity, and patience to pick apart the X86 binaries. RSA's successively broader distribution schemes inevitably placed the SecurID hash in ever greater risk of revelation. The exposure grew from binary code of the multi-megabyte ACE/Server in the hands of professionals; to "SoftIDs" for PCs distributed to thousands of corporate employees; to the tiny SecurID app for Palm Platforms, freely available for anyone to download from the RSA website (and designed so that the application itself -- in demo mode; but crypto, GUI, and all! -- could be "beamed" from Palm to Palm via IR). I don't think RSA was ever blind to this dynamic. As I saw it from the sidelines, RSA simply ranked its priorities. The company labelled customer security and new sales as its primary concerns, then tried to manage the risks associated with its expanded marketing initiatives as conservatively as it could. It was considered practical and reasonable to trade off, successively, the more robust layers of technical protection around the Brainard algorithm for greater market penetration. The exposure of the SecurID hash was simply never seen as a security risk, or something that could undermine or weaken the ACE/SecurID scheme. There was a historic corporate promise not to publish, and there was a routine effort to safeguard company-confidential information -- but since exposure of the hash was expected to have no meaningful impact on ACE security, there was no bunker mentality. No paranoia. A month ago, on the Firewall Wizards' mailing list, Michael H. Warfield <mhw () wittsend com> expressed surprised when he learned that the SecurID hash was still "unpublished." > Was my > understanding, from the same source that I got my SecureID app for > my palm pilot, that the same process that had led to that > application being available on the Palm Pilot had resulted in the > algorithm being known. Cryptographer David Wagner <daw () mozart cs berkeley edu> replied: | I believe the algorithm has been known to some subset of "hackers" for | some time. However, I don't know of too many "good guys" who have had | a chance to look at it (which presumably means that RSA is not able to | benefit from analysis from the open cryptographic community). | | This suggests that keeping the algorithm secret may not have served its | intended purpose. But then, secret design rarely does, when you are | talking about long-term widely-deployed commercial systems... For some, the problem with the historic secrecy of the SecurID hash has always been the question of Epistemology: the proper way to discover and validate truth, sufficiency, trust, and integrity in cryptography. Modern commercial cryptography today depends upon academic cryptanalysis to validate the integrity and probable "strength" of a cryptosystem. Open publication and review are integral to this process. For at least four years, RSA has been committed to open publication of the crypto to be used in a new version of the SecurID for the new millennium, a token with a 128-bit secret, and the planned upgrade of the ACE client/server protocol. In public presentations on the future of ACE/SecurID at the 1996 DIMACS Workshop on Network Threats, and the 1997 RSA Conference, RSA Labs' principal engineer John Brainard committed the future of ACE to open review. "The new protocol will be based on published algorithms and standards, and will, as you recommend, be made available for peer review," wrote Brainard in '96 to Shostack, founder of the SDAdmin mailing list. See: <http://www.homeport.org/~adam/brainard.html> The SecurID first came to market in an earlier era, when the credibility of a cryptosystem was established not by "open review" but -- particularly in the financial industries and among US DoD contractors -- by government evaluations and formal certification systems. The SecurID hand-held authenticator was certified and first placed on the NSA/NIST "Evaluated Products" list -- approved for US government use and recommended as cryptographically sound to industry -- on March 31, 1987. Since then, it has undergone periodic reviews; the SecurID is still widely used within sensitive US installations. The SecurID hash has been an unpublished RSA trade secret for all these years *not* because RSA felt the need to protect it from critical review and cryptanalysis, but because -- when RSA (then Security Dynamics) first brought the SecurID to market in 1987, the first customers for ACE/SecurID were banks and other financial institutions which insisted that the hash be kept secret. RSA -- giving its customers what they wanted -- made a commitment that it would not publish the algorithm. There was, of course, virtually no independent academic crypto community to offer "open review" or free cryptanalysis until well into the 1990s. What there was did not have much credibility with corporate purchasing agents. (Citing a government imprimatur is also an effective way to sidestep responsibility or liability concerns about any potential flaw in crypto -- an exotic tech few can effectively evaluate -- while exercising proper due diligence. The traditional system -- and its echoes in the standardization process -- has its obvious benefits, hence the acclaim for DES and the AES.) (The NSA, which controlled the most important certification systems in the US [as well as the crucial export-control regime], also liked the fact that the hash was not published -- although, frankly, that was probably generic NSA policy, rather than concern about this particular cryptographic hash. It has been suggested, however, that the secrecy of the SecurID hash was a factor in getting a "blanket" export approval for "authentication only" crypto tech in the early 1990s. For multinationals which wanted to use token-based authentication, that was a big win.) Ironically, over the past decade, RSA has itself been a leading corporate activist in the campaign to displace -- or at least, in the US, expand and complement -- the old government-dependent certification system with a new convention of publication and "open review" of proposed cryptosystems by academic, corporate, and independent cryptographers. (Professional cryptographers still get commissioned to do intensive reviews -- some estimate that there are only a few of hundred cryptographers capable of a full cryptanalytic analysis of any particular cipher or hash -- but publication opens the system up, counters untoward government bias, and invites young, unrecognized, but capable mathematicians and crypto technicians to take a shot.) In the early 1990s, when NSA officials crushed -- in the name of US "national security" -- private-sector efforts to standardize strong and effective crypto for key exchange and digital signatures in the American National Standards Organization and the American Bankers' Association's X9 committees, RSA led an independent multi-vendor effort to define and specify the seminal Public Key Cryptography Standards (PKCS) -- inarguably the most influential "private" standardization effort in modern cryptography. (See: <http://www.rsasecurity.com/rsalabs/pkcs/>) Since 1991, RSA's Crypto Challenge contests have sought to establish and define the work needed -- with the best "known" attacks -- to factor (RSA) public key crypto, with various size keys; and to brute-force crack symmetric cryptosystems of given key-lengths. These contests have, by any account, added enormous credibility to the "open review" paradigm in commercial cryptography and US public policy. Notably, the 1997 RSA Crypto Challenge which led to Ian Goldberg's 3.5 hour successful brute-force attack on 40-bit "export grade" crypto, and RSA's DES Challenge-II contest in '99 -- which led to the 56-hour EFF crack of the (56-bit) DES -- were momentous events, with profound political, legal, cultural, and technical ramifications. It was probably left mostly to crypto cognoscenti to appreciate how the publication of the SecurID hash limned the ironies and incongruities which inevitably haunt Commercial Crypto 2K -- an industrial technology only just emerging from government control, and the spook-sponsored "certification culture" associated with it. At least in the West. Russians like Mr. Wiener still need a FAPSI/KGB license to encrypt. Mr. Wiener claimed a Scriptural motivation for his decision to publish RSA's trade secret, the SecurID hash. Paraphrasing Kerchkoff's Principle -- the baseline assumption in all formal evaluations of a cipher's "strength" and trustworthiness for over a century -- Wiener quoted: > Once again, security of the cipher should be based entirely on the > secrecy of the key, not the algorithm. Kerchkoff's Principle codifies the practical reality that secrets which are stable, persistent, and ubiquitous are so difficult to keep confidential that sensible men prefer not to rely upon our ability to do so. "In modern cryptography, where complexity is cheap, we trade off complexity against secrecy," explained William Hugh Murray of Deloitte & Touche <whmurray () optonline net>. "That is to say, we make the mechanism sufficiently complex that the cheapest form of attack is an exhaustive attack against the key and, therefore, knowledge of the algorithm does not (further) reduce the cost of attack. "That is not to say if one could keep such a secret that security would not be enhanced," added Murray, noting an ongoing debate over the use of multiple layered ciphers, to make it more difficult for an adversary to know which of multiple ciphers were used to create a ciphertext. "Until recently, the [US] government insisted upon using only secret algorithms, regardless of their complexity," he pointed out. "Kerchkoff's Principle notwithstanding, they realize that anything of which the adversary is ignorant may raise his cost of attack." Now, suppose RSA's early ACE customers were able to gain (say from a NSA review of the SecurID for the US "Evaluated Products" list;-) assurance that the SecurID hash was sufficiently complex to deter anything less than a brute force attack. Does it seem unreasonable for the managers of those ACE sites to conclude that they would gain some additional security --call it insurance -- by requiring RSA to keep secret whatever need not be disclosed? Anyone who knows anything about the culture of corporate security -- physical security, "InfoSec," "CompSec," "ComSec" -- would not be surprised. To a security professional, hiding whatever need not be disclosed is second nature, an occupational habit. (Very few corporate purchasers of security products -- firewalls, authentication tokens, intrusion detection systems, etc. -- permit their vendors to publicly announce a purchase or installation, for example.) In the traditional and heavily-regulated bank and finance industries, the presumption of all security is reinforced by secrecy has multiple vectors. While the contemporary community of private-sector and academic crypto professionals would likely echo Mr. Wagner -- and many have pressed for the publication of the SecurID hash over the years -- it is perhaps telling that I have never heard of a corporate ACE/SecurID customer which demanded (or even asked;-) that RSA publish the SecurID hash. The market, clearly, had other channels by which it gained and built trust in the integrity and cryptographic credibility of this particular product. The SecurID did not become, among corporate network managers, what one SANS survey described as the most widely recommended mechanism <http://www.sans.org/newlook/publications/powertools.htm> for enhancing the security of new networks, solely by virtue of RSA's stellar salesmanship;-) Network security managers are all born in Missouri. Nevertheless, it does seem likely that the SecurID hash will now get the sort of "open review" that many crypto scholars, cypherpunks, and independent crypto activists have, for years, urged all corporate buyers to demand of all vendors of commercial cryptography. I don't think the scrutiny, per se, will trouble RSA;-) It would be rash for anyone to assume that just because the SecurID has historically been proprietary and unpublished, it has not been the subject of extensive and deeply intensive study by a large number of independent professional cryptographers. (Some of whom, doubtless, would have loved to count coup by finding a flaw in a RSA cryptosystem.) Over the past 14 years, hundreds of the world's most capable crypto and protocol analysts have had direct access (under NDA) to the SecurID hash and the ACE source code -- for customer pre-purchase evaluations, and in various government certification and evaluation programs (in the US and several other countries.) Each of those evaluations used the Kerchkoff base-line. Analysts always presume that all adversaries have full access to the SecurID hash and the ACE protocol -- full access to everything except the 64-bit seed, the SecurID's "shared secret." Brainard's SecurID hash is an "irreversible one-way function" which takes as input a true-random 64-bit token-specific "secret seed," places it head-to-toe with a 24-bit representation of Current Time, and processes the concatenated input to generate a continuous series of 6-8 digit SecurID token-codes. In the SecurID's trademark rhythm, each PRN token-code is displayed in an LCD on the face of the token for 60 seconds, whereupon it rolls over to display another. [RSA's authentication engine, the ACE/Server, can validate the identity of any token-holder registered to it because (knowing the "shared secret" and CurrentTime) it can calculate what token-code each SecurID is displaying, at any given moment. In practice, and fundamental to the SecurID design, the ACE/Server *always* requires a "two-factor" authentication: the SecurID token-code, and a user-memorized PIN or password.] RSA customers and serious potential customers have always been able to arrange for their chosen crypto experts to study the source code and the design of the SecurID hash under NDA. RSA has, I believe, also been willing to assist independent reviewers by providing access to cryptanalytic studies of the strength of the SecurID hash which RSA itself has commissioned from leading independent cryptographers in the US and elsewhere. (MIT Prof. Ronald Rivest -- the "R" in RSA; and author of MD2, MD4, and MD5; as well as RC2, RC4, RC5, and RC6 -- has also studied the Brainard hash. His conclusions about it have been known to have also reassured some prospective RSA customers.) Adam Shostack, now Director of Technology at ZKS, has for years been an outspoken advocate of the publication of the SecurID hash for open review. (Ironically, Mr. Shostack's employer when he started the SDAdmin mailing list in mid-90s was a financial services firm which, by my recollection, was among the companies which had earlier insisted that the SecurID hash not be published.) Mr. Shostack responded to the Bugtraq publication of the Wiener code with a jubilant check-list of cryptanalytic basics which implied, it seemed to me, that the SecurID had come to dominate its marketplace without serious cryptanalytic review by anyone: > Now that its publicly available, some smart cryptanalyst can easily > test the assertion that the numbers displayed on the face of the card > do not reveal enough information to determine the card secret. > (John Brainard made this assertion at the [1996] DIMACs Network > Threats workshop, and Steve Bellovin [who led the ATT Research team > which evaluated ACE/SecurID before ATT purchased and installed the > system] said that he'd looked at the issue as well.) > > There are lots of sub-questions here: Do the digits displayed leak > information about the cycle, how long are the cycles, are all cycles > of equal length? I postulate that it is widely accepted -- at least among RSA's ACE/SecurID customers -- that this particular unpublished algorithm has already survived far more demanding reviews (by skilled corporate cryptographers, as well as spooky government analysts) than many -- even, almost all -- "open source" or published cryptosystems. That, of course, is no guarantee that it is perfect <sigh>, but open source or published crypto doesn't come with any guarantees either. With crypto, especially, what counts is *who* does the evaluation -- not how long the code has been sitting in some freeware repository. (It is also justifiable to caution that when a flaw is discovered in modern commercial crypto, it is almost always a problem in the implementation -- rather than a problem with the algorithm, per se.) SANS' two most popular Alert summaries -- SANS' monthly report on Windows Security issues; and the Security Alert Consensus, a weekly summary of all security alerts for network security mavens (jointly published by SANS and Network Computing Mag) -- both used the publication of Mr. Wiener's SecurID token emulator, and the revelation of the SecurID hash, to lead their year-end-2000 editions: <http://archives.neohapsis.com/archives/sans/current/0123.html> and <http://archives.neohapsis.com/archives/sans/current/0122.html>. The headline in the SANS Windows Security Digest (v.3.12) was a bit hysterical -- "RSA SecurID Token is Crackable" -- but the text, thankfully, pulled up well short of that conclusion: "As of this writing, it appears that observation of the numbers on the token is not enough, however, to determine the card secret." Explained the SANS WinSec Editor: /> I.C. Wiener released sample code showing how to generate SecurID /> token responses without having the physical token. According to the /> advisory, the algorithm is easily breakable if one has access to the ASC /> files used to initialize the tokens. This is a weird analysis. I'm not sure if the author understood ACE technology; or even realized that RSA sells both SecurID hardware tokens and software apps which emulate SecurID tokens. With SecurID physical tokens, the tokens are initialized and sealed at the end of the manufacturing process, while still within RSA, and not at the customer site. When SecurID tokens are shipped to a customer -- already clicking along at a token-code a minute -- RSA also sends an ASCII file of the 64-bit true-random SecurID "seeds," indexed by serial number, which correspond to the keys embedded in that batch of tokens. (The local ACE Administrator loads the obfuscated seeds or ASCII "key file" into the ACE/Server as the first step in assigning SecurID tokens to individual employees.) Obviously, if you've got access and the key, any lock can be opened. The guy with the key doesn't have to "break" anything. It is bizarre to say that someone who obtains both the SecurID hash and the secret seeds (for some installation's set of SecurIDs) can "break" the algorithm. The purpose of cryptanalyzing or attempting to "break" the PRN output of this or any other "keyed hash" is to obtain the secret key or seed. With both the algorithm and key file in hand, of course, a bad guy could presumably get the proper time configuration data and use one of the 64-bit SecurID seeds to generate an apparently valid series of token-codes for a particular SecurID. (Unless he had totally corrupted an installation's ACE/Server and had access to its secured files, however, the attacker still would not know to whom a particular SecurID token had been assigned. Nor would he know which PIN that particular user had selected to reinforce his SecurID token-code.) Needless to say, the SecurID seed files are typically handled like crown jewels -- at RSA; while they are in transit, under the care of a bonded courier; and (hopefully) at the customer site. /> [Bugtraq's publication of the SecurID hash] is interesting /> because RSA has claimed that part of the security of SecurID is the /> security of the algorithm it uses. Now that this algorithm has been /> duplicated, the security of the token is based only on the token /> initializer and the PIN used to access the system protected by the /> token. Unfortunately, this SANS WinSec report is inaccurate and may have confused many readers. In fact, RSA has *never* claimed that the security, or the integrity, or the trustworthiness of its ACE/SecurID authentication was in any way dependant upon the secrecy of the Brainard hash. To the contrary, RSA -- in a hundred interviews, FAQs, articles, newsletters, white papers, and online posts by RSA executives and RSA evangelists (including me;-) -- has explained that the secrecy of the SecurID hash was simply a market requirement (something demanded by many of RSA's major customers in the 1980s and early '90s). They bluntly declared, repeatedly, that the secrecy of the SecurID hash is not, never was, never could be, and never should be, in any way "essential" to the security architecture of a SecurID, or to ACE Authentication. In the 1996 SecurID FAQ, I tried to stress this fact. Here's how I described the logical attributes of a SecurID token-code: .> As the product of a cryptographically solid one-way function, the .> integrity of the token-code (its ability to defy cryptanalysis and .> efforts to identify the token's secret-key) does not depend upon the .> secrecy of the cryptographic algorithm. .> .> It is unpredictable. This means it is computationally infeasible to .> predict the next token-code or future token-codes in the series .> (even given a list of prior token-codes and the hash algorithm which .> produced them all.) This is why the SecurID token-code is called a .> pseudo-random number or "PRN." There is no apparent relationship .> among the numbers, or within a series of SecurID token-codes. .> .> It is the product of an cryptographic hash algorithm sufficiently .> complex and destructive (e.g. discarding digits at various stages of .> the calculation) so as to make it impossible to "reverse engineer" .> the hash and determine the original input values from the PRN .> results, even if one knows or is able to estimate one of the input .> values (e.g., Current Time). Bemused industry commentators typically labelled the publication of the SecurID hash "interesting," then sat back to await further developments. There remains, always, the possibility that the SecurID hash might crumble in the sunlight of open publication and the rigors of public review. Comp128, CMEA, ORYX, the Firewire cipher, the DVD cipher, and the Netscape PRNG were all cracked within months of each being subject to "unauthorized publication." OTOH, RSA is probably the brand-name corporate poster child among US firms which have lost control of valuable intellectual property -- in RSA's case, crypto -- through its publication by anonymous or pseudonymous actors on the Net. Famously, in 1994, someone reverse-engineered RSA's BSAFE code to post Rivest's RC4 cipher (then an RSA-proprietary trade secret) to the Net. Again, in 1996, someone reverse-engineered Rivest's RC2 (another RSA-proprietary trade secret) to post the algorithm to sci.crypt. Of course, RC4, and to a lesser extent, RC2, remain mainstays of secure communications on the Net, in SSL/TLS and S/MIME, among other secure protocols. Their mid-90s publication was, it seemed clear at the time, largely intended to enable non-US developers to offer strong-crypto products which could interoperate with SSL cryptosuites -- without a license from RSA, but also (in what was probably more crucial to those who celebrated the revelations) without obtaining a US government permit for the export of strong cryptography. Arguably, the illicit publication of RC4 and the subsequent development of SSLeay in Australia snapped the US Government's control over who could obtain or use strong cryptography on the commercial web. Some might say those events dramatically changed the world, certainly e-commerce at the <blush> dawn of the 21st Century. No one is making any such claims about the publication of John Brainard's 15 year-old SecurID hash, Grand Old Dame of InfoSec that she is. Suerte, _Vin PS. Needless to say, I am a biased observer of these events. I have been a consultant to RSA, and SDTI before it, since before the SecurID first came to market, and a paladin for tokens even earlier. I also apologize to the Listocracy for the length of this holiday post. Blessing of the Magi on all! ------ "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 + <vin () shore net> -------------------
Current thread:
- Re: SecurID Token Emulator Vin McLellan (Jan 08)