MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: encrypt/decrypt

At 05:24 AM 8/25/96 PDT, you wrote:
>Encryption is not difficult.
>
>Its just messy, to get it so that it is secure.
>
>Essentially, an encryption routine, simply stores your message in a form
>that is not recognizeable. Security is supplied, by making it difficult for
>someone else to figure out how you made the data unrecognizeable.
>
>Cryptology, is an ArtForm, but you can make unauthorized decryption nearly
>impossible by mapping your alphabet across to an arbitrary code alphabet
>utilizing a non-repeating or almost random function, and changing the
>mapping periodically, so that it is difficult to use things like character
>frequency tables etc, to figure out what the message says.

Multialphabet ciphers are marginally harder than monoalphabetic ciphers to
decipher. Read Kahn's _The_Codebreakers_ for a quick description of the
process. For that matter, _The_Black_Chamber_ demonstrated how it works for
a three-key system. 

Also, you would have to store those alphabets somewhere on the server. If
you can access them, then you have to assume that I (as a malevolent
cracker) can access them. In that case you have a barrier to malevolent
crackers, but not a tall one. One-way algorithms form a nearly impenetrable
barrier. I can take your password file and encryption algorithm, but if the
one-way algorithm is designed correctly there's no way to find the plaintext
password that encrypts to a ciphertext pair other than trying every possible
plaintext password. That's where the strength of one-way algorithms comes from.

>Of course, you want to be able to decrypt it using a valid authorized 
>decryption program, but that requires that you have the ability to 
>synchronize both programs in some manner, so that they do the same task
>at the same time, only in reverse.

If the decryption program is available on the system then I can use it too.
Unless of course it's on a separate floppy disk that you stick into the
server and use every so often. Even then, most two-way algorithms that
people have developed are simple to break.

The important characteristic the encryption function for a MOO has to have
would seem to be that it be an effective deterrent. As for exporting
encryption, the available algorithms for export [DES &c] would seem to be a
formidable barrier. Even DES would require a million-dollar machine to break
a key in less than a few years.

The only organizations with the resources to break DES and other keys are
probably NSA and MI4, and possible Interpol. If you're keeping data on that
MOO that you want to keep hidden from those people, there are easier ways to
get the data than stealing a password. For the average MOO maintainer, there
are plenty of encryption algorithms that will prevent the casual cracker
from getting an account. Besides, if e gets far enough into your server to
get a password file, you've already got problems bigger than a minor problem
with encryption.

I apologize for the length of this message, but I don't see too many
situations where MUDs and MOOs would need government-strength encryption. As
for exporting encryption algorithms, there's plenty of code available
worldwide. If you're paranoid about ITAR regulations, then simply get a copy
of Dr. Dobb's magazine from last year (I don't recall the issue #). It was
completely on cryptography, and it had source code in the back. I don't
believe the ITAR regulations cover printed source, only source code or
binaries transmitted electronically across national boundaries. It's legal
to sell copies of _Applied_Cryptography_ to citizens of other nations, but
the floppy disk in back can't be sent across the borders of the U.S.

I will add this disclaimer that I'm not a lawyer of any kind, and I'm
woefully out of date with current cryptographic legislation. But I do know a
bit about cryptography.

Any flames, questions, comments, &c can be directed to the list or emailed
to me directly. Thank you for your time.

-Jeff <jeffgoff@synergy.net> Goff
Follow-Ups:
Home | Subject Index | Thread Index