Replies below (cross posted for the same reasons as my other post)

"Todd B" <ToddB@NOSPAMAgendumSoftware.com> wrote in message
news:<3a4b1d5a$1@news.devx.com>...
> One of the biggest advantages at this time is the ability to protect

source
> within a project from those that 1) may not have a security clearance,


Government stuff? Don't you have to document the algorithm that your using
and used an approved algorithm?

> 3) to lock down source so that no changes can be made unless
> authorized or handled through whatever controls your development group has
> in process.


So shouldn't the code be signed, not encrypted since you should still be
able to see the code, just not change it.

> Nope a system level debugger will not be able to read anything. As I
> mentioned, we have come up with a new design that we are going for a

patent
> on and it is called 'Streaming Encryption'. Sure you will be able to see
> a data stream but figuring out what that data stream is, how it fits
> together and what it is doing is the part that is the heart of the system.


I assume you are talking about your stage 2 implamentation, right? Unless
I'm wrong about VB there is a problem with your method. In order to go from
source code into compiled code you need to first parse the code, create IL
tokens and then create an executable file based on that. Your program would
need to decrypt the code into plain text inorder for VB to compile it. So
at somepoint the plain text has to be in the system.

Also this means that the key to decrypt the code is also stored in the
system since it needs to be able to decrypt the code in order to compile it.

So with the key and plaintext stored in memory it seems like you are
depending on security through obscurity which is not secure.

> Besides, this is currently intended for use during development.. An
> additional design stage (call it phase 3) for this technology does include
> the ability to do this in compiled executables giving you the ability to
> actually have a compiled program internally encrypted that on the fly will
> process on its own during execution.


So are you creating your own interpreter to interprete the source code at
runtime? Or are you decrypting the source code, compiling it, and then
reencrypting the executable file?

> This part of the design is also part of our new
> compression technology I spoke of a few months ago that allows compression
> in ranges not yet seen in the industry. (example: 60 meg file to 1.2 meg
> at 100% lossless values) No joke.. we have shown a working prototype and
> received funding to continue development on this technology. ;-)


What type of file does it compress? Normal text files are different from
binary executables, and source code is probably more compresible then normal
text.

--
Eli Allen
eallen@bcpl.net