HDTenEightyP/NetNews huggingface dataset:
Newsgroups: sci.crypt
Subject: Steganography and SECURITY
From: aspringman@eagle.wesleyan.edu
Date: 28 Sep 92 09:55:46 EDT
Organization: Wesleyan University

In article <1992Sep23.182419.21656@cactus.org>, ritter@cactus.org (Terry Ritter) writes:
> 
> 
>  But I don't think it solves our problem.  Not yet.
> 
>  The way I understand it, Ross proposes to hide a small amount of
>  data in normal text by hashing 40-byte blocks into a single bit
>  using a secret key.  During text construction, the text editor
>  would "beep" if a just-created block did not produce the correct
>  bit; in that case the user would back up and try again with
>  different words.
> 
>  The advantage is that we can get a hidden secret message past
>  the Opponent because the outer message looks innocuous.  Then,
>  once everybody has the message, we just announce the secret key
>  and everyone can unlock the hidden data (the validated public key).

	You are right.  It does not solve the problem.  Every move of the
person trying to distribute their key can be intercepted by the opponent in
this model.  If the opponent can't tell what's up with a message, if the outer
message looks innocuous, he can change the wording of the message thus
destroying the inner bit pattern without alerting the readers to a change.  The
opponent could then, as you said, announce that the public key is in the new
message and publish a key and algorithm to find it (after the distributor
attempts to announce such a key)

	The key to initial key distribution is SECURITY, not just CRYPTOGRAPHY.
There must be some form of communication that is un-interceptable to validate
any such distribution.  For example, after the initial distribution of the
outer text, two or three or the readers could physically bring the text they
received to the distributor for a comparison.  If they are murdered on the way
and substituted by an excellent team of imposters, we'd have a problem :)

	This solution is exactly the type of solution we are trying to avoid,
so I would love for someone to prove me wrong.

					Andrew Springman

Newsgroups: sci.crypt
From: flagg@blind-lemon.cs.unlv.edu (Scott Cunningham)
Subject: Re: Every Spy Should Carry a Bible
Organization: UNLV
Distribution: usa
Date: Thu, 1 Oct 92 04:20:50 GMT

In article <66926@cup.portal.com> Christopher_C_Lapp@cup.portal.com  
writes:
 "How about a cryptosystem that used the teachings of various
 "religious figures in the Bible as its key?
 "he/she would assign a "long beep" to sins in the bible, and a
 "short beep" to those that weren't. By using the bible as the key, we
 "could have uncrackable, undetectable, and public key encryption.
 "Any comments?
 "Chris Lapp

Why not use another more obscure text and do the same thing.  For example  
use a different pulp romance novel each time and associate your sins with  
those which actually occured in the book used.  This is by no means  
uncrackable, just real obscure.  It breaks down when you have to tell your  
partner what book to use, if someone were to find out they would have your  
code down cold in minutes.  The way around this is to use an encryption  
like RSA where each person has his/her own key thus no key to have to  
transmit, no key to intercept.

________________________________________________________________________
Scott Cunningham \ We're the NSA                                        \
Username: flagg  \ So your the ones I hear on the other end of my phone \
                 \ No, that's the FBI                                   \
-------------------------------------------------------------------------
Newsgroups: sci.crypt
From: uri@watson.ibm.com (Uri Blumenthal,35-016,8621267,)
Subject: Re: PGP *2.0* available
Originator: uri@aixproj.watson.ibm.com
Date: Wed, 30 Sep 1992 01:12:35 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

From article <>, by 74076.1041@CompuServe.COM (Hal):
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: 2.01

Hey, what's "Version 2.01"? Was the patch released yet?
Why isn't the world notified? (:-)

Regards,
Uri.
------------
<Disclaimer>
-- 
Regards,
Uri.		uri@watson.ibm.com
------------
<Disclaimer>
From: gdallal@pearl.tufts.edu (Jerry Dallal)
Newsgroups: sci.crypt
Subject: VCR Plus+ codes
Date: 29 Sep 92 21:01:00 GMT
Organization: Tufts University - Medford, MA
News-Software: VAX/VMS VNEWS 1.41


            Because the requests for code keep coming in, I am posting 
        a general response to the net.  In summary, I have decided not 
        to distribute my code. 

            Along with the requests  for code came a  few summaries of 
        earlier  discussions of the VCR Plus+  algorithm from here and 
        other  news  groups.   There is a running thread in all  these 
        exchanges that uses the word "lawsuit".  

            I make  the following observations.

            (1)  The SWK paper  is  titled  "Decoding a VCR Controller 
        Code," not "Encoding . . ." 

            (2)  It  took  the  assistance  of  the  EFF  to  get  SWK 
        published in a scholarly journal. 

            (3)  The  SWK  authors themselves have  not circulated  an 
        encoder.  And who, after all, is better able to do it?  

            (4)  I have heard that a program had been available at one 
        time,  but was withdrawn from circulation.   

            All of this makes me nervous and I have decided *not*   to 
        distribute  any code.   I  don't want anyone's attorneys at my 
        doorstep, even if their case might be frivolous. 

            However, let me restate part of my earlier posting: 

            Everything  needed  to write a 1 to  6  digit  encoder  is 
        contained in Shirriff K,  Welch C, Kinsman A,  "Decoding a VCR 
        Controller Code,"  Cryptologia, 16 (#3,  July 1992),  227-234.  
        If you can program in any higher level language,  it shouldn't 
        take  you  more  than a single afternoon.    (The  program  is 
        begging to be written in APL,  but BASIC,  C,   PASCAL or  any 
        other language,  will do fine, thank you.)   My only advice is 
        to  work  on it methodically,   one piece at a time,   knowing 
        everything you need is in SWK 

            Now  that SWK is available,  I  don't know how Gemstar can 
        hold back the floodgates.  SWK might not be an encoder, but it 
        contains  the  blueprint for one.   I  built one  without  any 
        special skills beyond  high school algebra.  Many others could 
        do  likewise.  It should be only a short time  before  someone 
        goes out on a limb to make source/executable available. 
Newsgroups: sci.crypt
From: bs@gauss.mitre.org (Robert D. Silverman)
Subject: Re: PGP 2.0 concern
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Thu, 1 Oct 1992 20:45:18 GMT

In article <BvGGME.1nD.2@cs.cmu.edu> jmount+@CS.CMU.EDU (John Mount) writes:
:In article <1992Oct1.172252.13437@vela.acs.oakland.edu>, phkahler@vela.acs.oakland.edu (KAHLER PAUL H.) writes:
:|> I agree that the pseudoprime tests are probably adequate for most use.
:|> However, it is VERY BAD to just choose a large random number and check
:|> that it is prime when using RSA. There are algorithms which can factor
:|> numbers containing certain kinds of primes very quickly. If n=p*q and
:|> either p-1 or q-1 contain no large factors, then n can be factored quickly.
:
:I think Bob Silverman has pointed out many times that if p is a prime chosen by
:the above method then p is VERY unlikely to have only small factors- so it
:isn't a bad idea at all.
:
It is actually more that the Elliptic Curve Algorithm has made such criteria
irrelevent. The problem is that for p sufficiently large, it is likely that
there exists a number near p, p+/-k (say) with k < 2sqrt(p)) such that all of
its factors are small. [the exact probability can be quantified with 
Dickman's function. See my forthcoming paper with Sam Wagstaff to appear in
Math. Comp. which outlines this].  

Under such conditions ECM can get lucky and there is NO way to prevent it.

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
Newsgroups: sci.crypt
From: erick@fraser.sfu.ca (Erick Bryce Wong)
Subject: Re: More on cracking DES algorithm
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Thu, 1 Oct 1992 04:09:02 GMT

shulick@yankton.ucs.indiana.edu writes:

>NOTE: Yes, you may have noticed I'm posting a lot about breaking DES/UNIX
>encryption.  I am not a hacker, I'm merely trying to understand the way it
>works and learn exactly how secure this algorithm really is.  I gave up hacking
>a long time ago. (:

I don't feel like going into the hacker/cracker distinction right now... :-)

>Let's say someone retreives the DES source code, which is easy enough.  Why
>WOULDN'T they be able to take every single mathematical operation, reverse each
>one, and then have a "decrypt()"?  I know it's not that simple, but how has DES
>made it so even a good mathematician can't just reverse all the operations?

Well, how do you plan on reversing the step that looks like "free(key)"?  If
you're referring to UNIX crypt(3) encryption, it's the password that is used
as the key...Even if you had the key/password, reversing every operation
pretty much leaves you with just 0's... :-)  If you mean DES encryption, well
of course there's a decrypt()...How else is someone supposed to be able to
read the data after they've encrypted it? :-)

My point: The only thing decrypt has to go on is the output of crypt, so you
can't simply reverse each operation...And sometimes (public-key, one-way hash
functions) it's still hard to reverse things even if you know exactly what
the encryption algorithm is doing to the plaintext...

-- 
 -- Erick, the perfect square  :-)
From: ffhoust@eos.ncsu.edu (FORREST FRANCI HOUSTON)
Newsgroups: sci.crypt
Subject: Re: Every Spy Should Carry a Bible
Date: 1 Oct 92 01:24:35 GMT
Distribution: usa
Organization: North Carolina State University

In article <66926@cup.portal.com>, Christopher_C_Lapp@cup.portal.com writes:
|> How about a cryptosystem that used the teachings of various
|> religious figures in the Bible as its key?As a spy, I would write
|> a passionate letter detailing my sins and moral turpitude to my spy partner, 
|> and he/she would assign a "long beep" to the aspects of my sins that were
|> in accordance with the bible, and  a "short beep" to those that weren't.  T
|> output would be a Morse-code of biblical proportions! By using the bible as t
|> key, we could have uncrackable, undetectable, and public key encryption.
|> Any comments?
|> Chris Lapp

I'm just getting started in studying cryptology but it seems to me that
the magnitude of such a message would outweigh any advantage gained by
do it.  Also every spy would have to be well versed in theology, which
has taken some people a life time in itself, in order to know which
sins are and which sins are not in the Bible.  While I'm in a low flame
mode how about problems that would arise from using different versions
of the Bible?

Just my $0.02
Later!
Forrest
Newsgroups: sci.crypt
From: marti@nugget.inf.ethz.ch (Robert Marti)
Subject: Re: pgp2.0 - what is an appropriate key length?
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 28 Sep 1992 16:08:34 GMT

In article <1992Sep25.191759.25545@nevada.edu>, oliverm@nevada.edu
(Moises Oliveira) writes:
|> Now, assume that the actual factoring is trivial by use of some mathematical
|> method.  What good does it do you?  Exactly how does having the two prime 
|> factors of some really big number do to help you crack RSA?
|> 
|> In other words, if I see someones public key, how can I find what really
|> big number they used? And then after I factor it, what whould I do to the
|> encrypted communications to return it to plain text?

Here is a Mathematica function to crack an RSA public key consisting of
the public modulus n ("the big number", as you call it) and the public
exponent e:

crackRSA[publicKey[e_,n_]] :=
  Block[ { factors = FactorInteger[n], p, q },
    p = factors[[1,1]]; q = factors[[2,1]];
    PowerMod[e, -1, (p - 1) (q - 1)]
  ]

p and q are the two prime factors of n.  The function returns the secret
(private) exponent d which is the multiplicative inverse of e in the
finite field of numbers in the range [0,(p-1)(q-1)-1].  (I have never
tried it for moduli n which have more than about 20 digits ... )

Check out any good book on modern cryptography or chapter 33 of
"Introduction to Algorithms" by Cormen, Leiserson and Rivest
for the number theoretical background.

-- 
Robert Marti                    |  Phone:    +41 1 254 72 60
Informationssysteme             |  FAX:      +41 1 262 39 73
ETH-Zentrum                     |  E-Mail:   marti@inf.ethz.ch
CH-8092 Zurich, Switzerland     |
Newsgroups: sci.crypt
From: cepek@vixvax.mgi.com
Newsgroups: sci.crypt
Subject: Pseudo-one-time pads
Date: 2 Oct 92 22:29:14 GMT
Organization: Management Graphics, Inc.

I have been thinking about pseudo-one-time pads (POTP) lately.

Assume you have a POTP generator (some new algorithm).  Let's say it
has a period of 2^64 (= 1.8e19) -- after that many output bytes the
pattern repeats.  The POTP seed maps to a starting point in the sequence
in a "complex" manner. 

Question 1:  Is 2^64 "enough"?  I realize this answer depends on many
things (cracking computer horsepower and memory, desired level of
security, number of years of intended use, computational complexity of
the POTP, etc.). Reasonably qualified answers like "it would take a
Cray-XMP about n years to evaluate 25 parallel multiply-add PRNGs 2^64
times" would be constructive here. 

Next, assume that we do not have access to any "real" random source.  By
this I am forcing the POTP seed value to be based only on user key(s)
and/or the message itself. 

Question 2:  With these two assumptions, how can such a POTP algorithm
be seeded "strongly"?  [An obvious example of weak usage: hashing a user
key into the (same) seed for each message.]  Are there good ways to
construct a seed given (only) a user key and the message text?

(Note: I know that keypress timings can be used to generate a very long,
random "message key", but I am excluding this option with my second
assumption above.) 

Further discussion and comments are hereby solicited.
_______________________________________________________________________
Mike Cepek, Senior Software Design Engineer     Internet: CEPEK@MGI.COM
Management Graphics, Inc., 1401 E. 79th St., Minneapolis, MN 55425  USA   
Front desk: +1 612/854-1220   My desk/Voice mail: 851-6112   Fax: -6159
\______PGP Public key available using FINGER or by email request______/
Newsgroups: sci.crypt
From: gregory j farrar <gfarrar@silver.ucs.indiana.edu>
Subject: pgp 2.0
Organization: Indiana University
Date: Tue, 6 Oct 1992 18:52:10 GMT

I've seen this posted before, but need the answer again.
Where can I ftp a copy of pgp 2.0 for a PC ?

Thanks,

Greg Farrar
Newsgroups: sci.crypt
From: S_TITZ@iravcl.ira.uka.de (Olaf Titz)
Subject: Pocket calculators (was Re: Every Spy Should Carry a Bible)
Organization: Fachschaft Informatik, Uni Karlsruhe
Date: Mon, 5 Oct 1992 19:02:48 GMT
X-News-Reader: VMS NEWS 1.23

Sorry if this is a bit off-topic, but...

In <PHR.92Sep30185509@napa.telebit.com> phr@telebit.com writes:

>...
>  One advantage of the Bible is that, at least until recent times, carrying
>  one wouldn't draw suspicion to the spy.  (Carrying a Hagelin machine
>  would be pretty incriminating).  As a modern day alternative, I've
>  often thought the No Such Agency could do the following:
>  
>     - write encryption/decryption code that runs in an embedded
>       micro of the kind found in calculators.
>  
>     - go to favorite defense contractor that also makes calculators
>       (e.g. TI), and say "we want you to make a new model of simple,
>       consumer calculator, priced so lots of people will buy them
>       (here's some $$$ to make it profitable), and by the way, when
>       the user types this undocumented 20-keystroke sequence, it should
>       run this code that we'll supply (from previous step).

This reminds me of my first scientific pocket calculator I used in
high school. (It was manufactured by Casio but I know the way TI
calculators suck and I surely can imagine a TI with such features too
;-)

It was a (then) highly pouplar model called fx85, which was slightly
cheaper than the fx100, which looked exactly the same, except that a
third (blue) layer of key definitions (apart from first (black) and
second (brown) functions) was missing from the 85. Knowing a bit about
mathematics you would have recognized the blue functions as
statistical functions. 

Both of the calculators had an INV key (some sort of a shift) and a
MODE key (for switching from degrees to radians). Pressing BOTH of
them would result in switching the machine into SD (statistical) mode,
in which the third function layer was in effect and, of course, some
keys had total different meanings.

The manual of the 85 stated that [paraphrased] 'some wrong input may
cause an ERROR sign to appear, in which case you should turn the
machine off and on again.' It turned out that the condition for
getting an ERROR was exactly INV-MODE, and the same could be used to
turn the ERROR off again.

Now, some people had the 100 model, and quickly we found out that
except for the nasty ERROR display instead of SD, the statistical
functions did work as well on the 85. The two models had the same CPU,
only the displays and key labels were different.

Now don't tell me that there are no pocket calculators with surprising
undocumented features :-)

MfG,
        Olaf
-- 
    o     Olaf Titz - comp.sc.student - univ of karlsruhe - germany
 _ /<_    s_titz@iravcl.ira.uka.de - uknf@dkauni2.bitnet - praetorius@irc
(_)>(_)   +49-721-60439 - did i forget something?
Wichtig ist, was hinten rauskommt. - Helmut Kohl
Newsgroups: sci.crypt,alt.security.pgp
From: res@colnet.cmhnet.org (Rob Stampfli)
Subject: pgp modmult alternatives
Keywords: UPTON MERRITT PEASANT
Organization: Little to None
Date: Wed, 30 Sep 1992 00:35:42 GMT

The pgp2.0 Makefile has a section where you can define one of three
modulo multiply algorithms.  They are called UPTON, which is selected
by default, MERRITT, and PEASANT.  Has anyone tried either MERRITT or
PEASANT and found them faster?
-- 
Rob Stampfli  rob@colnet.cmhnet.org      The neat thing about standards:
614-864-9377  HAM RADIO: kd8wk@n8jyv.oh  There are so many to choose from.
From: rmathews@zeus.calpoly.edu (Bob Mathews)
Newsgroups: sci.crypt
Subject: Re: More on cracking DES algorithm
Date: 2 Oct 92 18:07:51 GMT
Article-I.D.: zeus.1992Oct02.180751.186683
Organization: California Polytechnic State University, San Luis Obispo

dc91jld@brunel.ac.uk (John L Davies) writes:
>Obviously, if you know the key used, then DES is reversible - how else, can
>the plaintext be retrieved.  However, if you mean is it possible to reverse 
>the process to produce the plaintext & key from the ciphertext, then the answer
>is NO.

There have been a number of replies to Sam Hulick's article, and they all
say about the same thing.  However, I think Mr. Hulick has confused DES
with a public key system like RSA.  The question is, why can't you decrypt
a message with the public key?

I don't have a very good understanding of public key encryption, but I
think that the basic idea has two elements:
1) an extremely difficult problem
2) a trick for solving it quickly that only works when you have some
   special information (the secret key)
RSA is based on the difficulty of reversing exponentiation by large numbers
in modular arithmetic unless factors of the exponent are known (with a trick
discovered by Euler, of course) and the fact that multiplying two large prime
numbers together is much easier than factoring an even larger composite.
(At least, nobody knows of easy ways to do these things.  Yet.)  Conceptually,
it can be reversed, but the ammount of computation required is prohibitive.

swehtam bob
Newsgroups: sci.crypt,alt.security,alt.security.pgp
From: mgflax@ernie.Princeton.EDU (Marshall G. Flax)
Subject: Re: pgp2.0 - what is an appropriate key length?
Organization: Princeton University
Date: Mon, 28 Sep 1992 21:58:45 GMT

In article <1992Sep28.202620.25342@linus.mitre.org> lewis@aera8700.mitre.org (Keith Lewis) writes:
>Find a pair of numbers, E and D, such that mod(E * D, (P-1)*(Q-1)) = 1
>You publish N and E as your public key.  To encrypt messages, calculate
>    Y = mod(X ** E, N), where X is the input data
>
>You keep N and D as your private key.  To decrypt messages, calculate
>    X = mod(Y ** D, N), where Y is the encrypted data
>
>If you have somebody's N and E, and you somehow factor N into P and Q, you
>must then find a D that works in the above equality (a non-trivial task, I
>think).  Then you can decrypt his/her messages.

Suppose you know P, Q, and E.  Then D is the multiplicative inverse of E
modulo (P-1)(Q-1).  Finding multiplicative inverses is in fact a trivial
operation if one keeps track of the quotients and remainders generated
while applying the Euclidean algorithm in GCD(E,(P-1)(Q-1)), but I'll
leave that as an exercise to the reader!

marshall
-- 
=========== 5 Joyce Lane, Woodbury, NY 11797, 516-364-9331,9379 ===========
============ PGP 2.0 Public Key available by finger or request ============
===== c/o Jack Gelfand,Psych Dept,Princeton U.,NJ 08544,609-258-2930 ======
= Original material(c) 1992, Marshall Flax <mgflax@phoenix.Princeton.EDU> =
From: zeke@fasttech.uucp (Bohdan Tashchuk)
Newsgroups: sci.crypt
Subject: Re: Every Spy Should Carry a Bible
Date: 2 Oct 92 22:19:01 GMT
Distribution: usa
Organization: Fast Technology

Someone who can't post directly made some interesting observations to me in
mail. They follow up on the idea of using a common calculator for encryption.
He points out that ATMs offer similar possibilities.

His mail follows:

----------

I suppose you'd want TI rather than Casio (national security and all that).  I
suspect it is the TI small grey and blue plastic solar 16-button one ( I don't
know the model #).  A law firm where I used to work bought these by the case.
In NY they retail for about $8.99.  I plan to pick one up this afternoon and
spend the weekend starting an exhaustive search on all 20-40 key combinations.

But this gets me to thinking about other seemingly innocuous devices that could
have secret hidden lives . . .  If CIA were to have a front bank (maybe BCCI) on
the Cirrus ATM system . . .  just how much information could be given in an 
account balance?  No more need for dead drops for spies, just transfer funds 
(to send info) or check your balance (to receive info).  This could double as a 
means for paying informers.

Of course there are other big problems with this.  However, it really makes you 
wonder what "they" (that's the conspiratorial they) could get away with hiding 
in plain view if they had a mind to.

Jim Frohnhofer      frohnhof@ray.ncbi.nlm.nih
Newsgroups: sci.crypt,alt.security,alt.security.pgp