Strong Encryption (General Discussion)

Strong Encryption // General Discussion

1  |  

jerme

Apr 3, 2002, 1:23am
The recent events have prompted a lot of people to reconsider the .zip file
passwords, including me. As was proven, ZIP passwords are not sufficient to
protect object paths. It takes only a matter of hours, sometimes minutes to
crack a ZIP password. How people get the zip files to crack is the first
problem, finding a different method of encryption (that cannot be so easily
cracked) is a much larger problem.

First, all attempts to hide the object path's URL were totally obliterated
when the "object warnings" feature was added. Sure, it can be very helpful
when you're working with new objects, trying to perfect your model, but it
was a major oversight on the part of AWC. The solution to the first problem
would be to allow the user to turn on and off object warnings (just like
they can now), but not actually print them unless the user has caretaker
privileges in the current world. Also... why not just name the cache files
by the world name they come from? Store all the paths, or data that needs to
be cached in a encrypted file somewhere.

To solve the second problem: Why not use strong encryption? Such as PGP
keys... This system has been proven very secure. I'm not sure anyone knows
how to crack these (I've heard only the government code breaks, with the
supercomputers at their fingers can break these) If not this, *something* is
needed.. if not a proprietary tool for encryption (which I would not
recommend for obvious reasons) I'm not sure if strong encryption is truly
practical, as it takes a lot of processor usage, and would be slow to
decrypt hundreds of objects..

Here's how it works... You use a program like PGP (Pretty Good Privacy)
(check out the yahoo search here for an explanation -->
http://google.yahoo.com/bin/query?p=%2b%22pgp%22+%2b%22explanation%22&hc=0&h
s=0 ) to create your public and private keys. You then use the private key
to encrypt your object files. (You'll want to make a backup of your private
key, but keep it safe - you don't want anyone else to have it). You upload
the PGP encrypted versions of your objects to your object path just like
normal (maybe a different file extension).

Then when someone enters your world, the browser should receive notice that
the OP is PGP encrypted, and the world server will transfer the *public* key
to the browser. (Note: the public key should not be available via HTTP.. it
could then be downloaded, and would defeat the purpose of all this
encryption) The browser should store this key internally, and loose the
information when the user exits the world. The idea is to keep the user
from every being able to discover the public key, and only allowing the AW
browser to have the public key, in a situation where the use could not grab
it from a file later on. The key should not be stored permanently, or even
semi- permanently, on the user's hard drive. The browser then uses this
public key it has received to decrypt the objects and display them normally.

I'm not sure this setup would actually work when put into use, it's just an
idea. It would definitely impact initial world load times, but it shouldn't
cause significant lag as the objects only need to be decoded once (as they
come into view). Exploring areas with objects that your browser hasn't seen
in that session would be the laggiest. This would have to be considered, as
there are hundreds of objects that would need to be decoded in some worlds,
just by standing at GZ.

No matter the disadvantages, this would be the *ultimate* in security for
object path's. I've forward this e-mail to Roland, E N Z O, and AW support
as I believe it is of the utmost importance.

Let me know what you think...

Regards,
Jeremy

a.k.a. JerMe (#296967)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeremy Booker
JTech Web Systems
(www.JTechWebSystems.com -- Coming Soon)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

jerme

Apr 3, 2002, 1:29am
Well, it looks like I got a few things mixed up with the keys.. but you get
the idea...

Here's a short explanation I found from TechTV:
http://abcnews.go.com/sections/scitech/TechTV/techtv_encryption011203.html

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeremy Booker
JTech Web Systems
(www.JTechWebSystems.com -- Coming Soon)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[View Quote]

silenced

Apr 3, 2002, 1:32am
Sounds like a very good plan to me. Better then zip passworded files
accessable by HTTP :)

--Bowen--

[View Quote]

ananas

Apr 3, 2002, 4:56am
[View Quote] Object paths are often shared between worlds

jerme

Apr 3, 2002, 9:52am
Give each folder a number then, and have the browser keep a table of which
folder # is which op... (encrypted)

just *something* other that putting the path info right out there. That
totally defeats the purpose of the whole "hiding the path in the features
dialogue" thing....

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeremy Booker
JTech Web Systems
(www.JTechWebSystems.com -- Coming Soon)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[View Quote]

ima genius

Apr 3, 2002, 11:35am
Originally object paths were stored per world. However, trial worlds came
out and thus many worlds same the shared path (most often the AlphaWorld
object path).

I think a better idea is to make a one-way hash of the object path and store
the folder name as that. Perhaps using md5 or something similar.
- Ima

[View Quote]

ima genius

Apr 3, 2002, 11:46am
While it does sound like a good idea, it won't help as much as you
think. In the most recent case, the object passwords were not obtained by
zip cracking, but by decrypting the AW protocol and observing the password
as it was sent to the client. So, it would not help at all to solve that (a
hacker could just get the PGP key.) AW's encryption algorithm should be
improved to something much stronger.
However, this will not make it truly hack-proof. The difference between
AW and other systems requiring encryption is that you are trying to prevent
the user from knowing what the computer is doing... AW will still decrypt
the files on your computer. The idea with secure websites is that others
will not be able to take the encrypted data while it is traveling between
others' computers and decrypt it. With AW, your computer decrypts it but
the user cannot find out how.
In your example, you mention that the browser would store the key
internally. However, what is to prevent someone from viewing it in memory?
- Ima

[View Quote]

robbie

Apr 3, 2002, 1:34pm
I'm glad someone else knows whats going on, thanks Ima :)

-Robbie

[View Quote]

strike rapier

Apr 3, 2002, 5:47pm
Putting it simply, if someone knows the protocal uve got a problem.

True, from what i know u can easily kill the PW on ZIP files... short of
inventing a new type of compression protocal speccialy for aw objects a
always changing protocall might help.

[View Quote]

jerme

Apr 3, 2002, 6:41pm
>AW's encryption algorithm should be
> improved to something much stronger.

*cough* PGP *cough*

> In your example, you mention that the browser would store the key
> internally. However, what is to prevent someone from viewing it in
memory?

It would obviously have to use some kind of encryption scheme. It doesn't
really matter how, just a long as it keeps people from looking through AW's
memory registers and picking out the key... I know I left some places in the
process that need filling in. I'm not really shure how you'd accomplish
this. You know what you're talking about, so how would you do this? What
would you propose we do? Help me progress the idea into something we can
actully use...

-Jeremy

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeremy Booker
JTech Web Systems
(www.JTechWebSystems.com -- Coming Soon)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[View Quote]

agent1

Apr 3, 2002, 8:24pm
[View Quote] You can't. If you want your program to use it, it has to be decrypted into
memory sometime.

> I know I left some places in the process that need filling in. I'm not
really shure how you'd accomplish this.

Well, you'd need some sort of secure hardware that could do this sort of
thing, I think.


-Agent1

1  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2024. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn