1. Encrypting
Lucius L. Hilley raises two issues:
> 1. Encryption / Decrytion for Euphoria.
I've worked out an algorithm to do this, and I'll probably
put it into an upcoming release very soon.
You would shroud or bind using a new option to "encrypt"
the shrouded source. ex.exe would know how to decrypt
back to the shrouded source form. The load time penalty
would not have to be too bad.
It would be nice if the user could specify a password, but
then ex.exe would have to be told the password, or would have
to get it from the file. If it's in the file, and some algorithm can
read it, then there's really no point in having a password.
So... no password. The security will have to depend on the strength
and secrecy of the encryption/decryption algorithm. I have some
very sophisticated algorithms in mind.
Problems:
1. RDS would know the decryption algorithm and it wouldn't depend
on a password, so RDS could potentially convert any encrypted
program back to its shrouded form. RDS would not want to
share that knowledge with anybody since it would reduce the
value of Euphoria.
2. Most good encryption depends on a password, and in fact the
encryption/decryption algorithm is published and studied by lots
of smart people who look for general ways of cracking it.
This Euphoria encryption would depend on the secrecy of the
algorithm, and it is theoretically possible for some super-hacker
with a lot of time on his hands to try to execute ex.exe one machine
instruction at a time to determine the decryption algorithm.
He could then write a program to do it and distribute it to others.
At least they could only recover the shrouded version of the source.
3. The U.S. has laws against export of encryption algorithms and many
shareware
distributors refuse to touch anything that encrypts, so we
wouldn't call it encryption, but rather "enhanced shrouding" or
something.
It's arguably not encryption anyway, just a new undocumented internal
language
that can be executed by ex.exe.
Also we would only make this option available to registered users, to
increase security, and because we *can* export encryption
from Canada into the U.S. or any other country.
4. It would be safer if each user would protect his own program using his
own algorithm. If everyone depends on the RDS algorithm, that just
increases the economic value of cracking that algorithm. I noticed
that Zargaloids uses some sneaky way of hiding, loading and executing
the shrouded program. Maybe Michael Bolin can tell us (in general
terms)
what he does.
> 2. Bit shifting for Euphoria. Much needed Speed increase
The speed ratio between shifting versus multiplying or dividing
by a power of two, would not be as great in Euphoria as it
is in C or assembly language. Each operation in Euphoria
has a bit of overhead attached to it. Nevertheless it's probably
worth adding shifts. (integer divide by the constant "2" is already done
as a shift right).
Regards,
Rob Craig
Rapid Deployment Software
2. Re: Encrypting
> It would be nice if the user could specify a password, but
> then ex.exe would have to be told the password, or would have
> to get it from the file. If it's in the file, and some algorithm can
> read it, then there's really no point in having a password.
You could use two different algorithms. One is to decrypt the password, the
second uses the password to decrypt the rest of the file.
If no password, use padded spaces say 0's or something to attach before the
shrouded file to simulate a password.
In order to decrypt the file you must know both of the methods and the have
the key.
The only downside is that RDS would still know the encryption methods.
Just thinking,
Greg Harris
blackdog at cdc.net
