Subject | Re: [IB-Architect] Including encryption |
---|---|
Author | Jan Mikkelsen |
Post date | 2000-05-01T04:37:18Z |
David Berg <DaveBerg@...> wrote:
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.
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@...
>If Interbase needs encryption (and I'm not convinced it does), then wedon't
>need state of the art encryption, we need a long key. With a 1,000+ byteWhere does this rubbish come from?
>key a simple XOR algorythm is more unbreakable than the fanciest algorythm
>with a 64 bit key.
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 forI think the NSA would be perfectly happy if everyone used the system you
>export. So any algorythm must be hard coded to work with 64 bits, sort of
>like this:
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@...