Re: traffic analysis of phone calls?
Personal (Use it if you'd like, but keep me out of it.) Steve Bellovin wrote: Slightly off-topic, but a reminder of the sort of thing that ordinary crypto doesn't hide. http://www.silicon.com/news/59-51/1/5093.html?rolling=2 IT Myths: Colombian drugs gang's mainframe-assisted assassinations? Reminds me of a Supercomputer system admin I ran across in California in the mid-1980s -- a part time Deputy Sheriff -- who (at the request of a California state LEA, and with the approval of his boss) was banging away at the DES-encrypted records of a guy, alleged to be a bookkeeper or financial analyst for a Columbia drug cartel, who had been arrested in California. The story he told me was that the Deputy had been asked to try to brute-force the encryption on the file after the NSA and DEA had refused to attempt it. Using free cycles on his corporate machine, he was into the project for a couple of months when a guy from the NSA showed up and convinced his boss that his effort was counterproductive to national security -- apparently because it threatened the reputation of DES. At the time, I was more impressed that the Columbian was using a PC crypto package that apparently did not have an operational weaknesses that was then common in almost all commercial encryption packages for PCs. Hope all is well for you and yours. _Vin - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Code breakers crack GSM cellphone encryption
At 05:04 PM 9/8/03 , Trei, Peter wrote: Why the heck would a government agency have to break the GSM encryption at all? The encryption is only on the airlink, and all GSM calls travel through the POTS land line system in the clear, where they are subject to warranted wiretaps. A government agency would be interested in breaking GSM crypto when it wants to target a phone call which is going through a switch and local wires that are under the control of another nation, or perhaps where it does not wish to go through whatever process might be required to gain legitimate or warranted access to the call's content. A5/2 was the equivalent of 40-bit DES, presumed to be relatively weak and developed as an export standard. I always thought that the important fact about the GSM secure crypto protocol, A5/1, was that it was reportedly chosen and adapted for this function by the (never identified) members of the GSM SAGE committee of European experts, a multi-national group of industrial and government representatives. I always presumed the SAGE group had a common interest in unwarranted access -- to (A5/1-secured) calls in Europe, as well as (A5/2) calls elsewhere -- which, for the various national security agencies involved, outweighed their individual interest in providing security to their respective citizenry. As I recall, COMP128 came from German sources, and A5/1 was adapted from a French naval cipher. Breaking GSM is only of useful if you have no access to the landline portion of the system. That's right, of course. Crypto aside, I was wondered if it might be somehow easier (legally, technically, procedurally) to attack the radio link of a roving GSM call -- even given the rapid pace of hand-off from one tower to another, as a mobile caller rapidly passes through several small microcell territories -- than would be to recover that call by tracking it through a large number of successive connections to the land-line telecom GSM switches. A friend was telling me that he switches from one microcell to another every couple hundred yards in some communities. Anyone know? Suerte, _Vin - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES suitable for protecting Top Secret information
I missed that announcement too -- but Wikipedia, the web-based Free Encyclopedia, caught it! See Wikipedia on AES at: http://en.wikipedia.org/wiki/AES The Wikipedia module on AES Security has a link to the same NSA fact sheet Steve mentioned. I was surprised. I thought, as in so many other things, the NSA was going to say one thing and do another. Suerte, _Vin At 4/14/2004, Steve Bellovin wrote: I haven't seen this mentioned on the list, so I thought I'd toss it out. According to http://www.nstissc.gov/Assets/pdf/fact%20sheet.pdf , AES is acceptable for protecting Top Secret data. Here's the crucial sentence: The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information will require use of either the 192 or 256 key lengths. --- Vin McLellan + The Privacy Guild + [EMAIL PROTECTED] 22 Beacon St., Chelsea, MA 02150-2672 USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ECC Wit and Wisdom (Fwd)
Pithy wit and wisdom from New Zealand. lol. _Vin -Original Message- From: Peter Gutmann [EMAIL PROTECTED] Sent: Thursday, 23 March 2006 12:41 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Cfrg] Defining inter operable ECC keys in for IETF protocols Blumenthal, Uri [EMAIL PROTECTED] writes: I would MUCH prefer ECC - but my lawyers (yuk!) are telling me that there are licensing problems, and supposed NSA contacts don't call them back. Anybody knows anything useful about licensing of ECC GF(p), that he can share with me? Certicom have done such a good job of creating FUD about ECC legal issues that, unless you're a Certicom licensee, it's easier to not use it at all. So far every time I've been asked about ECC support (which admittedly is once a blue moon anyway), I've asked the organisation who want it to come back to me with either proof of a Certicom license or a clear statement of which non- infringing mechanisms they want me to implement. In every case, after looking at what's involved, they've decided they didn't need ECC that much anyway. It's like the conclusion from Wargames, the only way to win is not to play. Peter. ___ Cfrg mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/cfrg - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Deciphering Incan khipu
Boston Globe reporter Gareth Cook [EMAIL PROTECTED] was awarded the 2005 Pulitzer Prize for Explanatory Journalism for explaining, with clarity and humanity, the complex scientific and ethical dimensions of stem cell research. He's an unusually talented writer. _Vin R. Hirschfeld [EMAIL PROTECTED] quoted Gareth Cook, who wrote: snip I am wondering if you know anyone who might be able to help me with this I wrote a while ago about a fascinating project focused on deciphering the Incan khipu (see below). The basic idea is that they are collections of knots used in the Incan empire to record information. It is known that some of them contain numbers, perhaps recording census data or tax information for the empire. But some believe that the knots records language -- perhaps histories or other narratives. Cracking this code would be hugely important, not to mention interesting, because it would open up the still very mysterious Incan empire the same way that ancient Egypt has been opened up. All this is a rather long-winded prelude to my question, which is whether there are people out there who are working on computational techniques to decipher ancient scripts, not necessarily the khipu problem. I am thinking of doing a story on this. Any thoughts or leads at all would be most appreciated. It would even be a help to talk to someone who has done cryptography who could explain how the ancient scripts problem would be similar to, and different from, the problem of cracking a present-day encryption scheme. Let me know if you have any thoughts. Best, Gareth SCHOLAR SEES STRANDS OF ANCIENT SECRETS Author: By Gareth Cook, Boston Globe Date: 07/04/2003 CAMBRIDGE - For centuries, the mighty Incan empire has confounded researchers. The Incas controlled territory up and down the spine of South America, with a sophisticated system of tributes and distribution that kept millions fed through the seasons. They built irrigation systems and stone temples in the clouds. And yet they had no writing. For scholars, this has been like trying to imagine how the Romans could have administered their vast empire without written Latin. Now, after more than a decade of fieldwork and research, a professor at Harvard University believes he has uncovered a language of binary code recorded in knotted strings - a writing system unlike virtually any other. The strings are found on khipus, ancient Incan objects that look something like mops. About 600 khipus (also spelled quipu) survive in museums and private collections, and archeologists have long known that the elaborately knotted strings of some khipus recorded numbers like an abacus. Harvard's Gary Urton said the khipus contain a wealth of overlooked information hidden in their construction details, like the way the knots are tied - and that these could be the building blocks of a lost writing system which records the history, myths, and poetry of the Incas. The theory has Incan scholars abuzz. The discovery of true Incan writing would revolutionize their field the same way that deciphering the Egyptian hieroglyphics or Mayan glyphs lifted a veil from those civilizations. But it also has broader interest because the khipus could constitute what is, to Western eyes, a very unorthodox writing system, using knots and strings in three dimensions instead of markings on a flat expanse of paper, clay, or stone. What makes this work so interesting is that what is being expressed is being conceptualized in such a different way than we conceptualize, said Sabine MacCormack, a historian of the Romans and the Incas who is a professor at the University of Notre Dame. This is about an expression of the human mind, the likes of which we don't have elsewhere. The only way to prove Urton's theory correct would be to translate the khipus, which no one has yet done. In his new book, he proposes a new method for transcribing the knotted strings which he believes could lead to breakthroughs. And his work, funded in part by a genius grant from the MacArthur Foundation, has helped fuel a resurgence of scholarly interest in khipus. Later this month, the Chilean Museum of Pre-Columbian Art in Santiago is opening the world's first exhibit dedicated to the khipu. We are on the cusp of a very hot period, said Frank Salomon, a professor of anthropology at the University of Wisconsin who has studied khipus extensively. The khipu mystery dates to the early 16th century, when the Incas were conquered by Francisco Pizarro and the Spanish set about destroying their culture. The missionaries sent to South America tried to eliminate all touches of the old gods, including the strange stringed textiles that the Incas said held their histories. The Spanish chroniclers often exaggerated, but they did record histories of tributes and other stories they said were read to them
Re: RSA SecurID SID800 Token vulnerable by design
On Cryptography, and in several other online forums, Hadmut Danisch [EMAIL PROTECTED], a respected German information security analyst, recently published a harsh critique of one optional feature in the SID800, one of the newest of the six SecurID authentication tokens -- some with slightly different form-factors, others with additional security functions -- sold by RSA. It's raised quite a stir, and I'd like to respond. A personal authentication token, by classical definition, must be physical, personal, and difficult to counterfeit. The most popular implementations in computer security move the calculation of a pseudo-random authentication code -- a so-called One-Time Password, or OTP-- off an employee's PC and into a hand-held hardware fob, small enough to be attached to a personal key chain. RSA's mainstay token, the SID700 SecurID -- millions of which are used in over 20,000 enterprise installations worldwide, including many government agencies and financial institutions -- use AES (the US cryptographic standard) to process Current Time and a 128-bit token-specific secret to generate and continuously display a series of 6-8 digit (or alphanumeric) OTP token-codes which change every 60-seconds, and remain valid only for a couple of minutes. In practice, a RSA authentication server can then independently calculate the token-code that is appearing on a specific SecurID at this particular moment; compare that against an OTP submitted by a pre-registered user, and validate a match. RSA, which first introduced the SecurID in 1987, has always insisted on the necessity of two-factor authentication (2FA), where a remote RSA authentication server must validate both a SecurID token-code (evidence of something held) and a user-memorized PIN or password (something known.) A stolen password can be reused indefinitely to masquerade as the legitimate user, often with the victim wholly unaware. A token-generated OTP, valid only briefly, is a far more robust authenticator. With 2FA, if a SecurID is stolen or lost, it still can't be used to obtain illicit access to protected resources without the second secret: the user's memorized PIN or password. The elegant simplicity of the traditional SecurID -- and patents on the mechanism by which the drift in each individual SecurID's internal clock is tracked by the RSA authentication server -- has allowed RSA's time-synched SecurID to dominate the market niche for hand-held OTP authentication devices for 20 years. In a typical installation, anyone seeking to log on to a protected PC or network, or to access restricted online resources, must manually type in the OTP currently displayed on the SecurID -- as well as his memorized PIN or password -- to have his identity and access privileges validated. Network applications handle the combined SecurID pass-code like any long traditional password. The link between the user and the RSA infrastructure is often, but not always, an encrypted VPN channel. That's a local decision. Data exchanges between the RSA agent and RSA authentication server -- which typically means between one of the 350-odd SecurID-aware network applications and the RSA Authentication Manager, using RSA's own protocol -- are always fully encrypted. Mr. Danisch is an admirer of the classic SecurID (SID700), RSA's traditional hand-held token. His ire is directed at one of the two new hybrid SecurID designs that RSA has recently offered in an attempt to respond to new requirements in the boisterous and rapidly-evolving market for what's called strong authentication. With the nascent prospect of a new billion-dollar market in consumer authentication for financial services boosted by US federal regulatory initiatives, RSA announced the SecurID Signing Token, the SID900. The SecurID Signing Token still has a time-synched OTP, but RSA added a keypad and a challenge/response function which successively authenticates the user, the remote server, and a specific financial transaction, before the transaction (e.g., a funds transfer) is executed. On the other side of the market -- where again US laws and federal regulatory initiatives have boosted demand for internal controls and more accountability measures in enterprise IT -- RSA has introduced the SID800, another hybrid SecurID, to meet the requirements of organizations that want to move into a full public key infrastructure (PKI.) The SID800 SecurID is a multi-function authentication and cryptographic device that combines, in a single DPA-resistant token, the mobility and availability of the classic hand-held SecurID, as well as a smart chip that implements v2.1.1 Java tech (essentially a virtual smart card) in a USB format. It looks like a slightly smaller version of the classic SecurID key fob, with a USB plug jutting out at one end. It can carry up to seven X.509 digital certificates for PKI, as well as account information and
Re: debunking snake oil
I apologize for misstating your name, Mr. Simon. I thought I had answered your question. No one asked me to reply to Ruptor, or to you -- and you chose the tone of this exchange. As I said, I would be shocked if anyone at RSA or EMC even knows about this discussion. No one tells me what to post, or when to post. I've been doing this for a long time, and while I have to honor common-sense guidelines about secrets and upcoming products, I operate pretty independently when it comes to what I publish on the Net. My words are my own -- but when it is on-topic, I try to offer RSA's perspective, if I know it, along with the facts, as I know them. Personally, I think discussions here, and elsewhere online, would be a lot more constructive if vendors did not shun the Net's open forums. I'm grateful that RSA gives me leave to talk publicly about their products and technologies. If I sound prideful in discussing those products, as Mr. Simon says, in some cases I've been working on them for decades. I rarely initiate a discussion about RSA's products or technology. As in this case, I almost always respond to questions, claims, or comments from others --- and the tone of these discussions is almost always set by others. I generally just try to be helpful and informative; relatively low-key. Given my history, of course, it is also true that the product managers and others at RSA now expect me to contribute to any major online discussion about the RSA products. (I sometimes I decide it is counterproductive to do so.) No one at RSA told me to get into the SID800 debate, but they were certainly not surprised when I showed up to ask about it. As an internal consultant to RSA, I had some say in defining the SID800's evolving product specs. Some of what I suggested was adopted, some not. Online, I tried to talk about the goals of the SID800 product that was the result of the process, the balance it struck between security and accessibility, and offered my interpretation of how it fit within the market. Generally speaking, I don't expect to convert someone like Ruptor or Thor -- who start with a strong bias about a particular product -- so I try to address myself to the much larger community that just reads a forum like this. I don't think anyone gains points with objective observers by being nasty or arrogant; I think you gain credibility by being honestly informative and helpful. I try. Suerte, _Vin -- in response to Thor Lancelot Simon [EMAIL PROTECTED] wrote: snip I'll try again: yes, you've identified yourself as a consultant to RSA. When you have posted here, both in this most recent thread and in other threads, in particular the SecurID 800 thread, has it been at your own behest, or that of RSA? In other words, when you post here defending RSA products against criticism, often with very emphatic language and in a way that belittles the person making the criticism rather than engaging with the actual technical critique, can we assume that it is not the case that RSA asked you to do so? Or is it, in fact, sometimes the case that RSA asks you to post about their products here, and thus we should read your words as being RSA's words? snip - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
