HDTenEightyP/NetNews huggingface dataset:
From: strnlght@netcom.com (David Sternlight)
Subject: Re: Nonlinear Amplification of Information
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Sat, 9 Jan 1993 22:43:35 GMT

Robert Cain posts another of the distortions I've grown used to from him:

In article <1993Jan9.221553.4648@netcom.com> rcain@netcom.com (Robert Cain) writes:
>I have watched and crossed swords with Mr. Sternlight before in other
>groups.  One thing to know about him is that in whatever group or
>discussion in which he participates he manages to find the most
>extreme, unpopular and self serving position he can to draw the most
>flames, contoversy and attention.

Since I have no interest in ripem vs. pgp, or in RSA, and as I've
said to some I actually like the PGP interface much more, my
messages can hardly be called self-serving.

>He argued vociferously in a local netcom group that
>most of us there had no right to be on the internet because we had no
>"legitimate" academic or research purposes whereas he of course did.

This is another of Cain's falsehoods. The issue was playing games,
MUDs, etc. at public expense, and I argued that one might question
this based on the NSF guidelines. Very few users, not "most of us"
were involved in doing that. Cain didn't much like that suggestion,
and responded with personal invective of the sort his current message
is a comparatively restrained example.

The rest of Cain's message consists mostly of personal attacks, and
i won't dignify them with a reply.

I will point out that he's one who seems to be deliberately violating
RSA's patents by offering to correspond in both PGP 1.0 and 2.0
from a site actually quite near to RSA's offices in Northern
California, and that perhaps reveals more about Cain than anything
I can say.

David
-- 
David Sternlight
RIPEM Public Key on server  --  Consider it an envelope for your e-mail

Newsgroups: sci.crypt,alt.security.ripem
From: strnlght@netcom.com (David Sternlight)
Subject: Re: What's troubling Dave Sternlight now....
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Date: Fri, 8 Jan 1993 16:11:39 GMT

In article <PCL.93Jan8095731@rhodium.ox.ac.uk> pcl@ox.ac.uk (Paul C Leyland) writes:
>
>For what it's worth, one of these photos made the back page of _The Times_
>(of London).  It was printed quite large -- about 7" by 4" -- and showed
>lots of detail.  I remember being somewhat surprised that pictures of
>that quality were being published in a national newspaper.

This is a bit off the subject, but the reason pictures of that quality
were published is that one of the "secrets" in this area is just how
high the resolution of reconnaisance satellites is. Every so often
we read an episodic speculation ("able to read a license plate in
a parking lot") in Aviation Week or elsewhere. By publishing the
pictures in as high quality as possible, The Times was answering
the question by implication, and cleverly enough that the Official
Secrets Act folks didn't twig that that's part of what they were doing.

David



-- 
David Sternlight
RIPEM Public Key on server  --  Consider it an envelope for your e-mail

Newsgroups: sci.crypt
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Motorola 'Secure-Clear' Cordless Telephones
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 4 Jan 1993 12:30:32 GMT

In article <C05JAM.MJL@ais.org> tim@ais.org (Tim Tyler) writes:
+---------------
|      For those of you not familiar with speech inversion, it simply
| flip-flops the voice spectrum so that high pitched sounds are low,
| & vice versa.  It sounds a lot like Single Side Band (SSB)
| transmissions, although an SSB receiver will not decode speech-
| inversion scrambling.
+---------------

As a general statement, incorrect. If the sending radio uses AM, DSB, or SSB
modulation, it's trivial. All you have to do is listen to the upper sideband
of the speech-inverted signal as if it were a *lower*-sideband signal! Or
vice-versa, it doesn't matter. (You will of course have to manually search
for the inversion frequency.)

What you *may* have meant is that inverted speech sent via *FM* (such as
49 MHz cordless phones) cannot (easily) be received with an unassisted SSB
receiver. This is more nearly true, but still not a great protection:

1. Many cheap FM transmitters often have a significant AM component,
   sometimes even enough for an SSB receiver to be used as above
   (though with considerable other "garbage" leaking through).

2. If the FM "deviation" is large, there will be significant AM-like sidebands
   that might be listened to with an SBB receiver with sufficiently narrow
   filters. [O.k., my math's weak on this one. Maybe Phil Karn or some other
   radio-knowledgable type could comment further on this case.]

3. There also may be other "spurious emissions" from the FM set that a good
   AM or SSB set could snoop [such as amplitude variations of an oscillator
   due to poor power-supply filtering between the audio & RF sections of the
   phone]. Just because something meets FCC "Part 15" doesn't mean that it's
   of "TEMPEST" quality...

4. Finally, one simple way to decode speech-inverted FM is to send the audio
   output of an FM receiver (scanner) into an ordinary AM (or SSB) transmitter
   (such as an AM "wireless mike"), and then listen to the output of *that*
   with your SSB receiver on the "wrong" sideband. [This is in fact sort of
   how speech-inversion receivers work internally, using a 10's to 100's of
   KHz internal "AM" channel, and "SSB" reception of the "wrong" sideband by
   filtering (then "carrier-injection", then "AM reception").]

In any case, we all agree that speech-inversion is hardly secure.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Xref: sparky sci.crypt:6484 alt.security:5276 alt.security.pgp:463
Newsgroups: sci.crypt,alt.security,alt.security.pgp
Subject: PGP 2.1 source posted to alt.sources
From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
Date: Thu, 7 Jan 1993 11:53:35 GMT
Organization: Computer Science Dept. University of Auckland

-----BEGIN PGP SIGNED MESSAGE-----
 
I have posted the PGP 2.1 sources to alt.sources - see the posting itself for
more details (I assume everyone knows what PGP 2.1 is :-).
 
Peter.
 
-----BEGIN PGP SIGNATURE-----
Version: 2.1
 
iQCVAgUBK0wZd/oRqumdmX1HAQH54wP+NxF1ydxSAnfq2Hu4SaaA+nPE5hUO5hlL
m+sNxfNO21vF4F+PWbBnDPG54RkZt5yLXQFdrJUrqvO1mupbohvpS5idxjGifNxu
ReRCrYxrTrjyZoF1NPnp1hoXfo+VF2UK1v98HfaA8E0hsloaQJJA/Q5RSiU5iNIG
wjg5TF7GIX4=
=bsVc
-----END PGP SIGNATURE-----
--
 pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz
peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz
              (In order of preference - one of 'ems bound to work)
           -- Whoever dies with the most email addresses ... wins --

Newsgroups: sci.crypt
From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
Subject: Encryption plus compression (Was: Another well-intentioned novice's quest)
Reply-To: jhull@vulcan-gw.den.mmc.com
Organization: Martin Marietta Astronautics Group
Date: Tue, 5 Jan 1993 19:50:04 GMT

I thought that compression prior to encryption added "more than might
otherwise be expected" strength to a system because it made differential 
cryptanalytic attacks difficult or impossible.

Am I missing something here?

--- --- --- --- ---
	   _   _
    /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir  
/_/ \_/ /   /	  Aurora, CO 80012    303-977-1061

No matter where you go ... there you are.
#include <standard.disclaimer.h>
From: marc@tanda.isis.org (Marc Thibault)
Newsgroups: sci.crypt
Subject: Re: Zimmermann's responses to Sidelnikov's PGP critique
Date: Sun, 10 Jan 93 09:14:15 EST
Reply-To: marc@tanda.isis.org
Distribution: na
Organization: Thibault & Friends

In article <1993Jan8.193153.4336@netcom.com> 
(David Sternlight) writes: 

> In my many individual visits to the Soviet Union at the personal
> invitation of the Soviet Academy of Sciences, and in my discussions

        The kimono begins to open...

> It's inappropriate to take his remarks as if they were those of some
> competitive programmer picking nits about PGP's program code.  It's
> especially inappropriate to take a confrontational attitude.

        David, chill out. There is nothing in Phil's response that
        indicates a confrontational attitude. He is clearly open to
        the possibility that his implementation of MD5, RSA or IDEA
        are faulty. On the otherhand, it's harder to accept a
        suggestion that these methods are inherently weak. Phil is
        right that this needs some reproducible experimental data.

        Unfortunately, the text is so bad that there's no way to be
        certain just what Sidelnikov _is_ saying. It's hardly
        convincing if you consider that, if David is right, these are
        the people that have spent their lives decrypting US, British,
        and Canadian messages. Surely one of them, or someone they
        know, must actually speak the language?

        Can Sidelkov have such an ego that none of his people had the
        courage to suggest improvements to his text? Given David's
        description of the man, this is hardly likely.

        PARANOIA ON:
        Could this be ploy? If it is, PGP must be pretty darned good!
        :PARANOIA OFF

> Finally, I'd suggest extreme politeness in responding to Sidelnikov,
> and no little respect.

        David, that's a good idea. Why don't you take a little time
        from shilling for RSA and spend it with Sidelnikov. You could
        bring to him our real concern and help the rest of us
        understand what he is trying to warn us about.

        Cheers,
                Marc

---
 Marc Thibault        |  Automation Architect        |  All we are saying
 marc@tanda.isis.org  |  R.R.1, Oxford Mills,        |  is give global
 CIS:71441,2226       |  Ontario, Canada  K0G 1S0    |  warming a chance.
 NC FreeNet: aa185    |                              |

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0

mQBNAiqxYTkAAAECALfeHYp0yC80s1ScFvJSpj5eSCAO+hihtneFrrn+vuEcSavh
AAUwpIUGyV2N8n+lFTPnnLc42Ms+c8PJUPYKVI8ABRG0I01hcmMgVGhpYmF1bHQg
PG1hcmNAdGFuZGEuaXNpcy5vcmc+
=HLnv
-----END PGP PUBLIC KEY BLOCK-----



Xref: sparky sci.crypt:6351 alt.security.pgp:451
From: juha@elixir.elixir.e.kth.se (Juha Sarlin)
Newsgroups: sci.crypt,alt.security.pgp
Subject: PGP 2.1 uses a constant "random" prefix
Date: 4 Jan 93 15:42:58 GMT
Organization: School of EE, Royal Institute of Technology, Sweden

The first block in the IDEA-encrypted part of a message is supposed to
contain random data.  In most cases PGP 2.1 uses the very non-random
pseudorand() function to generate this data.  For example, encryption
with the command "pgp -e foo prz" always gives this data in the first
block: DC 19 22 C7 98 E5 BE F3.  One way to improve the randomness
would be to initialize the randseed variable with something more
unpredictable than the currently used constant.  Unfortunately this
would still give only 256 different values, because the least
significant byte from pseudorand() has a cycle length of 256.

The patch below replaces the pseudorand() function with a little
better one.  It might be even better to use something like the
idearand() function instead.

*** 1.1	1992/12/27 15:28:45
--- random.c	1993/01/04 14:04:43
***************
*** 43,44 ****
--- 43,85 ----
  */
+ #define MINIMAL_STANDARD_PSEUDORANDOM
+ #ifdef MINIMAL_STANDARD_PSEUDORANDOM
+ /**
+  ** Minimal Standard Pseudo-Random Number Generator
+  **
+  ** Author: Fuat C. Baran, Columbia University, 1988
+  **
+  ** Based on code in "Random Number Generators: Good Ones are Hard to Find",
+  ** by Stephen K. Park and Keith W. Miller in Communications of the ACM,
+  ** 31, 10 (Oct. 1988) pp. 1192-1201.
+  **
+  ** Requirements: maxint must be 2^31 -1 or larger.
+  **/
+ 
+ /* some constants we need */
+ #define A 16807
+ #define M 2147483647			/* Mersenne prime 2^31 -1 */
+ #define Q 127773			/* M div A (M / A) */
+ #define R 2836				/* M mod A (M % A) */
+ 
+ int pseudorand(void)
+ {
+ 	long hi, lo;
+ #ifdef DEBUG
+ 	static int seed = 1;
+ #else
+ 	static int seed = 0;
+ 	if (!seed) {
+ 		seed = clock();
+ #ifdef UNIX
+ 		seed += getpid();
+ #endif
+ 	}
+ #endif
+ 	hi = seed / Q;
+ 	lo = seed % Q;
+ 	if ((seed = A * lo - R * hi) <= 0)
+ 		seed += M;
+ 	return seed;
+ }
+ #else
  static int randseed=0; /* used only by pseudorand() function. */
***************
*** 49,50 ****
--- 90,92 ----
  }	/* pseudorand */
+ #endif
  
*** 1.1	1992/12/27 15:10:44
--- system.c	1993/01/04 13:25:41
***************
*** 336,337 ****
--- 336,338 ----
  	struct rusage ru;
+ 	struct timeval t;
  
***************
*** 338,340 ****
  	getrusage(RUSAGE_SELF, &ru);
! 	return ru.ru_utime.tv_sec + ru.ru_utime.tv_usec +
  		ru.ru_stime.tv_sec + ru.ru_stime.tv_usec +
--- 339,342 ----
  	getrusage(RUSAGE_SELF, &ru);
! 	gettimeofday(&t, NULL);
! 	return t.tv_usec + ru.ru_utime.tv_sec + ru.ru_utime.tv_usec +
  		ru.ru_stime.tv_sec + ru.ru_stime.tv_usec +
--
Juha Sarlin   juha@elixir.e.kth.se or juha@tds.kth.se
Xref: sparky sci.crypt:6647 alt.security.ripem:97
From: strnlght@netcom.com (David Sternlight)
Newsgroups: sci.crypt,alt.security.ripem
Subject: Re: Complete ITAR Available
Date: 11 Jan 93 17:29:18 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)

In article <CKD.93Jan10211803@loiosh.eff.org> ckd@eff.org (Christopher
Davis) writes:

>
>Even if this is the case, that would imply (in my layman's understanding)
>that export of RIPEM would be legal, which would make it possible for those
>both inside and outside the US and Canada to use it, and make it a
>practical cross-border public-key encryption system.

RSA's attorneys say not, at least with respect to RSAREF, which right now
is an essential part of RIPEM. Let's leave it there instead of continuing
to repeat ourselves.

David
-- 
David Sternlight
RIPEM Public Key on server  --  Consider it an envelope for your e-mail
Newsgroups: sci.crypt
From: karn@servo.qualcomm.com (Phil Karn)
Subject: Re: Anti-spoofing protocol?
Organization: Qualcomm, Inc
Date: Tue, 5 Jan 1993 03:18:05 GMT

In article <1993Jan4.215027.17258@netcom.com> rcain@netcom.com (Robert Cain) writes:
>This all assumes that you have a secure means of getting your public key
>to the other or an authenticated one.  Both seem equivalent in the end
>to swapping a secret key to me.  This makes me question the fundamentals
>of PK actually.

Why do you say that? An authenticated channel is much easier to get
than an authenticated and secret channel. I can get pretty good
authentication right now by calling up somebody on the phone whose
voice I know well and exchanging MD5 hashes of whatever information we
want to authenticate (e.g., a public key).  I could care less if
somebody eavesdrops this call, but I certainly *would* care if we were
exchanging secret DES keys instead.

Phil
Newsgroups: sci.crypt
From: frank@hsr.no (Frank A Stevenson)
Subject: Fraction part of squareroots as one time pads ?
Organization: Rogaland University Centre
Date: Mon, 11 Jan 1993 11:13:51 GMT

At one time I calculated pi and e with several houndred thousand decimal digits,
and after taking interest in cryptology the question sprung to mind: Would it be
safe to use the binary expansion of an irrational number as a one time pad. To my
knowledge suche sequences of bits exhibits no knowns statistical patterns, and
provided the key is large enough >60 bits, the one time pad would be sufficently
hard to find.

If I where to use a 68000 processor for the implementation of this scheme two
difficulties arises:

1) Taking square roots is rather expensive, and this limits the size of the
message to be encrypted.

2) For effeciency reasons it is best to extract square roots limited to 32 bits
of length. (The greatest divisor fopr the DIVU command) This provides a rather
limited key space.

To give a remedy to point 2, would it be possible to extract the square roots of
two 32 bits numbers and subtract them to give a key length of 64 bits (addition
would only give 63 bits). Given that no more than one of the keys are a square
number (giving a 000000... bit sequence) would the bit sequens exhibit any known
weakness?

Any comments would be welcome.

	Frank


-- 
><>
Newsgroups: sci.crypt
From: schneier@chinet.chi.il.us (Bruce Schneier)
Subject: Bit Commitment
Organization: Chinet - Public Access UNIX
Date: Fri, 8 Jan 1993 00:28:51 GMT

Bit commitment is an easy protocol.  Alice commits to a bit (or a series
of bits) in such a way that Bob does not know what the bits are until Alice
tells him, and Alice cannot change her bits once she has commited to them.

What I am looking for is a real-world example of where this protocol would
be useful (besides magic tricks).  It can be a computer example, or it could
be a non-tech example.  Useful is good.  Interesting is better.  Humorous
is best.

Any suggestions?

Bruce
From: scs@ziggys.cts.com 619/262-6384 (Stewart C. Strait)
Newsgroups: sci.crypt
Subject: Re: another well-intentioned novice's question
Date: 6 Jan 93 19:08:55 GMT
Organization: Ziggy's Den Of Iniquity, East of East SD CA

I'm something of a novice myself, but I suspect that the added security
from compression before encryption will vary from negative (message
easier to break) to enormous.  Consider an adversary who can carry
out a known plaintext attack in some time t, with n bits of plaintext.
Further suppose that this adversary can only attack unknown plaintext
problems by succesive guesses at "probable words" n bits long.

If the compression algorithm starts the message with a fixed string
of bytes, or introduces some other regularity, one or a few guesses
at probable words may be enough.  On the other hand, if n is somewhat
large (I would guess 100-1000 bits) and the compression reduces a
lot of common strings longer than n bits to ones a lot shorter, the
task might be very difficult.  The extreme case is where the 
compression is perfect in the eyes of the adversary, that is, based
on the adversary's state of knowledge, all compressed messages of
the same length as the intercepted one are equally likely.  In
this case cryptanalysis is impossible unless the encryption lengthens
the message in such a way that only one compressed message can yield
the given ciphertext.  I do wish to emphasize that perfect compression
implies perfect knowledge of your adversary's knowledge of the
probabilities of all plaintexts, and thus is usually an unreasonable
possiblity to even approach.

              scs@ziggys.cts.com - BBS (619)262-6384
                 Ziggy's Den Of Iniquity
From: rlward1@afterlife.ncsc.mil (Robert Ward)
Newsgroups: sci.crypt
Subject: Re: Primitive Polynomials (Mod 2)
Keywords: Primitive Polynomials (Mod 2)
Date: 11 Jan 93 18:38:29 GMT
Followup-To: sci.crypt
Organization: National Computer Security Center

1) Brillhart and Zierler are merely informing you that they had not, at the 
time of publication of their article, tested those T_n,k(x) for primitivity, 
only for irreducibility.  

2) The correct statement is that if f(x) is a primitive irreducible polynomial
over of degree n, then so is x^n*f(1/x) [after multiplying through to clear 
fractions].  This implies your first statement (for trinomials).  Tetranomials
can never be irreducible, much less primitive:  they are divisible by x + 1.  
This also implies that x^p + x^q + x^r + x^s + 1 primitive iff 
x^p + x^(p-s) + x^(p-r) + x^(p-q) + 1 primitive.

Robert L. Ward
From: muenx@heike.informatik.uni-dortmund.de (Holger Muenx)
Newsgroups: sci.crypt
Subject: How fast is DES?
Date: 7 Jan 1993 14:06:14 GMT
Organization: University of Dortmund, Germany
Distribution: world
NNTP-Posting-Host: heike.informatik.uni-dortmund.de
Summary: Fast implementation needed


Guten Tag!

  Due to the complexity of the DES algorithm involving various bit
swapping and table lookup operations during multiple iterations I am
wondering how fast the DES is in praxis.

  Is it possible for a software solution to reach an encryption rate
of about 100kB/sec (read 100 * 1024 Byte not 100 * 1024 Bit per second)
on a typical PC (say, Intel 386DX 33MHz)?

  If not: are there any other secure encryption/decryption algorithms
which are running faster?

  Any information will be appreciated. Many thanks in advance for your
help!

                                                   -Holger

==============================================================================
| Holger Muenx                        muenx@heike.informatik.uni-dortmund.de |
| -------------------------------------------------------------------------- |
| "... diese ewig fortlaufende Mechanik ist es, die sie hindert, gleich mir, |
| Kritik am eigenen Leben zu ueben, seine Dummheit und Seichtheit, seine     |
| scheusslich grinsende Fragwuerdigkeit, seine hoffnungslose Trauer und Oede |
| zu erkennen und zu fuehlen." (Hermann Hesse)                               |
==============================================================================
From: bz223@cleveland.Freenet.Edu (Danny Guy Frezza)
Newsgroups: sci.crypt
Subject: New Motorola Secure-Clear Cordless phones coming
Date: 8 Jan 1993 21:50:25 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: bz223@cleveland.Freenet.Edu (Danny Guy Frezza)
NNTP-Posting-Host: hela.ins.cwru.edu


	I just read today's USA Electronic Edition of "telecommunications",
that Motorola has announced four, new, "secure-clear" models of their phones.
	Does anyone have any information on these new models, in terms of
the "security-part" of the cordless phone?

	Also, it seems that security of voice transmissions by cordless
phones, will take a new jump down after reading today, on USA Electronic
Edition of "telecommunications", that AT&T will release for sale new
Cordless phones, priced around $499, that will send voice-transmissions
about a mile from its base unit.  Interesting that AT&T does not add
any security at all to it.

-- 

Dan Frezza
Internet: bz223@cleveland.Freenet.Edu
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt
Subject: Re: Encryption plus compression (Was: Another well-intentioned novice's quest)
Date: 7 Jan 1993 07:06:47 GMT
Organization: Stratus Computer, Software Engineering
NNTP-Posting-Host: ellisun.sw.stratus.com

In article <1993Jan6.215140.18753@ee.eng.ohio-state.edu> butzerd@blanc.eng.ohio-state.edu (Dane C. Butzer) writes:
>Sorry if this has been brought up, but don't many compression programs put
>some type of table at the start of the compressed file (defining what
>characters map to what uncompressed sequences, for example)?

>Seems
>like you'd have to be careful to avoid this (although I don't know how you
>would).

Most compression programs put some known header on the data.

One way to avoid it is to follow the compression with a substitution (eg.,
XOR) or transposition using as many bytes of key as there are bytes of
known header in the compressed file.

The transposition scatters the known header bytes to unknown locations.
The substitution encrypts the header with a 1-time pad (the key, which
should be different for each message).  Each adds as much key as the
compressor added trivial redundancy, bringing the unicity distance back to
what it would have been had there been no header.

The output of that encryption then gets fed to the normal encryption
algorithm, of course.

-- 
-- <<Disclaimer: All opinions expressed are my own, of course.>>
-- Carl Ellison						cme@sw.stratus.com
-- Stratus Computer Inc.	M3-2-BKW		TEL: (508)460-2783
-- 55 Fairbanks Boulevard ; Marlborough MA 01752-1298	FAX: (508)624-7488
Newsgroups: sci.crypt