[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Commerce Undersecretary William Reinsch defends the government’s encryption policy
I especially like the part about DEEPCRACK and how because EFF knew that the
message was in English that it doesn't really prove that the FBI can break
56bit DES encryption.
Q & A WITH WILLIAM REINSCH
Crypto’s Key Man
Commerce Undersecretary William Reinsch defends the government’s
policy—even though it puts him "in the hot seat."
BY ANDY BRINEY
Q: How would you characterize current U.S. cryptographic export policies?
A: The President has consistently articulated a policy of balance—between
privacy, electronic commerce, law
enforcement and national security. We believe all four elements are
important, and we’re trying to produce a policy
that takes all of them into account.
But is it really possible to balance all these issues at the same time?
We think so. I’m not sure the industry agrees with us, and it’s not easy.
The privacy issues involved have been
discussed for 50 years in debates about wiretaps and law enforcement devices
for intercepting phone conversations.
Encryption poses some of the same issues: privacy vs. law enforcement. The
country has come to terms with
wiretaps over the years, and people still use phones—even though, with
proper court orders, there’s the possibility
that law enforcement could be listening in. We think we’ll be able to arrive
at the same common public
understanding with encryption. But there’s no question that getting there
will be difficult.
What kind of time frame are we looking at? Is the administration looking at
releasing a "final" crypto export policy
within the next three months? Six months? A year?
The policy I articulated—one of balance—is based on implementations in the
marketplace. We expect the market to
develop the products we like, and we expect that there will be a demand for
We want to work through the market. What that means is, if the market turns
in unexpected directions, we have to
be ready to re-evaluate our policy. So I don’t think you’re going to see a
"final" version—ever. As long as the
market moves and changes, our policy will be tweaked to accommodate what’s
In the short run, however, the policy we are currently operating under
expires January 1. We’ve told industry we
expect to revisit that policy this fall, and make judgments about what’s
going to happen after January 1. So we’ve
committed to trying to come out with the next update, hopefully by Labor
Day, although my expectation is it may
take a little longer than that.
Can you be more explicit about what this policy might entail?
No. Because we’re not there yet.
What has been the industry’s reaction to current policy?
Industry has been quite active, particularly with submitting key-recovery
plans. We provide more liberalized export
controls for companies that provide plans by which they will build
key-recovery products. We’ve approved some 55
plans now—with a few more pending.
I don’t think they’re doing it just because the government asked them to;
they’re doing it because they see a market.
In addition, in the spring the FBI and the Justice Department asked
companies to come in to see if a technical
solution could be found to deal with these issues. Companies have done that,
At the same time, of all the economic sectors in the country, this one’s
moving the fastest. There’s a real danger
that, if we can’t get our policy together and out there in the marketplace
soon, we could be overtaken by events
Recently, a panel was charged with developing a Federal Information
Processing Standard (FIPS). One of this
group’s directives was to design a federal computer security system that
includes back doors—which they failed to
do. What’s next for this panel, and for this issue?
My understanding is that, at the request of a majority of the panel’s
members, the Secretary [of Commerce] has
extended their charter to the end of the year. The Secretary received a
letter from the panel in which the majority
felt they would be able to complete their work with additional time.
However, they also said they weren’t entirely
confident that at the end of the day it would be unanimous product.
Even if it were possible to do key escrow on the scale the government is
asking, would anyone willingly buy such a
product knowing that stronger encryption products without back doors are
available? To prevent this, wouldn’t it be
necessary to criminalize the domestic possession of stronger crypto?
First of all, we haven’t supported the latter. Second, I think you need to
look at this problem in pieces, not as a
unitary problem. The pieces are: stored data, data in transit (such as
e-mail) and voice communications. I would
argue that with the first two
of those pieces, there’s going to be substantial demand in the market for
the kinds of products that are helpful from
For stored data, we see a demand for key recovery—we’re not using the term
"key escrow" much anymore.
Particularly in business and financial institutions, there’s a demand for
recovery products, because people want to be
able to access employees’ data in the event of accidents or other such
As for e-mail, the most significant development there was the announcement
nine companies made in early July.
Each of these companies submitted an application for a so-called "door bell"
technology, which connotes a variety of
means of recovery at the server level.
What we see developing here is growing use of network encryption—as opposed
to encryption at the PC—for
secure transmission of messages. Employers will want that, for employee
control purposes. From the standpoint of
law enforcement, that’s a happy development, because it creates two "third
point" locations—the sender’s server
and the recipient’s server—that are physically separate from the sender and
recipient of the message. These points
are often controlled by third parties, namely contractors running the
system. So, with the proper court order, law
enforcement could go to those third points and obtain plain-text access.
What was your reaction to the Electronic Frontier Foundation’s cracking of
DES in July?
I think you have to contrast that situation, which was reasonably
artificial, with the reality of law enforcement. In
this case, it took a decent amount of resources to crack a specific message
that, I believe, the people doing the
crack knew was in English, and knew was one message.
Now, if you’re the FBI, think about that. From their standpoint, we’re
talking about traffic that isn’t so easily
identifiable. It might be a long stream of encrypted material that they’re
trying to intercept in real time; they don’t
necessarily know what language it’s in; they don’t necessarily know what
part of the message is of interest to them;
and they don’t know whether it’s words or text or graphics or what it might
be. Telling the FBI that, under those
circumstances, you can buy an expensive computer and crack one message in 56
hours—that’s not a lot of comfort
to the FBI. And it doesn’t seem to me that it should make anybody in the
private sector nervous about the security
of 56-bit products. If that’s the best we’re going to get—56 hours for a
single message decrypted by equipment
most people don’t have and aren’t ever going to have—that doesn’t exactly
mean that it’s an unsecured product.
But it does illustrate a trend. As time passes, it’s taking fewer and fewer
resources and less and less time to crack
the same algorithm. In 1997, it took three months. In February, it took 39
days. Now, it’s one $250,000 computer and
56 hours. Who’s to say in two more months it won’t be cracked in an even
shorter amount of time with even fewer
You can project that curve, and maybe you’ll be right. The immediate effect
of that is that it’s going to accelerate a
trend that’s already begun anyway, which is toward 128-bit products. I think
that’s a trend that would have occurred
regardless of this particular event.
The technical people I’ve talked to say that once you get beyond 90 or 100
bits, it doesn’t make all that much
difference because you’re talking about brute-force cracking times that are
beyond any real time that you can
imagine. Obviously, the faster you can crack 56 bits, the faster you can
crack 90 or 100. But since each successive
bit doubles your time, by the time you get to 90, I think you’re into
thousands of years...
But the question is, assuming that 90 is safe, wouldn’t it then be prudent
to have a policy that allows uniform export
of 90-bit products without special dispensation?
I don’t think we expect to set bit-length requirements. We believe in the
marketplace deciding what is secure and
what is not. The government is not going to say that 90 is good or 128 is
But right now it’s saying 56 is sufficient.
No, the government is saying that 56 can be exported under certain
circumstances. What the government has also
said is that if it’s a key-recovery product, it can be exported with any bit
length without constraint. And that’s what
we would prefer to focus on—to tell people, if you’re product has recovery
features, bit length doesn’t matter.
That’s the incentive.
What happens if a key-recovery standard cannot be agreed upon? Is there a
We are doing everything we can to encourage people to find it acceptable and
to get the market to move in that
direction. We think that’s what’s happening. So I don’t think we’ve
developed a Plan B in that sense.
Can you discuss progress on the Advanced Encryption Standard (AES)?
No. I’m not particularly involved in that. I think you need to talk to some
NIST or NSA people about that.
Q: You seem to be the government’s point man on encryption policy issues. Is
that a function of your office, your
background, or what?
A: "Designated victim" is the term we use [laughs]. Actually, it’s a
function of the office. An integral component of
our policy involves export controls, and the BXA [Bureau of Export
Administration] administers export controls of
dual-use items for the government. So I end up in the hot seat.
EDITOR’S NOTE: Next month, Bruce Schneier, author of the definitive text
Applied Cryptography, will respond to
Undersecretary Reinsch’s comments in a special Word in Edgewise article.