At 3:18 PM 3/18/93 -0500, Markowitz(_at_)DOCKMASTER(_dot_)NCSC(_dot_)MIL wrote:
... please explain to me, if you can,
how PMSP/DMS is more "interesting" or "relevant" (see below) than an
similar ElGamal/DSA/DES product.
PMSP (now being tested in prototype, and planned for use in DMS) is
interesting in the context of the pem-dev list because:
(1) It seems to be a complete electronic mail system/architecture with
very nearly the same functionality as PEM, and is interesting from a
comparative viewpoint.
(2) DMS is not used just by DoD, and not even just by the U.S. Government.
Even if just by DoD, PMSP will be used across the Internet by a major
subcommunity of the Internet, and this naturally raises the question of
interoperability and/or coexistence/cooperation with PEM.
(3) El Gamal is not by itself an e-mail system. Given that a PEM
implementation already needs RSA for protecting DEKs, why also be burdened
with a different, separate signature algorithm? There would have to be
functional advantages to paying for extra software. Are there?
PMSP uses the NIST "suite" of algorithms (at least the DSA/SHA). It's a
good bet MSP will use the same algorithms for sender and message
authenti- cation.
As PMSP evolves to MSP, it might continue to use the same algorithms that
it does now. It might also evolve to different Type 2 algorithms. In any
case, these algorithms, other than DSA and SHS, might never be published.
The algorithms might even migrate from software into custom hardware that
is designed to prevent reverse engineering. In any event, all this
addresses only unclassified information. For classified information, its a
VERY good bet that MSP does NOT use the same suite. By definition it uses
a Type 1 suite, not a Type 2 suite.
Or maybe it's okay to discuss these things as long as the algorithms
involved aren't mentioned. Please clear this up for me, Rob.
I am not in charge of this list or of any working group; I was just passing
out relevant information to help people in the industry do their job.
Stupid as it sounds, MITRE's charter is to work in the public interest.
(We have no shareholders; we have no shares! If MITRE decides to go out
business, the assets that remain are basically given to the President of
the United States to dispose of as she sees fit.)
However, since you ask, IMHO it is OK to discuss the algorithms. For
example, at the PSRG Workshop in San Diego in February, there was an active
discussion of RCx and potential uses in Internet protocols. I think that
it might be appropriate for someone to follow on here with a well-written
analysis of the pros and cons of using an exportable suite of algorithms in
place of the one specified in RFC 1423. For example, GOOD because
exportable and therefore rapidly deployable; BAD because 40 bits of key
length implies less strength than 56; etc. However, such an analysis, to
be constructive, needs to propose a complete suite that is exportable.
What do we use to replace RSA for protecting DEKs? That is how we have
viewed the DSS question in the past: When the Government publishes a
complete suite/profile of algorithms for PEM, they should be considered for
inclusion. Mixing and matching would seem to inhibit rather than foster
interoperability that scales to the world.
Steve Kent apparently feels such discussions are outside the scope of
the WG, not to mention this mailing list.
[Personally, I for one would welcome the posting of BSAFE benchmarks
here, including those for RC2/RC4. I'm sure I'm not alone in this--I
think Rob's original query even asked for them. Anyone from RSADSI
listening?]
I think that there are other, obvious places to post that kind of stuff,
like sci.crypt, for example. I was asking about PEM performance.
PEM needs to get on the DSA/SHA bandwagon for long-term *survivability*
as well as short-term *utility*. You do want PEM to be deployed on at
least as large a scale as PGP, don't you?
PGP doesn't use DSA/SHA either, no?
My simple understanding of the situation is that use of PGP by, for
example, The MITRE Corporation, not to mention General Motors, or even
official support of large-scale PGP usage by the student body at a large
University, leaves the institution open to very damaging legal action.
(New York Times, 18 March 1995: "U.S. Marshalls in cooperation with
Software Publishers Association and Public Key Partners today raided the
offices of Crosscountry Insurance Corporation in 15 cities, confiscating
numerous computers, including some containing unlicensed copies of software
that uses RSA encryption.") We decided not even to keep a copy on a
restricted server for analysis.
The legal situation causes PGP to have inherent limits to growth. PEM does
not have those limits. Further, when RSA comes built into my Mac OS along
with a built-in license, even the licensing problem will no longer be a
barrier to PEM growth in the U.S. How the export issue will play out, time
will tell. But the algorithms you propose are no more and no less
exportable than the ones already approved for PEM.
Provided we
can get Steve Kent's permission, that is. :-)
Don't waste your technical and entrepreneurial talents being snide. Show
up at the IETF, or present your ideas electronically. The IETF is one of
the most open and tolerant forums for technical discussion that can be
found in the world. It has to be to keep with the technology it is
attempting to standardize. Any well-reasoned Internet-Draft on the subject
of alternative algorithms would be a positive contribution that surely
would have no trouble finding space on the pem Working Group agenda or on
its official discussion list, pem-dev.
Regards, -Rob-
Robert W. Shirey, The MITRE Corporation, Mail Stop Z202
7525 Colshire Dr., McLean, Virginia 22102-3481 USA
shirey(_at_)mitre(_dot_)org * tel 703-883-7210 * fax 703-883-1397