Just to make this more organized I'll try spliting up my replies which are
below. (I cross posted since this topic seems to pertain to that group too
so anyone if the security.infrastructure group may want to look at the
previous messages in the off.ramp)

"Todd B" <ToddB@NOSPAMAgendumSoftware.com> wrote in message
news:3a4b058f@news.devx.com...
> Now here comes the really nice part... I can cut and paste ANY of those
> encrypted segments of source, move them to any other part of the project,
> paste them and unencrypt them there!! Plus if you have another completely
> different project that happens to use the same Key, I can actually encrypt
> in one project, cut and paste to a second project and unencrypt there!!


Couldn't you store some sort of hash of the key in each project allowing cut
and paste between any project. If the hashes don't match then decrypt it
and re-encrypt it (assuming the user has both passwords) and if the hashes
do match jst do it the way you are now.

> Each project uses its own key and each project can only have one key.
> As a security measure we also designed it so that you cannot alter, delete
> or change that key as well especially when using this tool in FULL network
> and group project development mode.


So if the password leaks there is no easy way of changing it forcing you to
create a completely new project? Couldn't you just decrypt everything and
the re-encrypt with the new password?

> Once it has been out for a bit with no problems, we
> will move to release of the update allowing our 'Streaming Encryption'
> technology. Next upgrade will include the actual execution of the
> encrypted source on the fly. We are calling it 'Streaming Encryption' (TM)
> and in fact are applying for a patent on this part of the technology.


While I don't have my crypto books here (left them in my dorm room) I'm
pretty sure that term is already used for things like PGPfone and related
technologies where you encrypt a steam of data.

> > Any chance to support code signing like PGP?

>
> We are discussing the ability to have selectable encryption types

including
> RSA and PGP however you should know that we built what we call a 16 level,
> 128 bit encryption process. In essence it uses a method that is most
> probably unbreakable unless you know specifically the types, methods and
> keys of each level of encryption.


In terms of security you seem to be missing a few things:

First, an algorithm that depends on no one knowing the algorithm for
security is never secure. An algorithm should only depend on the private
key being kept a secret for security.

Second, are you saying you created your own semetric encryption algorithm
and expect it to be just as secure as IDEA, twofish or any of the other
publicly known (some are free for use) algorithms?

Third, there is the cryptoAPI which most people consider secure using good
algorithms already so there is no reason to implament your own.

The reason I asked about PGP was for for its signing ability. You seem to
be using a symetric algorithm which doesn't allow for code signing. Code
signing would allow a developer to know who wrote a block of code and make
sure no one else modified it.


--
Eli Allen
eallen@bcpl.net