"ConCryption" patent(s)

6 views
Skip to first unread message

Peter Gutmann

unread,
Dec 28, 1995, 3:00:00 AM12/28/95
to


The following was posted to misc.news.internet.announce by Modemac
<mod...@netcom.com>, who got it from a post by Route <ro...@infonexus.com>
(it's a well-travelled posting), since it covers both compression and
encryption patents (with the threat of more patents to follow) I've posted it
to comp.compression and sci.crypt. Given that the ideas I've seen to date for
combined encryption+compression algorithms provide both questionable
encryption and questionable compression, I'd be interested in knowing more
about this... I can't see people dropping proven algorithms like the
combination used in PGP for an unproven combined algorithm, but the patent(s)
could be something to worry about if they're very broad and cover, say, the
basic idea of using both compression and encryption of data, especially if it
predates any general publication of the idea. There are references to it from
before then along the lines of "it is advantageous to compress before
encrypting" comments in crypto papers and "you can probably use this as an
encryption scheme too" comments in compression papers, but the only non-recent
prior art I could find is "On the Privacy Afforded by Adaptive Text
Compression", Ian Witten and John Cleary, Computers and Security, No.7 (1988),
p.397.

That "group of collateral patents, issued and pending" phrase gives me the
creeps.

Peter.

---------------------------INCLUDED TEXT-------------------------------------

CAMBRIDGE, MASS. (Dec. 26) BUSINESS WIRE -Dec. 26, 1995-- Security Dynamics
Technologies, Inc. (NASDAQ: SDTI), a leading provider of network and computer
security solutions, announced that today it was issued U.S. Patent No.
5,479,512 by the U.S. Patent Office for Concryption (TM) technology, a process
that combines data compression and data encryption technologies in a single
integrated series of operations.

Concryption is designed to significantly reduce the amount of time it takes
business users to send compressed information over the Internet in an
encrypted form. By integrating data compression and data encryption,
functions that traditionally had been done separately, the technology enhances
information privacy and data integrity while simultaneously reducing
transmission time, CPU overhead and data storage space. When the technology
is used with integrated public key encryption, the identity of the sender and
recipient can be assured. "The technology encompassed by this patent could
become important in the information age," said Kenneth Weiss, Chairman and
Chief Technical Officer at Security Dynamics. "I believe that Concryption is
an enabling concept technology which could affect the way that data from
various sources, including telecommunications, the Internet and satellites,
are communicated in the future."

"This patent is one of a group of collateral patents, issued and pending,
developed during the process of enhancing and protecting our core technology,
which Security Dynamics may make available for license by third parties," said
Charles Stuckey, President and CEO of Security Dynamics.

--
pgu...@cs.auckland.ac.nz http://www.cs.auckland.ac.nz/~pgut01

Key escrow to rule them all; key escrow to find them.
Key escrow to bring them all and in the darkness bind them.
In the land of surveillance where Big Brother lies.

Mark Dean

unread,
Dec 28, 1995, 3:00:00 AM12/28/95
to
>CAMBRIDGE, MASS. (Dec. 26) BUSINESS WIRE -Dec. 26, 1995-- Security Dynamics
>Technologies, Inc. (NASDAQ: SDTI), a leading provider of network and computer
>security solutions, announced that today it was issued U.S. Patent No.
>5,479,512 by the U.S. Patent Office for Concryption (TM) technology, a process
>that combines data compression and data encryption technologies in a single
>integrated series of operations.

Wow, some invention! Like they've never heard of PKZIP with the -s option
(which seems to do a pretty fair encryption). It only predates their
patent by about 10 years. The Patent Office really needs to get a clue.

Mark

Mark Adler

unread,
Dec 29, 1995, 3:00:00 AM12/29/95
to
Well, keep in mind that RSA itself is patented.

As for the possible benefit, I can imagine one. Most compression techniques
have constraints on the first several bytes (usually Huffman tree
descriptions) that essentially amount to plaintext. It might make sense to
design a compression format specifically for encryption in which any bit
stream is a valid compression stream.

mark


LESLIE MCBRIDE

unread,
Dec 30, 1995, 3:00:00 AM12/30/95
to
PKZIP uses two series of operations ... one for compression and
one for encryption ... These people suposedly combined the two
in a new manner .. hence a patenable process .. but is it
secure?
Leslie McBride


Paul Shirley

unread,
Dec 30, 1995, 3:00:00 AM12/30/95
to
In article <mdeanDK...@netcom.com> md...@netcom.com "Mark Dean" writes:

>>CAMBRIDGE, MASS. (Dec. 26) BUSINESS WIRE -Dec. 26, 1995-- Security Dynamics
>>Technologies, Inc. (NASDAQ: SDTI), a leading provider of network and computer
>>security solutions, announced that today it was issued U.S. Patent No.
>>5,479,512 by the U.S. Patent Office for Concryption (TM) technology, a process >>that combines data compression and data encryption technologies in a single
>>integrated series of operations.
>
>Wow, some invention! Like they've never heard of PKZIP with the -s option
>(which seems to do a pretty fair encryption). It only predates their
>patent by about 10 years. The Patent Office really needs to get a clue.
>

I'd have thought PGP was a better example.

--
Paul Shirley: too lazy to change this sig.

Phillip Williams

unread,
Dec 31, 1995, 3:00:00 AM12/31/95
to
In article <820347...@chocolat.demon.co.uk>,

Does PGP compress too?

Although PKZIP allows for compression and encryption, it does not encrypt
the outgoing data being transmitted. It must first be compressed/encrypted,
then using any Data Transmission method, sent. Two separate processes.

All compression, is a form encryption. ARJ, ZIP, LHA, LZ77...even MNP5

MNP5 is an example. If you don't have MNP5 on the other end, all you get is
garbage. it is done on the fly at transmission time.

So maybe there trying to make a new type of MNP. Same line of operation.

Sorry, for me, I want to be able to change how I encrypt my data. If
somebody does crack it, I change what I use, not what is built into the
transmitter. A better solution would be to allow the use of an external
encryption program/library/DLL/VBX/OCX ... that can be feed the information
to be transmitted. This too could be done with compression programs..
IE Pre-prosses Data befor transmiting. An added feature.


For a lot of MS-DOS based terminal programs, there are external protocols.
All one would need to do is to make a BATCH file that compress/encrypt the
file, then do the normal protocol. Very little change on how you actually
send the file. The reverse would be to do the reverse, get file, decode it.

Any takers?

ph...@cowboy.net

Ralf Brown

unread,
Dec 31, 1995, 3:00:00 AM12/31/95
to
-----BEGIN PGP SIGNED MESSAGE-----

In article <4c2tvd$h...@klein.delphi.com>, LESLIE MCBRIDE <MCBR...@mci.newscorp.com> wrote:
}PKZIP uses two series of operations ... one for compression and
}one for encryption ... These people suposedly combined the two
}in a new manner .. hence a patenable process .. but is it
}secure?

Yeah, that's the question. The idea of making some sort of scrambling an
integral part of the compression process is hardly new -- many compression
algorithms lend themselves to performing (weak) encryption as part of the
compression process. Three examples:

1. Huffman coding: exchange the 0/1 labels on the arcs in the compression
tree based on a key. This is essentially a monoalphabetic substitution
cipher.

2. LZW: reorder the initial compression dictionary (which normally contains
all of the characters of the character set in order) based on a key.
Again, this is essentially a monoalphabetic substitution cipher.

3. Arithmetic coding: reorder the coding table, thus shuffling around the
cut-off points. This can be done repeatedly as compression progresses,
leading to a much stronger cipher than the other two examples above.


Newsgroup: sci.crypt 30-Dec-95


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBMOVe5zNR+LwsPsklAQHsuwf/VfqzjpncUiizFlXqO9H1/lry8jpwjskZ
rlQ5Aic1PCok2iLRPkiybEvEiWl3BtqJU3gSYKxw5xY1zPV0P6pep8hiyZzWQ6bG
thxwYbqUSkLOBafcbfkHW4svI0K60+J/vbx++jR0DVLkpf3HfhYGb3krbNgCobKr
4vSlhGpnXK
--
My employer will | I'net: ra...@telerama.lm.com Fido: Ralf Brown 1:129/26.1
deny knowing of | "Man is the only kind of varmint sets his own trap, baits
this message... | it, then steps in it." -- John Steinbeck, _Sweet_Thursday_

fri...@exo.com

unread,
Jan 1, 1996, 3:00:00 AM1/1/96
to

>Wow, some invention! Like they've never heard of PKZIP with the -s option
>(which seems to do a pretty fair encryption). It only predates their
>patent by about 10 years. The Patent Office really needs to get a clue.

"Fair" is an accurate description of Pkzip encryption. A '486 can extract
the password in about two hours from an encrypted ZIP file.

Tobin Fricke

Achille Hui, the Day Dreamer

unread,
Jan 1, 1996, 3:00:00 AM1/1/96
to
+---In <30e55d70@ralf>---
| Ralf Brown <ra...@telerama.lm.com> writes...
+---------
| -----BEGIN PGP SIGNED MESSAGE-----
|
| In article <4c2tvd$h...@klein.delphi.com>, LESLIE MCBRIDE <MCBRIDEL@mci.n...

| }PKZIP uses two series of operations ... one for compression and
| }one for encryption ... These people suposedly combined the two
| }in a new manner .. hence a patenable process .. but is it
| }secure?
|
| Yeah, that's the question. The idea of making some sort of scrambling an
| integral part of the compression process is hardly new -- many compression
| algorithms lend themselves to performing (weak) encryption as part of the
| compression process. Three examples:
...
|
| 3. Arithmetic coding: reorder the coding table, thus shuffling around ...
| cut-off points. This can be done repeatedly as compression progres...

| leading to a much stronger cipher than the other two examples above.
|

A simpler approach is to use a binary instead of multi-alphabet arithemetic
coder. When you try to encode a bit in a binary coder, one always have a
choice to assign the '0' interval to the lower or upper portion of the
active interval. Instead of making the same choice for all the incoming bits,
one can make decision based on another binary random stream.

It the random stream is truely random. It is not hard to see the strength
of this encryption is equivalent to one-time encryption. A plain binary
encoder (equipped with a good predictor) is pretty good in removing
redundacy and its output is relative random. When we mix this stream with
the quasi-random stream. I don't thing the resulting stream is susceptable
to any statistical attack. The real thing one need to worry about is
differetial plain text attack start from the beginning of the encoded stream.
One can potentially compensate this by furthur one-time encrypting
a initial portion of the encoded stream and scrambling the initial states
of the quasi-random number generator. I think it is possible to choose
the portion long enough to erase any history and short enough for easy of
key exchange.

The speed of this concoder properly depends on the speed of generating
quasi-random stream. In a implementation I have played around before, if
I generate the quasi-random stream using Knuth's modification B of the
55 step additive congruence random number. It is only 10% slower than a
plain binary encoder.

How does other people think about this simple sceneraio.

In any event, any concryption that will be tolerated by the U.S. govenment
is probably not very strong in the first place.
--------------------------------------achille (eill...@drizzle.stanford.edu)


LESLIE MCBRIDE

unread,
Jan 1, 1996, 3:00:00 AM1/1/96
to
Ralf Brown <ra...@telerama.lm.com> wrote:
>Yeah, that's the question. The idea of making some sort of scrambling an
>integral part of the compression process is hardly new -- many compression
>algorithms lend themselves to performing (weak) encryption as part of the
>compression process. Three examples:
>
> 1. Huffman coding: exchange the 0/1 labels on the arcs in the compression
> tree based on a key. This is essentially a monoalphabetic substitution
> cipher.
>
> 2. LZW: reorder the initial compression dictionary (which normally contains
> all of the characters of the character set in order) based on a key.
> Again, this is essentially a monoalphabetic substitution cipher.
>
> 3. Arithmetic coding: reorder the coding table, thus shuffling around the
> cut-off points. This can be done repeatedly as compression progresses,

> leading to a much stronger cipher than the other two examples above.
>
>
The first two are definitely NOT SECURE ...
the third method would depend on the transformations involved
compression could be considered encyption if the
method wasn't known ... But if these people from
concryption or whatever .... have really found
a secure way of integrating compression and encryption
that provides decent compression and security in
one step then it is something new .. not the idea
but the process ... remember ideas without application
are presumed not to be patentable .. ie. the idea
must be reduced to practice (no I am not a patent lawyer)
of course the patentability of encryption has never really
been tested in court. (from FAQ)
Leslie McBride


LESLIE MCBRIDE

unread,
Jan 2, 1996, 3:00:00 AM1/2/96
to
eill...@drizzle.StanFord.EDU ( Achille Hui, the Day Dreamer ) wrote:
>In any event, any concryption that will be tolerated by the U.S. govenment
>is probably not very strong in the first place.
>--------------------------------------achille (eill...@drizzle.stanford.edu)
>
The U.S. government doesn't much care for triple-DES
but it exists :)

Has anyone actually looked at the concryption patents?
Leslie McBride


Peter Gutmann

unread,
Jan 2, 1996, 3:00:00 AM1/2/96
to
eill...@drizzle.StanFord.EDU ( Achille Hui, the Day Dreamer ) writes:

>A simpler approach is to use a binary instead of multi-alphabet arithemetic
>coder. When you try to encode a bit in a binary coder, one always have a
>choice to assign the '0' interval to the lower or upper portion of the
>active interval. Instead of making the same choice for all the incoming bits,
>one can make decision based on another binary random stream.

I've seen a few variants of these schemes in the past, and even mentioned them
in passing in my thesis about a hundred years ago. The problem with all of
them (and the reason I never followed any of the ideas up) is that using the
output of a (cryptographically strong) RNG to manipulate a compression scheme
is never noticeably better[1] than simply XOR-ing the RNG output into the
compressed data like a standard stream cipher. Consider the simplest case of
a static Huffman tree being used to compress data. To use it for encryption,
you take the next bit of RNG output and use it to adjust the decision over
whether you follow the left or right branch of the tree (in effect you XOR the
RNG bit with the bit which encodes the branch of the tree you follow).
However this is equivalent to just XOR'ing the output of the Huffman
compressor with the RNG output, which means you've just reinvented the stream
cipher.

Using a binary arithmetic coder as outlined in the previous post is pretty
much the same, except you don't have the direct equivalence of RNG-driven
Huffman encoding <-> Huffman encoding followed by XOR with RNG output because
you're introducing a slight extra level of complexity via the arithmetic
coder - this is why I put the [1] note in the above text. However there is to
date no research which shows that this strengthens security beyond the level
of "throw in enough mess to confuse them and they'll never figure it out"
(something which is popular with amateur encryption algorithm designers :-).
I posted the results of some basic work I did in 1991 or 1992 to this group (a
post now lost AFAIK) which showed that it was possibly to perform a
known-plaintext attack on an arithmetic coder/encryptor even if several tens
of initial random symbols had been prepended to the data to compress in order
to "randomize" the initial state. The best I could find in my archives was
the following posting from April 1994:

>I looked at it a few years ago using arithmetic coding, wrote up a few pages
>on it, posted it either to sci.crypt or comp.compression, and have never
>been able to find it again since then. From what I remember, the end result
>was rather discouraging. Assuming an order-0 model, you needed to generate
>some hundreds of random symbols to obscure the initial probabilities of each
>symbol being compressed. When compressing a Markov source, you could make
>an estimate of what symbols were likely to occur, and use this as the basis
>for an attacld affect only symbols which don't appear in the text, resulting in no
>"encryption" at all. For a random key and English text, I think you needed
>something like 50-odd random symbols before there was a noticeable effect on
>the compressed data (this was a while back, YMMV on the exact number).
>
>With a higher-order model, the problem is even worse - the skewing of
>probabilities is even less effective since most of the time you change the
>probabilities of symbols which *never* occur (this counts for most
>dictionary-based compressors as well, which are roughly equivalent to
>higher-order Markov models in an obscure way I won't bore you with here).
>
>There are other problems as well, such as the amount of compression achieved
>being a good indication of how well the initial seeding of the model fits
>the data being compressed - this leaks information on the key being used.
>
>I have a (possibly unpublished) 1992 paper here entitled "A Chosen-plaintext
>Attack on an Arithmetic Coding Compression Algorithm" by some people from
>the Queensland University of Technology (Australia) which, although not as
>pessimistic as my analysis, tends to come to the same conclusions.
>
>In short, it's not worth it. Compress the data first, then use a proper
>encryption algorithm to encrypt it.

I still hold by that conclusion: Use a good compressor and follow it with good
encryption. Don't try to combine the two (unless patents and the potential
for competitive marketing are at stake).

Peter.

Owen Lewis

unread,
Jan 2, 1996, 3:00:00 AM1/2/96
to

>"Fair" is an accurate description of Pkzip encryption. A '486 can extract
>the password in about two hours from an encrypted ZIP file.

Are you sure? Brute force/dictionary attack given ciphertext only?

--

-= Owen Lewis =-
@
Tele/fax +44-(0)1794-301731 ELOKA Consultancy & Project Management
o...@eloka.demon.co.uk
pgp 2.x public key on request

Owen Lewis

unread,
Jan 2, 1996, 3:00:00 AM1/2/96
to
In article <4caht6$f...@klein.delphi.com>
MCBR...@mci.newscorp.com "LESLIE MCBRIDE" writes:

>The U.S. government doesn't much care for triple-DES
>but it exists :)

In fact, there seems to be an undertow, outside as well as inside the US
to have major users of cryptography adopt triple-DES. As this undertow comes
from some sources that are most unlikely to move without govermental approval,
one does wonder.....

Padgett 0sirius

unread,
Jan 2, 1996, 3:00:00 AM1/2/96
to
Well my Viacrypt-PGP credits "ZIP" comression by Mark Adler and Jean-Loup
Gaily and an "ASCII armoured" encrypted file is shorter than the binary
original so it is obvious that compression is being used.

As a result, I would be curious to know just what the "ConCryption" patent
covers. Has anyone read it or the abstract ?

A. Padgett Peterson, P.E.
Cybernetic Psychophysicist
Totally Obsessed with TransOceanics
My other car is a Pontiac too
We also walk dogs
PGP 2.7 Public Key Available

Peter Gutmann

unread,
Jan 2, 1996, 3:00:00 AM1/2/96
to
Owen Lewis <o...@eloka.demon.co.uk> writes:

>In article <4caht6$f...@klein.delphi.com>
> MCBR...@mci.newscorp.com "LESLIE MCBRIDE" writes:

>>The U.S. government doesn't much care for triple-DES
>>but it exists :)

>In fact, there seems to be an undertow, outside as well as inside the US
>to have major users of cryptography adopt triple-DES. As this undertow comes
>from some sources that are most unlikely to move without govermental approval,
>one does wonder.....

As far as I know the USG (more specifically the NSA) is strongly opposed to
the adoption of triple DES as a standard. About a year ago the NSA circulated
a document among the members of the ANSI X9 standards committee urging a
negative vote on the proposal based mostly on the fact that triple-DES is
"counter to national security and economic concerns", a curious claim since
the reasons for X9 working on the triple-DES standard were to provide better
protection for financial information than that afforded by single DES. The
adoption of triple DES would provide a major setback for the NSA who would be
faced with the threat of a standardised encryption algorithm providing more
strength than the Skipjack algorithm used in Clipper, but without Clipper's
key forfeiture mechanism. *That* is the reason why the USG doesn't like
triple DES, and not any of the bogus reasons they've been giving until now.

Owen Lewis

unread,
Jan 4, 1996, 3:00:00 AM1/4/96
to
In article <4cc4af$c...@net.auckland.ac.nz>
pgu...@cs.auckland.ac.nz "Peter Gutmann" writes:

>Owen Lewis <o...@eloka.demon.co.uk> writes:
>
>>In article <4caht6$f...@klein.delphi.com>
>> MCBR...@mci.newscorp.com "LESLIE MCBRIDE" writes:
>
>>>The U.S. government doesn't much care for triple-DES
>>>but it exists :)
>
>>In fact, there seems to be an undertow, outside as well as inside the US
>>to have major users of cryptography adopt triple-DES. As this undertow comes
>>from some sources that are most unlikely to move without govermental approval,
>>one does wonder.....
>
>As far as I know the USG (more specifically the NSA) is strongly opposed to
>the adoption of triple DES as a standard. About a year ago the NSA circulated
>a document among the members of the ANSI X9 standards committee urging a
>negative vote on the proposal based mostly on the fact that triple-DES is
>"counter to national security and economic concerns",

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That is, of course open to diametrically opposed interpretations, but
perhaps the context sorted it out.


>a curious claim since
>the reasons for X9 working on the triple-DES standard were to provide better
>protection for financial information than that afforded by single DES. The
>adoption of triple DES would provide a major setback for the NSA who would be
>faced with the threat of a standardised encryption algorithm providing more
>strength than the Skipjack algorithm used in Clipper, but without Clipper's
>key forfeiture mechanism. *That* is the reason why the USG doesn't like
>triple DES, and not any of the bogus reasons they've been giving until now.


The difficulty with these things is one can never know for sure which way is
up.

Consider first single DES. Few doubt that NSA and perhaps some others have been
able to read DES traffic since before it was released. Therefore why the
brouhaha over its export and the careful sifting of oversea end user applicants
(before that system rotted so thoroughly it simply fell over)? There is
little doubbt that NSA has profited from reading DES traffic and that that
traffic has been encouraged by the puffing of its 'national security' status.

AFAIK, though theoretic attacks have been described, there is no commercially
available DES cracker still, almost twenty years after NSA let it loose.

So, we come to triple DES. The concept of re-encryption is hardly new and
could have been applied to DES from the outset. Though I do not know that it
is so for DES, there is at least one known major cipher (a version of ENIGMA
ARAIR without looking it up) whose routine breaking was much helped by
a German attempt to improve security by using re-encryption.

If NSA say "Jeez, we don't want this triple DES on the streets because its
much too hard for us", I do ask myself why they would say that and, if it were
so, why DES was not designed from the outset to defeat such a simple
enhancement of its strength.

Why use triple DES? There are other ciphers which are faster and whose
development owes nothing to a Government intelligence agency. With luck more
will come as the crypto market burgeons.

There is clear evidence that the US has already joined the club of nations who
use national intelligence resources for commercial espionage. For some, such
as Russia and Israel, such distinctions have never been recognised.

For most purposes, and though one might not like it, it may not matter a damn
if Uncle Sam can read your traffic. If it does really matter to you then I
feel that triple DES should come with a health warning.

R.S. (Bob) Heuman

unread,
Jan 4, 1996, 3:00:00 AM1/4/96
to
Owen Lewis <o...@eloka.demon.co.uk> wrote:

>In article <4caht6$f...@klein.delphi.com>
> MCBR...@mci.newscorp.com "LESLIE MCBRIDE" writes:
>
>>The U.S. government doesn't much care for triple-DES
>>but it exists :)
>
>In fact, there seems to be an undertow, outside as well as inside the US
>to have major users of cryptography adopt triple-DES. As this undertow comes
>from some sources that are most unlikely to move without govermental approval,
>one does wonder.....

>--
Banks here are moving to 3DES, and the h..l with whatever the govt
wants... A bank can be sued by its clients if their private info is
revealed via communications when 3DES would secure it... Money (lost
via the courts) counts more than govt desires, where banks are free to
make this type of decision....

Bob


Mark Dean

unread,
Jan 5, 1996, 3:00:00 AM1/5/96
to

Hi Andrew - why are you flaming Owen Lewis so much here? He post was
quite reasonable. He had a couple good thoughts in it, as well as some
reasonable assumptions.

>: Consider first single DES. Few doubt that NSA and perhaps some others have been

>: able to read DES traffic since before it was released.
>

>It doesn't matter if "few people" doubt it. In this forum, some
>evidence is expected. All of the public domain analyses of DES have
>tended to confirm that it is an extremely well designed cipher. In
>1977 it would have been extremely hard and expensive for the NSA to
>build a brute force DES breaking machine, and there's never been any
>evidence of a backdoor in the algorithm.

You ask for evidence of the abilities of the most secret organizations
within any government? Get real. Even "in this forum" informed
reasoning is the best we can do on many subjects. (Funny though, you
next make a claim about how hard & expensive it was in 1977 for the NSA
to build a DES-cracker. Where's your evidence?)

>: Therefore why the brouhaha over its export
>
>There is no difference between the rules for exporting DES and the
>rules for exporting any other strong encryption technology.

True, but irrelevant. 40-bit DES may be exported, regular 56-bit not.
Owen is just asking why the NSA makes such a phony distinction between them.
As Netscape found out, 40-bit brute force cracks are no longer out of the
reach of many users (whether you're cracking DES, RC4, or anything else).

>: little doubt that NSA has profited from reading DES traffic and that that

>: traffic has been encouraged by the puffing of its 'national security' status.
>

>"There is little doubt". Another entirely unsupported assertion. I'm
>not asking for proof, just tell us why we should believe you.

Maybe he doesn't care if you believe him or not. I think it's pretty
obvious; but what you or I think doesn't carry much weight. If you want
to disagree, with any relevance, see if you can get anyone who's given a
presentation at a crypto conference, or written a book on cryptography,
to support you.

>: So, we come to triple DES. The concept of re-encryption is hardly new and

>: could have been applied to DES from the outset. Though I do not know that it
>: is so for DES, there is at least one known major cipher (a version of ENIGMA
>: ARAIR without looking it up) whose routine breaking was much helped by
>: a German attempt to improve security by using re-encryption.
>

>So? Do you have any evidence that this can be applied to DES? Public
>domain research (particularly "DES is not a group") supports the
>assumption that DES is not weakened by multiple encryption.

So you're both right.

>: If NSA say "Jeez, we don't want this triple DES on the streets because its

>: much too hard for us", I do ask myself why they would say that and, if it were
>: so, why DES was not designed from the outset to defeat such a simple
>: enhancement of its strength.
>

>Partly because DES was not designed by the NSA, and partly because it
>would have been very difficult to hide such a weakness.

Sure it was: by IBM and at least partially by the NSA.

>: For most purposes, and though one might not like it, it may not matter a damn


>: if Uncle Sam can read your traffic. If it does really matter to you then I
>: feel that triple DES should come with a health warning.
>

>Tell us why.

Seems obvious to me. The "may not matter" part because I've never sent
anything over public lines that would cause problems if the government
read. The "health warning" comment is just common sense. Do you really,
truly believe that you can create/find/use ANY crypto algorithm that the
NSA cannot break? None of use here (other than the NSA spooks themselves
who may be reading this) know their true levels of capabilties. And few
of us are smug enough to say the NSA can crack this algo, but not that one.

(Apologies to everyone for doing what I wish Andrew hadn't done: waste
bandwidth with a message that doesn't contribute any useful information
to the community. But I get so tired of seeing pointless flames, and
useless messages. Opposing discussion is useful, but tearing someone
down is useless. Defending someone, in the hopes he and others will
continue to post their ideas and questions, isn't quite as useless.)

Mark

LESLIE MCBRIDE

unread,
Jan 5, 1996, 3:00:00 AM1/5/96
to
a...@atml.co.uk (Andrew Haley) wrote:

>Owen Lewis (o...@eloka.demon.co.uk) wrote:
>: For most purposes, and though one might not like it, it may not matter a damn
>: if Uncle Sam can read your traffic. If it does really matter to you then I
>: feel that triple DES should come with a health warning.
>
>Tell us why.
>
>Andrew.

Unless you are actively engaged in activity that the NSA
would be compelled to act on .. ie. terrorism .. it is
highly unlikely that they would come out of the wood-work
and present your decrypted messages in court .. and if
anyone else has the resources to crack DES, they aren't
talking!
Leslie McBride


Andrew Haley

unread,
Jan 5, 1996, 3:00:00 AM1/5/96
to
Owen Lewis (o...@eloka.demon.co.uk) wrote:

[ deletia ]

: Consider first single DES. Few doubt that NSA and perhaps some others have been
: able to read DES traffic since before it was released.

It doesn't matter if "few people" doubt it. In this forum, some
evidence is expected. All of the public domain analyses of DES have
tended to confirm that it is an extremely well designed cipher. In
1977 it would have been extremely hard and expensive for the NSA to
build a brute force DES breaking machine, and there's never been any
evidence of a backdoor in the algorithm.

: Therefore why the
: brouhaha over its export

There is no difference between the rules for exporting DES and the
rules for exporting any other strong encryption technology.

: and the careful sifting of oversea end user applicants


: (before that system rotted so thoroughly it simply fell over)? There is

: little doubbt that NSA has profited from reading DES traffic and that that

: traffic has been encouraged by the puffing of its 'national security' status.

"There is little doubt". Another entirely unsupported assertion. I'm
not asking for proof, just tell us why we should believe you.

: AFAIK, though theoretic attacks have been described, there is no commercially


: available DES cracker still, almost twenty years after NSA let it loose.

: So, we come to triple DES. The concept of re-encryption is hardly new and

: could have been applied to DES from the outset. Though I do not know that it
: is so for DES, there is at least one known major cipher (a version of ENIGMA
: ARAIR without looking it up) whose routine breaking was much helped by
: a German attempt to improve security by using re-encryption.

So? Do you have any evidence that this can be applied to DES? Public
domain research (particularly "DES is not a group") supports the
assumption that DES is not weakened by multiple encryption.

: If NSA say "Jeez, we don't want this triple DES on the streets because its

: much too hard for us", I do ask myself why they would say that and, if it were
: so, why DES was not designed from the outset to defeat such a simple
: enhancement of its strength.

Partly because DES was not designed by the NSA, and partly because it
would have been very difficult to hide such a weakness.

: Why use triple DES?

Because it has had the most public scrutiny of any cipher. Many other
ciphers have been published and broken after a few years. It seems to
me that it would be foolish to reject the apparently well designed DES
on such grounds.

Mind you, there's a very simple solution: multiple encryption with
different ciphers. This would protect against the US government
(assuming that they really can break DES) and everyone else if the
other cipher is broken.

[ deletia ]

Bruce Schneier

unread,
Jan 5, 1996, 3:00:00 AM1/5/96
to
I got a copy of the "ConCryption" patent, and I can't believe it was awarded.
All it consists of is the steps of encryption and compression done as a
single operation, like PKZIP does, like PGP does, like many other systems do.

The first claim just consists of four steps: obtaining the plaintext,
obtaining an encryption key, compressing, encrypting, and outputting the
result.

Big deal.

In any case, Security Dynamics released a press release saying that they are
now licensing their invention.

Assuming their terms are reasonable, no one will challenge this abomination.

Makes you proud to be an American.

Bruce

**************************************************************************
* Bruce Schneier APPLIED CRYPTOGRAPHY, 2nd EDITION is
* Counterpane Systems available. For info on a 15%
* schn...@counterpane.com discount offer, send me e-mail.
**************************************************************************

Bob Silverman

unread,
Jan 5, 1996, 3:00:00 AM1/5/96
to
In article <mdeanDK...@netcom.com>, Mark Dean <md...@netcom.com> wrote:
>

stuff deleted....

>>There is no difference between the rules for exporting DES and the
>>rules for exporting any other strong encryption technology.
>
>True, but irrelevant. 40-bit DES may be exported, regular 56-bit not.
>Owen is just asking why the NSA makes such a phony distinction between them.
>As Netscape found out, 40-bit brute force cracks are no longer out of the
>reach of many users (whether you're cracking DES, RC4, or anything else).
>
>>: little doubt that NSA has profited from reading DES traffic and that that
>>: traffic has been encouraged by the puffing of its 'national security' status
>>

>>"There is little doubt". Another entirely unsupported assertion. I'm
>>not asking for proof, just tell us why we should believe you.
>
>Maybe he doesn't care if you believe him or not. I think it's pretty
>obvious; but what you or I think doesn't carry much weight. If you want

I am not sure of the antecedent of 'it' in "it's pretty obvious".
Is it being stated that "it is obvious that NSA can crack DES" or is
the opposite being stated?

>to disagree, with any relevance, see if you can get anyone who's given a
>presentation at a crypto conference, or written a book on cryptography,
>to support you.

OK. I will.

I am not sure who said what here, but I do agree with the statement that
"There is a lot of doubt". In fact, I have very strong doubts that NSA
can routinely read DES traffic.

Yes, if there were some message of sufficient importance I have no
doubt that they could crack it. But the resources required would be
very large and the number of such messages (that they can or have cracked)
would be quite small.

There *is* a fair amount of evidence to support the claim that there is
no back door in DES. Just read the papers in Proceedings of Crypto or
Eurocrypt. DES has been extensively investigated and noone outside the
NSA has found a back door.

> Do you really,
>truly believe that you can create/find/use ANY crypto algorithm that the
>NSA cannot break? None of use here (other than the NSA spooks themselves
>who may be reading this) know their true levels of capabilties. And few
>of us are smug enough to say the NSA can crack this algo, but not that one.

I am smug enough to say that NSA can't break RSA or discrete logs.

--
Bob Silverman
The MathWorks Inc.
24 Prime Park Way
Natick, MA

Owen Lewis

unread,
Jan 5, 1996, 3:00:00 AM1/5/96
to
In article <4cj1sf$9...@gatekeeper.atml.co.uk>
a...@atml.co.uk "Andrew Haley" writes:

>Owen Lewis (o...@eloka.demon.co.uk) wrote:
>
>[ deletia ]
>
>: Consider first single DES. Few doubt that NSA and perhaps some others have
> been
>: able to read DES traffic since before it was released.
>
>It doesn't matter if "few people" doubt it. In this forum, some
>evidence is expected.

The feasibility of brute force cracking of DES was open sourced within a year
of DES's launch (no time to check the actual dates). There is evisence that
the NSA inspired revision to the S box design substantially reduced the
vulnerability of the cipher to differential analysis of which there was no
open source knowledge for many years after DES's release. The limitation,
NSA inspired, of the limitation of DES keylength left it vulnerable to the
massive use of brute force. In the late 70's is quite possible - even likely -
that other major cryptanalytical agencies were already aware of the
differential analysis technique. Probably no other agency than NSA could have
possessed a brute force cracker; for a fair while, the US maintained a
stranglehold on the level of IT technology concerned..

>All of the public domain analyses of DES have
>tended to confirm that it is an extremely well designed cipher.

Of course. It would have been designed, as far as possible and for as long as
possible to shield against all but the NSA. If that were not so, why would
the NSA have blessed its release and now complain that 3-DES is too hard and
should not therefore be released?

>In 1977 it would have been extremely hard and expensive for the NSA to

>build a brute force DES breaking machine.....

You assume that such a machine would have had to be procured and was not
already possessed. I do not assume this.

>..... and there's never been any evidence of a backdoor in the algorithm.

True, there's no open source evidence; and there won't be until someone finds
a hole and *chooses* to publish what would still be a most valuable secret.

Consider LUCIFER, which was flawed from the outset. Do you believe that NSA did
not know that it was flawed? Do you believe that the publicly undiscovered
flaw in LUCIFER was not a part of the USG's drive to see it replaced by
something less vulnerable to second rate intelligence agencies? Did NSA,
knowing that LUCIFER was fatally flawed, publish that information?

>
>: Therefore why the
>: brouhaha over its export
>

>There is no difference between the rules for exporting DES and the
>rules for exporting any other strong encryption technology.

The rules may be the same but the licensing conditions vary.

>: and the careful sifting of oversea end user applicants
>: (before that system rotted so thoroughly it simply fell over)? There is

>: little doubt that NSA has profited from reading DES traffic and that that

>: traffic has been encouraged by the puffing of its 'national security' status.


>
>"There is little doubt". Another entirely unsupported assertion. I'm
>not asking for proof, just tell us why we should believe you.

There is no reason whatsoever for you to believe me, whoever 'I' may be or
whatever I may think. What I offer is food for thought, based on my own
experience of life and information that I have garnered along the way. The
most one would expect is that you compare it critically with your own
knowledge base and draw whatever conclusions may be appropriate. Perhaps
conclusions is the wrong word; marking down areas of doubt might be better.

In crypto one rarely if ever can deal with absolute certainty. The true
purpose of crypto is to diminish high levels of risk. Therefore, I would
suggest, in the light of imperfect knowledge it is always prudent to steer
away from any probable area of risk rather than to assume that, because
the rocks don't actually break the troubled surface, that they are not there.



>: AFAIK, though theoretic attacks have been described, there is no
>: commercially
>: available DES cracker still, almost twenty years after NSA let it loose.
>
>: So, we come to triple DES. The concept of re-encryption is hardly new and
>: could have been applied to DES from the outset. Though I do not know that it
>: is so for DES, there is at least one known major cipher (a version of ENIGMA
>: ARAIR without looking it up) whose routine breaking was much helped by
>: a German attempt to improve security by using re-encryption.
>
>So? Do you have any evidence that this can be applied to DES? Public
>domain research (particularly "DES is not a group") supports the
>assumption that DES is not weakened by multiple encryption.

None. Nor do I have any evidence that the tripling process absolutely
guarantees an improvement in DES security. The analogy I was trying to draw
out is that even a very clever and experienced group of cryptologists have
failed to spot a weakness caused by re-encryption with the same cipher,
though that weakness was found and exploited by another gifted group (who,
naturally, kept that information to themselves).

>: If NSA say "Jeez, we don't want this triple DES on the streets because its
>: much too hard for us", I do ask myself why they would say that and, if it
> were so, why DES was not designed from the outset to defeat such a simple
>: enhancement of its strength.
>
>Partly because DES was not designed by the NSA,

Well, let's not chop words. DES was produced to a USG requirement with NSA
as the supervising and authorising agency (in fact. if not in name). After all,
what other poool of such authoritative knowledge and special expertise does
(did) the USG maintain?

> and partly because it would have been very difficult to hide such a
> weakness.

Anything is dificult until someone discovers (and shares) the technique.
Lucifer?

>: Why use triple DES?
>
>Because it has had the most public scrutiny of any cipher. Many other
>ciphers have been published and broken after a few years. It seems to
>me that it would be foolish to reject the apparently well designed DES
>on such grounds.

Well, that's a view. Ultimately its persuasion must rely on a decision as to
whether NSA would turn loose a cipher that it could not break when push came
to shove. Either they did or did not do that with the initial release of DES.
If they did, then why now the fuss over 3-DES? If they did not, why should one
trust a derivative of the same cipher.

>Mind you, there's a very simple solution: multiple encryption with
>different ciphers.

Exactly. So one wonders why 3-DES is being pushed by those to whom the
advantages of this proven course are known?

>: For most purposes, and though one might not like it, it may not matter a damn
>: if Uncle Sam can read your traffic. If it does really matter to you then I
>: feel that triple DES should come with a health warning.
>
>Tell us why.

I think I have made that plain. Others are equally entitled to tread their
own path in fear and trembling.

Owen

Henry Baker

unread,
Jan 6, 1996, 3:00:00 AM1/6/96
to
In article <4cm7vb$n...@blackice.winternet.com>,
schn...@parka.winternet.com (Bruce Schneier) wrote:

> In article <4cl6u0$q...@klein.delphi.com>,
> LESLIE MCBRIDE <MCBR...@mci.newscorp.com> wrote:
> >It is my understanding that in PKZIP and PGP the
> >encryption and compression are separate steps.
>
> You are right, in both of those programs, encryption and compression are
> seperate steps. In patent 5479512, encryption and compression are also
> seperate steps. It's weird.
>
> Claim 1:
> "1. A method for utilizing a data processor to change the form of data
> comprising the steps of:
> a) obtaining the data at the processor in clear form;
> b) obtaining an encryption key at the processor;
> c) the processor performing a multi-step compression operation
> on said clear-form data;
> d) the processor automatically utilizing said encryption key in
> conjunction with the results as directly generated by the
> processor for a selected step of said compression operation in
> performing an encryption operation, the compression steps of
> step (c) and the encryption step of step (d) being integrated
> to be performed as parts of a single operation; and
> e) the processor outputting the resulting compressed and encrypted
> version of the clear-form data."
>
> Is there ANYONE who can tell me how that claim is different from either
> PGP or PKZIP?

I'm not a lawyer, but it's my current understanding that patent claims should
be read in such a way that they are initially presumed valid. I think that this
means that if there is prior art -- e.g., PGP, PKZIP -- then the meaning of
the words in the claim are more narrowly interpreted and the equivalents to
the exact methods described in the patent are correspondingly
reduced. Without having read the patent, the patent file history, and
compared carefully the patent methods with the prior art, it would be
impossible to say for sure what is going on. Nevertheless, if PGP and/or
PKZIP really are 'prior' art, then I could imagine that the patent coverage
could be quite narrow.

Furthermore, the claims are often ordered in such a way that the broadest
claim is the first one, with a number of 'dependent' claims which narrow
the coverage. Thus, even if the 'independent' claim is found to be invalid,
there are still claims dependent upon that claim that might still be valid.
If there are 50 claims, and you infringe on just one, then you infringe,
even if the other 49 are all invalid.

--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html

Copyright (c) 1996 by Henry G. Baker. All rights reserved.
** Warning: Due to its censorship, CompuServe and its subscribers **
** are expressly prohibited from storing or copying this document **
** in any form. **

The Right Reverend Colin James III

unread,
Jan 6, 1996, 3:00:00 AM1/6/96
to
LESLIE MCBRIDE <MCBR...@mci.newscorp.com> posted with deletions:

| It is my understanding that in PKZIP and PGP the
| encryption and compression are separate steps.
|

| I would really like to see those patents. If
| you would be so kind as to direct me to an online
| source or post a copy here.
| Leslie McBride

You can search for them yourself at any public patent repository site.

The PKZIP patent is pathetically short and does not cover encryption
but rather use of pointers in a look up table. It is a perfect
example of a software patent which should never have been issued due
to prior art, etc.


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Colin James III, Principal Scientist cja...@cec-services.com
CEC Services, 2080 Kipling St, Lakewood, CO 80215-1502 USA
Voice: 303.231.9437; Facsimile: .231.9438; Data: .231.9434
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~


Bruce Schneier

unread,
Jan 6, 1996, 3:00:00 AM1/6/96
to
In article <4cl6u0$q...@klein.delphi.com>,
LESLIE MCBRIDE <MCBR...@mci.newscorp.com> wrote:
>It is my understanding that in PKZIP and PGP the
>encryption and compression are separate steps.

You are right, in both of those programs, encryption and compression are


seperate steps. In patent 5479512, encryption and compression are also
seperate steps. It's weird.

The abstract:

"A method and apparatus for the integrated compression and encryption
(concryption) of clear data and for the deconcryption of concrypted
data to obtain the clear data for utilization. For concryption, the clear
data and an encryption key are obtained, at least one compression step
is performed and at least one encryption step is performed utilizing the
encryption key. The encryption step is performed on the final or
intermediate result of a compression step, with compression being a
multistep operation. For deconcryption, decompression and decryption steps
are performed on concrypted data in essentially the reverse order for
the performance of corresponding compression and encryption steps during
the concryption operation."

Claim 1:

"1. A method for utilizing a data processor to change the form of data
comprising the steps of:

a) obtaining the data at the processor in clear form;

b) obtaining an encryption key at the processor;

c) the processor performing a multi-step compression operation
on said clear-form data;

d) the processor automatically utilizing said encryption key in
conjunction with the results as directly generated by the
processor for a selected step of said compression operation in
performing an encryption operation, the compression steps of

step (c) and the encryption step of sted (d) being integrated


to be performed as parts of a single operation; and

e) the processor outputting the resulting compressed and encrypted
version of the clear-form data."

((Apologies for any typoes. It's early.))

Is there ANYONE who can tell me how that claim is different from either
PGP or PKZIP?

Bruce

Bob Martin N6MZV

unread,
Jan 6, 1996, 3:00:00 AM1/6/96
to
In article <4ck9of$7...@blackice.winternet.com>,
schn...@parka.winternet.com (Bruce Schneier) wrote:

> I got a copy of the "ConCryption" patent, and I can't believe it was awarded.
> All it consists of is the steps of encryption and compression done as a
> single operation, like PKZIP does, like PGP does, like many other systems do.
>
> The first claim just consists of four steps: obtaining the plaintext,
> obtaining an encryption key, compressing, encrypting, and outputting the
> result.
>
> Big deal.
>
> In any case, Security Dynamics released a press release saying that they are
> now licensing their invention.
>
> Assuming their terms are reasonable, no one will challenge this abomination.
>
> Makes you proud to be an American.
>

> Bruce
>
> **************************************************************************
> * Bruce Schneier APPLIED CRYPTOGRAPHY, 2nd EDITION is
> * Counterpane Systems available. For info on a 15%
> * schn...@counterpane.com discount offer, send me e-mail.
> **************************************************************************

If you've got a printed reference describing a system that does those four
steps that was available more than a year prior to the filing of the
original "concryption" application (I think it was in 1991, don't have the
patent in front of me), then the issued patent has serious problems.

I was surprised that there was no non-patent prior art (things such as
Cryptology publications, CRYPTO, IEEE, ACM, etc.) cited on the cover sheet
of the patent. Unfortunately, this looks like another area where the
Patent Office doesn't have access to the relevant prior art.

Perhaps you should send them a couple copies of your book!

--

Bob Martin N6MZV * r...@netgate.net

LESLIE MCBRIDE

unread,
Jan 7, 1996, 3:00:00 AM1/7/96
to
I think the key to the wording that allowed them a patent is in
claim 1 section d "the compression steps of step (c) and the
encryption step of step (d) being integrated to be performed as
parts of a single operation". How they are integrated is evidently
a key part of this patent claim ... from what I have seen they
claim to have a faster algorithm that integrates compression
and encryption. In PGP and PKZIP the operations are separate
in any case having a patent doesn't mean it is valid :)
Leslie McBride


Bruce Schneier

unread,
Jan 7, 1996, 3:00:00 AM1/7/96
to
In article <4cngl5$8...@klein.delphi.com>,
LESLIE MCBRIDE <MCBR...@mci.newscorp.com> wrote:

Agreed. But there is nothing in the body to indicate that they have a
faster algorithm. Both the body and the figures show that compression
and encryption are seperate steps, and not a single algorithm. There
is no math in the patent; an algorithm for compression is not specified,
nor is an algorithm for encryption.

Mike Tighe

unread,
Jan 7, 1996, 3:00:00 AM1/7/96
to
In article <4cjudl$e...@puff.mathworks.com>, Bob Silverman says...

>I am not sure who said what here, but I do agree with the statement that
>"There is a lot of doubt". In fact, I have very strong doubts that NSA
>can routinely read DES traffic.

Perhaps a better way to draw a conclusion to this question is to ask, who
is using DES and does the USG/NSA have a significant interest (ie, willing
to invest significant money) in reading their mail?


Andrew Haley

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
Owen Lewis (o...@eloka.demon.co.uk) wrote:
: In article <4cj1sf$9...@gatekeeper.atml.co.uk>
: a...@atml.co.uk "Andrew Haley" writes:

: >All of the public domain analyses of DES have


: >tended to confirm that it is an extremely well designed cipher.

: Of course. It would have been designed, as far as possible and for as long as
: possible to shield against all but the NSA. If that were not so, why would
: the NSA have blessed its release and now complain that 3-DES is too hard and
: should not therefore be released?

This is an interesting question, but not quite on charter here.
However, the NSA has dual roles: one one hand, to aid US interests
(for which strong encryption for use by US corporations is required),
and on the other, to gather telecommunications intelligence. It may
be (and no, I have no evidence for this) that in this case the former
interest won, and the latter interest was satisfied by the short key.

Thus, the DES algorithm may have no backdoors but still be breakable
by exhausive attack. Note that I didn't say that the NSA couldn't
break single DES: I just challenged your assertion that they did so
before 1977.

The NSA has zero or more DES cracking machines. Therefore any prudent
person will use a combination of ciphers to protect himself. For
example, it's perfectly reasonable to use single DES if the key is not
used for very long. For the transmission of session keys it probably
makes sense to use some combination of other methods.

Andrew.

Ralf W. Stephan

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
Owen Lewis writes:
> There is no reason whatsoever for you to believe me, whoever 'I' may be or
> whatever I may think. What I offer is food for thought, based on my own
> experience of life and information that I have garnered along the way. The
> most one would expect is that you compare it critically with your own
> knowledge base and draw whatever conclusions may be appropriate. Perhaps
> conclusions is the wrong word; marking down areas of doubt might be better.

I agree with this, but let me ask a naive question: Why don't
anyone mark doubts on IDEA? Why not hypothetically assume that
IDEA could be partly developed by the Swiss Secret Service, or if you
prefer, by the secret service of a nation that has huge interests
that people prefer IDEA over a cipher that was doubted over 20 years?


ralf
--
PGP: 1024/0xA713ECE9 2047/0xC8E605F5

WHMurray

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
In article <4cpl3g$7...@softserv.tcst.com>, ti...@spectrum.titan.com (Mike
Tighe) writes:

>Perhaps a better way to draw a conclusion to this question is to ask, who

>is using DES and does the USG/NSA have a significant interest (ie,
willing
>to invest significant money) in reading their mail?


Now that I think about it, not a particularly good way to look at it at
all. As long as NSA knows who is using the encryption, they do not worry
about it too much. For example, banks are heavy users of encryption; as
long as NSA knows that noisy looking traffic originates and terminates in
a bank, they do not worry about it much. Likewise, IBM is a big user; NSA
can discount that. In other words, NSA need not invest money in reading
the mail of those that they know and expect to use encryption. On the
other hand, they panic at the very prospect that the ether might fill with
noisy looking traffic.

Never forget the money. The issue is 60,000 jobs and $22B. The issue is
the efficiency of signals intelligence. It is not so much about reading
encrypted traffic as it is about ensuring that most traffic is in the
clear.

William Hugh Murray

LESLIE MCBRIDE

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
schn...@parka.winternet.com (Bruce Schneier) wrote:
>In article <4cngl5$8...@klein.delphi.com>,
>LESLIE MCBRIDE <MCBR...@mci.newscorp.com> wrote:
>
>>I think the key to the wording that allowed them a patent is in
>>claim 1 section d "the compression steps of step (c) and the
>>encryption step of step (d) being integrated to be performed as
>>parts of a single operation". How they are integrated is evidently
>>a key part of this patent claim ... from what I have seen they
>>claim to have a faster algorithm that integrates compression
>>and encryption. In PGP and PKZIP the operations are separate
>>in any case having a patent doesn't mean it is valid :)
>
>Agreed. But there is nothing in the body to indicate that they have a
>faster algorithm. Both the body and the figures show that compression
>and encryption are seperate steps, and not a single algorithm. There
>is no math in the patent; an algorithm for compression is not specified,
>nor is an algorithm for encryption.
>
>Bruce
>
If there really isn't a difference in the algorithm that they
are using and that used in PGP or PKZIP, then the patent isn't
valid ... H**L maybe the whole office was drunk on spiked
punch (it was the holidays) and said "Lets give them techno-jerks
something to argue about" :) .. if the patent isn't valid
then who cares.
Leslie McBride

ps. no I am not calling anyone names but lets face facts
the US government would like to see public encryption
disappear from the face of the earth (the NSA anyway)

Mark C. Henderson

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
In article <4cl6u0$q...@klein.delphi.com>,

LESLIE MCBRIDE <MCBR...@mci.newscorp.com> wrote:
>It is my understanding that in PKZIP and PGP the
>encryption and compression are separate steps.
Yes


>I would really like to see those patents. If
>you would be so kind as to direct me to an online
>source or post a copy here.

Perhaps the Splay Tree encryption algorithm is prior art. My copy
of the implementation is dated Feb. 20, 1989

Certainly seems to do encryption and compression in one step, but then
I haven't seen the patent.

A copy is available in the Wimsey archive (ftp://ftp.wimsey.com/pub/crypto)
to U.S./Canadian persons in the U.S. or Canada as splay.tar.gz

/pub/crypto/software/dist/US_or_Canada_only_XXXXXXXX/Misc/splay.tar.gz

to get the value of XXXXXXXX
get
/pub/crypto/software/README
--
Mark Henderson -- ma...@wimsey.bc.ca, hend...@netcom.com, m...@squirrel.com
PGP 1024/C58015E3 fingerprint=21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46
cryptography archive maintainer -- ftp://ftp.wimsey.com/pub/crypto
ftp://ftp.wimsey.com/pub/crypto/sun-stuff/change-sun-hostid-1.6.1.tar.gz

WHMurray

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
In article <4cpl3g$7...@softserv.tcst.com>, ti...@spectrum.titan.com (Mike
Tighe) writes:

>>I am not sure who said what here, but I do agree with the statement that
>>"There is a lot of doubt". In fact, I have very strong doubts that NSA
>>can routinely read DES traffic.
>

>Perhaps a better way to draw a conclusion to this question is to ask, who

>is using DES and does the USG/NSA have a significant interest (ie,
willing
>to invest significant money) in reading their mail?

I think that key word is "routinely." My working assumption is that NSA
can read any traffic that it wants. It just cannot read all the traffic
that it wants. I do not have any reason to believe that they can read DES
encrypted traffic. I have a lot of reason to believe that if they can, it
is not cheap.

I think Owen is being disingenuous here. What do they call it? "Dog in
the manger?"

(As to the title of this thread, I was scheduled to go to Cambridge on
Tuesday. I was anxious to hear how wide they construe this patent to be.
(I am not aware of many implementations of encryption that do not include
compression; have to reduce the redundancy. Most implementations of
compression will throw in a little data hiding.) However, we are in the
midst of a blizzard here and I may not be going anywhere for a while.)

William Hugh Murray

Richard M. Hartman

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
In article <4cr19r$o...@newsbf02.news.aol.com>,

WHMurray <whmu...@aol.com> wrote:
>Now that I think about it, not a particularly good way to look at it at
>all. As long as NSA knows who is using the encryption, they do not worry
>about it too much. For example, banks are heavy users of encryption; as
>long as NSA knows that noisy looking traffic originates and terminates in
>a bank, they do not worry about it much. Likewise, IBM is a big user; NSA
>can discount that. In other words, NSA need not invest money in reading
>the mail of those that they know and expect to use encryption. On the
>other hand, they panic at the very prospect that the ether might fill with
>noisy looking traffic.


Doesn't IBM have international offices? Certainly there are international
banks. So using your logic, you could run a reasonably secure spy ring
by using agents employed by IBM/USA on one end and IBM/Europe on the other
(Or Sanwa bank, or...). Since the NSA expects to see encrypted mail from
IBM and the banks, they'd ignore it?


-Richard Hartman
har...@zoom.COM
--
"It is useless for sheep to propose vegetarianism while wolves remain
of a different persuasion."
-- Turkish proverb


Padgett 0sirius

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
In article <4cm7vb$n...@blackice.winternet.com> schn...@parka.winternet.com (Bruce Schneier) writes:
>For concryption, the clear
>data and an encryption key are obtained, at least one compression step
>is performed and at least one encryption step is performed utilizing the
>encryption key.

Well, this "sounds" like at least one compression step is performed using
the encryption key since there is no intervening comma. Haven't received my
copy yet (on order) so have not a clue what this means. Any real lawyers
care to comment ?

Owen Lewis

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
In article <4cr19r$o...@newsbf02.news.aol.com> whmu...@aol.com "WHMurray" writes:

> As long as NSA knows who is using the encryption, they do not worry
>about it too much. For example, banks are heavy users of encryption; as
>long as NSA knows that noisy looking traffic originates and terminates in
>a bank, they do not worry about it much. Likewise, IBM is a big user; NSA
>can discount that. In other words, NSA need not invest money in reading
>the mail of those that they know and expect to use encryption. On the
>other hand, they panic at the very prospect that the ether might fill with
>noisy looking traffic.

No, that's simplistic. USG, and other G, expect serious criminals, terorists
etc to use encryption.

And you conveniently step over the war on drugs that had become the war of
organised crime, i.e. the washing of money into legitimate (big) busisness.

Oh, BTW, your view is quite parochial. You overarch entirely the USG need to
read non-US traffic.

>Never forget the money. The issue is 60,000 jobs and $22B. The issue is
>the efficiency of signals intelligence.

The issue is not the efficiency of signals intelligence. The issue is power.
But I think you know that even if you will not say it.

>It is not so much about reading
>encrypted traffic as it is about ensuring that most traffic is in the
>clear.

Of course, it's cheaper that way :-)

Owen Lewis

unread,
Jan 8, 1996, 3:00:00 AM1/8/96
to
In article <4cr195$o...@newsbf02.news.aol.com> whmu...@aol.com "WHMurray" writes:

>In article <4cpl3g$7...@softserv.tcst.com>, ti...@spectrum.titan.com (Mike
>Tighe) writes:
>
>>>I am not sure who said what here, but I do agree with the statement that
>>>"There is a lot of doubt". In fact, I have very strong doubts that NSA
>>>can routinely read DES traffic.
>>
>>Perhaps a better way to draw a conclusion to this question is to ask, who
>
>>is using DES and does the USG/NSA have a significant interest (ie,
>willing
>>to invest significant money) in reading their mail?
>
>I think that key word is "routinely." My working assumption is that NSA
>can read any traffic that it wants. It just cannot read all the traffic
>that it wants. I do not have any reason to believe that they can read DES
>encrypted traffic. I have a lot of reason to believe that if they can, it
>is not cheap.
>
>I think Owen is being disingenuous here. What do they call it? "Dog in
>the manger?"

Naah. I'll share a bone with anybody. Anyway, none of the above guff belongs
to me.

WHMurray

unread,
Jan 9, 1996, 3:00:00 AM1/9/96
to
In article <821148...@eloka.demon.co.uk>, Owen Lewis
<o...@eloka.demon.co.uk> writes:

>>example, it's perfectly reasonable to use single DES if the key is not
>>used for very long.
>

>I take another view. The sole criteria is whether someone capable wants
to
> read your traffic. It is generally accepted that 56 bit DES can be
broken,
>brute force in considerably less than a day.
>
>

Owen, perhaps you miss the point. The issue is not merely one of
capability but also of motivation. If I reduce the information encrypted
under a single key, at some point it becomes uneconomical for you to
attack it.

If a 56 bit DES key is the weakest point in your security, then you are
strong indeed. If your resources are such that I am willing to break a 56
bit DES key to obtain them, then you are rich indeed.

Again, it appears to me that you are being disingenuous. What am I
missing?

William Hugh Murray
New Canaan, Connecticut

WHMurray

unread,
Jan 9, 1996, 3:00:00 AM1/9/96
to
In article <821150...@eloka.demon.co.uk>, Owen Lewis
<o...@eloka.demon.co.uk> writes:

>So why are the major corporations being nudged gently down the road
toward
>3DES?
>
>

In part, because what I know about DES I can impute to 3DES. Are you
suggesting a conspiracy?

Andrew Haley

unread,
Jan 9, 1996, 3:00:00 AM1/9/96
to
Owen Lewis (o...@eloka.demon.co.uk) wrote:
: In article <4cqvtc$8...@gatekeeper.atml.co.uk>
: a...@atml.co.uk "Andrew Haley" writes:
: >........ For
: >example, it's perfectly reasonable to use single DES if the key is not
: >used for very long.

: I take another view. The sole criteria is whether someone capable wants to
: read your traffic. It is generally accepted that 56 bit DES can be broken,
: brute force in considerably less than a day.

...if they have the right hardware, yes. But all that they will get
is one session key, and it may not be worth their while to do all of
that work for a small amount of information. It all depends on how
valuable the information which may be obtained by breaking a single
key is.

If breaking that key doesn't get them any information in the future,
it may well not be worth their effort. Even if the message may be
important to the NSA, such as (say) Libyan diplomatic traffic, it may
well not be worth breaking a DES key for every single one of thousands
of messages.

Andrew.

Owen Lewis

unread,
Jan 9, 1996, 3:00:00 AM1/9/96
to
In article <4cqvtc$8...@gatekeeper.atml.co.uk>
a...@atml.co.uk "Andrew Haley" writes:
>........ For
>example, it's perfectly reasonable to use single DES if the key is not
>used for very long.

I take another view. The sole criteria is whether someone capable wants to
read your traffic. It is generally accepted that 56 bit DES can be broken,
brute force in considerably less than a day.

Owen

Owen Lewis

unread,
Jan 9, 1996, 3:00:00 AM1/9/96
to
In article <1996Jan8.1...@ark.franken.de>
ra...@ark.franken.de "Ralf W. Stephan" writes:

> ..... Why don't


>anyone mark doubts on IDEA? Why not hypothetically assume that
>IDEA could be partly developed by the Swiss Secret Service,

Because the Swiss confine their concept of vital interests to within their own
borders (and have become very rich thereby).

> or if you
>prefer, by the secret service of a nation that has huge interests
>that people prefer IDEA over a cipher that was doubted over 20 years?

Given the way that the world is, if you want to launch a world dominating
application of algorithms, crypto or otherwise, you launch in the US market.
That market alone is so rich and fond of the homegrown that any market leader
needs to be US or represent as US. Do you think that Microsoft could *ever*
have achieved its market dominance had it the same products and been a Swiss
company?

Of course, none of this says that IDEA is unflawed but only that it would be
a fairly unsuccessful 'plant'. By any measure other than age, IDEA seems a
stronger cipher than 1DES and is a faster (and as strong) a cipher than 3DES.


So why are the major corporations being nudged gently down the road toward
3DES?

--

WHMurray

unread,
Jan 9, 1996, 3:00:00 AM1/9/96
to
In article <821148...@eloka.demon.co.uk>, Owen Lewis
<o...@eloka.demon.co.uk> writes:

> It is generally accepted that 56 bit DES can be broken,
>brute force in considerably less than a day.

It is generally accepted that a nation state could break a DES key in less
than a day if it wanted to do so. It is less than generally accepted that
it has ever been done. Though nation states often spend far more to
accomplish something than it is worth to do so, they do not do it over and
over again. Though they may spend more to do something than it is worth,
they will still choose the cheaper of two obvious ways to do it.

I do not understand this line of argument. What point are you trying to
make?

Peter Gutmann

unread,
Jan 10, 1996, 3:00:00 AM1/10/96
to
whmu...@aol.com (WHMurray) writes:

>In article <821150...@eloka.demon.co.uk>, Owen Lewis
><o...@eloka.demon.co.uk> writes:

>>So why are the major corporations being nudged gently down the road toward
>>3DES?

>In part, because what I know about DES I can impute to 3DES. Are you
>suggesting a conspiracy?

Well, it is two (2) key, triple (3) DES, 2 + 3 = 5, I think the implications
are obvious fnord.

Peter.
--
pgu...@cs.auckland.ac.nz http://www.cs.auckland.ac.nz/~pgut01

Key escrow to rule them all; key escrow to find them.
Key escrow to bring them all and in the darkness bind them.
In the land of surveillance where Big Brother lies.


Ralf Brown

unread,
Jan 10, 1996, 3:00:00 AM1/10/96
to
In article <4cqcco$f...@merlin.delphi.com>, LESLIE MCBRIDE <MCBR...@mci.newscorp.com> wrote:
}if the patent isn't valid then who cares.

Unfortunately, patents are presumed valid until overturned by the courts
or a Patent Office review (which is rare enough that the re-examination
of the Compton multimedia patent made headlines). Until then, someone
with an invalid patent can cause quite a bit of damage.

What is needed is a six-month public review period before a patent takes
effect. If someone can show prior art, the patent would be revoked
before it becomes final, thus saving lots of litigation.

--
My employer will | Internet: ra...@pobox.com | "If carried too far, virtues
deny knowing of | Fido: Ralf Brown 1:129/26.1 | can evolve into various
this message... | http://www.pobox.com/~ralf | faults." -- Eugene T. Maleska

Mike Tighe

unread,
Jan 10, 1996, 3:00:00 AM1/10/96
to
In article <4cr19r$o...@newsbf02.news.aol.com>, WHMurray says...

>In article <4cpl3g$7...@softserv.tcst.com>, ti...@spectrum.titan.com (Mike
>Tighe) writes:

>>Perhaps a better way to draw a conclusion to this question is to ask,
>>who is using DES and does the USG/NSA have a significant interest (ie,
>>willing to invest significant money) in reading their mail?

>Now that I think about it, not a particularly good way to look at it at
>all. As long as NSA knows who is using the encryption, they do not

>worry about it too much.

What I meant was, you do no attempt to cryptanalyze an algorithm, and the
build automated resources to derive intelligence data from it, just
because someone somewhere might be using that algorithm. You have to have
a valid intelligence requirement.


LESLIE MCBRIDE

unread,
Jan 10, 1996, 3:00:00 AM1/10/96
to
Ralf Brown <ra...@telerama.lm.com> wrote:
>In article <4cqcco$f...@merlin.delphi.com>, LESLIE MCBRIDE <MCBR...@mci.newscorp.com> wrote:
>}if the patent isn't valid then who cares.
>
>Unfortunately, patents are presumed valid until overturned by the courts
>or a Patent Office review (which is rare enough that the re-examination
>of the Compton multimedia patent made headlines). Until then, someone
>with an invalid patent can cause quite a bit of damage.
>
>What is needed is a six-month public review period before a patent takes
>effect. If someone can show prior art, the patent would be revoked
>before it becomes final, thus saving lots of litigation.
>
What type of damage? Very few infringement claims ever get settled in
court. Ie. It took 15 years of litigation to get any results on
the intermittent windshield wiper patent (don't know the references)
And the PGP case was settled without ever going to court. Or the funnel
cap for the old round oil cans, obsolete before it even made it
to arbitration.

A public review period is a good idea. Or perhaps a specific
'patent court' that hears only patent cases. But then that is what
arbitration boils down to. Most patents found to be invalid are
overturned by courts (if it gets there). The patent office basically
doesn't review patents except under extremely unusual circumstances.

Save Litigation?????? Are you crazy!!!! All of the time and effort
lawyers put into making laws so they have work!!! BLASPHEMY!!! :)
If I were a lawyer I would sue you for just suggesting such a thing <G>.
Leslie McBride

Lawyers called 'congressmen' make laws so that they can argue among
themselves and have decisions made by lawyers called 'judges' and
charge everyone else for it, and they call that 'justice'
retired lawyer


Alec Muffett

unread,
Jan 10, 1996, 3:00:00 AM1/10/96
to
In article <821150...@eloka.demon.co.uk> Owen Lewis <o...@eloka.demon.co.uk> writes:

>Because the Swiss confine their concept of vital interests to within their own
>borders (and have become very rich thereby).

[...]

Owen,

Reading back through this thread, a brief summary of your position
might seem to be that:

1 If the NSA can't break it,
they make sure we don't hear about it.

2 If the NSA can break it with effort,
they try to ban it.

3 If the NSA can break it routinely,
they pretend that they can't,
and then whinge (publically) to that effect.

4 If the NSA can break it easily,
they ignore people using it.

5 If the NSA control it,
they make it a federal standard.

...the argument being that since the NSA are whinging about 3DES, it
fits into categories 2 or 3, above, and is therefore breakable.

Well I'm not qualified to judge the mind of a federal agency, but it's
interesting to speculate where other crypto algorithms fit into this
lookup table.

Musingly yours,

- alec 8-)

--
#!/usr/local/bin/perl -- -pwcracker-in-3-lines-of-perl-plus-disclaimer
$u{$p[1]}=$p[0] while(@p=getpwent);while(<>){chop;foreach $c (keys %u)
{printf "u=%s p=%s\n",$u{$c},$_ if(crypt($_,$c) eq $c);}} # Use: pwc dict ...
# Alec.M...@UK.Sun.COM. Not speaking for my employers. Not my fault.

David R. Conrad

unread,
Jan 11, 1996, 3:00:00 AM1/11/96
to

In patent 5479512, the ConCryption patent (via Bruce Schneier):

>>The abstract:
>>
>>"A method and apparatus for the integrated compression and encryption
>>(concryption) of clear data and for the deconcryption of concrypted
>>data to obtain the clear data for utilization. For concryption....

It took me a while to understand their neologism, "ConCryption". "Cryption"
is obvious, and I think "Con" must stand for "Confidence", as in "confidence
man", "confidence game", etc.

Seems the people at the patent orifice are as clueless as ever. *sigh*

--
David R. Conrad, con...@detroit.freenet.org, http://www.grfn.org/~conrad
Hardware & Software Committee : finger -l con...@grfn.org for public key
Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50
No, his mind is not for rent to any god or government.

Owen Lewis

unread,
Jan 11, 1996, 3:00:00 AM1/11/96
to
In article <4ctno4$j...@gatekeeper.atml.co.uk>
a...@atml.co.uk "Andrew Haley" writes:

>Owen Lewis (o...@eloka.demon.co.uk) wrote:
>: In article <4cqvtc$8...@gatekeeper.atml.co.uk>


>: a...@atml.co.uk "Andrew Haley" writes:
>: >........ For
>: >example, it's perfectly reasonable to use single DES if the key is not
>: >used for very long.
>
>: I take another view. The sole criteria is whether someone capable wants to

>: read your traffic. It is generally accepted that 56 bit DES can be broken,


>: brute force in considerably less than a day.
>

>...if they have the right hardware, yes. But all that they will get
>is one session key, and it may not be worth their while to do all of
>that work for a small amount of information.

It depends on the implementation, doesn't it? As also on what/who is the target.

It all depends on how
>valuable the information which may be obtained by breaking a single
>key is.

True.

>If breaking that key doesn't get them any information in the future,
>it may well not be worth their effort. Even if the message may be
>important to the NSA, such as (say) Libyan diplomatic traffic, it may
>well not be worth breaking a DES key for every single one of thousands
>of messages.

What would be the value of preventing another WTC or Oklahoma bomb?
Belay that. What would be the value of preventing another such *n?
The difficulty is, since not everything can be read, what do you read?
As any good auditor will tell you random sampling is a vital tool.

Owen Lewis

unread,
Jan 11, 1996, 3:00:00 AM1/11/96
to
In article <yd5ivik...@coyote.uk.sun.com>
al...@coyote.uk.sun.com "Alec Muffett" writes:

>In article <821150...@eloka.demon.co.uk> Owen Lewis <o...@eloka.demon.co.uk>
> writes:
>
> >Because the Swiss confine their concept of vital interests to within their own> >borders (and have become very rich thereby).
>[...]
>
>Owen,
>
>Reading back through this thread, a brief summary of your position
>might seem to be that:
>
> 1 If the NSA can't break it,
> they make sure we don't hear about it.

/
\/


> 2 If the NSA can break it with effort,
> they try to ban it.


they make sure we don't hear about it.

>
> 3 If the NSA can break it routinely,
> they pretend that they can't,
> and then whinge (publically) to that effect.

they make sure we don't hear about it.


>
> 4 If the NSA can break it easily,
> they ignore people using it.

they make sure we don't hear about it.

>
> 5 If the NSA control it,
> they make it a federal standard.
>

.... and they make sure we hear about it.

>...the argument being that since the NSA are whinging about 3DES, it
>fits into categories 2 or 3, above, and is therefore breakable.
>
>Well I'm not qualified to judge the mind of a federal agency, but it's
>interesting to speculate where other crypto algorithms fit into this
>lookup table.

Yes it is, isn't it? We find our way though this life in fear and trembling
as anyone who knows Aber Coll will appreciate.


With best (and also musing) regards,


Owen

Owen Lewis

unread,
Jan 11, 1996, 3:00:00 AM1/11/96
to
In article <4ctvi5$s...@newsbf02.news.aol.com> whmu...@aol.com "WHMurray" writes:

>Owen, perhaps you miss the point. The issue is not merely one of
>capability but also of motivation. If I reduce the information encrypted
>under a single key, at some point it becomes uneconomical for you to
>attack it.
>
>If a 56 bit DES key is the weakest point in your security, then you are
>strong indeed. If your resources are such that I am willing to break a 56
>bit DES key to obtain them, then you are rich indeed.
>
>Again, it appears to me that you are being disingenuous. What am I
>missing?


1. In terms of national security some information is sufficiently vital that
if you can get it you must. Cost is not the prime factor (no pun intended).

2. In terms of commercial espionage, if you see a take worth $1Bn, is an
investment $10M and (say) a year to get that take. You know it makes sense.

3. Suppose you had assets for 1. and were also supplying a value added service
to X, Y and Z Inc in accordance with the growing trend for intelligence
asset employment, economies of scale apply. As a strawman, say the minimum
target value drops to $100M. That would not only puts such as biotech,
pharmaceuticals and aerospace in the frame, but, say some car and even
food and drink manufacturers.

4. Think on, too, in regard to the requirement for *random* sampling.

You have (gently) used the epithet 'disingenuous' on me before. I shall
not return the compliment as if is unedifying for others to listen to the
pot calling the kettle black :-).

WHMurray

unread,
Jan 12, 1996, 3:00:00 AM1/12/96
to
In article <821376...@eloka.demon.co.uk>, Owen Lewis
<o...@eloka.demon.co.uk> writes:

>>Owen, perhaps you miss the point. The issue is not merely one of
>>capability but also of motivation. If I reduce the information
encrypted
>>under a single key, at some point it becomes uneconomical for you to
>>attack it.
>>
>>If a 56 bit DES key is the weakest point in your security, then you are
>>strong indeed. If your resources are such that I am willing to break a
56
>>bit DES key to obtain them, then you are rich indeed.
>>
>>Again, it appears to me that you are being disingenuous. What am I
>>missing?
>
>
>1. In terms of national security some information is sufficiently vital
that
> if you can get it you must. Cost is not the prime factor (no pun
>intended).

Agreed. Will you grant me that I will do so at the least cost to me?

>
>2. In terms of commercial espionage, if you see a take worth $1Bn, is an
> investment $10M and (say) a year to get that take. You know it makes
>sense.

I do.

>
>3. Suppose you had assets for 1. and were also supplying a value added
>service
> to X, Y and Z Inc in accordance with the growing trend for
intelligence
> asset employment, economies of scale apply. As a strawman, say the
minimum
>
> target value drops to $100M. That would not only puts such as biotech,

> pharmaceuticals and aerospace in the frame, but, say some car and even

> food and drink manufacturers.

Now we are getting somewhere.


>
>4. Think on, too, in regard to the requirement for *random* sampling.
>
>

Oh, I do, I do. Indeed, I believe that is what the program of the princes
is all about. Nonetheless, I consider that activity to be chilling to
legitimate endeavor and more than minimally intrusive. While I accept
that ethical spys are careful not to use non-target facts that come to
their attention, I am glad that I am not one and believe that I would not
be one.

>You have (gently) used the epithet 'disingenuous' on me before. I shall
>not return the compliment as if is unedifying for others to listen to the

>pot calling the kettle black :-).

Never on you, Owen, only on the post. (I sometimes picture with your
tongue planted firmly in your cheek.) I can risk a slight over
characterization because I know that you know the high regard in which I
hold you. Since I see no need to edify you, and I doubt that you are
trying to instruct me, we must be engaged in some other activity here.

Regards, Bill

WHMurray

unread,
Jan 12, 1996, 3:00:00 AM1/12/96
to
In article <821377...@eloka.demon.co.uk>, Owen Lewis
<o...@eloka.demon.co.uk> writes:

>>I do not understand this line of argument. What point are you trying to
>>make?
>

>Two points really.
>
>1. As has been said by others, if your job is sifting information the
more of
> that you can force/inveigle into clear mode the easier your life will
be.

Ah! Of couse! I must have lost the thread somewhere.

>2. What information cannot be forced/inveigled into clear mode should as
far
> as possible in one of as few ciphers as possible and to many of which
> as possible you hold the keys (e.g. RAMBUTAN & CLIPPER) or can break
if
> required. This requirement may have to live alongside a contrary
> requirement to ensure that as few as possible other than oneself can
break
> the cipher.

Agreed, though you and I may read the tea leaves differently as to which
others they prefer.

>Please let me add that I do not argue the benefits nor even, ultimately
the
>practicality of such a view. However, straws that blow past me indict
that
>there are those in the employ of many governments who might argue this
way in
>private.

Yes, I know that they do. That is one of the reasons that I do not want
_them_ making _all_ the policy _there_.


WHMurray

unread,
Jan 13, 1996, 3:00:00 AM1/13/96
to
In article <821378...@eloka.demon.co.uk>, Owen Lewis
<o...@eloka.demon.co.uk> writes:

>Yes it is, isn't it? We find our way though this life in fear and
trembling
>as anyone who knows Aber Coll will appreciate.

I agree. I hope that we will be able to make the princes understand that
at some point fear and trembling become destructive of community and good
public order.

Owen Lewis

unread,
Jan 14, 1996, 3:00:00 AM1/14/96