You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
it should be checked whether the counter/IV really stays unique even if a backup is interrupted and the manifest with the highest used IV is not written.
The text was updated successfully, but these errors were encountered:
thinking further: can an attacker with write access to the backup target remove the last valid manifest and force the "backup interrupted" mode? or, similar to #271, can he remove all manifests to restart encryption with a zero IV (but while still keeping encryption enabled so that even a victim that uses manual backup and verifies that the passphrase prompt appears is affected)? can the attacker replay an old manifest and thus force IV re-use?
I'm more and more convinced that CTR mode with a fixed key in this threat scenario is inherently unsafe and should not be used.
proposed solution: for every "operation" generate a random ephemeral key and restart the counter at zero. encrypt the ephemeral key with the long-term key and store it with the data. the definition of an "operation" has to absolutely, positively, guarantee no counter re-use, so I'd suggest to make every invocation of the attic binary one operation. consequently: continuing a failed backup from a checkpoint must be a new operation with a new key.
it should be checked whether the counter/IV really stays unique even if a backup is interrupted and the manifest with the highest used IV is not written.
The text was updated successfully, but these errors were encountered: