HDTenEightyP/NetNews huggingface dataset:
Newsgroups: sci.crypt,comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Crypt should be based on MD5 (was: the Crypt 16 discussion)
Date: 23 Jul 92 15:56:07 GMT

dhesi@cirrus.com (Rahul Dhesi) writes:
[t0 is the time at which the intruder acquires the encrypted password,
T1 is the time to crack it,
T2 is the time to use it (login)]

>It makes sense to set the password expiration period to be less than T1 +
>T2.  Then, by the time the intruder is ready to use the password, it has
>been changed.
...
>For well-chosen Unix passwords T1 is at least decades, if not several
>centuries...
>It should be reasonable to expire a password in about a year.
...
>CONCLUSION 1:  If passwords are well-chosen, password expiration adds
>nothing to security.

This conclusion does not follow from your above discussion.  It looked like
you were leading up to saying that expiring passwords annually will add to
security.  I thought that the exabyte tape method decreases T1 to be less
than decades even for reasonable passwords.  This is not including the possible
availability of the plaintext of passwords (e.g. ethernet snooping, looking
over people's shoulder).

>If the intruder can
>immediately get access to the encrypted form a password when it is
>changed, then password expiration becomes irrelevant.  Mathematically
>speaking, if the intruder is always trying the *current* encrypted
>password, his chances of guessing it neither increase nor decrease if the
>encrypted password changes every 6 hours (or however often).

This conclusion does not follow from your above discussion.  How frequently the
intruder gets access to the encrypted password is your "t0", which does not
appear after your original definitions.  Access to the current encrypted
password has no effect given your analysis on the effectiveness of password
expiry.
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: sci.crypt
Subject: Re: Padded Data
Date: 31 Jul 92 20:02:38 GMT

From article <1992Jul31.153719.28374@ncsu.edu>,
by Webbge@che17.ncsu.EDU (Greg Earl Webb):
> 
> I've seen some interesting posts here recently, but I have yet to
> see the topic of padding data with garbage.

In my splay-tree based data compression code (C source available on
request), , the compressor adds a random prefix to the data when asked
to encrypt as well as compress.

In this case, encryption is done by adjusting the initial state of the
adaptive compression and expansion data structures by smashing the text
of the key through them.  I threw in the random padding because so many
documents tend to start with predictable stuff such as "From:" and I
figured that even a slight random addition to the source text would
significantly complicate the effort needed to make a known plaintext
attack.

In fact, had I thrown in a random byte or two every few tens of
characters, I'd have done even better because that would significantly
complicate controlled plaintext attacks, to which I know my splay-tree
based code is vulnerable (immediately after compressing the sequence
aaaaaaaa on an 8 bit alphabet, the code a is known, independant of the
starting state of the model).  An occasional random number thrown into
the stream of compressed data will prevent a longer sequence from
putting the entire compression data structure into a known state.

				Doug Jones
				jones@cs.uiowa.edu
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt
Subject: Better use of FTT
Date: 28 Jul 92 19:53:20 GMT
Organization: Stratus Computer, Software Engineering


If using the FTT I just posted to diffuse DES, it makes sense
to do

	DES|FTT|FTT|FTT|DES|FTT|FTT|FTT|DES|FTT|FTT|FTT|DES|...

(or to modify FTT to do the equivalent of 3 rounds at once)

Eg...

> more foo
0000000011111111222222223333333344444444555555556666666677777777
> ftt < foo | more
0404040404040404151515151515151526262626262626263737373737373737
> ftt < foo | ftt | more
0246024602460246024602460246024613571357135713571357135713571357
> ftt < foo | ftt | ftt | more
0123456701234567012345670123456701234567012345670123456701234567
>
From: brnstnd@nyu.edu (Dan Bernstein)
Newsgroups: sci.crypt
Subject: Re: New record non-networked factorization of difficult number
Date: 25 Jul 92 04:27:26 GMT
Organization: IR

In article <1992Jul25.004256.4641@linus.mitre.org> bs@faron.mitre.org (Robert D. Silverman) writes:
> The reason they were able to factor a 145 digit number

(2^488 + 1)/257 had 146 digits, last I counted.

> A general number of 145 digits will yield
> a polynomial with coefficients around 23-24 digits --> a BIG difference.

Take any 150-digit number n. Now try to find positive integers m and m',
together with six coefficients c_0 through c_5, such that n = c_0 m'^5 +
c_1 m'^4 m + ... + c_5 m^5. We could of course choose m around 25
digits, and m' = 1, and write n in base m, giving coefficients around 25
digits. This is where Bob gets his estimates.

If you choose all eight of these parameters up to 25 digits then you get
about 200 digits to play with---and n has only 150 digits. So we should
in theory (modulo some plausible heuristics) be able to chop those extra
50 digits out of the c's, ending up with 25 - 50/6 < 17 digits per c for
some pair (m,m').

Exercise for the reader (yes, kids, you can try this at home!): Can you
compute m and m' for RSA-150 so that the c_i are smaller than ``23-24
digits''? Can you beat Bob's best polynomial? Hint: Brute force.

Now can you compute m and m' so that the c_i are under 20 digits?

> The speed of the method strongly depends on the size of these coefficients.

This is true.

> My estimates show that the Number Field Sieve becomes faster than the
> quadratic sieve for general integers somewhere between 135 and 140 digits.

Ah, yes, and didn't Adleman's estimates a year ago ``show'' that GNFS
would probably be slower than MPQS around 330 digits?

---Dan
Message-ID: <1992Jul21.035158.22689@qualcomm.com>
From: karn@qualcom.qualcomm.com (Phil Karn)
Newsgroups: sci.crypt,alt.security
Subject: Re: PIN codes
Date: 21 Jul 92 03:51:58 GMT
Reply-To: karn@chicago.qualcomm.com
Organization: Qualcomm, Inc

In article <1992Jul19.210601.27046@cs.ucla.edu>, gast@oahu.cs.ucla.edu (David Gast) writes:
|> I think it is a disgrace the way that buttons are set up so that it is
|> virtually impossible to block the person behind from seeing what is typed,
|> particularly given that most banks only allow a four digit PIN.  The
|> fact that most ATM machines are close to a (reflective) window does not
|> help either.  Home Fed does not allow any PINs longer than 4 digits.

Most San Diego Trust and Savings ATMs seem to have recently acquired a
tinted brown plastic wall about 6 feet in front of the machine. It's
not opaque, but I'm sure it makes reading a PIN from a distance using
binoculars a lot harder. I suspect this is the idea.

Nevertheless, I still make it a point to stand close to the machine
and cover my hand whenever entering my PIN.

Phil

Newsgroups: sci.crypt
From: wayner@cs.cornell.edu (Peter Wayner)
Subject: Re: Padded Data
Keywords: pascal crypt
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Fri, 31 Jul 1992 17:26:27 GMT

Webbge@che17.ncsu.EDU (Greg Earl Webb) writes:


>I've seen some interesting posts here recently, but I have yet to
>see the topic of padding data with garbage.  It seems to me that
>if you had an algorithm that would not only encrypt the data, but would
>also insert random data into the original data (without following
>a regular pattern) that it would be almost impossible for someone
>to tell what was real information and what was just junk.  Although
>the size of the document would increase, the difficulty in decrypting
>the message would also increase considerably.

>The only problem I can see with this method is how do you insert data
>in a non-regular pattern and still have the ability to remove it later.
>Please comment on this type of procedure.  I'm sure people have thought
>on these lines before and would be interested in seeing what they have
>to say......

>			Greg Webb

A guy names William Simon (email address: alain@elevia.UUCP) posted
some stuff long ago about "braiding" messages. Essentially you took
two streams of data (a and b) and a pseudo-random source. Everytime a
1 came from the source you took a block of data from a and everytime a
0 came from the pseudo-random source you took a block of data from b.
Reconstructing a and b is possible if you have the same pseudo-random
bit stream. 

There were long debates about how easy it is to reconstruct this, but
Simon showed that it was equivalent to the one-time pad. (I believe he
assumed that a and b had "random" patterns. Obviously if a is all
zeros and b is all ones, then reconstruction is simple.) 

In the other direction, a fellow named Dave August once wrote a paper
for Cryptologia (circa 1987) about the technique of deleting random
letters from a plaintext message. The redundancy of English left the
message still readable.

-Peter
-- 
Peter Wayner   Department of Computer Science Cornell Univ. Ithaca, NY 14850
EMail:wayner@cs.cornell.edu    Office: 607-255-9202 or 255-1008
Home: 116 Oak Ave, Ithaca, NY 14850  Phone: 607-277-6678
From: cme@ellisun.sw.stratus.com (Carl Ellison)
Newsgroups: sci.crypt
Subject: Re: transposition ciphers
Date: 27 Jul 92 15:21:26 GMT
Organization: Stratus Computer, Software Engineering

In article <92207.142318U27239@uicvm.uic.edu> U27239@uicvm.uic.edu (Gerald Strom) writes:
>This Caesar Cipher is not secure by the standards of today but
>interestingly, the method used, substituting one letter or character for
>another in a regular way, is still the fundamental basis for encipherment
>in modern ciphers systems.  The DES system developed by the United States
>government, the various public key ciphers systems, as well as the German
>Enigma cipher cracked by Allen Turing during World War II using one of the
>first computers are all substitution ciphers whereby letters in the plain
>(or un-enciphered) text are replaced by different letters or characters to
>create the cipher (or enciphered) text.

This is an inaccurate statement.  It gives the impression that all these
systems operate on individual characters and are as insecure as Caesar.

A transposition over, say, 25-byte blocks is a substitution just as DES is
a substitution over 8-byte blocks -- only the transposition is simpler.

A one time pad is a substitution cipher -- and about as secure as you can
get.

A self-inverse transposition was posted here a month or two ago --
operating over large blocks (up to 8K).  With FFT techniques, we can build
a much larger block DES -- eg., operating on 8K blocks.  I would prefer
the large DES over a large transposition.
From: hal@venus.mitre.org (Hal Feinstein)
Newsgroups: sci.crypt
Subject: Re: transposition ciphers
Keywords: cipher transposition multiple anagram broken US civil war
Date: 27 Jul 92 13:56:56 GMT
Organization: Malox Corporation, Vienna, VA

>	Doesn't this only work with a route and/or block transpositions?
	(Stuff Deleted...)
>	Incidentally, there
>	are only about 40 systematic routes through a 5x5 transposition
>	Alec Chambers.


Transposition systems that were in use back during WWII used much larger
non-square type "blocks" for example 15 x 33 characters. The characters
were read off using some route that changed from message to message. The
one I looked at used a key word derived from a common book.  The key word
expands into instructions on how to select characters from the grid.
The grid contained lots of nulls that made things more difficult to solve.

Double transposition seems to have enjoyed a vogue up until sometime in the
'50. Spys seems to have liked it in WWII, the German Secret Service for one.
One account says that with the introduction of the computers most  
transposition systems became insecure. Experts I talk to doubt that any 
transposition system arse useful except perhaps for low grade tactical 
use.

Lance Hoffman, a Prof down here at
Geo Washington Univ and author of security books thinks that 
transpositions are probabily adaquate for business privacy use (*but not all 
cases*) .  It keeps non-experts out and given the pain of decrypting one 
of these, as a hacker I would probabily not bother fooling  with a files or 
messages so rearranged. 
 
A point of triva: back in '73 one of the ciphers submitted to NBS as a 
candidate for a national data encryption standard was a multiple transposition 
cipher. It didn't win. 
Newsgroups: sci.crypt
From: richard@sfu.ca (Richard Chycoski)
Subject: Re: Unemployed cryptologists?
Reply-To: richard@sfu.ca
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Wed, 29 Jul 1992 22:47:26 GMT

In article <76351@ut-emx.uucp> bhall@ccwf.cc.utexas.edu (Bowman Hall) writes:
> Besides working for governments and researching at universities,
> what employment is there for cryptologists?
> 
> Bell Labs?
> 
> 
> -- 
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Bowman Hall
> Department of Mathematics
> University of Texas at Austin
> bhall@dopey.cc.utexas.edu

How about IBM, AT&T, and any of the companies that reverse-engineer other  
companies' encryption schemes (e.g. Cable TV descramblers)? (:-)



--
- Richard Chycoski, VE7CVS            richard@sfu.ca (Internet)
  Senior Systems Consultant           richard@sfuvax (BITNET)
  Academic Computing Services
  Simon Fraser University             (NeXT Mail OK)
Newsgroups: sci.crypt
From: mrr@scss3.cl.msu.edu (Mark Riordan)
Subject: Re: Where is the FAQ for sci.crypt?
Organization: Michigan State University
X-Newsreader: Tin 1.1 PL3
Date: Fri, 31 Jul 92 17:05:28 GMT

erc@unislc.uucp (Ed Carp) writes:
: Is the FAQ for sci.crypt regularly posted?  I looked in news.answers, but
: couldn't find it.

The sci.crypt FAQ has been dormant for a while, but has recently 
been resurrected and is being reviewed by a "Cabal" of five.
It'll be a couple of months, probably, before the FAQ is fully
resurrected and posted.  It's currently 1100 lines long, and
there are 7000 written lines of suggested changes, plus
changes to be made that are as yet unwritten.

Hang in there...

Mark R.
From: brnstnd@nyu.edu (Dan Bernstein)
Newsgroups: sci.crypt
Subject: Re: NIST stumbles on proposal for public-key encryption
Date: 28 Jul 92 12:30:24 GMT
Organization: IR

In article <1992Jul28.055837.10815@cactus.org> ritter@cactus.org (Terry Ritter) writes:
>  If that is the case, then isn't it a shame that NIST does not own
>  the public key patents.

NIST seems to believe that DSS can be used without royalties. If it is
incorrect then it will almost certainly withdraw DSS.

>  There are at least two patent holders who claim
>  that DSS infringes their patents [1].

Let's not mince words here: *RSA Data Security Incorporated* claims that
DSS is insecure, that DSS infringes upon its patents, etc., etc., etc. I
am astounded that people like Rivest have the nerve to comment on DSS
without admitting their financial interest in RSA. I am unhappy, though
not so surprised, that people go around repeating RSADSI's claims as if
they were true.

---Dan
Newsgroups: sci.crypt
From: ritter@cactus.org (Terry Ritter)
Subject: Re: NIST stumbles on proposal for public-key encryption
Organization: Capital Area Central Texas UNIX Society, Austin, Tx
Date: Tue, 28 Jul 1992 18:08:55 GMT


 In <4788.Jul2812.30.2492@virtualnews.nyu.edu> brnstnd@nyu.edu
 (Dan Bernstein) writes:


>NIST seems to believe that DSS can be used without royalties. If it is
>incorrect then it will almost certainly withdraw DSS.

 Oh, I see.  After the banks have all installed DSS and are finally
 sued, and after the suit prevails (say 6..8 years), *then* NIST
 will say:  "Gee, I guess we were wrong after all."

 That will be very comforting to the patent holders, who will demand
 compensation for many years of losses, and to intellectual property
 users, who could be liable for considerable expense.

 The fact that the NIST legal crew has an opinion which states that
 DSS does not infringe is not particularly comforting.  If lawyers
 did not hold (or *say* they hold) conflicting opinions, there would
 be no need for courts.


>Let's not mince words here: *RSA Data Security Incorporated* claims that
>DSS is insecure, that DSS infringes upon its patents, etc., etc., etc. I

 One of the patents claimed to be infringed by DSS is the US version
 of a European patent.

 ---
 Terry Ritter   ritter@cactus.org


Newsgroups: sci.crypt
From: gideony@microsoft.com (Gideon Yuval)
Subject: Re: Unemployed cryptologists?
Date: 23 Jul 92 18:59:10 GMT
Organization: Microsoft Corporation
Summary: try MS 

In article <76351@ut-emx.uucp> bhall@ccwf.cc.utexas.edu (Bowman Hall) writes:
>Besides working for governments and researching at universities,
>what employment is there for cryptologists?

Microsoft (who is not the only one!) has licensed RSA's technology.
My boss (Nathan Myhrvold, MS VP for advanced technology) testified
before congress that his kids will think of the no-encryption
systems around now the way _we_ think of the unlocked houses
of old rural America. So I think companies who think like that
will need good encryption bodies.
-- 
Gideon Yuval, gideony@microsoft.com, 206-882-8080 (fax:-883-8101;TWX:160520)
From: erick@fraser.sfu.ca (Erick Bryce Wong)
Subject: Re: choosing passwords (was: Re: Crypt should be based on MD5)
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Tue, 28 Jul 1992 20:02:52 GMT

freitag@elrond.toppoint.de (Claus Schoenleber) writes:
>erick@fraser.sfu.ca (Erick Bryce Wong) writes:
>
>I don't think so.  Here you have to write (11 - i) if i=1 is the leftmost
>position, because the first digit has to be multiplied with 10, the following
>with decrement 1, etc. Then the sum has to be subtracted from the next greater
>number dividable by 11. Your formula stops at the same point as my first
>(and wrong) one.

But, don't the two operations of subtracting i from 11 and of subtracting the
total from a multiple of 11 cancel out?  (Two wrongs make a right? :-)

>There are several ways to write it down, of course. It was meant as an

Quite true.  I just figured that simplifying it would make it look, well,
um, er, simpler... ;)

-- 
 -- Erick, the perfect square  :-)
Newsgroups: sci.crypt
From: avalon@coombs.anu.edu.au (Darren Reed)
Subject: RSA Public Key Generations.
Organization: Computer Services Centre, Australian National University
Date: 29 Jul 92 08:46:06 GMT

Hi, I've been looking at implementing RSA encrpytion and have found that
generating the initial keys is a somewhat tricky.  The only algorithm
I have found for generation the public key is:

N = x*y
p*s mod (x-1)(y-1) = 1

and solve for p. :(

Is there an easy way to solve this problem ?

If anyone can give me some clues on how to do this, it would be great
(or even where to look for some clues :).

Thanks,
Darren
Newsgroups: sci.crypt
From: jonathan@chpc.utexas.edu (Jonathan Thornburg)
Subject: Re: transposition ciphers
Summary: say that transposition ciphers can be broken by multiple anagramming?
Keywords: cipher transposition multiple anagram broken US civil war
Organization: U of Texas at Austin / Physics Dept / Center for Relativity
Date: Sun, 26 Jul 92 07:41:21 GMT

In article <92207.142318U27239@uicvm.uic.edu> Gerald Strom
<U27239@uicvm.uic.edu> writes:
>The following is a little piece I wrote recently about transposition
>ciphers.  As I am far from being an expert in this field, I hope I
>didn't get too much wrong and I would appreciate comments.
> [description and C code deleted]

Shouldn't you also point out that any transposition cipher can be
broken by multiple anagramming?  Kahn "The Codebreakers" discusses
this and gives a couple of examples of broken transposition ciphers,
I believe dating back to the US civil war and the 1884 (?) US
presidential election.

- Jonathan Thornburg
  <jonathan@einstein.ph.utexas.edu> or <jonathan@hermes.chpc.utexas.edu>
  University of Texas at Austin / Physics Dept / Center for Relativity
  and (for a few more months) U of British Columbia / {Astronomy,Physics}
From: clercqm@nijmeg.ingr.com (Marien de Clercq)
Subject: Re: PIN codes
Organization: Intergraph Nijmegen
Date: Tue, 21 Jul 1992 11:51:42 GMT

gast@oahu.cs.ucla.edu (David Gast) writes:

>In article <1674@uel.co.uk> mike@uel.co.uk (Michael Convey) writes:

>I don't know all the details of the Home Fed Bank, but ...

>>2) An account number (which he could have got from an ATM repceit)

>Their ATM receipts do not print the entire account number.

>>3) A PIN (which he could have got from looking over someone's shoulder)

>I think it is a disgrace the way that buttons are set up so that it is
>virtually impossible to block the person behind from seeing what is typed,
>particularly given that most banks only allow a four digit PIN.  The
>fact that most ATM machines are close to a (reflective) window does not
>help either.

What I want I to add to this remark is that - at least here in Holland - in 
more and more shops you can also pay with your PIN-code. For this reason they 
have these ATM's on the counter, producing a receipt for you with a carbon copy
for the shop holder.
To my surprise and worry I did not see one ATM yet that was placed in a way 
that you could prevent people looking over your shoulder AND - what even may 
be more important - to prevent the person behind the counter to see what you 
enter (even though he or she will see it upside down).
The way these devices are placed in most shops perfectly allows the shopkeeper
to collect PIN-codes of all his customers. Together with the Card-numbers that 
are fully printed on his copy of the receipt, this is exactly the information
that is warned against in earlier postings about this subject.

A little cap over the keypad could prevent a lot of misuse, but I guess 
that is far too expensive ...


-- 
Marien de Clercq                            ___ "She was bored with the man,
Intergraph European Mfg. bv.      /|/|    //     because no matter what happened
Nijmegen - The Netherlands       /   | __//      he was always happy as a ...
E-mail: clercqm@nijmeg.ingr.com /    |/_/ \___   clown"    -  Laurie Anderson
From: mrr@scss3.cl.msu.edu (Mark Riordan)
Newsgroups: sci.crypt
Subject: Re: RSA Public Key Generations.
Date: 29 Jul 92 21:40:14 GMT
Organization: Michigan State University
X-Newsreader: Tin 1.1 PL3

avalon@coombs.anu.edu.au (Darren Reed) writes:
: Hi, I've been looking at implementing RSA encrpytion and have found that
: generating the initial keys is a somewhat tricky.  
: 
: If anyone can give me some clues on how to do this, it would be great
: (or even where to look for some clues :).

The principal challenge is in finding the two prime numbers that
constitute (most of) the private key.  Though there are restrictive
guidelines for choosing these if you're really concerned about security,
choosing random primes will work.
There are plenty of "bignum" packages that will help you do that,
including the widely available GNU Multiple Precision package
"gmp".  Look for gmp-1.2.tar.Z at your favorite FTP site.
Newsgroups: sci.crypt,comp.security.misc
From: engholm@nodule.lmo.dec.com (Larry Engholm)
Subject: Re: choosing passwords (was: Re: Crypt should be based on MD5)
Organization: Digital Equipment Corp, Marlboro, MA
	<NL3uNB2w165w@elrond.toppoint.de>
	<1992Jul19.213045.7286@tpki.toppoint.de>
Date: Thu, 23 Jul 1992 06:28:33 GMT

In article <1992Jul19.213045.7286@tpki.toppoint.de> freitag@tpki.toppoint.de (Claus Schoenleber) writes regarding the ISBN checksum:

	       / 10         \
	      /  __          \
   c = 11 -  (   \   a  * i   )  mod 11
	      \  /_   i      /
	       \ i=2        /

   >If c = 10, then take letter 'X' instead.

So what if the sum mod 11 is 0, and therefor c=11?  Is 'Y' used?

This algorithm implies that c can't be 0.  (Maybe 0 is used for 11).
Xref: sparky sci.crypt:2708 comp.security.misc:750