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

Re: encrypt/decrypt

Goff is of course correct....

GRAEME SMITH                         email: grysmith@freenet.edmonton.ab.ca 
YMCA Edmonton             
(Back on line!>

On Sun, 25 Aug 1996, Jeff Goff wrote:

> 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. 

Right, quite true, however, if you look at the description of the earlier
message, I did not say, that you should use multiple alphabets, but suggested
a periodically changed mapping to a single alphabet, if done fast enough and
in a random enough fashion, it is as secure as the one-time-pad, which Kahn
and later codebreakers, have noted was annoyingly difficult if not impossible
to decrypt. Of course for that reason, you have to hide your seed in some way
so that the decryptor cannot figure out what the algorythm for the random
number generator will be, and for that you want something like the DES 
Algorythm, or the RSA Algorythm, that hides the real value in some fancy
shell game. But I maintain, it is not making the data unrecognizeable that
is hard, it is hiding the information about HOW you made it unrecognizeable
so that no one can just walk in, and steal the password, and have access
to your 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. 

Which is why, I didn't suggest the multiple alphabet option.

> One-way algorithms form a nearly impenetrable
> barrier. 

Ah Yes, the operative word is nearly, certainly it should separate the 
professional from the merely curious.

> 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.
> 

Which is why I used it for passwords in the MOD0 of NewCore. I do not however
claim to have made the one-way algorythm unbreakable, since: 1. it is wizard
readable, 2. it is in the same system as the passwords, and 3. it was my
first attempt at a one-way algorythm, and I have no idea, if I got it messed
up enough to do the job or not. ;)

> 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.
> 
Most people do what is said to be a cursory encryption, which makes it 
difficult but not impossible for the amateur codebreaker. If you want a 
Military Grade Encryption Algorythm, then expect to spend some money on
a purpose built system.

> 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.

Hm....

I think the problem here, is deciding what the person wants. I already wrote
a one-way code algorythm for encryption of passwords, what I hear here, is
the need to have an algorythm for in-db security. Which is of course 
going to have to be a separate algorythm, because there is no "Shared 
Secret" between the encryption and decryption processes for such a 
data-oriented system, unlike the one-way algorythm, that I used.

> 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.

Heck, if you really want a quick and dirty encryption algorythm, I will build
one, that is ALREADY outside the U.S. Which was the main point I was trying
to make. It will, of course, be IMPORTED into the U.S. if anyone there, 
tries to use it, the point is, it WON't Decrypt my Password files :)

It will have to be a slightly different algorythm, just so that it can
be decrypted. but I have the experience, to at least have an idea where
to start. No guarantees that NSA can't break it, or that MI whatever, or
Interpol can't decrypt it, but until it gets into general use, the odds are
somewhat lower, that they will even try. Certainly, it should slow down the
15 year old kid that got a computer for christmass.

It will probably be set up to be run only from a Wiz bit, called from the
Archwizard, of the MOO, but that is my own interpretation of how it should
be called, not necessarily the best implimentation. Might want to make the
encryption publicly accessable, but limit the decryption to the owner, or
something.
> 
> 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.
> 

Good point, I second that disclaimer.

Further, I make no warrantees to the effectiveness of any encryption
algorythm I release to the Public Domain, as the nature of such release,
tends to make the technology more accessible for breaking. The only thing
I have going for me, is that I am already outside the U.S., and therefore
subject to different export restrictions.


				GREY
References:
Home | Subject Index | Thread Index