HDTenEightyP/NetNews huggingface dataset:
Subject: Re: DES (Was: Re: 800MHz
Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
Date: Fri, 8 Jan 1993 01:33:00 +0000

 -=> Quoting Steven Bellovin to All <=-

 Govt use of DES

 SB> Definitely not in the U.S.  
 
 >  ..... claim that the cost to the US taxpayer for breaking each DES 
 >  ciphertext is $56. ...

 SB> These appear to be Diffie and Hellman's numbers. .......each solution 
 SB> would cost $50.

 SB> I don't think that that projection has held up.....

 SB> ..... conclusion -- and I agree with it -- is that straight DES is
 SB> probably still useful for protecting individual sessions, but is not
 SB> suitable for encrypting keys. ...... suggest using triple encryption for
 SB> key distribution. 

 My thanks to Steve for the informative post. I admit to being interested 
 in the arguement posted in this news group, more than once, that multiple  
 encryption with DES  - or keylengths more that 56 bits - do not actually 
 improve resistance to cryptanalysis. I don't have the ability to prove 
 this mathemetically one way or the other but I wonder if searching  
 the ciphertexts for identifiable patterns, where the encryption is of short, selected 
 and repetitive plaintexts and using various multiples of encryption rounds, 
 might be an interesting exercise. If only there was time follow up all one 
 found interesting.
  


___ Blue Wave/QWK v2.11
From: lrk@k5qwb.lonestar.org (Mr. Lyn R. Kennedy)
Newsgroups: sci.crypt
Subject: Re: DES (Was: Re: 800MHz
Date: 11 Jan 93 15:39:26 GMT
Organization: Radio Amateur k5qwb

Owen.Lewis@purplet.demon.co.uk (Owen Lewis) writes:

>  -=> Quoting Lyle_seamanAllransarc.com to All <=-
> 
>  (Owen Lewis) writes:
>  > Does the US government (use DES)?  I believe not.
> 
>  Ly> I would bet that this is because they want classified material to be 
>  Ly> safe for a hundred years or so.  They recognize that DES (while it may
>  Ly> be relatively safe for the near future) will be highly vulnerable to
>  Ly> brute-force attack within 50 years, and they have a lot of secrets
>  Ly> they'd rather no one found out about.   It doesn't have to be because
>  Ly> there are hidden flaws in DES.
> 

Yes, the U.S. Government REQUIRES DES for some devices. Motorola's 
radios can use DES or Motorola's own system for voice encryption. The 
Gov't requires DES. It's true, however, that DES is not permitted for 
protecting classified information.


-------------------------------------------------------------------------
                 
73,            internet     | lrk@k5qwb.lonestar.org
Lyn Kennedy    packet radio | K5QWB @ N5LDD.#NTX.TX.US.NA
               pony express | P.O. Box 5133, Ovilla, TX, USA 75154

-------------- "We have met the enemy and he is us."  Pogo --------------
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: sci.crypt
Subject: Re: Complete ITAR Available
Date: 11 Jan 93 01:38:36 GMT
Organization: CWI, Amsterdam

(Omitted alt.security.ripem because we do not have it here.)

In article <1993Jan11.003432.15501@netcom.com> strnlght@netcom.com (David Sternlight) writes:
 > Putting it another way, if PGP infringes, then the author does not
 > have the legal right to declare it public domain, in that he doesn't
 > own the infringing portion.

This makes it still more interesting.  This would mean that PGP violates ITAR
only of it infringes RSA's patent.  So unless the latter case is decided there
is nothing to decide the first.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
From: Christopher_C_Lapp@cup.portal.com
Newsgroups: sci.crypt
Subject: Protecting Commerical info with virtual reality
Date: Tue, 12 Jan 93 13:37:15 PST
Organization: The Portal System (TM)
Distribution: usa

A cover-plaintext encrypt is a topic of discussion used to create a 
 virtual reality  which conceals a true encrypted dialogue.  
Plaintext encryption allows the encrypting parties to use two 
channels of discourse- the  phony  channel which a skilled 
adversary will see when he decrypts, and the real, uncrackable 
channel that the phony channel represents.  I suggest for 
concealing commercial and industrial information, that the 
conversing parties rifle their files for every bad and impractical 
idea their respective R&D departments have rejected.  These 
ideas and all of the information filed with the ideas can be used to 
create a phony dialogue about the errant technology, which would 
conceal the real dialogue and technical information being 
exchanged.  Using controlled plaintext encryption, it is possible, 
using rule based expert systems and adequate discourse structure 
to create a fully encrypted artificial dialogue that contains all of 
the encrypted information.  Thus, when the clever adversary 
decrypts PGP 2.0 or DES or whatever, the adversary will only 
see an involved discussion about technical concepts that only after 
involved investigation will prove to be fruitless.  This is how 
technical information will be concealed in the future. 
Any comments?
From: curt@kcwc.com (Curt Welch)
Newsgroups: sci.crypt
Subject: Re: Any way to *CREATE* Vcr+ (VCR PLUS) codes??? (please read)
Date: 6 Jan 93 17:46:39 GMT
Reply-To: curt@kcwc.com (Curt Welch)
Organization: KCW Consulting

David Sternlight writes:
>Back then, I noticed that two
>sources of published codes, the L.A. Times and TV guide occasionally
>had different codes for the same program, which suggests other
>than a central source. (They weren't typos, and both worked.)

oppedahl@panix.com (Carl Oppedahl) writes:
>I trust that readers of this group have no trouble figuring out why
>this would happen -- right?

>The VCR+ people provide programs to the LA Times, and to TV Guide,
>that are not identical.

That's a good theory, but I doubt it's correct.  I've checked hundreds
of codes from many different publications and I've never found two
different codes that mapped to the same show.  Our 6 digit algorithm
produces a perfect 1 to 1 mapping of numbers to shows for all 6 digit
codes, so there's no way Gemstar could have different programs
producing different numbers.

Part of the success of the VCR Plus+ system is due to the length of
the codes being very short.  Gemstar bent over backwards to reduce
this as much as possible.  This was the key weakness in the code that
made it so easy to break.  If they allowed multiple PlusCodes to map
to the same show (so they could tell who encoded it) then it would
make the codes longer.  I doubt they did this.

Sometimes, the same show
will have different numbers because the different guides will be using
different channels (which they expect you to deal with using the channel
mapping function of the VCR Plus+).  But you can see this when you punch
in the numbers because it shows you the channel.

If you punch in two different numbers, and it seems to map to the same
show and same channel, then the difference is probably in the duration.
This has been the case every time I've found two different numbers
for the same show.  It will typically be for shows when strange
durations or start times.  On guide might use a duration of 1:50 and the
other will choose 1:55.

/-----------------------------------------------------------------------------\
| Curt Welch - KCW Consulting           By 1995, there will be just two kinds |
| curt@kcwc.com - NeXTmail please!      of professionals:  Those who use NeXT,|
| (703) 938-4152  FAX (703) 938-5756    and those without Jobs.               |
\-----------------------------------------------------------------------------/
Newsgroups: sci.crypt,alt.security.ripem
From: strnlght@netcom.com (David Sternlight)
Subject: Re: Nonlinear Amplification of Information
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Mon, 11 Jan 1993 00:10:53 GMT


Bob Cain says
"The problem between RSA and Phil is very, very complicated and the way
it all came down it deserves to be if you hear both sides."

Given that my view of that situation is thought partisan by some,
I'd be very interested to hear Bob's view, since there can be no
doubt he's not a fan of mine.

The reason I ask is his characterization of Jim Bidzos as reasonable
and tough. I'd agree with that, so perhaps those who don't care for
my views about the RSA/PGP situation might be more able to hear what
Bob has to say about that (not knowing in advance what that might be).

David
-- 
David Sternlight
RIPEM Public Key on server  --  Consider it an envelope for your e-mail
From: ct@dde.dk (Claus Tondering)
Newsgroups: sci.crypt
Subject: WordPerfect and US crypto laws
Date: 5 Jan 93 14:09:49 GMT
Organization: Dansk Data Elektronik A/S

As far as I know, US laws forbid the export of cryptographic
software. However, WordPerfect contains a (very simple and insecure)
cryptographic feature. And WordPerfect is exported from the US with
this feature. Why is this legal? Is it because the code is so
easily broken? Is this the very reason for making the code so
incredibly simple?


-- 
Claus Tondering
Dansk Data Elektronik A/S, Herlev, Denmark
E-mail: ct@dde.dk
------------------------------- Why do they never serve pizza on airplanes?
From: smb@research.att.com (Steven Bellovin)
Subject: Re: Complete ITAR Available
Date: Mon, 11 Jan 1993 21:45:24 GMT
Organization: AT&T Bell Laboratories

In article <1993Jan11.172610.1281@netcom.com>, strnlght@netcom.com (David Sternlight) writes:
> Before someone is tempted to respond with counter-arguments,
> let me say that only an attorney can probably get to the
> bottom of this, and the thread is already tiring many.

This issue -- just what constitutes ``technical data'' -- comes up
repeatedly on sci.crypt.  A year or two ago, someone (John Gilmore?)
posted an analysis by some DEC attorneys, explaining why they didn't
think the liberal position espoused here would fly.  Did anyone save
a copy?  I suspect I did, but it's not in any of the files I'd expect
to find it in.  Can someone repost it?  I did find a note indicating
that (not surprisingly) the State Dept sees it DEC's way, i.e., that
one can't just post cryptographic software.
Newsgroups: sci.crypt
From: oppedahl@panix.com (Carl Oppedahl)
Subject: Re: Any way to *CREATE* Vcr+ (VCR PLUS) codes??? (please read)
Keywords: VCR+ patent
Organization: PANIX Public Access Unix, NYC
Date: Wed, 6 Jan 1993 05:59:39 GMT

In <1993Jan5.191138.16420@netcom.com> strnlght@netcom.com (David Sternlight) writes:


>As I understand things from my conversations with the inventor of the
>VCR+ ... [stuff deleted]
>they provide the program to the stations on very stringent security
>terms, to compute the codes. That was my info as of six months
>ago--it may have changed--dunno. Back then, I noticed that two
>sources of published codes, the L.A. Times and TV guide occasionally
>had different codes for the same program, which suggests other
>than a central source. (They weren't typos, and both worked.)

I trust that readers of this group have no trouble figuring out why
this would happen -- right?

The VCR+ people provide programs to the LA Times, and to TV Guide,
that are not identical.  Sure the codes work the same from both versions
of the program, but the difference in what is printed in the guide 
makes it possible for the VCR+ people to figure out _which_ copy
of the program was used to create a given set of plus codes.
That way if, say, LA Times started selling codes to TV Guide, or to
someone else, the VCR+ people would be able to blame the LA Times.
We intellectual property lawyers call that a "spike".


-- 
Carl Oppedahl AA2KW  (intellectual property lawyer)
30 Rockefeller Plaza
New York, NY  10112-0228
voice 212-408-2578     fax 212-765-2519
Newsgroups: sci.crypt
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: Another well-intentioned novice's question
Date: Mon, 4 Jan 1993 14:28:17 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <1993Jan04.051300.26089@rat.csc.calpoly.edu>,
by rteasdal@polyslo.csc.calpoly.edu (Rusty):
>                                           ... cryptographic	
> efficiency would be greatly enhanced by compressing a message
> before encrypting it, the better to remove repetitive patterns
> from the plaintext.
> 
> 	I don't see, though, that standard (i.e. LZW) compression
> algorithms actually do remove any of the redundancy from the text;

If you compress text with a good data compression program, the
compressed text looks like a random bit pattern.  Encrypting one
random looking bit pattern typically produces another, and
cryptanalysis of such patterns is far harder than analysis of
encrypted normal text because the compression process has removed
(some of) the redundancy which cryptanalytical techniques rely on
to break codes.

It's also worth noting that many compression algorithms can
themselves be used for (private key) encryption.  The source model
used by the algorithm is, in effect, the key.  For some compression
algorithms, the resulting cryptosystems are pretty weak, but for
others, little is known about their security.

For example, I proposed (in CACM, some years ago) an adaptive
compression algorithm based on splay trees (or splay tries?) where
the initial tree used for prefix code construction is the key.  I
have heard nothing about the security of this algorithm since I
published it, although I believe that it is vulnerable to a
controlled text attack (that is, if you can select the text to be
encrypted, you can infer the key that was used).

If anyone's curious, I have been distributing a UNIX based data
compression utility based on my algorithm for a number of years.
It's about half the speed of LZW and produces equally compact output
(sometimes better, sometimes worse).
					Doug Jones
					jones@cs.uiowa.edu
Newsgroups: sci.crypt,alt.radio.scanner
From: billn@hpcvaac.cv.hp.com (bill nelson)
Subject: Re: AT&T news release
Organization: Hewlett-Packard Company, Corvallis, Oregon USA
Distribution: usa
Date: Wed, 13 Jan 1993 00:19:55 GMT

rschnapp@metaflow.com (Russ Schnapp) writes:
: 
: I've heard about frequency hopping and spread spectrum stuff for over a
: decade now.  It sounds like a great idea, but I have never bothered,
: for some reason, to ask two basic questions:
: 
: 1)  How does it increase range without increasing effective radiated
: power?  If it's simply a matter of raising the effective
: signal-to-noise ratio, how does it accomplish that?

I expect that the increased range is due to using digital transmission - not
to spread spectrum technology.

: 2)  How do the transmitter and receiver agree on the hopping sequence,
: and how do they synchronize?

I would guess that it will scan sequentially through the channels that 
are chosen. That would simplify the software tremendously. Or, since it
is digital, the next channel to be used could easily be transmitted, along
with the voice data. There would be plenty of bandwidth for control signals.

Bill
Newsgroups: sci.crypt
From: karn@servo.qualcomm.com (Phil Karn)
Subject: Re: Anti-spoofing protocol?
Organization: Qualcomm, Inc
Date: Tue, 5 Jan 1993 07:35:26 GMT


Bob Cain suggests the possibility of a spoofer interfering with a
plaintext voice call. Sure, this is certainly possible in theory,
although I wouldn't want the job of doing it in real time between a
pair of speakers who know each other very well.

Nevertheless, this is just one example of the general concept. With
public key cryptography you eliminate the need for confidentiality of
the initial key-setting path, even if you still do need to maintain
authenticity. And that is an enormous practical advantage, because I can
think of *many* non-confidential channels where I can maintain a
pretty high level of integrity in the traffic not being modified.
And I can use several such channels for redundancy.

Phil
Newsgroups: sci.crypt
From: dnadams@nyx.cs.du.edu (Dean Adams)
Subject: Re: KH-11 pictures -
Organization: University of Denver, Dept. of Math & Comp. Sci.
Date: Tue, 12 Jan 93 13:49:17 GMT


kaufman@Xenon.Stanford.EDU (Marc T. Kaufman) writes:

 >>Such a replacement for the SR-71 exists.  I believe that the name 
 >>of the new plane is "Aurora" ...
 >No, you have to say:
 >Such a replacement for the SR-71 does NOT exist.  

No, the *government* "has" to say that... :->

 >IF is existed it's name would probably be Aurora

Well... something exists, but the official name is more than likely no longer
"Aurora" (if it ever was).  But the rest of us have nothing better to call it.

 >it would probably use a pulse ramjet engine that would 
 >leave telltale diamond contrails,
One of the variants could be using PDWE propulsion...

 >and it would make a lot of noise with sonic booms.
Something up there has been shaking up southern cal.

 >After all, the SR-71 didn't exist, either [until Lyndon Johnson 
 >renamed the YF-12].

Not quite.  The YF-12 was around for a while before the SR-71.  The YF-12
first flew in August, 1963, while the SR-71 didn't have it's first flight
until December 23, 1964.  Of course the A-12 beat them both by first flying
on April 26, 1962.  The SR-71 certainly was NOT created simply by "renaming"
the YF-12.  They are considerably different in several areas...

I guess this is pretty much exhausting the sci.crypt relevance,
BUT... the up/downlink from Keyhole satellites use the absolute
very best encryption that NSA can generate!  So I guess not all
of it was off topic...
From: karn@servo.qualcomm.com (Phil Karn)
Newsgroups: sci.crypt
Subject: Re: Anti-spoofing protocol?
Date: 4 Jan 93 10:40:51 GMT
Organization: Qualcomm, Inc

In article <1993Jan4.090057.20269@netcom.com> rcain@netcom.com (Robert Cain) writes:
>
>The problem of detecting a spoof in between two ends of a
>Diffie-Hellman exchange is unsolved, as far as I know, using any known
>protocol.

Why do you say that? You can detect the "ends against the middle"
attack against DH if the parties sign their DH exchanges (using RSA or
some other digital signature scheme) and verify them before using the
DH-generated key to encrypt anything real.

The most I think an active attacker could do against this scheme is to
trick the parties into revealing their public key certificates, if
that matters.

Phil
From: karn@servo.qualcomm.com (Phil Karn)
Newsgroups: sci.crypt
Subject: Re: Ciphers
Date: 4 Jan 93 11:03:56 GMT
Organization: Qualcomm, Inc

In article <R90TwB1w165w@west.darkside.com> sspy@west.darkside.com (mshannon) writes:
>Another question, gentlemen. Suppose someone, the feds or whoever, hace 
>an encrypted disk that they want to crack, but they don't know what 
>cipher was used. How can they find out. Are there programs that will 
>analyze it and make this determination based on the way certain ciphers 
>cipher?

In general, no. By itself, any good cipher produces ciphertext that is
indistinguishable from purely random bits by anyone who doesn't know
the key.  In practice, however, many encryption packages format their
ciphertext output to make it easy for the intended recipient to
recognize as a message encrypted with that particular package. This
will tip off an eavesdropper that a particular system and possibly a
particular set of keys are in use (implying the identities of the
correspondents), even if he can't actually crack the contents.

For example, PGP puts out the "BEGIN PGP MESSAGE" banner, and it
specifies the public key that was used to encrypt the message so the
receiving program knows which of possibly several secret keys to use
to decrypt it. Anyone with a reasonably complete public key collection
can see who an intercepted message is addressed to, at least at the
outermost level (it might contain several levels of encapsulated
encryption, as in some of the anonymous remailer schemes).

Other encryption packages, such as Sun's 'des' command (and the one I
wrote that's compatible with it) produce *no* identifying information
in the ciphertext -- it looks like purely random bits. This has the
advantage of denying an eavesdropper knowledge of the system you're
using, but it has the disadvantage that the user must know, a priori,
which algorithm and key to use to decrypt it. This is okay in a single
key cryptosystem (you could consider the algorithm specifier to be
part of the "key" that you exchange ahead of time) but it is not
practical in a public key cryptosystem, which is supposed to let you
send encrypted messages to someone without special prior arrangement.

On the other hand, it would not be hard to take that little bogus PGP
ciphertext generator I posted the other week and go much farther with
it. It could produce a properly formatted PGP message, with correct
checksums, etc, that causes PGP on the receiving end to prompt for a
totally random and fictictious key. To an eavesdropper, such messages
would be indistinguishable from real PGP messages encrypted with
unknown public keys. One could conceive of generating continuous
streams of such traffic just to provide some haystacks in which to
hide your needles.

Phil
Newsgroups: sci.crypt
From: karn@servo.qualcomm.com (Phil Karn)
Subject: Re: Another well-intentioned novice's question
Organization: Qualcomm, Inc
Date: Tue, 5 Jan 1993 18:45:00 GMT

In article <1993Jan05.160811.29681@rchland.ibm.com> lwloen@rchland.vnet.ibm.com writes:
>But, an illuminating one, I think.  I claim, still, that compression should
>be done as an economy-of-transmission move and not a security move, per se.

And an economy-of-CPU move too. Most compression algorithms, although
somewhat CPU-intensive, are still less so than most encryption
algorithms when implemented in software. So if you compress and then
encrypt you may actually take many fewer cycles than if you just
encrypt.

Phil
From: unruh@physics.ubc.ca (William Unruh)
Newsgroups: sci.crypt
Subject: Re: Any way to *CREATE* Vcr+ (VCR PLUS) codes??? (please read)
Date: 7 Jan 1993 01:57:34 GMT
Organization: The University of British Columbia
Distribution: world
NNTP-Posting-Host: physics.ubc.ca

ptrei@bistromath.mitre.org (Peter Trei) writes:

>      A possibly relevant note appears in John Dvorak's column in the
>Jan 12 PC Magazine. To summarize:

>      Sega sued Accolade, which was making Sega Genesis game
>cartridges without getting licensing from Sega. This suit was settled
>in Accolade's favor with a ruling that:

> * Accolade could make Genesis games without asking Sega's permission.
> * Accolade could reverse engineer the Sega software needed to let the
>   cartridge talk to the machine.
> * Accolade could use a Sega cartridge as a model for the reverse engineering.

>   Dvorak says: "Who says you can't look at the code of the product
>you're reverse engineering? ... This means that software code of a
>competitor now can be examined for the purposes of reverse
>engineering."

That's one Judge on the particulars and peculiarities of one case. Teh
next judge could well ignore this judgement and come to the opposite
conclusion, or say that the case is sufficiently different that this
judgement has no bearing. Ah the fun of the Law.

Newsgroups: sci.crypt