[EMAIL PROTECTED] wrote:
>
> How do we push your suggestion for a native encrypt/decrypt function
> forward? Do we put it to a Vote on this list or drop it in the
> suggestion box or is there some other procedure ;-)
>
Good question. I'll copy this to feedback and a couple of folks and
see what response we get.
>
> I do have three related questions:
> a. Would a binary encrypt/decrypt be a very big performance hit?
> (Well ok just how do we quantify big?)
>
You must have read my mind! ;-) We could make a couple of quick
generalizations, though.
1) I think it's reasonable (for a rough first approximation) to say
that encrypt/decrypt time will correlate to the strength of the
security; stronger crypto will tend to burn more cycles. So,
how much security are we willing to "pay for" by added overhead.
Perhaps having more flexibility to manage the level of security
would be good (variable key length, etc.)
2) I suspect that the PERCEIVED overhead is more of a ratio than an
absolute number. Five seconds of decryption for a script that
runs for an hour is low impact; five seconds of decrypt for a
200 millisecond run is likely to be perceived very differently.
Of course, if the script only needs 200 msec, is it that much of
a secret? YMMV!
>
> b. Is it currently possible to view a script as it is executing
> (some sort of debug or trace feature).
>
Well, there's always
trace on do something trace off
but I'm assuming that a native 'do-crypt would have access to more
of REBOL's innards than standard mezzanine functions, and therefore
could disable tracing as the first thing it did (restoring the
state of tracing upon exit would also be well-mannered! ;-)
I should have mentioned that assumption in my original note on the
subject, because 'trace would have to be dealt with. Thanks for
catching my oversight!
>
> c. is it possible to assign a script to a word then view a script
> using SOURCE, after the script has executed
> e.g., myscript: system/script or myscript: %ms.r
> Do myscript
> source myscript
> Just a thought that if encrypted one still might be able to see the
> script at some point during or after execution
>
I don't propose any way to assign the script to a word. I propose
that it be decrypted (into an internal reference), executed, and
discarded, all within the native 'do-crypt.
Perhaps someone else knows something I don't (come to think of it,
that's almost dead certain ;-), but I'm not aware of any way to look
at a block of code during execution (assuming, of course that the
code wasn't written for that purpose).
Ultimately, my suggestion offers only as much security as compiling,
because someone can always hex dump an executable file or run it
through a dis-assembler for reverse engineering. Even though Java
(for instance) compiles to internal VM-dependent data structures,
it can be decoded with enough effort -- I've written a primitive
Java "dis-assembler" myself. If the value of doing so is high
enough, anything one person can hide, another person can find.
I understood (or perhaps misunderstood) the original note to have
more casual users in mind, such as students taking a class, who
might be quizzed via scripts whose source (and data!) wouldn't be
made public. Is that market likely to support a serious crypto-
cracking effort?
-jn-
