Conference noted::hackers_v1

For the vacarious thrill-seekers out there, you could code up the DES algorithm
(available in CACM, volume mumble mumble), and then

$ TYPE <foreign-node>::<your-node-here>"<account> <password>"::DES.MAR

And if you're incredibly brazen, debug it first!

					- Gilbert 

Just think of the bother that could happen if, say, DEC UK had to get
an export license for every bit of software brought over the E-Net.
Just think of the duty that would have to be paid to UK Customs &
Excise!

Even a modest ciphering algorithm could cause the monitoring authority
problems. If a ciphered transmission took say, 5 minutes to crack, there
would be an awful lot of resources required to crack them.

In theory, the old Post Office who used to run our telecommunications
services in the UK required everyone who used ciphers to deposit a 
key with them. This was an old rule intended for Telex/Telegraph
services. Although I don't believe that such a rule is enforced
any more, I couldn't imagine that being applied in the States.

The point is that there is no right to secure transmission services
over here and if you are sufficiently paranoid, the telephone company
(British Telecom) is starting to market computers.

Regards,

Hugh.

P.S.	If you have ever looked at a data scope on a Decnet line, you will
realise how easy it is to intercept password/account and other information.

P.P.S.	Sorry about the timezone problem, although we have the latest Notes,
we do not have enough privilege (in theory) to set up the system logical.

Hugh noted that the post office once required users to deposit cypher
key books for telex/telegraph services.  If I remember correctly,
there were different rates for different cypher services.  One,
for which you had to deposit a cypher book, served only to shorten
the communication:  AABA meant "We will ship on the aggreed upon date",
while BBAA meant "The software in this document is subject to change
without notice".  I think the requirement for deposition was to prevent
argument in subsequent lawsuits -- either party could point to an
"official" decription.

The other cypher'ed service (which, I believe, had a higher tariff),
was encrypted -- but the post office didn't have decription possibilities.

Martin.

Will this clear things up or add to the confusion?

A "cipher" (from Arabic sifir = empty, cipher, zero) implies concealment
of meaning (almost always) therefore "secret cipher" is a redundant
expression

A "code" (from Latin codex = tablet of wood covered with wax for writing)
applies to any symbolic transformation (such as Morse code) including,
but not limited to concealed transformations. therefore "secret code" is not
a redundant expression

The use of Commercial Codes in Telegraphy had a brief history for several
reasons.  The greatest one being the errors that were introduced by
message entry, noise, and message decoding.  Another being the lack of
"standards" so that messages could be exchanged by many corporations.
Finally, concern by governments that "national security" would be compromised
in the event of war.

History has an odd way of repeating itself.  Was is Michael Hammer who said
that Electronic Mail started with Samuel Morse?

Pat Sweeney

	When I studied cryptanalysis, we made the following distinctions:

	    o CIPHER - Substitution of symbols for characters.  This would
	      make Morse Code a cipher, not a code.

	    o CODE - Messages depending on pre-agreed syntax for translation.
	      Thus, a "code book" would tell you that "Three Green Fish" means
	      "My Wife Suspects."  Note that computer languages are properly
	      called code.
		<_Jym_>

re: .4, .5

Does this make ASCII a cipher, not a code?  It does substitute
symbols (7/8 bits) for characters.

Actually, cipher means zero and that's about the content of this
message.  :-)

Andy V

Re .5, .6:

I basically concur with Jym.  I remember a code as being defined as any
encryption (encoding?) done upon units larger than characters.  One example
was a code used by Germany in WWI which translated individual words into
page and line numbers in a popular German dictionary.  Someone suspected
that that might be what the code was, bought a lot of German dictionaries,
and figured out which one it was.
				/AHM

Re .7:

As opposed to the cypher mentioned in an episode of Mr. Nice, a 60's sitcom,
where the crooks translated individual letters into digits based on the
letters on a telephone dial.  The writers didn't seem to notice that you get
three choices for each letter, and I don't remember any extra digits for
disambiguating the situation.
				/AHM

re .-1, the Phone cipher

You could either have 7 characters per 7-digit phone number, and "play" with
it to get a readable translation.

Or you could have just 5 characters per phone number, and use the (leading) two
extra digits to disambiguate the 3**5 = 243 possibilities (which still takes a
little playing).  Although archaic now, in the early '60s, an few extra bits
could be encrypted by using letters for the exchange (ala HUdson3-2700).

					- Gilbert

re:  Cipher vs. Code distinction

The "cipher for letters, code for words" distinction used to make sense.  In
modern cryptography - certainly anything since WW II - it's quite obsolete.

Even in the old days, what would you call a system that had unique codes
(ciphers?) for each pair of consecutive letters?
							-- Jerry

Based on what I remember reading, it's a code.  What a professional from
1945 would call it, I better not say.  I don't know if it is the same kind
of issue as "what is a byte?".  (I use PDP-10s - a byte is a string of 0
or more bits).

As far as hacks go, I have seen 0 bit byte pointers used.  The code in DMPREL
which sets up a byte pointer to relocation bits or psect indices for the
current REL block being dumped uses 0 bit byte pointers for blocks with no
relocation bytes.  That way, routines deep in the REL file reader that read
data and relocation just get relocation bytes of 0.
				/AHM

From:	RHEA::DECWRL::"chris@maryland.ARPA" (Chris Torek)
Date:	Wed, 5 Sep 84 08:56:04 edt
Subj:	Re:  U.S. may tap lines to halt software smuggling by phone

Oh good grief!

I'll bet the Reagan administration has never heard of USENET.  (For
those of you who haven't, it's a network that is somewhat similar to
ARPAnet, except that it (a) isn't high speed; (b) isn't centrally
administered, and (c) isn't really all that well defined anyway.
However, it has links into Europe and Australia and Korea -- all sorts
of places.)  Among lots of other stuff, software is broadcast over
this net.

Let me make a few medium-range predictions:

  - WORLDNET will happen, eventually.

  - There will be lots of effort to stop it on the part of those who
have vested interests in the current situation, especially
governments.

  - The nature of computer networking (simultaneous broadcast and
point-to-point communications) will have as dramatic an effect on
society as the printing press.

Just think:  if you have a worldwide network and want to start some
subversive activity, just broadcast two messages.  The first contains
instructions (or code) for decrypting the second; the second is the
subversive message.  You can't catch the second by keyword search
because it doesn't have any keywords until it's decrypted.  (The
encryption can be as simple as a Caesar cipher.)

Here's another thing to think about.  Right now, we can't discuss and
vote on ordinary happenings because the information and votes can't
happen fast enough.  That's why we (the U.S.) have a representative
democracy for a government; we're (theoretically) paying these guys to
do what we would have done.  Now stick in a high-speed computer
network.  Voila!  We *can* discuss and vote on the issue!  [Not that
we *would*, just that we *can*.]

Naturally there are problems with these, but what I'm saying is that
*things are going to change*, providing we don't blow ourselves to
smithereens first.  It won't happen instantly and it probably won't be
painless either, but that's the way I see it.  Trying to ``put a lid''
on software going out of the country is going to be expensive, and
won't succeed, though it will have an effect.  The question now is,
``is the effect worth the cost?''  Personally, I doubt it.

re 8,9

  In modern times ...
    A code is created for reasons other than security (usually).
    A cipher is created to hide or protect.

 re 0
  It goes to show you how dumb the news media is when it comes to
  computers. Even monitoring voice communications is next to impossible
  because of the number of calls (a lot of people eves dropping to a lot
  of boring conversations). I concur with .-* even a very simple cipher
  would mess 'em up.

George

...but tapping data lines is much easier than voice calls!  Data calls
are trivial to identify (listen for modem tones) and can be monitored
directly by computer (unlike voice calls which have to be taped and
screened/transcribed by humans).

In fact, you can screen for cyphered data by looking for data that does
not obey the statistics of plaintext.  (for example, near-equal frequency
of all 256 possible byte values.)  That would isolate very quickly the
data most worthy of a serious cracking effort.  After all, if it's
cyphered, it must be worth something, right?

	Paul

...and about simple cyphers: modern technology can crack simple cyphers in
a matter of minutes if not seconds.  "Simple" includes most if not all
cyphers invented before 1945 (except for the one-time pad, of course!).
DES is a different case, of course, but any sensible person has to assume
that the NSA can break that relatively easily too.

Re .12: that reminds me of "the Probability Broach" (by Neil Smith)

    If you accept the dictinction a few notes back,  I'd call a .LBR
    file being transmitted by KERMIT "coded" but not "cyphered".  I
    think it's non-trivial to distinguish code from cypher, and
    therefore not as easy as you claim to monitor all data calls
    for "good stuff".

re .15
	Simple substitution ciphers are easy to break.  But some sophisticated
	codes were around long before 1945.  See "The Codebreakers" for an
	out-of-date history of codes and how they are broken (it was published
	circa 1972(?), but I still see it advertised in the Sci.Am. press).

re: 17 

"Codebreakers" David Kahn, New York: NAL/ Signet and it's still in print 

It's not an obsolete survey but THE indispensible book covering all "codes"
from prehistory right up to 1967. 

I'd recommend "The Puzzle Palace" to bring you up to date to 1984.

Pat Sweeney 

Yes, I've read the codebreakers (the paperback condensed edition -- anyone
have the full-size hardcover and willing to sell it?).  That's why I said
what I said, because it appears obvious that even the most sophisticated
cyphers of the WW2 era can be easily broken today.  Consider, for example,
that NO cyphers of that era were secure against known-plaintext attack,
which is a fundamental requirement for any modern cypher.  Of course, that
doesn't stop all sorts of fly by night outfits from selling garbage, but
that's another matter.  (Consider an example mentioned in the WSJ of 11/12/84:
"Elite software systems Inc." is quoted as offering an "encryption"
utility for disk data, and offering $10k to anyone who can break it --
but with a twist: only those who break it with a micro need apply, someone
who used a "mainframe" (that probably means a 780) was laughed out the door.
Obviously those clowns are either frauds or ignorant fools to take that
attitude.)

	Paul

Re: .19

The hard cover edition is still available.  I just bought it last year
from my father's bookstore.  I'll warn you it's a rather expensive book
but like everyone else has said ... it's worth it.  I started reading it
and put it down... picked it up... etc.  Sooner or later I'll finish it.
The book is not one of those novels you can't put down.

Steve

Re: .19

You might even try the Nashua Public Library.  The book was even in the
Holden, MA library when I was a kid.  That was real heavy stuff back when
I was in the 8-9th grade.

Steve

I'll try it again at some local bookstore.  Last time I tried I was told
it's out of print.  If I still have no luck, I'll ask you for a pointer
to your father's bookstore... :-)

I think the sheer volume of data being transmitted internationally makes
it quite impractical for NSA to do more than an extremely cursory check
for forbidden data.  I would venture a wild guess that the amount of data
entering and leaving the country every day is in the multi-gigabyte range.
Now, NSA has a lot of computers, but they have other fish to fry too, and
as a result I'll bet the only people they catch that way are people who
are innocently transmitting stuff they didn't know was export-controlled.

Anyone who is sufficiently determined can use an R-S-A algorithm with
a long enough key that NSA won't be able to break it for months, maybe
years.  Assuming they even pick up on it and start to try.

Plus, all we have to do is start encrypting everything that goes out
over phone lines (not hard) and pretty soon the NSA will be burning
up all its Cybers decrypting notes file entries!

- Larry Campbell
  Eastern Research Lab (Hudson)

You're making the assumption RSA is secure.  If I were intent on getting
past the NSA, I wouldn't make that assumption!  Remember that RSA is
clearly no more secure than the difficulty of factoring (which is an
unknown quantity) and it has not been proven that there exist no ways
to break RSA that are easier than factoring.

As for issues of volume: I'm quite sure you could build a two-chip board
to screen any single phone line: one chip for the modem and the other
for the single-chip micro that collects the data  statistics looking
for data that seems to be encrypted.  Alternatively, since by the time
it gets to the satellite the phone data is already muxed into T1 carriers
and higher-order stuff, it might take even less than that.  Certainly not more.

	Paul

The encrypted data which emerges from at least one algorithm I know of
(ENDECR for the PDP-10, used in SOS and BACKUP), has a very distinctive
pattern.  All character values are equally likely.  I discovered this
when analyzing an encrypted file with a Huffman code data compression
algorithm.  The data was so random, that there was no real benefit to
trying to compress it.

I won't claim that all good cyphers have this characteristic, but I bet
that most algorithms which don't try to avoid this effect end up having
it.  If someone can quote any good sources on cryptography on this topic,
I'd be interested in reading it.  Claims as to the intuitive truth or
falsehood of the statement would be interesting, too.  Remember, I didn't
pull this out of thin air, I observed the effect by accident, and then
made a sweeping generalization to cover it.
				/AHM

I can't see why it should be theoreticallly required that the frequency
stats are "flat", but on the other hand I find it difficult to think of
a (reasonably secure) cypher that doesn't come out flat.  Codes are
a different matter, of course -- but that's hardly relevant for electronic
data communication.

One of my favorite references on cryptography is "Privacy and authentication:
an introduction to cryptography" by Diffie and Hellmn, Proceedings of
the IEEE, Vol 67 No 3, March 1979.  It contains an immense bibliography
as well.

	Paul

Konheim's "Cryptography, A primer" has been a eye-opener for the mathematician
in me...

/Bevin

Re: .25

Presumably any binary (as opposed to ASCII) transmission, will also have
a random bit distribution. I wonder what decryption would make of that...

Andrew M.                                         

Re .28:

    no, most binary data transmission are far from random.  Just try
    counting the occurences of each of the values of the 8 bit bytes
    in a .EXE file.  You'll be surprised.

    If binary transmissions were truly randome, then Huffman compression
    wouldn't gain anything for them.

    Dave

Why do a Huffman-encoding on the encrypted data?

If, instead, encryption is done on the Huffman-encoding, you'll have
shorter messages.

Huffman-encoded data is, of course, 'flat'.  I'd expect that most good
encryption algorithms also produce flat 'cipher-text'.

FWIW, there are a variety of 'on-line' or dynamic data-compression techniques
that could be included in an encrytion/decryption black box.  This would work
best for voluminous text data; and it could increase the size of some messages
(those that already 'flat').

Re .30:

    I'm not sure who you were responding to...

    If you were responding to me (.29), please note that I was referring
    to the Huffman encoding of NON-ENCRYPTED binary data.  An example is
    the SQ/USQ pair of programs used in personal computer circles to 
    save disk space (and file transfer time).  If "plain" binary data were
    flat, then no one would Huffman-code it.  Programs like LU/USQ 
    wouldn't be used on .EXE files.

Response .30 was prompted by /AHM's remarks in .25.

One should expect any good encryption algorithm to produce essentially "flat"
output.  This is easy to explain:  Consider encryption as a function from
plaintext to codetext.  There is one function for each key value.  Write the
function as Fk for key value k.

Now, normally one wishes encryption to leave the size of the text essentially
unchanged; that is, if M is the message space, we normally want Fk to map M to
itself.  (There are codes that don't do this, but they are not common; they
aren't any easier to build than those that don't expand - unless they expand
by very large amounts.)  Now, for any message m, consider the set {Fk(m)} for
all possible key values.  This should contain a lot of different possible
values, for just about every possible m; otherwise it's too easy to guess
messages.  However, for any PARTICULAR statistics, there can't be too many
encrypted messages of a given size with that set of statistics; in fact, the
more "distinctive" the statistics are, the fewer matching messages there can
be.  (This is pretty much what "distinctiveness" has to mean.)  Hence,
{Fk(m)} must look pretty "random".  You can make exactly the same argument
for different m's when k is fixed.

This is a rather informal argument, but in fact it can be formalized within
information theory - it has to do with the fact that any eveness in the
\\\make that un-evenness - in the statistics represents information about the
message, and the whole point of encryption is to hide that information.

This has an interesting real-life implications.  Consider how to encrypt
voice.  An obvious thing to do is do an A/D conversion, run through some
good encryption algorithm, do a D/A, and transmit over your phone line,
radio channle, or whatever - reversing the steps at the other end.  Unfor-
tunately, this doesn't work.  Analog channels have limited bandwidth, since
voice does.  Once you encryt and do your D/A, you have a VERY broadband
signal, which you can no longer effectively transmit.  So there is, and
will for a long time continue to be, a market for analog scramblers of
various sorts.  (Commonly, they do things like divide the frequency spectrum
into a buch of bands and scramble them around.)
							-- Jerry

re .-1
	Ah, this seems to be part of the *definition* of a 'good encryption
	algorithm': a significant statistic of the plaintext should not be
	transformed into a significant statistic of the ciphertext.

re .-1 (last paragraph)

	This is another case where "compress, then encrypt" is appropriate.

More on voice encryption: there does exist current (in fact, 3-4 year old)
technology that can transform voice to a 2400-bps digital signal and restore
it to voice, in real time, with high enough quality that the voice remains
"natural-sounding" and the speaker can still be recognized (i.e. no robot
voice).  I saw a pointer to this in a magazine about voice synthesis and
related stuff (which I gave away); it mentions the availability of the
algorithm but unfortunately it's classified.  It runs in real time on 
some signal processing computer (Ford?) and also exists in Fortran as non-
realtime.  Obviously any algorithm the  military can invent someone else
can re-invent.  And 2400 bps on a voice grade line is off-the-shelf
technology.

You didn't mention that ALL analog scrambling methods have terrible security...

	Paul

With all the problems systems have when trying to read tapes made
on other systems, or the problems we have networking different systems to
each other, I find it hard to believe that it's not really easy to transmit
information that normally couldn't be decrypted.
We can't decrypt information when we know the specs sometimes!

Using VMS itself as the code is a way to avoid decryption. Here is the way
I led up to it: let's say that a book is the 'code' itself.  In other words, 
the page number and word 
number (or putting this info into some formula) then lets the reader know
which word to use by looking it up in the text of the book.  The book could
be the VMS notebook set, an index into a standard HELP message, or be indexed
by any character that normally exists in VMS itself.

given that the 'book' was large enough (ie. the VMS notebook set), even if
the codebreakers were able to figure out which 'numbers' meant which 'words'
(without realizing the VMS notebook set was involved), there would be so
many occurences of the same word, that there would always be new 'numbers'
to decode.  Thus, as long as people randomly selected the words from any
of the notebook volumes, and the formula of (vol#*x)+(page*y)+(line*z)+
(word*w) would have new values of w,x,y, and z periodically, your code
would always be way ahead of the codebreakers.  The trick is making sure
that the book you select is 'common' for the intended reader.
An old trick in this regard is to use a periodical as the index. (For instance,
the New Yorker was supposedly such a 'key' during WWII, and if you're really
stoned, there is actually a picture which depicts exactly when and where the
strike at Pearl Harbor was about to occur (due to the numbers on the dice in
the picture, etc).

Of course if the VMS notebook set was online, you could even write a program
to do your random word-finds for you to generate your coded message.
(Of course you could even do it on a character by character basis, and you
could have the program generate indexes into a standard VMS monitor rather
than the standard VMS notebooks if you want....).

So it's lucky the DES standard is commonly being used, because otherwise people 
might think up methods like this, and then our government wouldn't be able to 
decode them to protect our national security, etc.

Hopefully, this note file is protected by 'DECnet' and other encumberances...

Humbug.  You forget that book codes have frequently been broken even before
there were computers available to help.

Another problem is that the current state of the art in cryptography calls
for all systems to be secure against known plaintext attack.  This system
clearly fails that test.  Besides, it's a bitch to use.

	Paul

Just because book codes were 'frequently' broken, does not mean that they
always can be broken before the book or the key changes.

By the way, how can you be sure that my note itself was not an encrypted
message.  If you take the ascii value (or even Ebcdic) of the first letter
in every other word, that might be the offset into the current VMS
monitor.

Back when books were the codes, you might not have needed computers, but
now that computers are around so that codes are not a bitch to use, 
you need to have MUCH more computing power to break the code, and in many
cases, it will not be decoded by plaintext or whatever, since only true
investigative talent would bring the realization of what type of code it
was in the first place.
(remember, any particular letter (ie. 'a') might never be referred to by
the same code twice (ie. everyone might pick a different occurence of it
in the notebook set, so until someone realizes the notebook set is 
involved (or the monitor, layered software, or whatever), the decoders will
not really have any leads to go on.

    An interesting sidelight to this discussion would be "secret codes"
    by which I mean, coded messages that are embedded in another plaintext.

    Once you see the plaintext, it can be extraodinarily difficult to
    realize that there is an extra message in there.  Such realization
    generally depends on noting that there is something odd or unusual
    about the plaintext that was caused by constraints imposed by the
    overlaid code.

    In one example from WWII, a single "wrong" note in a broadcast
    symphony, contained the entire message.  This one was detected,
    by the way!

    Wouldn't it be interesting if the NSA were to regard the transmission
    of a FOO.OBJ file overseas as being worthy of cracking, and their
    standard decryption mechanism decoded it into FORTRAN?  ;-)
    
    #ken

    
    The discussion has (justifiably) taken the direction of talking
    about encryption....but back to the original message.
    
    %NOTES-W-MEDIA HYPE, media hype detected in message....
    
    
    Transmit a useful CAD program on an overseas line using typical
    PC modems in 5 minutes?
    
    Sounds like the typical media exaggeration of computer exploits.
    
    
    A 5 minute transmission on DECnet....well thats different - but
    there isn't a hell of a lot you could send over the phone lines
    in that short a time that could be useful to the Russians....nor
    would the NSA have time to look at EVERY short transmission.
    
    (I know....I am now going to get a list of things that COULD be
    useful...like a program to do DES encryption (a non-exportable item
    itself, as I recall) but in general its going to be a hell of a
    lot more than 5 minutes to send a satellite weapons simulation or
    some such thing)...
    
    
    we now return you to your discussion...