HDTenEightyP/NetNews huggingface dataset:
From: Erik.Lindano@ofa123.fidonet.org
Newsgroups: sci.crypt
Subject: New ENcryption - a Challenge
X-Sender: newtout 0.02 Nov 17 1992
Date: 18 Nov 92  21:52:50

Writes marc@tanda.isis.org (Marc Thibault):
 
 > For an encryption to present a challenge, it has to be robust 
 > under plaintext attack when the attacker has a copy of the 
 > mechanism.
 
 Spoken _ex cathedra_.  I think an encryption might be extremely 
 easy or extremely difficult to break whether one has a "copy of 
 the mechanism" or whether one doesn't. In the real world, during
 a practical attempt at breaking a code, you might not have the 
 algorithm. 
 
 
 > Whether he is just being cute, or thinks he has patent 
 > possibilities, the sad fact is that the only way Erik's 
 > friend will get anyone's attention is by publishing his 
 > method.
 
 We are not being cute. We wanted to make a test, and the test may
 or may not work, we don't know.  Or, if the test works, we may
 loose or we may win, we don't know.  Or, if we loose, it may mean
 something or it may not, we don't yet know.  These things remain 
 to be seen, but there are other avenues open as well.  We just 
 though you guys might enjoy a simple little challenge... :-)  But 
 the cryptolibido here seems so low...  tsk... tsk... the 
 crypthormone levels are waaaaaay down...
 
 > There may be a way out: He can claim that the method is the 
 > key. In that case he should publish the technique used to 
 > generate a very large number of cryptographically different 
 > methods. 
 
 We've really not claimed that. We haven't claimed anything. But we 
 will not publish the algorithm for reasons already explained.
 
 
 > I've already proposed something very much like that in this group, 
 > which (strangely|sadly) didn't stimulate any discussion.
 
 By now, Id' tend to say: sadly, yes.  But _strangely_?  I don't 
 know... my feeling is that you've run across the NIH syndrome as 
 well.
 

--- Maximus 2.00
Newsgroups: sci.crypt,comp.theory,sci.math
From: sgall+@CS.CMU.EDU (Jiri Sgall)
Subject: Re: Cryptography and P=NP
Organization: Carnegie Mellon University
Distribution: inet
Date: Sat, 21 Nov 1992 17:28:11 GMT

In article <722273103@pike.cs.duke.edu>, srt@duke.cs.duke.edu (Stephen R. Tate) writes:
|> In article <BxzD1t.3xA.2@cs.cmu.edu> sgall+@CS.CMU.EDU (Jiri Sgall) writes:
|> >So if you know that P=NP, you also have a polynomial algorithm for SAT that 
|> >either answers NO or gives you an satisfying assignment. You can do the same 
|> >for anything in NP.
|> 
|> No, this is not true.   There are two *different* problems here:  knowing
|> that P=NP, and having an algorithm for SAT (or any previously proved 
|> NP-complete problem, for that matter).   Don't forget the perfectly valid 
|> possibility that someone comes up with a non-constructive proof of P=NP --- 
|> this would be amazingly frustrating though.  Imagine knowing that P=NP, so you
|> know that polynomial time algorithms exist for all problems in NP,
|> but you don't know a polynomial time algorithm for any problem previously
|> shown to be NP-complete!  I think that's what the original poster probably
|> meant.

And I was exactly arguing that it cannot get so bad. The first sentence was 
supposed to read "you also know that there exists" instead of "you also have",
sorry for the confusion. The rest of the argument is valid.

My claims are:

1. I have an explicit algorithm for factoring which is polynomial if P=NP. 
(No matter if you prove that nonconstructively.)

2. I have an explicit algorithm that finds a satisfying assignement of a 
satisfiable formula (but may run forever on an unsatisfiable one) if P=NP.

These claims are proved theorems (not by me), well known in the complexity
community. They more or less say that ANY proof of P=NP has some strong
consequences about concrete algorithms.

OK?

-- Jiri Sgall
Xref: sparky sci.crypt:4930 comp.org.eff.talk:7104 alt.privacy:2317 talk.politics.guns:24221
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt,comp.org.eff.talk,alt.privacy,talk.politics.guns
Subject: Re: Risks of Using PGP 2.0
Keywords: legal, patent, export, ITAR
Date: 17 Nov 92 17:12:59 GMT
Distribution: inet
Organization: Stratus Computer, Software Engineering
NNTP-Posting-Host: ellisun.sw.stratus.com


Is the text of the ITAR available on the net?
-- 
-- <<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: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt
Subject: Re: Question about USA crypt export restrictions
Date: 19 Nov 92 21:32:13 GMT
Organization: Stratus Computer, Software Engineering
NNTP-Posting-Host: ellisun.sw.stratus.com

In article <2643@cronos.metaphor.com> polk@Metaphor.COM (Ben Polk) writes:
>Do the US crypt export restrictions prohibit distibution of
>executable code that uses RSA to protect passwords?


You don't need RSA to protect passwords.  All you need is a hash function.

Hash functions (eg., MD-5) are freely exportable.

-- 
-- <<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
Subject: Re: Limits on the Use of Cryptography?
From: a_rubin@dsg4.dse.beckman.com (Arthur Rubin)
Date: 17 Nov 92 19:37:57 GMT
Organization: Beckman Instruments, Inc.

In <1992Nov13.231403.28927@cactus.org> ritter@cactus.org (Terry Ritter) writes:


> In <a_rubin.721673990@dn66> a_rubin@dsg4.dse.beckman.com (Arthur Rubin)
> writes:

>>>    2. As an alternative, I have proposed that each user be
>>>       responsible for providing keys, after the fact, in response
>>>       to a legal warrant.  Failure to do so would be a crime.
>>
>>_I_ think this would violate the Fifth Amendment.

> Possibly.  But does the fact that the government requires radio
> operators to keep logs, and may inspect those logs, also violate
> the Fifth Amendment?

That's a radio licensing argument.  I happen not to agree with it, but
because the government owns/controls radio frequencies, they can specify
regulations on use.

> If the government were to regulate the use of cryptography and
> license users, keeping key logs could well be a condition for
> obtaining (and retaining) a license.

The government does not claim to own/control the phone lines (yet).


>>In addition, as I noted in another message, there is no duty to actively
>>cooperate with a warrant; only to provide the information.

> Does this constrain the argument that courts already have sufficient
> power to compel key disclosure?

Probably.
--
Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
My opinions are my own, and do not represent those of my employer.
My interaction with our news system is unstable; please mail anything important.
Xref: sparky sci.crypt:4960 comp.sys.next.misc:22098
From: strnlght@netcom.com (David Sternlight)
Newsgroups: sci.crypt,comp.sys.next.misc
Subject: Re: UNIX Mail with PubKey Encryption
Date: 18 Nov 92 08:28:55 GMT
Article-I.D.: netcom.1992Nov18.082855.6284
Organization: Netcom - Online Communication Services (408 241-9760 guest)


Vesselin Bontchev is incorrect about RSAREF running only on PCs. In the
ripem versions under beta test, which use RSAREF, there is a Mac and
a Unix version as well as a PC version.

He is also mistaken about the interface. ripem, which uses rsaref, has
the same kind of command line interface that PGP does.

-- 
David Sternlight
(pgp 2.0 and ripem public keys available on request)
From: jwh@cs.bham.ac.uk (James "wibble" Hawtin)
Newsgroups: sci.crypt
Subject: RSA-PGP help
Date: 23 Nov 92 07:23:58 GMT
Reply-To: jwh@cs.bham.ac.uk
Organization: School of Computer Science, The University of Birmingham, UK

I am interested in obtaining a standard RSA compatable key, I only have access to PGP
I have managed to get it to display its calculations :-

256bit calculation.

 modulus n = 2E0574EB 8331D378 71B184F5 1AE02817 
             9EB9113C 366AE339 82549484 74125977 
exponent e = 00000011 
exponent d = 103E2944 102FB40C 645CC583 AF21F008 
             093EA014 A60689FC 56931557 4A36C7D1 
   prime p = 63BB6D2D 38765E6E 5930457A C52DD959 
   prime q = 76218929 D237532A DE839292 5C9E9F4F 
 inverse u = 6A3CD1F9 36DF2A5E 871C4456 3E785001

However I am not sure have have got the meaning of the numbers correct..... 

In standard RSA, 3 things are used general modulus, public key and private key

so does :-

n = the general modulus
d = public key
u = private key 

When I use n, d & u in a standard power modulus algorithm it does not work ;-(
What to I have do do to transform this data into the standard RSA numbers? I know PGP takes some short cuts but have a made a mistake in my calculation or am I using the wrong numbers?


				James.
Newsgroups: sci.crypt
From: frank@hsr.no (Frank A Stevenson)
Subject: DES info wanted
Keywords: DES
Organization: Rogaland University Centre
Date: Mon, 23 Nov 1992 07:28:42 GMT

	I have managed to get hold of information on the main DES encryption /
decryption algorithm, but miss a few pieces of information. I am reading Security
in Computing by Charles P. Pfleeger. The book explains how the S-boxes and P
box works, but doesn't give any information beyond the existance of the initial
permutation and the inverse initial permutation.

	I would like someone to explain how the initial permutation and
reverse initial permutation works, in sufficient detail so that I can write my
own DES code.

-- 
    /// Frank Andrew Stevenson ><>
\\\///  Rogaland University Centre
 \XX/   Norway (frank@hsr.no)
From: Erik.Lindano@ofa123.fidonet.org
Newsgroups: sci.crypt
Subject: New Encryption - a Challenge
X-Sender: newtout 0.02 Nov 17 1992
Date: 18 Nov 92  21:56:20

>>  6. To make things REAL easy, you've been asked to suggest 
 >>     any other input or test method of your own choosing.
 >
 > Well, I have.  You did not respond to my email, although I have no 
 > way of knowing if you received it, but I have received no 
 > responses.
 
 I am very sorry!  The system I'm using is not a regular USENET 
 site; it carries Fido conferences as well - the e-mail is not 
 announced, it must be specifically searched for.  But if I conduct 
 a search, it starts to search every Fido conference (and USENET
 newsgroup) looking for e-mail.. sigh. Maybe I haven't configured 
 it right or something...  In the process of reading newsgroups, etc.
 I often neglect to search the "true" e-mail cubicle... sorry.  
 My fault.  :-)
  
 I went looking for your message and found it, as well as some others.
 All those who wrote e-mail to me should be aware that it seems kinda
 public here... at least, I can read some e-mail addressed to others, 
 so I assume the reverse is also true... don't know for sure how it 
 works.  In any case, you might as well post publicly to me! 
 

--- Maximus 2.00
Newsgroups: sci.crypt
From: lwloen@rchland.vnet.ibm.com (Larry Loen)
Subject: Re: Attack Methods
Date: Fri, 20 Nov 1992 16:23: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 <1992Nov19.215029.22401@bernina.ethz.ch>, caronni@nessie.cs.id.ethz.ch (Germano Caronni) writes:
|> 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

But, in the real world, the opponent will quickly find out.

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,
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.

-- 
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer
Newsgroups: sci.crypt
From: phr@telebit.com (Paul Rubin)
Subject: Re: Cryptography and P=NP
Followup-To: sci.crypt
Organization: Telebit Corporation; Sunnyvale, CA, USA
	<PHR.92Nov15203840@napa.telebit.com> <97800@netnews.upenn.edu>
Date: 16 Nov 92 13:29:59

    >It is true that if P=NP then all cryptography everywhere (not just RSA)
    >is dead;

    Why?  Assuming you mean public-key, the question of whether there
    exist one-way functions is not dependent on P!=NP, right?

No.  All you need is a polynomial-time method to decide if a given
key is the right one for decrypting a given ciphertext.  If you have
any info at all about the nature of the traffic (e.g., it's English
text), you can guess and verify the secret key.  The difference
is that the problem instance is a block of ciphertext instead of
a public key from which to recover the private key.
Newsgroups: sci.crypt
From: mbrownb@cix.compulink.co.uk (Michael Brown)
Subject: Hardware DES devices
Reply-To: mbrownb@cix.compulink.co.uk
Date: Thu, 19 Nov 1992 17:59:00 +0000

Does anyone know of any PC based hardware DES 
encryption/authentication devices?

Am after a something  which is secure (tamper proof) and  has its own 
key management for encrypting and/or authenticating messages in an 
OLTP system (mainframe with PC front ends).

Any info would be great.

Michael Brown

CIX  -  mbrownb@cix.compulink.co.uk
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Newsgroups: sci.crypt
Subject: Re: Attack Methods
Date: 18 Nov 92 13:42:43 GMT
Article-I.D.: qiclab.1992Nov18.134243.24089
Reply-To: Leonard.Erickson@f51.n105.z1.fidonet.org
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.

jdailey@dadd.ti.com (Jim Dailey) writes:

>So what are some of the methods used to attack an encrypted text, when the
>encryption method is unknown?

First you run frequency tests. This will tell you *immediately*
if a "reasonably sized" text was encrypted via *any* character
transposition cipher. 

Then you run statistical tests. These can identify the key length
in character based substitution ciphers.

Once you have the key length (unless it's long enough to have only been
used a *very* few times in the length of the message) you can start
solving the message as bunch of different *simple* substitution
ciphers.

I assume that there are methods for the "fancier" sort of cipher, but
for most folks, these do the job nicely. Alas, I misplaced the
disk with the programs on it and I haven't re-worked them from the
book again. 
-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/51	 Leonard.Erickson@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)
From: Erik.Lindano@ofa123.fidonet.org
Newsgroups: sci.crypt
Subject: New Encryption - a Challenge
X-Sender: newtout 0.02 Nov 17 1992
Date: 18 Nov 92  21:33:08

Writes butzerd@columbia.eng.ohio-state.edu (Dane C. Butzer):
 
 > 1) A crypto system without keys is useless (I agree, but did 
 > his original post say this?  
 
 I didn't say that NuCrypt used keys, or that it didn't use keys.
 At the time, I just said that the program did not create any 
 output other than the ciphertext. Some people jumped to 
 conclusions, a very bad trait for a cryptanalyst. 
 
 (Now, as of today, I am saying that NuCrypt uses embedded 2048-bit 
 shifting keys.)
 
 
 > This (no key == no value) seems blantantly obvious, and somebody 
 > else [forget who] questioned this point also... Response, Erik?)
 
 Like all obvious things, this one probably has wrong facets as well. 
 The value of a key is that it can be kept secure. But a conventional 
 key is not the only thing that can be kept confidential or secure.  
 By the same token, anything can be stolen. Including a key.  
 So what's the big deal in any case? 
 
 
 > 2) Nobody will look at a challenge unless the encryption method 
 > is fully disclosed first.  Now here's where I have a dilema...
 
 (We don't have a dilemma at all. We just don't want to disclose it.)
  
 > Lets say I invent some new encryption scheme (call it Rcrypt - for 
 > Really crypt) and it is Honest to God unbreakable 
 
 Hold it for a second.  We don't *know* that our NuCrypt method is 
 "really unbreakable", whatever that means in theory and in practice. 
 If we did, we wouldn't need to make the challenge.  But we do think 
 it's extremely good and hard to break. I said "unbreakable" earlier 
 and was being a bit facetious. Still, until somebody breaks it, it 
 remains "unbroken" in practice, eh? 
 
 
 > I do have an idea for a solution.  How's this sound:
 >
 > 1) Run a challenge with a large amount of known plaintext and 
 > ciphertext (like 50K to 100K), a nice reward ($500?), but do not 
 > publish the encryption method.  Let this test run 3 months.  The 
 
 Sure, if that's what is wanted. I just think that even 50 kB is
 too large to post here, certainly 100 kB - do you really need 50 K? 
 Some people have asked for megabyte-long files... OK, if that's 
 what's needed, that's fine with us... will have to get somebody to 
 ftp the stuff to some site... don't have ftp at this system...   
 Billions of bytes... billions of bytes... jeeez! 
 However, please note that the reward we offered would have been 
 comparable to what you're proposing. 
 
 
 > Also offer the working object code to anybody in the US 
 > that wants it ...
 
 This we are not planning to do.
 

--- Maximus 2.00
Newsgroups: sci.crypt
From: uri@watson.ibm.com (Uri Blumenthal)
Subject: Re: Attack Methods
Date: Wed, 18 Nov 1992 23:09:05 GMT
Reply-To: uri@watson.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM  T. J. Watson Research Center

In article <1992Nov18.194435.18141@cas.org>, jac54@cas.org () writes:
|> >To encrypt:
|> >    0) compose the message
|> >    1) add (to both the front, and the back) additional characters,
|> >       chosen to produce a flat histogram.  Pseudo-randomize, as needed.
|> >       Perhaps also pad to a standard size block?
|> >       Perhaps randomize the positioning of the message within the block?
|> >       Perhaps break the original message into bite-sized pieces and
|> >       include additional material between bites as well as at the
|> >       beginning and end?
|> >    2) apply the character transposition cipher.
|> 
|> 	Read the article the"Two Soviet Spy Ciphers" by David Kahn in
|> 	"Kahn on Codes".  The system used by Hayhanen did several of
|> 	these things and, if I remember correctly, everything was
|> 	susbtituted first. 


If my memory serves me -  Hayhanen system didn't have a SINGLE null.
Basically it's monoalphabetic substitution followed by two irregular
columnar transpositions. What gives it strength are:
	1) Substitution's done via straddling checkerboard.
	2) All the keys are generated using pseudo-random sequence,
	   which in turn differs from message to message (and it's
	   based on a truly random number which is added to the
	   final ciphertext in prearranged place).
	3) Second transposition has D-areas, which mess things a lot
	   for a cryptanalist.


|> 	Despite all this, I think
|> 	the transposition would fall to multiple anagramming fairly
|> 	quickly.  Somebody very patiently explained to me that
|> 	transpositions are considered very weak these days.

It really depends! (:-) [Unless you meant transposition alone.]
Substitution+Transposition is the strongest combination! (:-)


|> 	Incidentally, the Soviets seem to have put a lot of effort
|> 	into putting field-expedient ciphers together so that they
|> 	wouldn't forever be delivering one-time pads to their
|> 	people.

I would assume one-time pads are still in use both here and there.
But it is convenient to save one-time pads for the top guys, while
lesser folks can get almost-unbreakable mnemonic system!   Neat...
But nothing can really beat one-time pad! (:-)
-- 
Regards,
Uri.		uri@watson.ibm.com
------------
<Disclaimer>
From: Erik.Lindano@ofa123.fidonet.org
Newsgroups: sci.crypt
Subject: New Encryption - a Challenge
X-Sender: newtout 0.02 Nov 17 1992
Date: 18 Nov 92  21:35:10

Writes cme@ellisun.sw.stratus.com (Carl Ellison):
 
 > The point which should be made (in the FAQ at least, and probably 
 > here) is that the fact that no one reading this group wants to 
 > take this time does not imply that the method is secure.  
 
 The point should also be made that neither does it mean the opposite.
 In other words, it means neither thing, which leaves me wondering 
 why you bothered to make the point.  
 
 (Actually, some people _did express_ willingness to try.)
 
 > This attempt goes under the name "security by obscurity" and 
 > protects only against lazy attackers.  A system which is secure 
 > only against lazy attackers isn't worth anything.
 
 If the intention of my original challenge had been what you 
 describe, then you might have been right. But my intention was not 
 what you describe. My intention was to offer a test and see if 
 anyone would willingly participate. No intentional "obscurity" was 
 specifically intended.
 
 In any case, OBSCURITY is what cryptanalysis deals with all the
 time, is it not?   OBSCURITY is the subject matter of the 
 cryptomancer.  The objective is either to produce OBSCURITY, or 
 to extract light from OBSCURITY.
 
 In this newsgroup, OBSCURITY is definitely not a bad word...
 

--- Maximus 2.00
Newsgroups: sci.crypt,sci.math,comp.theory