Subject Re: [IB-Architect] Including encryption
Author Jan Mikkelsen
David Berg <DaveBerg@...> wrote:

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


Where does this rubbish come from?

A one time pad is only secure if keys are never reused. XORing your
plaintext against a 1000 byte key means that your one time pad lasts 1000
bytes, and then you reuse it for the next 1000 bytes. And you still have
the problem of securely distributing your one time pad to both parties to
the session.

To use XOR effectively, you need a cryptographically secure random number
generator to generate a stream of bytes to XOR your plaintext against. For
example, this is how RC5 works. The length of the key is not the length of
the random number stream used for XORing, but rather the size of the seed to
the random number generator.

To anyone actually implementing security systems, please read a good book on
the subject before believing that XOR is the answer to the world's problems.
Something like Bruce Schneier's "Applied Cryptography" would be a good
start.

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


I think the NSA would be perfectly happy if everyone used the system you
proposed. Most of the XOR based pseudo "one time pad" snakeoil crypto
products can be exported.


I think you've also missed the point of the US export regulations (which
have changed recently, anyway), but that is another matter.

Jan Mikkelsen
janm@...