This is more of a cryptography question than a coding question,
so I've Cc:d [EMAIL PROTECTED], and you may want to shift the
discussion there.
How small do you need? And how unpredictable?
RC4's pretty small, though it has issues with how you use it.
DES isn't really all that big these days - I think I've seen it in
10 lines of obfuscated Perl. Some of the AES candidates were pretty tight.
What're your application and your threat model like?
>At 06:00 PM 1/23/01, John Kedzie wrote:
>I am looking for an algorithm, as small as it can be (code size), as long as
>it can withstand the following:
>
>if an attacker has access to the plain text, and can see the outgoing
>ciphertext that is created by the plaintext, but he does NOT have the key
>used to encrypt, is there any way that if he sees the plaintext another
>time, he can predict what the ciphertext will be?
>
>i need something where when you encrypt one time with the same key, the
>ciphertext will change every time, if that's not possible, the closest
>possible thing to it will have to do. any suggestions? (would TEA work?
>i'm only suggesting it because it easily meets the size req, but i am unsure
>about the second part of my problem)
I'm puzzled - are you asking for an algorithm that,
given the same input, will produce different output
on different runs? Doesn't make much sense....
Or are you asking for an algorithm that,
given different inputs and the same key, produces different outputs?
If you're looking for the former, it's somewhat equivalent to
asking for an algorithm that has two key parts,
one reusable and one non-reusable (as Jim Gillogly mentions below).
Many algorithms support block chaining modes that can do this,
but it does increase the length of the cyphertext by one block -
you'll have to decide if your algorithm minds this.
At 07:00 PM 1/23/01 +0000, Jim Gillogly wrote:
>You can use any cipher with a random IV included in the key
>and exposed in the ciphertext, such as CipherSaber, an RC4
>based system: http://www.ciphersaber.gurus.com/ .
RC4 has one basic rule - never EVER use the same key twice,
because it's a stream cypher that works by XORing the input data
with a pseudo-random stream derived from the key.
Using the same key twice opens up many different attacks
on the (plaintext1 xor plaintext2) stream.
If you've got room for an IV, you _could_ do something like
XORing the IV with the key, not the data stream -
that means that it isn't really using the same algorithm
for the IV as for the rest of the data stream, but you may not care.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
