HDTenEightyP/NetNews huggingface dataset:
From: copper@WATSON.IBM.COM ("Don Coppersmith ", 914-945-2288 tie 862)
Newsgroups: sci.crypt
Subject: Re: DES Encryption/ Encrypting more than once.
Date: 16 Oct 92 13:19:38 GMT
Reply-To: COPPER@watson.ibm.com

Keith Campbell claims that repeated encryption under a single DES key
comes back to the original plaintext in about 2^32 rounds.  This is
not true; it usually takes about 2^64 rounds.

The confusion may have two sources: First, he is treating DES (with a
fixed key) as a random function, when in fact it acts like a random
permutation.  (Different plaintexts must yield different ciphertexts.)
A random permutation will have cycle length on the order of 2^64.
A random function will repeat values in time about 2^32, but will not
return to the starting point in that time; so you cannot use the random
function to discover the original starting point.

"Random functions" and "random permutations" should be in the required
syllabus for any cryptographer.

An exception is when the so-called "weak keys" are used.  These are
sixteen keys with special properties, discovered by Donald Davies.
Using these weak keys we can produce short cycles (about 2^32).
I proposed in 1985 to use the l.c.m. of these cycle lengths as a lower
bound on the size of the group generated by DES, and my recent
experiments showed that this group has size at least 10^277.

Don Coppersmith
Newsgroups: sci.crypt
From: m_reymond@zeus.dev.macsch.com (Mike Reymond)
Subject: Re: VCR Plus Codes
Reply-To: m_reymond@macsch.com
Organization: MacNeal-Schwendler Corporation
Date: Tue, 13 Oct 92 14:25:38 GMT


I am reposting this article because in the previous post the lines 
were greater than 72 characters. I've already received a response to 
this article and if anybody is interested feel free to e-mail me.
I apologize for the inconvenience.

I just got a VCR Plus device (@Fry's in LA for $28.88) and think it's
the greatest thing since sliced bread.  No, I am not VCR illiterate.
It's just that I have an old VCR which does not have on-screen
programming. 

I am new to this newsgroup and I have been trying to figure out how 
the VCR Plus codes are derived? 

My inquiry is purely academic. I don't intend to invent my own device.
I've tried to determine if there is a consistent pattern, but have
found none.I suspect there is some sort of encryption. I have also 
noticed that prime time shows on channels 2-13 have codes with the 
fewest digits.

I was told by a helpful netter in rec.puzzles that this newsgroup has
been down this line of inquiry before.

If this query has already been answerd in a FAQ, let me know where I
can get it or e-mail it to me. If this is the wrong group for this I
apologize and point me in the right direction.

Thanx

--
Mike Reymond
MacNeal-Schwendler Corp., Los Angeles, CA, USA
m_reymond@macsch.com
(213) 259-4926
From: hacker@works.uucp (DamDum)
Newsgroups: sci.crypt
Subject: Re: Using genetic engineering for exhaustive DES key search
Keywords: exhaustive, DES, genetic engineering
Date: Mon, 12 Oct 92 16:23:15 EDT
Organization: The Works BBS - Informational Archives - Est. 1985

lou@Cadence.COM (Louis K. Scheffer) writes:

> 
> While pondering the well known problem of DES cracking via exhaustive
> key search, I started wondering if you could apply genetic engineering to
> the problem.  It seems like it may be possible.
> 
> The basic approach would be to build a bacteria that acts as a DES key search
> machine.  Each bacteria generates keys at random, decrypts the encrypted bloc
> with the key, and compares the result with the plaintext.  If there is a matc
> it generates lots of a string of DNA that contains the key and a specific
> marker that binds to an antibody, and excretes the result.  Otherwise it
> just keeps trying keys.
> 
> To decrypt a message, build a string of DNA that contains the encrypted block
> and a potential portion of the plaintext.  Make a lot of copies (say 10^20) 
> and circulate the copies of the original and the antibody through a tank full
> bacteria, and examine the output for something bound to the antibody.  If you
> find something, sequence the DNA to recover the key.  Use the key and
> conventional computers to decipher the rest of the message.

        Hmmm... I'm new to all this DES stuff...But do have a general 
purpose DES encripter that I can run in a batch file!!

        After reading all theas messeges about trying to brake 
DES....well has anyone ever thought that only a dum &^%$ would only 
encript a file/text only ONCE?!?!?!?!?!?!?!?!?!?!?

        Of cores if you have than I must not be reading very well and I 
will be more perseptive in the fucher!

        -Hacker (DamDum inc.)

        hacker@works.uucp
Newsgroups: sci.crypt
From: idealord@dorsai.com (Jeff Harrington)
Subject: PGP 2.0 FTP Address
Organization: The Dorsai Embassy, New York's Computer Consulate. +1.718.729.5018
Date: Wed, 14 Oct 1992 12:59:39 GMT

Sorry to be redundant but where can I find the much maligned code?
Thanks
Jeff Harrington
idealord@dorsai.com
 
**Still Zappin' Dan Rather On Thursday CBS Evening News***
IdEAL ORDER Psychic TV!
Newsgroups: sci.crypt
From: craig@jido.b30.ingr.com (Craig Presson)
Subject: Re: query: how to synch crypto streams
Reply-To: craig@jido.b30.ingr.com
Organization: Intergraph Corporation, Huntsville, Alabama
Date: Fri, 16 Oct 1992 17:36:36 GMT

In article <1992Oct15.162327.28555@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. "Buddy can you spare a clue?" Ranum) writes:

	   I'm just wondering. What kinds of techniques are usually used for
   synching two crypto streams? Suppose I have a pair of boxes that each can
   talk DES. There is a wire between them. I want to pass data back and
   forth encrypted. What kinds of tricks might I use to get them both talking
   together (and able to understand eachother) ;) without having to pass some
   kind of a key over the wire that an enemy could use?

How timely you should ask this, I'm just about to go off and read up
on key exchange protocols, so I'll be interested in what other answers
come up. But, to get you closer to solid ground, in the case of
symmetric (private-key) systems, the boxes have to have one master key
which is securely installed; they then use this key to exchange
session keys in a secure fashion. Since wiretapping is the threat
being guarded against when you do point-to-point encryption, you need
to assume that the bad guy has recorded every bit you transmitted from
the diagnostics on installation day to the message saying it's been
nice talking to you, we don't need this link anymore
*click* Hmmmmmmmmmmmmmmmmmmm

-- Craig Presson




Newsgroups: sci.crypt
From: reuter@venice.sedd.trw.com (Joseph Reuter)
Subject: Re: DES Encryption/ Encrypting more than once.
Organization: TRW Systems Engineering & Development Division, Carson, CA
Date: Thu, 15 Oct 1992 19:47:09 GMT

In article <1992Oct15.144341.15104@rchland.ibm.com> lwloen@vnet.ibm.com writes:
>[stuff deleted]
>The simplest way to show this is to do Simple Substitution
>ciphers.  One can re-arrange the standard two alphabet key as
>chains of substitutions.  For instance, consider (for brevity) the following
>simple substitution key 
>
>ABCDEFGHIJK...   for plaintext and
>REPUBLICAND...   for ciphertext.
>
>This has B->E->B (and hence, is B<->E), but G->I->A->R->morestuff->G.  This
>sort of irregular value for n is commonplace in ciphers.
>

This argument shows that the MINIMUM value of n is different for each plaintext
character.  However, the number of plaintext characters is finite (even in
DEX it is 2^64, which is finite) and the least common multiple of the various
n's has the property that repeating the substitution that many times will
transform each plaintext character into itself.  Far from disproving the
original assertion, you have proved it!

-- 
Joseph A. Reuter, Wizard-in-Training
Speaking for myself from reuter@venice.sedd.trw.com
"Olorin I was in my youth in the West that is forgotten." -- J.R.R. Tolkien
"You can't win, you can't break even, and it's the only game in town."
Newsgroups: sci.crypt
From: schneier@chinet.chi.il.us (Bruce Schneier)
Subject: FEAL and N-Hash
Organization: Chinet - Public Access UNIX
Date: Fri, 16 Oct 1992 01:10:22 GMT

I am looking for a C programmer who is willing to implement FEAL and N-Hash.
FEAL is a block algorithm from Japan; N-Hash is a one-way hash function from
the same place.  Eli Biham and Adi Shamir made mincemeat out of them with
differential cryptanalysis, but they still have some interest.

Anyway, I have paper copies of C source code that claims to implement the
algorithms (a few pages; not very long).  I am looking for someone who is
willing to get them working, and then let me publish the source code in my
book.

This looks like a pretty simple operation for an experienced C programmer.
Any takers?

Bruce

****************************************************************************
* Bruce Schneier
* Counterpane Systems         For a good prime, call 391581 * 2^216193 - 1
* schneier@chinet.chi.il.us
****************************************************************************
Xref: sparky sci.crypt:3797 alt.security:4569
From: nyelle@ccrs.emr.ca (Norman Yelle)
Newsgroups: sci.crypt,alt.security
Subject: Re: Letter Frequency
Date: 15 Oct 92 14:09:18 GMT
Organization: Canada Centre for Remote Sensing, Ottawa

In article <1big1qINNrnq@matt.ksu.ksu.edu> holland@matt.ksu.ksu.edu (Rich Holland) writes:
>I'm in dire need of a letter frequency chart for the English language.  I
>remember as a kid reading books on basic cryptanalysis and seeing these
>charts of the most frequently used letter (like "E" is most often used,
>then "S" or "R" or something, etc).  I don't remember the order, but now
>I need it.  Anyone got a copy of a table of something like this online?
>
>If not, got a source where I can go look it up quick?
>

If you have an on-line copy of the dictionnary, then you can do the
following:

  grep -i e /usr/dict/words | wc

... to find how many words contain the letter 'e'.  You can do this for all
26 letters.  This is the results I got with a dictionary of 25144 words:

   a   13190
   b    3862
   c    7204
   d    5324
   e   14835
   f    2342
   g    3756
   h    4844
   i   11428
   j     427
   k    1848
   l    8625
   m    5320
   n   10256
   o   10285
   p    4929
   q     377
   r   11533
   s    8700
   t   10599
   u    5989
   v    1848
   w    1907
   x     616
   y    3523
   z     380

Norman.
-- 
Norman Yelle      (Email: nyelle@ccrs.emr.ca)             |       Amazing
Canada Centre for Remote Sensing                        --+--      Grace
588 Booth Street, Ottawa, Ontario, Canada  K1A 0Y7        |
  Phone: (613) 947-1299     Fax: (613) 947-1408           |     Romans 1.16
Newsgroups: sci.crypt
From: kornele@a.cs.okstate.edu (KORNELE BRYAN WAYN)
Subject: FAQ almost an answer 
Organization: Oklahoma State University
Date: Sat, 10 Oct 92 04:16:17 GMT




This is not a faq list but this site has a very good paper
on cryptography (modern techniques, explanations, and lots
of refs) if anyone is interested. This paper is very long 
about 9,000 lines if I remember.

ftp anonymous at van-bc.wimsey.bc.ca  (192.48.234.1)

Has lots of other stuff to including different C implementations
of various cyphers.

The name of the paper is crypt.txt  under pub/crypto .

Bryan



------------------------------------------------------------------------------
Bryan Kornele: Oklahoma State University    |
------------------------------------------------------------------------------
Internet: kornele@a.cs.okstate.edu          | 
-----------------------------------------------------------------------------
"Hey! What the Hell?"--David Letterman      |
-----------------------------------------------------------------------------
Newsgroups: sci.crypt
From: egurney@vcd.hp.com (Ed J. Gurney)
Subject: How secure is this encryption scheme?
Date: Mon, 12 Oct 1992 22:48:39 GMT
Organization: Hewlett-Packard VCD
X-Newsreader: TIN [version 1.1.4 PL6]

I've been working with the following encryption scheme and am wondering
how hard it would be (or if it's even possible at all) to devise a method
of "reversing" it.  Someone has told me this is an "NP-Hard" problem,
but I thought I'd ask all you net.gods.  Here's a description:

The system works by encrypting the data in 8 byte chunks.  So repetitive
data (8-byte aligned) always appears the same way in the encrypted data.

In other words, if the data contains the bytes
 :00 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00:
the encrypted data might be (as an illustration)
 :01 23 45 67 89 ab cd ef:01 23 45 67 89 ab cd ef:01 23 45 67 89 ab cd ef:
But the sequence
 :ff 00 00 00 00 00 00 00:00 00 00 00 00 00 00 00:
might encrypt to
 :11 22 33 44 55 66 77 88:01 23 45 67 89 ab cd ef:

Again, this is just to illustrate the fact that data aligned to the same
eight-byte boundary, and then repeated, has the same encrypted data on
eight-byte boundaries.

This particular encryption method uses an 8 byte key, which is in turn 
passed to a routine to generate a (unique) sequence of 32 bytes used in
the actual [en|de]cryption.

My question is this:  Assuming you know for a fact that a certain eight
bytes of encrypted data decrypt to a known set of eight plaintext bytes,
can you find the original key and decrypt the rest of the data?  The only
information you have is the decryption routine written in C, the eight
encrypted bytes, and the eight plaintext bytes.  The decryption routine
is _not_ the same routine used for encryption.  (i.e., feeding the plaintext
and a key to the decrypter does not generate the encrypted data.)

A brute force approach does work (I've verified that, but it takes a long
time to try all 2^32 possible combinations, even on a relatively fast RISC
machine.)  This is probably acceptable because the number of keys will be 
very high and would take a long time to find them all.  Assuming that
                  Plaintext + Key = Data
it follows there should be some way to then apply
                  Data + Plaintext = Key
I want to know if this logic holds, or if this system is "immune" to that 
sort of approach.

If it matters, the decryption algorithm consists of the routine to generate
a 32 byte "subkey" from the original 8 byte key and another routine with an 
8-cycle loop that exclusive ors, rotates left and adds byte-sized
operands.

Any thoughts, comments, or ideas would be greatly appreciated.

If anyone's interested in trying to "reverse" the decryption algorithm,
I could consider mailing/posting my C code decryption algorithm and some 
sample data.

Best regards,
Ed

--
Ed J. Gurney  N8FPW       Hewlett-Packard Company      Vancouver Division
egurney@vcd.hp.com                       #include <standard-disclaimer.h>
"Failures are divided into two classes-- those who thought and never did,
      and those who did and never thought."     John Charles Salak
Newsgroups: sci.crypt
Subject: Re: Public key patents in Europe?
From: a_rubin@dsg4.dse.beckman.com (Arthur Rubin)
Date: 12 Oct 92 22:03:52 GMT
Organization: Beckman Instruments, Inc.

In <bontchev.718919860@fbihh> bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:

>Well, so I am asking those of you who are "in Europe": do you have any
>information about the above? Could you tell me in which countries
>exactly public-key cryptography is patented and which are the patent
>numbers? Thanks in advance.

My understanding, from reading comp.patents, is that RSA is unpatentable in
countries other than the USA, because it was published (in Scientific
American, no less) before the patent was applied for.
--
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.
Newsgroups: sci.crypt
From: gardner@convex.com (Steve Gardner)
Subject: Re: RSA outside the US
Date: Sun, 11 Oct 1992 23:43:24 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 <1992Oct9.233126.10429@uoft02.utoledo.edu> jsteiner@anwsun.phya.utoledo.edu (jason 'Think!' steiner) writes:
>please correct me if i'm wrong, but in reading the FAQ my mind started
>to boggle & i need to clarify this:
>
>   1. RSA is pretty much a standard in Europe.
>   2. it is illegal to export RSA stuff from the US.
>
>now i've always thought the US government was a bit bass ackwards,
>but this is just silly.
	Yeah, incredible isn't it! It seems most americans don't care 
	how daffy (or evil!) their government is.  We've got an enormous 
	bureauracy devoted to fighting an "evil empire" which is now defunct, 
	we've got fundamentalist nut cases determining what goes into high 
	school biology texts and we have a War on Some Drugs that is quickly 
	eroding	what is left of the Bill of Rights.  We've also got a bunch of 
	cold war left overs in the NSA trying to protect us from the
	"evil empire" and in the process harming the US telecommunications
	industry.  It's a sad horrible joke but you get blank looks from 
	the man in the street when you mention it.  Perhaps now that the
	economy has hit the skids and we are on the edge of another great
	depression people will start to look at who our real enemies are
	and see that they aren't foreign after all. . . 



						smg
Newsgroups: sci.crypt
From: gauthier@ug.cs.dal.ca (Paul Gauthier)
Subject: Re: An apology to people who have emailed me about keys
Organization: Math, Stats & CS, Dalhousie University, Halifax, NS, Canada
Distribution: dal
Date: Fri, 9 Oct 1992 13:44:50 GMT

In <books.17.0@fsunuc.physics.fsu.edu> books@fsunuc.physics.fsu.edu (Roger Books) writes:

>My hard drive crashed (actually, the stoned virus and Stacker ate it.) So
>I have not returned any messages about keys, or anything else actually.  I
>will have to download PGP again and generate a new key.  I'm sorry if I 
>annoyed anyone with this but there was not much I could do about it.

Ya, sure. You expect us to believe this!? Spoof alert! Spoof alert! Someone
is trying to place themselves between us and Roger Books. We must~* &*nM{M

NO CARRIER
-- 
===========================================================================
                             Paul Gauthier
cyclist, rock climber, skydiver, computer scientist (...in order of danger)
Electronic: gauthier@ug.cs.dal.ca  Voice: (902)423-0089  Fax: (902)420-1675
Newsgroups: sci.crypt
From: etllnfr@eddie.ericsson.se (Lyndon Fletcher)
Subject: Re: Every Spy Should Carry a Bible
Organization: Ericsson Cellular Division
Date: Wed, 7 Oct 1992 15:01:28 GMT

>>In article <BvpEx7.7Iq@fulcrum.bt.co.uk> igb@fulcrum.bt.co.uk (Ian G Batten)  
>>writes:
>> "Suppose I strip off the bottom bit
>> "of each sample in a piece of music on CD and replace it with my ideal
>> "random bits, and press the CDs.
>>
I know that during the war two forms of "personal codes" for agents were used.
One was the book code where the agent and his control used a common book as the
source of a "random pad" for encoding messages.

For example if agent X used Hamlet for his book code he may have used

"Alas poor Yoric, I knew him..........."
as the random sequence to encode the plain text. Both agent and control
know that that paragraph is the "random pad" of the day but a potential 
enemy would have to know at least the book, if not the passage to decode
the cyphertext.

SOE agents used poems because they can be easily memorised so the agent need
not carry a book (and thus the basis of their personal code ) with them.
This has the secondary advantage that the code dies with the agent. A book
found with an agent could be used for spoofing even if the agent where
uncooperative or dead. When the Germans became aware of the poem codes and
checked all published poems against received cyphertext the British just wrote
new unpublished poems, some of which are the most beautiful coding systems
you have ever heared :-)

My point is this. Why with the CD system is it nescessary to produce and
 distribute special CD's.
Instead the agent has a PC and a CDROM player and a very large collection of
 standard off the shelf CD's.

The agent knows that in December the "disk of the month" is for instance
Queen's "A Kind of Magic". This is a standard CD bought at a local music shop.
The software on the PC takes a beginning block postion or time on the CD and
uses that as a start point for encryption. As the disk contains a lot of
effectively random data and the disk is changed regularly the method of
finding the start position can be real simple without compromising the code.
Suppose the spy takes the date and mutiplys it by 2 for example.
The start position for today would be 921007 * 2 = 1842014, which is either
a block number or a time in ms.

This has to be a perfect cypher. The musical data is effectively an agreed
random number sequence, both the disk used and the start point are known
only to the agent and his control. Even if the agent was discovered the
huge amount of possible sequences even with a modest CD collection
would be astronomical and make the code resistant to spoofing without the
help of the agent (and all codes would fail in that case!!!!).

If the agent only bought his CD's as he needed them the code would be even
better. IF the FBI raids agent X's house on August 20th they may discover
his complete setup (v. unlikely) but if agent x hasn't actualy
bought the disk which is the basis of Septembers code sequence, they stand
no chance of discovering what it is without his assistance.

Well what do you think???

Fletch
From: clements@bbn.com (Bob Clements)
Newsgroups: sci.crypt
Subject: Re: VCR Plus Codes
Date: 15 Oct 1992 15:33:26 GMT
NNTP-Posting-Host: classic.bbn.com

In article <1992Oct14.152230.16549@linus.mitre.org> ptrei@bistromath.mitre.org (Peter Trei) writes:

>    Nevertheless, the algorithm for codes of up to 6 characters (ie,
                                                ****^****
>the vast majority of them) has been decrypted and published:

>    Curiously, the channel number is only 5 bits long.
				       ****^****


These two facts seem to be correlated.  If you look at the listings
for channel 68 in Boston, for example, you'll find that every listing,
even for prime time one-hour or half-hour programs, has more than
six digits.

So, roughly, the added two digits in the longer codes must encode
the extra channel numbers as well as the number of five-minute
increments to add/subtract from the start time and duration.

>							Peter Trei
>							ptrei@Mitre.org

Bob Clements, K1BC, clements@bbn.com