Should the message counters also be used for Replay Detection?

[mchlnix]

Between links replay detection is used, so that no outside attacker can replay the same message multiple times and can gather information about the sender. However this does not guard against an attacking mix trying the same thing.

As of right now the message counter values are chosen randomly by the client in requests or the respective mixes in responses. In both cases they are transmitted link encrypted so accessible to the mixes. This means that an attacking mix can replay every packet it likes.

If these channel specific message counters would also be used to detect replay attacks, then a mix could either change them to avoid replay detection, but thereby trashing the payload making it useless for detection (but not for traffic analysis) or keep the counter of the saved message and trigger the replay detection making replaying impossible.

[mchlnix]

Also using link replay detection makes it difficult on the first mix, because it has to keep up the link encryption with potentially hundreds of different clients. Pending some use of link replay detection, that is not also achieved by message level replay detection, the link replay detection can be removed.

[mchlnix]

Link replay detection makes it impossible to replay unchanged messages by an outside party listening in on the communications to, and between the mixes.

Is this necessary for data messages?

Data messages have themselves a message counter prefix, that was used to symmetrically encrypt them. It is a counter and therefore unique to each message sent over a channel. This means, that replaying a data message by simply replaying it, link header included would fail, because the message counter prefix is already known.

An attacking mix can change the message counter prefix, but that would break the message and the next message counter prefix. Additional link replay detection would not solve this, since mixes can link encrypt whatever they want.

Is this necessary for initialization messages?

Initialization messages do not use message counter prefixes, which means message level replay detection is not possible with them. Therefore link level replay detection keeps outside attackers from replaying them. Bad Mixes can, however, recycle received initialization messages and send them out with a new link header, without destroying the message content, causing a problem later on.

Without link replay detection outside attackers can spam initialization messages as much as they want.

If we add a message counter prefix to initialization messages, they could be used for message replay detection, protecting from outside attackers. Since the message counter prefix is seen by the mixes as plain text and since the message counter prefix is not used for the init message, the mixes can simply change them however they like. Later on they can simply drop data messages until the counter prefixes are synchronized again.

That means that the message counter has to be tied to the mix keys somehow, since these are not known by the other mixes. That way a manipulated initialization message will look different, to the originals, or they will be caught by the replay detection.

If this is done, the link replay detection will be unnecessary.

[mchlnix]

The channel keys and the payloads are encrypted using AES-CTR. Before a starting value of 0 was used. If we use the message counter prefix in these operations, the channel keys and payload is tied to those values.

[mchlnix]

This way only the payload and channel key part is secured. If an attacking mix would try and replay a channel init message with a new message counter the first 29 bytes (the element of the elliptic curve) would stay the same, which make them basically replayable in the sense, that they can be recognized and traced as the same message.

[mchlnix]

It is possible to make message counters into blinding factors and additionally blind the group elements of the init message. Thus it should be enough to either detect replay attacks or make the changes not predictable from the outside.