Now again, as in the case of message authentication codes,
the definition we've just given does not take into account Replay attacks at all.
And of course, does nothing preventing an attacker from taking a prior
message signature pair, and replaying that to a recipient.
And the receiver will then verify that, just as they did the first time around.
Now in many settings, this can be problematic.
For example, imagine the patch distribution case that we
talked about in the previous lecture.
And imagine that the software company issues a new patch.
And what the attacker does is to replace that new patch with a patch from
last year.
Well that patch was signed a year ago.
That signature is still going to appear valid, and so
the client may in fact install the year old patch.
And that may have the effect actually of rolling back the client to
a previous version of a software.
That doesn't violate the definition of security of a signature scheme.
And if we did want to prevent that sort of an attack,
we would have to handle it by some other mechanism.
In this particular setting it would not be hard to do that.
We could, for example, include a date inside what we sign, and
then the client would check that the date on the patch is later than the date on
the last patch that it applied.
The point is, however, that we can't handle this using signatures alone.
We have to instead handle it using some higher level mechanism.