HDTenEightyP/NetNews huggingface dataset:
From: lwloen@rchland.vnet.ibm.com (Larry Loen)
Subject: Re: Attack Methods
Date: Fri, 20 Nov 1992 18:46:19 GMT
Reply-To: lwloen@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <1992Nov20.162319.24428@rchland.ibm.com> I wrote:

>Consider the press release.  It is sent, in encrypted and padded form
>to 100 branch offices of Fortune 500 firm X.  The opponent intercepts
>some of these.

>A day later, the plain text is published verbatim, freely available.
>The opponent counts the bytes and goes "aha".
>
>This sort of thing is not uncommon and would reveal the padding pretty
>readily; deciding which text was the press release is a separate problem,

   ". . .deciding which text was the press release"

  That is to say, which of the many intercepted encrypted messages that
  day was the press release as opposed to some other encrypted message
  sent that day.

>but 100 copies of the same thing is a pretty good clue. . .and this
>exact kind of attack _has_ succeeded many times.  Government crypto
>groups spend a lot of time on it.  They can often correlate very 
>accurately even when the can't solve the cipher.

   "correlate very accurately even when they can't solve. . ."

   That is to say, they can often be very sure about which message is
   the press release even when they can't solve it.  This analysis is
   called "traffic analysis".  As far as I know, there is no way to
   prevent the traffic analysis part in general, though maybe it can
   be beaten off with enough super-encryption.  The basic problem is that
   one can figure out that some message was sent from Washington to Berlin,
   and thereby begin to sort out what messages went with what later public
   text.  Repeated messages (say, a simultaneous press release in
   the same language, released from multiple sites) are especially tough
   to guard against.

   In any case, it is a separate problem, needing to be solved separately,
   and most people don't even know it is a problem.

-- 
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer
Newsgroups: sci.crypt
Subject: Re: Cryptology and criminals
From: jsteiner@anwsun.phya.utoledo.edu (jason 'Think!' steiner)
Date: 18 Nov 92 18:04:49 EST
X-Newsreader: Tin 1.1 PL4

linnoise@bigboy (LineNoise) writes:
> The same holds with cryptography-- limit it so that the abuse by 
> criminals and other hostile bodies will have the capability to 
> misuse it.                             ^
			do you want a "not" in here? how do 
			you propose to enforce this? the same
			way it's "worked" (actually -not- worked)
			for guns?

> Allow only those encryption methods defeatable by the law 
> enforcement agencies to distributed and outlaw the distribution of 
> more powerful methods.

again, how do you enforce this? "more powerful methods" are already
out. should we censor Scientific American? sounds very much like
a police state to me. and it -still- wouldn't work.

> And enforce laws that will help protect the common man's privacy 
> from those who have no business in decrypting his data.

sorry, the police are under -no- obligation to protect you, much less
your data. not only that, but they're already overworked & often
incapable of enforcing the silly laws we've given them. i have a -lot-
of respect for most law enforcement officers, but even they will admit
that we're living in a world where pizza gets to your house faster
than the police. laws don't protect people (or data). -people- 
protect people (and data). take away the individual's ability to protect
themselves & we'll see a society where no one is safe from "those who
have no business in decrypting his data". 99% of the time, that includes
the government.

jason

--
sorry, my .signature is on strike.
Xref: sparky sci.crypt:5029 sci.math:15261 comp.theory:2475
From: srt@duke.cs.duke.edu (Stephen R. Tate)
Newsgroups: sci.crypt,sci.math,comp.theory
Subject: Re: Cryptography and P=NP
Date: 19 Nov 92 20:56:54 GMT
Followup-To: sci.crypt
Organization: Duke University Computer Science Dept.; Durham, N.C.

I tried to send the following by E-mail, but the IBM gateway wouldn't
accept it....


In article <1992Nov19.193036.26711@rchland.ibm.com> you write:
>Or is it, rather, P runs in polynomial time when it finds an answer?  I 
>realise this is very basic, but I have yet to have encountered any significant
>sub-set of programs that are not trivial that can be counted on to halt.

Huh?  I can think of very, very few algorithms (programs) that can not
be counted on to halt.  The only simply stated one has the halting problem:
given a program, decide whether or not it will ever halt.  You will not
be able to guarantee that a program correctly solving this problem will
halt.  Other examples deal with word problems over certain algebras, but
not many people deal with that.  To re-iterate:  programs that cannot
be counted on to halt are very, very, very rare.  Most people will never
see one.

>Surely, it can't be this easy.  I get squeamish whenever I see clocks and
>numbers on arguments of this kind.  Is the cardinality of the set of
>P algorithms == number of natural numbers?  Why doesn't Cantor's diagonal
>argument crop up somewhere and spoil everything?  (I don't necessarily mean
>the original, but an appropriate analog of it).

Yes, the cardinality of polynomial time algorithms is == the cardinality
of the natural numbers.  And you *can* use Cantor's diagonalization on
the set of P algorithms!  This is exactly how you show that there are 
algorithms (in fact, infinitely many of them) that are not in P.  This is the
"hierarchy theorem".  In fact, there many specific problems that you can
prove have no polynomial time algorithm (so the problem is not in P).
Unfortunately, these arguments simply do not work for separating P and
NP.  In fact, it has been shown that no diagonalization argument (ala
Cantor) will be able to separate P and NP --- regardless of how you try
to enumerate polynomial time algorithms. 


-- 
Steve Tate srt@cs.duke.edu | The reason why mathematics enjoys special esteem,
Dept. of Computer Science  | above all other sciences, is that its laws are
Duke University     | absolutely certain and indisputable, while those of all
Durham, NC  27706   | other sciences are to some extent debatable. (Einstein)
Newsgroups: sci.crypt
From: gardner@convex.com (Steve Gardner)
Subject: Re: Weak cryptography >> Key registration
Date: Sat, 21 Nov 1992 23:50:12 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <1ejd00INN894@transfer.stratus.com> cme@ellisun.sw.stratus.com (Carl Ellison) writes:
>I trust the NSA not to be in the pay of the mobs.
	Forever?  How about if things get tough here and government pay
	is cut but drugs haven't been legalized? A combination of a 
	federal government financial crisis (brought on by the federal
	deficit) and increased corruption brought on by the war on
	drugs could put even the NSA in the pay of mobsters  Columbia 
	and Bolivia have already experienced this level of corruption.  
	It could happen here if we don't clean up our act.



>Meanwhile, I'd be surprised if the NSA would bother breaking weak systems (eg.
>straight single CBC DES) just for fun (eg., as a favor to someone (like the
>local police) legally authorized to do the interception).
	What do you suppose that they have to occupy themselves now that
	the Ussr is kaput?  They need the practice don't they? ;-)
	


							smg


Newsgroups: sci.crypt
From: Marc_North@mindlink.bc.ca (Marc North)
Subject: Request for FAQ
Organization: MIND LINK! - British Columbia, Canada
Date: Thu, 19 Nov 1992 01:30:48 GMT

I've looked on various ftp sites for the FAQ to this group, but found
nothing. Could someone please email me a copy of a recent FAQ?

Thanks,

Marc North


--
Marc North  --  The Lanceholder's Group
Newsgroups: sci.crypt,alt.privacy,comp.org.eff.talk
From: uri@watson.ibm.com (Uri Blumenthal)
Subject: Re: A Silver Bullet to Limit Crypto?
Date: Tue, 17 Nov 1992 23:56:59 GMT
Reply-To: uri@watson.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: Get lost.

In article <01010064.iqm1p1@titipu.resun.com>, ed@titipu.resun.com (Edward Reid) writes:
|> > When this brief period finally comes to an end, LE will have to go back
|> > to doing what it did before.
|> 
|> Not exactly.  "What it did before" was part of a world without electronic
|> communication.  Whatever happens wrt cryptography, electronic communication
|> will remain.  The old LE tools are not likely to be applicable.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ bull****
There still are those "traditional" methods, like personal
surveillance, monitoring personal contacts, planting mics,
eavesdropping on terminal emissions and so on. These tools
are perfectly applicable. Besides, how about witnesses, or
evidence (like blooded knife, gun, banknotes with recorded
numbers)?
-- 
Regards,
Uri.		uri@watson.ibm.com
------------
<Disclaimer>
From: bart@netcom.com (Harry Bartholomew)
Newsgroups: sci.crypt
Subject: Re: PKP and RSA
Date: 17 Nov 92 11:26:20 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
X-Newsreader: Tin 1.1 PL5


     You might try email to  jim@RSA.COM (Jim Bidzos)
Newsgroups: sci.crypt,comp.theory,alt.security,sci.math
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt,comp.sys.next.misc
Subject: Re: UNIX Mail with PubKey Encryption
Date: 16 Nov 92 22:54:45 GMT
Organization: Stratus Computer, Software Engineering
NNTP-Posting-Host: ellisun.sw.stratus.com

In article <Bxs60u.JKy@ux1.cso.uiuc.edu> lemson@ux1.cso.uiuc.edu (David Lemson) writes:
>Does blessing = $$$ as it supposedly does now?  (I am under the
>impression that you can use things like PGP if you get a license
>from Public Key Partners)


I had the same thought and checked with RSADSI.  The answer is that
PGP has problems other than RSA license and they won't license it.

However, they'll sell you a package of their own called Mailsafe ($50
for network people, I believe) -- or give away the code (and license)
which lets you make a PGP look-alike.  The latter is called RSAREF.

-- 
-- <<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
From: mvanheyn@whale.cs.indiana.edu (Marc VanHeyningen)
Newsgroups: sci.crypt
Subject: Re: ripr - sh script to pipe ripem-encrypted files to in elm
Date: 21 Nov 92 01:21:55 GMT
Organization: Computer Science Dept, Indiana University
X-Quoted: 55%

Thus said boucher@csl.sri.com (Peter K. Boucher):
>
>------------- clip clip -----------------------
>#!/bin/sh
># ripr [output_plaintext_file_name] < encrypted_file_name
># Decrypts and saves a RIPEM-encrypted file (from stdin) - pipe to this from ELM.
># Edit the following variables to reflect your situation before using this script.
>ripem="$HOME/bin/src/ripem/main/ripem"
>pubkeys="$HOME/bin/src/ripem/main/pubkey.ripem"
>seckeys="$HOME/bin/src/ripem/main/seckey.ripem"
>user_id='boucher@csl.sri.com'
>tmp_crp="$HOME/bin/r_${$}.crp"

This stuff, too, is in the environment.

BTW, thanks for using a Real Programming Shell; many people would try to
write this using <gag> cshell.

If I use this script, how exactly am I supposed to know who the message
is from?
-- 
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted
"If it were not for the First Law of Thermodynamics, all bright students
of mechanical engineering would want to work on perpetual motion!"
		- Maurice Wilkes on AI
Newsgroups: sci.crypt
From: jdailey@dadd.ti.com (Jim Dailey)
Subject: Re: unpredictable random generators (terminology)
Followup-To: sci.crypt
Reply-To: jdailey@dadd.ti.com
Organization: Design Automaton Div., Texas Instruments, Inc.
Date: Thu, 19 Nov 1992 17:04:19 GMT

pom@anke.imsd.uni-mainz.DE (Prof. Dr. Klaus Pommerening) writes:
>In article <1992Nov12.171127.2162@ee.eng.ohio-state.edu>  
>> ...  How about trying on a new acronym,
>> too: URNG for Unpredicatble Random Number Generator, to distinguish RNGs
>> that are designed for cryptography from the typical PRNGs?
>
>In the literature there is a certain confusion as to how call this sort
>of (unpredictable) pseudo-random generators. Examples are:
> - secure
> - unpredictable
> - cryptographically strong
> - perfect
>I prefer the latter term, because it is so short, and, more
>important, the cryptographic strength implies that the generator
>passes all efficient statistical tests -- truly perfect, isn't it?

It's perfect with the exception of the ensuing acronymn conflict: does PRNG
mean "Pseudo Random Number Generator" or "Perfect Random Number Generator"?
I rather like URNG.

---
Jim  jdailey@dadd.ti.com
   TI pays absolutely no attention to me or my opinions; therefore,
   the foregoing posting cannot possibly represent TI's viewpoint.
From: knight@hal.gnu.ai.mit.edu (Nighty Knight)
Newsgroups: sci.crypt
Subject: PKP and RSA
Summary: Questions about getting in touch with PKP
Date: 17 Nov 92 04:37:27 GMT
Organization: Some, you'd be surprised.


     I'm interested in getting in touch with PKP about the distribution
of RSA licenses, but I don't have any information about them to get in
touch -- address, phone number, or even examples of how they conduct
the licensing process -- by flat fees or by royalties.

     Thanks in advance.

   - Eric
Newsgroups: sci.crypt
From: xmtalk@miller.cs.uwm.edu (J. Lu R. Keeler)
Newsgroups: sci.crypt
Subject: DES stream encryption code needed
Date: 16 Nov 1992 01:39:47 GMT
Organization: University of Wisconsin, Milwaukee
Distribution: world
NNTP-Posting-Host: 129.89.9.13
Summary: DES stream encryption code needed


I need a code or a site that has a code for encrypting individual 
(8 bit) characters on the fly using DES. I have the code
for block encryption(64 bits) so don't give me that. This is needed 
to a project I am working on and is greatly needed.

Thanks in advance!

Robert J Keeler
xmtalk@miller.cs.uwm.edu
---
Xref: sparky sci.crypt:5162 sci.math:15353 comp.theory:2504
From: ramsay@math.ubc.ca (Keith Ramsay)
Newsgroups: sci.crypt,sci.math,comp.theory
Subject: Re: Cryptography and P=NP
Date: 21 Nov 92 23:39:18 GMT
Distribution: inet
Organization: University of British Columbia, Vancouver, B.C., Canada
NNTP-Posting-Host: gauss.math.ubc.ca

In article <1992Nov21.191944.87493@Cookie.secapl.com>
frank@Cookie.secapl.com (Frank Adams) writes:

>Given a problem which actually is in NP, this universal machine will in fact
>solve it in polynomial time if P=NP -- indeed, it will solve any problem in
>P, given an NP formulation, in polynomial time.  If the NP problem is in not
>in P, it will always halt, but will not necessarily run in polynomial time.

There is a problem with what you say here. Suppose we have a problem
formulated as an NP problem, but which is in fact in P. This
"universal" algorithm will indeed halt in polynomial time for the
cases for which the answer is "yes" (by finding the "non-deterministic
guess" required to show that the answer is indeed "yes"). If the
answer to the problem is "no", however, one may not know when to stop
looking for a positive answer. For it really to solve such a
problem-class in polynomial time, it has to have some rule for
determining when to say "no".

Keith Ramsay
ramsay@unixg.ubc.ca
Newsgroups: sci.crypt
From: Marc VanHeyningen <mvanheyn@whale.cs.indiana.edu>
Subject: Re: ripr - sh script to pipe ripem-encrypted files to in elm
X-Quoted: 43%
Organization: Computer Science Dept, Indiana University
Date: Sat, 21 Nov 1992 12:29:55 -0500

Thus said boucher@csl.sri.com (Peter K. Boucher):
>Marc VanHeyningen writes:
>|>
>|> This stuff, too, is in the environment.
>
>I only started using ripem a couple of days ago, and found it painful to use.
>These scripts definitely made it better.  If you have something useful to say,
>say it.  Otherwise, me'tetelo por donde no llega el sol.

I like RIPEM, and I hope that it will gain wide use.  To this end, I
would like to see good, well-written scripts which provide a user
interface for it.

I believe that posting scripts for interface to RIPEM when RIPEM hasn't
even been released yet is not a good idea.

>|> BTW, thanks for using a Real Programming Shell; many people would try to
>|> write this using <gag> cshell.
>
>BOURNE STRIKES AGAIN!!!

heh heh...

>|> If I use this script, how exactly am I supposed to know who the message
>|> is from?
>
>The header's in the clear, and you can choose the name of the output file.

Which header do you mean exactly?  Elm normally shows you the From:
header, which cannot be trusted...

>Do you have something better?  How about sharing it?

I have something I believe works well, although it's written with MH in
mind.  I mentioned it in a previous post, and it's been ftp'd to the
RIPEM site.  It still could use some improvements, such as adding easy
responses to messages; I'll do them when I got time...
-- 
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted


Family values are much too important to allow politicians into them.
Newsgroups: sci.crypt
From: feustel@netcom.com (David Feustel)
Subject: Re: address, phone # list of congress
Organization: DAFCO: OS/2 Software Support & Consulting
Date: Fri, 20 Nov 1992 01:43:53 GMT

How about an updated list with the names and addresses for the NEXT
congress so we can get our letters in early?
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
GE knew there was lots of money to be made in the diagnostic medical
machine field since it was only a matter of time before people started
getting sick from the effects of all of GE's toxic and radioactive
waste dumping. I expect GE to get into the Mortuary business next.
From: polk@Metaphor.COM (Ben Polk)
Newsgroups: sci.crypt
Subject: Question about USA crypt export restrictions
Date: 19 Nov 92 19:35:09 GMT
Reply-To: polk@Metaphor.COM (Ben Polk)
Organization: m4

Do the US crypt export restrictions prohibit distibution of
executable code that uses RSA to protect passwords?  I seem
to remember hearing the restrictions were limited to things
that could be used to encrypt arbitrary data.

Ben Polk
polk@metaphor.com
From: m1tca00@fed.frb.gov (Thomas C. Allard)
Newsgroups: sci.crypt
Subject: Re: PGP and real criminals
Date: 18 Nov 92 17:22:41 GMT
Reply-To: m1tca00@fed.frb.gov (Thomas C. Allard)
Organization: Federal Reserve Board, Wash, DC

In article <1992Nov17.001101.21926@ncar.ucar.edu>, prz@sage.cgd.ucar.edu (Philip Zimmermann) writes:
[lots deleted]
> First, on item (1):  This guy is a repeat offender, who just started
> using PGP after getting out of jail from last time.  Carefully
> evaluating everything the cop told me, I was convinced the guy was
> probably guilty.  But these cases are hard to prove in court, and as
> most people know, there are usually a lot more facts known in a case
> than what is admissible in court.  Ah, you say, that was not
> explained.  But even so, why should you be so sure of yourself when
> you so glibly assert that the cops had absolutely nothing on this guy
> except the fact that he had some encrypted files?
> 
[lots more deleted]

1. Inncocent until PROVEN guilty.  That is his constitutional right.  Maybe you think that it is a bad policy, but it is (supposed to be) a right in this country.  If you want to debate this, it wouldn't belong in sci.crypt so I'll do everyone a favor by just leaving it at that.

2. Right to remain silent.  Again, it is a (supposed) constitutional right that citizens are not required to testify against themselves.  I see no reason why that should not extend to one's private papers.  I believe that, on balance, this right is a good thing (and, like (1) above, this isn't the place to debate the rights of the citizens).  I see encryption as a means of protecting that right from a hostile government (even paranoids have real enemies).

This thread's been going on for a while, so I'm trying to be brief here...  The bottom line is that if people do not agree with (1) and (2) above, they will likely be hostile to the use of cryptography as a means of protecting these rights (and for you logic fans, you'll note that this does NOT imply that if they agree with (1) and (2) then they will support cryptography).  

Consider how would you convince someone that a "bad" person (like, say, Ronald Reagan :) should be allowed to say what he likes if that person doesn't accept free speech to begin with.

rgds-- TA  (uucp: uunet!fed!m1tca00 | internet: m1tca00@fed.frb.gov)
[implied disclaimer]

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

mQCNAisD0LIAAAED/iySMqSjhdDpeer8AVNJNzRTh61uIgGHVwkczinCxLs9fp4w
6V96UxImXqAGXn9lwNTPYu1cnahFnfaGqNG4AMtOrcVdfcisRHxbOdgCExnKVRAH
BN0c+XoZ+HLVB2ryB+lyEC2C6nR2NV64DneZE+jCKUD9S7H6F2Oj3mNEdldnAAUR
tCBUb20gQWxsYXJkIDxtMXRjYTAwQGZlZC5mcmIuZ292Pg==
=btzW
-----END PGP PUBLIC KEY BLOCK-----
Newsgroups: sci.crypt
From: rcain@netcom.com (Robert Cain)
Subject: Re: URNG
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sat, 21 Nov 1992 16:27:54 GMT

I should have attributed that IDEA code fragment to Richard De Moliner
of the Swiss Federal Institute of Technology.  Now that I think about
it it probably would be fine to seed the dataIn with all zeros and
begin the URNG stream with the first output.  Only the key then would
need be known by two people to generate the same stream. 

I forgot the Mul() function and some constants.  They are included below.

Bob

#define mulMod        0x10001 /* 2**16 + 1                                    */
#define addMod        0x10000 /* 2**16                                        */
#define ones           0xFFFF /* 2**16 - 1                                    */

#define nofKeyPerRound      6 /* number of used keys per round                */
#define nofRound            8 /* number of rounds                             */

/* multiplication                                                             */

u_int32 Mul(a, b)

u_int32 a, b;
{
	int32 p;
  u_int32 q;
  
  if (a == 0)
		p = mulMod - b; 
  else if (b == 0)
		p = mulMod - a;
  else
	{
		q = a * b;
		p = (q & ones) - (q >> 16);
		if (p <= 0)
			p += mulMod;
	}
  return (u_int32)(p & ones);
} /* Mul */
-- 
Bob Cain    rcain@netcom.com   408-358-2007

"There are some strings.  They're just not attached."
                                                    Victoria Roberts


               PGP 1.0 or 2.0 public key available on request.
Newsgroups: sci.crypt
From: caronni@nessie.cs.id.ethz.ch (Germano Caronni)
Subject: Re: Attack Methods
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Thu, 19 Nov 1992 21:50:29 GMT

You are discussing the act of padding an encrypted text so, that there
are no peaks in any statistic whatsoever. How about encrypt the whole text,
analyze character-frequencies, and sequences of characters, and then pad
the text in predefined places with characters that flatten the peaks or create
wrong peaks in some sorts of statsistic you would like to apply ? As long as
the opponent does not *know* you have added these pads, perhaps this will
work ?
Other ideas ?
	
	gec
-- 
Instruments register only through things they're designed to register.
Space still contains infinite unknowns.

Germano Caronni    caronni@nessie.cs.id.ethz.ch
Newsgroups: sci.crypt