-----BEGIN PGP SIGNED MESSAGE-----


Here are my noted and remembered impressions from Wedensday's NIS&T
conference on key escrow (aka GAK) export. Please note that there is
a separate conference next week on creating a FIPS PUB standard for
key escrow. That standard will be promulgated, just as GOSIP, POSIX
and Clipper/Skipjack were promulgated. This export conference was
separate from that FIPS standardization process.

I got stuck in a construction traffic jam, and missed the introductory
speaches. Perhaps one of the other c'punks can fill us all in on what I
missed.

The first item is that the export criteria will be changed. A small number
of bits will be added to unescrowed crypto, and 64-bit escrow'd (GAK'd)
systems will be allowed. They don't care which algorithm is used, DES, RC4,
blowfish, etc. They care about key length. If it is short enough, it is
exportable.

The conference seemed to be an attempt to co-opt industry into agreeing
that 64-bit GAK is much better than the current situation. After all,
it would be too strong for a "hacker in France" to break it.

When they opened the floor, there were a few comments/questions
that indicated that not everyone was convinced that this was a good thing.
I pointed out some graduate students don't consider "hacker" a compliment,
and that I thought Damian did a great job breaking RC4-40. I also pointed
out that it was broken again in 31 hours with a "bunch of commercial
systems, Sun and Pentiums" with no need for supercomputers.

I then asked if the criteria were fixed, as setting criteria controls the
result. The NIS&T approved board said that changes to the criteria was
part of why the conference was being held.

The next hour and a half was presentation from "industry." Essentially
comments on the proposal. Nearly all of the spokesmen said that the criteria
were flawed. Some said that they already had commercial products
that met most of the real needs of the industry (key recovery) but they
didn't meet the NIS&T/NSA "criteria." Probably the strongest was the
condamnation by Robert Holleyman of the Business Software Alliance.

Hollyman said that BSA represents firms such as Microsoft, Novell, Lotus,
Sybase, SCO, Autodesk, and Intergraph. He said that current policy "directly
threatens" the industry because of "The US Government's continuing refusal
to adopt realistic export control policies." He went on and on.
It was clear that his position is that the proposed policy is a mistake.

After the presentations, there were more questions. I proposed one
additional criteria (based on email that I received from the c'punks):
How do we expire court approved access to encrypted data, so that once the
court orders are over, the LEAs no longer have the ability to decrypt.
The answer was that with clipper, special hardware is needed, and it goes
away when the court order does. I asked how that model worked in a software
only world. There were mumbled statements about adding it as a criteria.

The conference then broke for lunch and breakout groups. The one I was in
discussed criterias 5 and 6 of Topic 3, published in my URL
http://www.isse.gmu.edu/~pfarrell/nistmeeting.html
They are short enought to reproduce here.

5.    The product shall be resistant to any alteration that would
      disable or circumvent the key escrow mechanism, to include
      being designed so that the key escrow mechanism cannot be
      disabled by a static patch, (i.e., the replacement of a
      block of code by a modified block).

6.    The product shall not decrypt messages or files encrypted
      by non-escrowed products, including products whose key
      escrow mechanisms have been altered or disabled.

After I commented that the person writing the notes has the ability to
detirmine what was said, the folks from NSA and NIS&T asked me to take
the notes. I love it; but I did try to be objective.

In the middle of this discussion, a government-generated, but anonymnous
paper was distributed. It had "Example Suggested Solutions." It suggested
that source code not be available for products suitable for export. It also
suggested other ideas, such as storing a checksum/hash and having the
system "check the cryptographic code several times during its use." There
was a strong reaction against these suggestions, not because they were
bad ideas, but because the paper was delivered with no prior publication.
This precluded any planned response to its ideas.

We reworded #5 to say "want to Trust the Product." This means that it
is untampered, works as expected, etc. We then hashed out ways to
know this. The list ended up looking like:
1. is available only as object code
2. contains some "hash" function to check for modifications
3. contains some unique hash, with uniqueness based upon something
        like "site," "per copy" or "per release"
4. Contains policies against modification, such as liscense language
        against decompilation.
5. OS-related security, such as runs "protected mode" instead of as a
        wild DOS program.

Of course, the software vendors went wild against "per copy" identifiers,
saying it would add two orders of magnitude worth of problems to
manufacturing.

The items on the list were not "must have all of these" rather it was
a pick-and-chose menu. We also required that the standard allow
for technical innovation to keep up with the evolving state of the art.

The discussion of #6 was more lively. We took a long time figuring out what
it said. For instance, could ViaCrypt sell a product that was compatible
with PGP 2.6.2 (non-escrowed) that also worked with the new escrowed
ciphers? It seems to me, and a lot of other folks there, that such a product
would be non-exportable. We simplified the criteria to:
  "right products won't talk to wrong products."
with "right products" meaning those that are exportable, and wrong products
being those that aren't, or are hacked, or ...

We then developed "goals" including:
1. One version for sale worldwide
2. Allow development in the US
3. Domestic Law Enforcement Agencies want Escrowed (I almost wrote GAK :-)
4. Must interoperate with everything
5. Receiver can only decrypt if escrow agencies can decrypt.

This leads to a bunch of issues and observations, including:
a. Can goals 1, 2, and 4 be met simultaneously?

There was a suggestion of a "friendly man-in-the-middle" who would
receive a GAK'd conversation, and strip off the GAK parts, and reencrypt
it, and retransmit it to a non-GAK user. Which leads to:
b. Can we prohibit a friendly MITM?

The big issue was:
c. Startup compatibility. No one will buy products unless they have
sales attractiveness. This means compatibility with existing systems.
Yet the criteria #6 seems to say that approved products must refuse
backwards compatibility.

This was labeled a "non starter" by the group.

The consensus was that companies can develop a substantial competitive
advantage by developing off-shore and offering both escrowed encryption
and compatibility with existing systems.

There was a discussion of grandfathering in some technologies.
This was to help interoperability. The conversation became fuzzy,
Grandfather technologies included DES, 3-DES, IDEA, and long key RC4.

One key idea was that it may make sense to allow software that encrypts with
escrowed keys, but can also decrypt with any algorithm. This allows the LEA's
to access outgoing messages, while allowing interoperability.

The discussions frequently wandered to discuss the language of the criteria.
The wording was considered simultaneously too subjective  and impractical.
For example, we considered the phrase "tamper resistant" to be preferable
to the original "prevent tampering," because it is impossible to absolutly
prevent modification to software.

The issue of interoperability was raised repeatedly.
It is critical that exportable products interoperate with other,
existing export products.

The last issue in the session was that the length of the key, 64-bits,
was defined in criteria #1. There was no discussion at the conference on
this criteria. It seems that the NIS&T and NSA folks believe that
this is a closed topic. The folks in the session did not agree. They
felt that 64-bits was not enough.

Once the breakout session was over, the entire conference met together,
and the "reporter" from each session reported their comments and findings.

All breakout sessions had suggested changes. The group that discussed
criteria #9 recommended removing it. The group that discussed criteria #2
(no multiple encryption) reported that industry was working on a general
solution to the problem of key recovery, and that their solution would
probably appear as quickly without the government's "help."

Several groups identified that there are at least two separate
problem domains: communications and data storage. Communications
typically is short term, and has unique keys for each session.
Data storage has far fewer keys that are used
for long periods. Several speakers suggested that while communications
keys were not suited to be escrowed, there was a large need for
key recovery for data storage. There was no response from the government
representatives to any of these points. One government speaker
did say that there would be a Federal key escrow standard, period.

After the combined session, there were more break-out sessions. In the one
that I attended, the folks from National Semiconductor described their
CAKE system. This is a smartcard/PCMCIA device that uses 2000+ bit
public/private key encryption and signatures. They are hoping for export
approval; it is necessary for the project to be viable.  The system looks
pretty interesting, but it too complicated to describe here. In short,
random session keys are generated and signed with a Data Recovery Center's
public key. The LEAs could then send encrypted session keys to the DRC,
which would decrypt them, and return the unencrypted session keys which
the LEA could then used to decrypt the messages.

While this is a hardware system, its concepts could be transfered to
a software implementation.

One obvious problem is that NS' system doesn't meet criteria #8 (retuiring
repeated involvement of the escrow agent), since it may require
hundreds or thousands of session key decipherments. It also has
a number of attractive features, such as never sending the private
key anywhere, only the session key is escrowed.

The general discussion showed concerns that in the international
community, requiring government escrow may cause lose of valuable data,
as some foriegn governments are not as trustworthy as the US. It was
the consensus that requiring users to have 50 or more escrow centers was
unworkable. Yet this could be required for large multinational companies
working in 50 or more countries, if each required a local key escrow service.

The NS model would allow both date stamping of session keys, and periodic
rekeying. Either would satisfy my "unaccepted" Citeria #11, technical
limits to the time that a court ordered decryption could be executed.

There was a discussion of changing the criteria so that only the transmission
of data was concerned with escrow. This would simplify the issue of
multinational escrow. We did not resolve whether this would be sufficient
or acceptable.

Today, we will talk about suitable escrow agencies.

Pat


-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBME7WOLCsmOInW9opAQHbawP+PSC+9p7ll7yKTiwnkzrIf+aT/ZfuoCqj
Fp6ZhykIoJQVF5YAEhz9O1t9FKOauo3baMDhaIvU4pUSm2b/hKlUFB8cwYr7KTjd
MFGxTOG/D7blGuX6ZXbHlS5EkKeT1pDtfrd9GlnTKWHxfga/51ROWCG/33BWZxHR
lyNLI07UPbo=
=kFkC
-----END PGP SIGNATURE-----



-----BEGIN PGP SIGNED MESSAGE-----

Date: Fri, 8 Sep 1995 09:32:43 -0400 (EDT)
From: "Pat Farrell" <pfarrell@127.0.0.1>
To: cypherpunks@toad.com
Cc:
BCc:
Subject: Day 2 NIST meeting notes
X-NUPop-Charset: IBM 8-Bit


Thursday's GAK Export meeting started with reports from the prior
afternoon's breakout meetings. I reported on the session I was in,
saying what I posted to the list yesterday (about National Semi's product,
etc.) The other breakout groups reported their problems with the
criteria, again asking that #9 be dropped, longer, keys, etc.
The presentation for Group "A" was different. It was a speach.
It asked that the process be stopped to let industry develop
market-driven solutions. It was greeted by applause from the
vendors and privacy advocates, with no reaction from the
government representatives.

Randy Williams of Commerce, and Dan Cook of State, described the
current export approval process. Lots of talk of jurisdictions
and types of liscenses. I quickly got lost in the jargon.
The moderator wisecracked that the official language of the session
was English. You couldn't tell from some of the exchanges.

They were questioned on import restrictions. Both Williams and Cook
said that there are no import restrictions into the US. They also
pointed out that Treasury, not State or Commerce, has jurisdiction over
imports.

An engineer from Compaq asked a question: He said that his company
buys liscenses to software, and bundles it as "value added" to
their systems. They are interested in bundling in security features.
He asked if his computers would then be subject to export restrictions.
The answer was yes. He asked if he could purchase security software
overseas and import it. The answer was again yes. He asked if
he could install that software on his computers, again yes. And
export the computers, NO. They didn't even seem to think that this
was illogical.

So Commerce, State, and the rest of the government are activly
encouraging the development of competing software industries in
Israel, Germany and other counrties. I hate to think what they'd
do if they tried to hurt US industry.

And interesting tidbit came up after the session. In an offline
conversation, the topic of "personal use export" came up. A
reliable source said that revised regulations are being developed,
and will, be avaialble soon. I explicitly asked if this meant
"PGP on a notebook computer" and was told, Yes, that will be allowed;
with the usual rules that it can't be for export, you can't be attempting
to sell it, etc. Personal use, carry out and carry back. The "source" was
asked if they had read Matt Blaze's personal use disaster story.
The name didn't ring a bell, but the story was well know and considered
a nightmare.

Penny Brummitt of NSA was to talk about Clipper's key escrow agents,
but called in sick. I didn't catch the name of the replacement.
He talked about Clipper's process, not as an example of what will
be required for GAK agents, but as an "existance proof" that some
agents can be found.  The essence was that Clipper escrow facilities are
strong, and staffed with people cleared to the "Secret" level. They also
tosed out the phrase "US Person" in regard to the corporate entity that is
responsible for the contract.

Geoff Greiveldinger, of the US Department of Justice, gave a frequently
inaudible recounting of the evils of strong encryption in the war
on D, P, & T, and also corrupt mayors. He was very personable. He also
sounded like a fascist. Throughout the meeting, all sides tried to
have a civil discussion, even though we disagreed. It was
impossible to stay civil through his drivel. Ruby Ridge and Furman
had been unmentionable up until his speach.

Mr. Greiveldinger said that acceptable escrow agents will be in the US.
This caused considerable concern among vendors trying to sell
in the International market.

Dan Weitzer of CDT (the EFF spinoff) gave a short, rousing speach. It
was a call to arms. He said that since NIS&T was ignoring the
consistant input from industry to stop this silly and stupid GAK, that
we need to immediately contact our congresscritters.

Ken Mendelsen [sic?] of TIS gave a great speach. He suggested that
the critera for escrow agents be the same as the form to export tanks
and other munitions. Then he showed the one page form used by State.
He argued that legislative solutions to the escrow agent approval process
will take too long and kill the effort. I'll try to get copies of his
presentation.

F.W. Gerbracht, Jr a VP Merril Lynch, represented the Securities Industry
Association. He said that they are willing to work with the government,
but they need long keys, strong ciphers, and international escrow agents.
He used the phrase "unlimited algorithms and keyspace" as a requirement.
They also need buy in from their regulators, and presented a long list
of SEC, CFT, NYSE, NASDealers, and 50 state regulators, all who have
to sign off.

Nanette DiTosto of Bankers Trust gave a short, to the point presentation.
She said that BT has a commercial key escrow service, but that was not
what she wanted to get accross. She said that multinational banks demand
strong encryption and non-US escrow agents. And that they would
settle for nothing less.

A speaker from VTW gave a nice presentation. VTW is something like
voter's telecommunications watch. They have a mailing list, at
listproc@vtw.org. He said that escrow was doomed to failure. That there
is no middle ground. I'll try to get his slides too.

Jack Wack of TECSEC gave a pitch for his shrinkwrapped product. He
said it is exportable now, they've jumped through all the hoops.
He also gave a great crack from his son. It want roughly like:
"Dad, if you own the data before you encrypt it, how come the
government says you don't own it after you encrypt it?"
It brought down the house. (if someone has a more accurate quote, please
let me have a copy).

Professor Hoffman of George Washington gave a great speach. He listed
the Al Gore to Maria Cantwell letter's criteria, as a matrix. He then
filled in the matrix with the Export GAK's criteria. It was painfully
obvious that the NIST/NSA propsal didn't come close. He recommended
that they focus closly on the Gore criteria, and come up with an
approach that meets all the the criteria.

While I planned on staying for the remainder of the meeting, a crisis
came up at my day job. I can't say I was looking forward to more,
a day and a half was enough for me, and I wasn't the only person leaving
early. Attendance was down visibly Thursday relative to the first day

Pat

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBMFBGEbCsmOInW9opAQEfQgP+P/P0MRGe3EOElzM0UPQy+xce0XGe3wex
gfQdTrGWhL+FbYt/7taj6jgtcRg9zih1yQ3W+kN/VUXY9J4I1b6dw+j0sb6MkCjT
pShnflDI5OPQmmUq9KZlmy50u2yXuBqfWSdXd9NypjDsh7XDrWIqvqIcuT1cc/di
quNZ3u7aymw=
=oJC7
-----END PGP SIGNATURE-----