I have one Arduino sending a string "hello" en encrypted string, say, "slfny" over using RF.
A receiver Arduino receives the "slfny" and decrypts it to "hello".
The problem is that the radio message "slfny" can heard and recorded by a third arduino and played back to receiver.
This problem is solved by encrypting "hello" using a different algorithm every time so that "hello" will be encrypted to "sndjk" the next time.
Where can I find so public domain source for this to be used with arduino?
I don't think you need a different algorithm.
There are a few ways to do it. The first 2 off the top of my head....
Change the key. You might change keys once a year or maybe you have a very long list of keys pre-arranged so you can change keys every minute.
Salt the cleartext.
2a. Use a sequence number so that after decoding "1hello" you only accept the next message with a "2" in front of it. "2hello" should encrypt to a totally different ciphertext so that it is not obvious that only one character changed.
2b. Use the date and time as the salt. Send "20181115120101hello". Then the receiver can easily check if the time is close enough to "now".
2b and 1 together suggest using the time (and other secret data) as the key.
You are concerned about a "replay" attack. Encode a time stamp with the payload and check it is not too old.
If you Google "Arduino encryption library" I am sure you will find some code that can be imported and used. However....
How are you planning on "using a different algorithm every time"? Let's assume that you use 100 different encryption keys and both the Sender and the Receiver use the same 100... What happens if the Sender transmits a string and remembers that Password 32 was already used and will use Password 33 next time.... However, the Sender didn't receive the string with Password 32 so it will continue looking for Password 32 and communication breaks down... Even using some time controlled Password technique, the times for Sender and Receiver can get out of synch.
While not perfect, I have used multiple keys (for example 16 different ones) and combining the required bits (in the Event of 16 keys, four bits are necessary) with additional bits which are generated "randomly". Anyone recording would have to know the 16 Passwords, how to extract the proper bits to determine which Password, etc. Theoretically, the same Password could be used 16 times and appear differently each time.
Of course, this can be made even more complex. For example using a different Password depending on if it is morning or evening. If the clocks get out of synch for a few seconds or minutes, Errors could occur for a short time until the second clock gets "Close enough".
I should also admit that I am neither a security expert nor an encryption expert.
If both sender and receiver have GPS then you can be sure the clocks are synchronized. You just have to look out for a message that was started sending just before "midnight"* and is recieved/checked/analyzed after midnight.
Edit: fixed autocorrect error.
you can be sure the cocks are synchronized
But only during the mating season.
Pete