> Couldn't you store some sort of hash of the key in each project allowing

> 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.

Aye, it is similar to what we did for this first release in AgMapthat PB+.
In fact for this first run that we have shipped, we are using a couple
things to track and maintain encryption integrity. One of the things we use
to track against is the specific comment string for example. Obviously you
cannot just use that because projects have comments all over them. But
since we added comments anyhow to help a programmer show the start and stop
positions of the encrypted area (and it also helps when working with the
encrypted source), we went ahead and used the comments in addition. This
has been tested for over a year to be absolutely sure we got it right. But
the tough thing we found is that you have to check for ANY variation of any
kind including things like odd characters and more.. You would not believe
some of the things that VB does and how it operates. If anyone outside ever
got to see the source code for VB itself, we would probably all be shaking
our heads. Some brilliant capabilities in VB but in some of those
brilliant capabilities, there is a lacking of even obvious things in some
cases. For example, reloading the same project.. Try finding an event,
any event that is consistent everytime that you can apply against a project
in order to say update a tree. Wow what a nightmare. In some cases we
were able to let our system handle things automatically yet in other even
more obvious situations, there was absolutely nothing there to use as an
event or change or whatever that we could hook into.

In some cases, VB does not even track a change in a project until you do
something very specific. You can actually make a change in a project in
some cases that VB does not know you have made until it saves the project
for example. In essence you could move a bunch of code in a project or
alter the project in some ways and if you were able to look at what VB
thinks it sees and what is reality, you would get two completely different
views. Working around those issues was the extremely difficult problem we
were faced with. Plus there are many undocumented 'features' that VB
either has but are not openly available or are there but not even used. Yet
when you do something specific, suddenly you have to deal with it else what
you want to do will not work.

> So if the password leaks there is no easy way of changing it forcing you

> create a completely new project? Couldn't you just decrypt everything and
> the re-encrypt with the new password?

In this version and based on both our Beta feedback and our corporate
clients who had Beta copies under full network use, we made the decision to
not allow the changing, deletion or any other edit of the encryption keys
for a project once they have been set. This reason is primarily based
around security. If you allow the key to be changed, someone could
maliciously change the key and encrypt the source with a new key thereby
locking you out. Or let's say someone got a copy of the source. If they
could remove the key, what kind of protection would your source have since
they could just change the key and unencrypt your source?

We are working on a change that will allow for special key changes to a
project. We have not yet decided on all of the aspects of this nor whether
we are even going to add it in a future version.. Again, we took the
direction we did based on both our Beta feedback and the corporate clients
who got pre-release copies to play with in their network development groups.
They all stated that security was the main issue and one of the ways to
insure security is to forbid the alteration of the key.

Remember each project can have its own key but once set, it cannot be
changed. And we are thinking about having some way of maybe allowing
this... but unless we can be absolutely sure that it will not compromise
the security, it will not be changed.

> 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.

That could be. I do not know to be honest. A patent search will determine
that. If that is the case, we will change the name. No big deal. We just
want the technology protected. Once we have the protections, we will then
start to worry about all the other 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.

To be honest, encryption is not my area. So you may be teaching me a bit
here. I know the basic behind its workings but not the semantics. I do
know that it is not based on knowing the algorithm. My partner taught me
that one. He also said that besides the key, we are using some other
things. One of the terms he used was OffSet plus some others but I do not
remember what they are called. I will ask him so I can let you know because
I do not.

I do know this, he has some tools that are used to ... dam cannot remember
the term he used.. but in essence they 'test' encryption methods?! Each
segment of the encryption was run through his tools and in a 7 day period, I
know that none broke. Now whether that is significant or not, I honestly do
not know but for me, knowing that all 16 methods passed that testing he did,
tells me it is pretty darn good. Maybe unbreakable is not what I should say
since I do not know enough about this stuff but I guess if someone wants to
take a few mainframes to break it, well as far as I am concerned, go for it!

> 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?

I have no idea and again would need to ask. But we did create our own
complete system and it is not just one encryption that is used. Again, this
is not my area so all I can tell you is what I do know and what I do
understand about it. I will see if I can get him to visit OR and join in.

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

We agree on this. It is in development for a future update. We had taken
a different approach and it was after another of our partners joined Agendum
and a comment from one of our customers, that cryptoAPI became something we
realized we needed to be implementing.

> 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.

The current way we have the system set up is very basic for where we want to
go with it in the next few updates. We have been moving toward signing on
all our development in the near future. We are not currently ready to take
that step yet but you will see it very shortly because we agree that it is
now becoming a very important necessity especially for our corporate

The next product update we are actually hoping to have a form of generic
signing where AgMapthat Project Browser Plus will track each block just as
you mentioned. We actually wanted to do this initially but since that was
an idea that came after we locked the project scope, it had to be pushed to
the next generation update. This tool took almost two years to write and
changing the scope 2 months before completion is not something I will allow
in our development of any project. If I remember correctly, our new
AgMenuPlus does have signing built in however and actually has a built in
security capability in direct support of that. I will have to check that
but I think that was added to the scope for that product.. If not, that
will have to wait as well because it is going final beta any day now. Our
encryption ActiveX, AgProtect, is also being revamped with both signing
capabilities and cryptoAPI as well so we are moving in that direction.

You seem to be very knowledgeable about this stuff. Much more than I am for
sure. We may have to hire you for your expertise! Right now only one of my
partners would be considered an expert in encryption with another one being
almost as good. ;-) I am more of the 'idea', concept, and design type
person and I get to handle much of the debugging and re-coding. I design
more of the flow aspects in the code... I fit everything together and make
them work but let the experts handle the writing of the deep math, AI and
other really heavy stuff. If you look at AgFastform, AgTransform, or
AgMapthat PB+ and the user interfaces and the 'flow' of the products, you
see what I work on much of the time. Half the time one of the guys will
give me a new function and I have to get a lesson on what and how it works..
Once I am shown through the code, I then understand what it is doing but to
take some of this stuff they write and just read it... well... no way! LOL

Take it light!!

Todd B

"Eli Allen" <eallen@bcpl.net> wrote in message
> 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

> so anyone if the security.infrastructure group may want to look at the