Re: debunking snake oil

2007-09-04 Thread Vin McLellan

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.


  -- in  response to 

Thor Lancelot Simon [EMAIL PROTECTED] wrote:

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?


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: RSA SecurID SID800 Token vulnerable by design

2006-09-14 Thread Vin McLellan

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 

Deciphering Incan khipu

2006-03-29 Thread Vin McLellan

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.


R. Hirschfeld [EMAIL PROTECTED] quoted Gareth Cook, who wrote:


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.



 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 

ECC Wit and Wisdom (Fwd)

2006-03-23 Thread Vin McLellan

Pithy wit and wisdom from New Zealand. lol.


-Original Message-
From: Peter Gutmann  [EMAIL PROTECTED]
Sent: Thursday, 23 March 2006 12:41 PM
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.


Cfrg mailing list

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: AES suitable for protecting Top Secret information

2004-04-14 Thread Vin McLellan
I missed that announcement too -- but Wikipedia, the web-based Free 
Encyclopedia, caught it!  See Wikipedia on AES at:

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.

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 ,
AES is acceptable for protecting Top Secret data.  Here's the crucial
   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]

RE: Code breakers crack GSM cellphone encryption

2003-09-08 Thread Vin McLellan
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 

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?


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: traffic analysis of phone calls?

2003-07-12 Thread Vin McLellan
(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.

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 

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.


The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]