Restic crypto and nonce reuse

Hello, all! I’ve searched the forum but couldn’t find an exact answer to this question. If it has been answered and I’ve just glossed over it somehow, my apologies.

I have been comparing Restic and Borg lately, particularly how they implement encryption. As of right now, both projects use AES-256 in counter mode. I am not a cryptographer (I really only know enough to be dangerous), but I understand that Borg’s Achilles’ heel is it’s vulnerable to nonce reuse. If an adversary with access to the repository is able to modify/rewind the last-seen nonce (it’s stored in a plaintext file) and the Borg client doesn’t notice, then the AES-CTR encryption is effectively defeated. In fact, some reading suggests this isn’t just a Borg problem, it’s a problem with CTR mode in general.

I’ve not been able to find a discussion, warning, disclaimer or similar about nonce reuse with Restic. This tells me Restic’s implementation must handle the problem differently, which is good. Just to set my mind at ease, though, can someone explain how Restic addresses this?

Maybe you can find your answers here:

1 Like

Restic does not use consecutive initialization vectors. Instead each encrypted blob uses a new random 16 byte nonce. That is an attacker cannot control the used nonce.

1 Like