On Tue, 23 Jan 2001, 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)

Use a chaining cypher and make the first chunk of data be random garbage.
(The length of which depends on how you want to handle it. The number of
bytes should be larger than one.)

Some versions of 3des use this. They call it "whitening".

Reuse of keys is not always a good idea. If you can, you might find a way
to fix that weakness.

alanctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen | to my mail, just hit the ctrl, alt and del keys.
    "In the future, everything will have its 15 minutes of blame."

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]