If Interbase needs encryption (and I'm not convinced it does), then we don't
need state of the art encryption, we need a long key. With a 1,000+ byte
key a simple XOR algorythm is more unbreakable than the fanciest algorythm
with a 64 bit key.

Of course, the NSA knows this and that's why longer keys are banned for
export. So any algorythm must be hard coded to work with 64 bits, sort of
like this:

// DO NOT INCREASE THE NUMBER OF KEYBYTES IF THIS SOFTWARE
// WILL BE USED OUTSIDE THE UNITED STATES OF AMERICA.
// OTHERWISE YOU MAY BE IN VIOLATION OF USA LAW AND SUBJECT
// TO PROSECUTION.
#define keybytes = 8;
...


Then anybody who HAS to have really good encryption only has to change one
number...



-----Original Message-----
From: Doug Chamberlin [mailto:dchamberlin@...]
Sent: Saturday, April 29, 2000 4:43 PM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] Including encryption


At 4/29/00 06:22 PM (Saturday), Bill Karwin wrote:

>Me too. My reasons are:
>
>o The state of the art of encryption moves too quickly for
> InterBase to keep up.

No need to. It does not have to be state of the art.

We don't need to visit the argument that "if it isn't the best available
then it isn't worth anything", do we?

>o Once InterBase claims to support encryption, the vendor accepts
> a level of liability for security that too high.

True, there is some level of liability.

The claims can be only to call the encryption API at the appropriate times,
however.

>o An InterBase-only encryption mechanism is useless.
> Any security package that an IT shop chooses must account for
> any type of traffic, which is typically email, file access,
> http, and perhaps telnet.

I don't agree. I'd like to be able to say that, at least the database
communications (SQL statements and result set data) are not passed in the
clear. That alone would satisfy many customers.

> > However, there are some practical problems which
> > would be easily solved if this could be included.
>
>The problems are typically not technical, but bureaucratic in nature.

Actually, I think they are a mix of these.

>A security-conscious site *wants* application-independent control over
>their network encryption and security.

Well, that's lumping a lot of people and places into one big category. I
don't agree we can do that.

>Most shops won't trust encryption that is bundled with an application.
>They've done their independent research and settled on their network
>security implementation, and they have a policy that anything -- even
>encrypted traffic -- has to use their secure connection.

Ok, but so what? If everything still works then no harm done, assuming they
can live with the performance of it all.

>My point is that these hassles won't be reduced, whether InterBase
>includes encryption or not. The people running the VPN won't allow
>*anything* to come into their network that isn't using *their* security
>mechanism.

But if we had database level encryption of some sort we might not have to
go to the VPN level at all.

> > All that would be left would be to ensure that the port in use was

allowed

> > to be used.
>
>This is another problem. Secure networks typically are not eager to
>open up more ports than they have to. They prefer that if you need to
>use a port, you use a "tunnel" on their preferred security
>implementation. They are *not* going to open up port 3050, even if
>InterBase includes encryption technology.

But an argument can be made that a database product needs *some* port on
which to communicate and since we can redirect Interbase to another port
number they can pick which one they are willing to assign.


------------------------------------------------------------------------
Accurate impartial advice on everything from laptops to table saws.
http://click.egroups.com/1/3020/3/_/830676/_/957051684/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com