[mschempp]

Thanks for the feedback and pointing out ostiary. Fixing replay attacks is on my todo list, maybe I can learn some things from how ostiary does it.

Kind advice from my PoV:

Your comment could be read as "your project is shit, there is ostiary which has replay protection and yours doesn't".

I'm sure you didn't intend for you comment to not come across that way, and I also did not read it that way, but others could have.

Also keep in mind that ruroco is a very young project and is by no means finished. I was thinking about using one-time-pads or other encryption algorithms as well. I also posted this here to get feedback to improve my project.

So hopefully when I release version 1.0.0 all the issues that this project has atpit are resolved ;)

[praptak]

Ostiary prevents replay by salting. Client's reply is only valid for the unique salt that the server has generated and only for a short time and obviously only once.

A replay attack can only make the server do whatever the legit client intended it to do, just up to [timeout] seconds later.

[mschempp]

hmmm just validated my implementation

the deadline that is sent from the client is being added to the blocklist after the command was executed, so sending the same packet again will not work, because the deadline (which is in nanoseconds) is already on the blocklist and therefore the command will not be executed again.

This effectively means that replaying a packet is not possible, because the server will deny it.