Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

potential counter/IV uniqueness issue #270

Open
ThomasWaldmann opened this issue Apr 5, 2015 · 1 comment
Open

potential counter/IV uniqueness issue #270

ThomasWaldmann opened this issue Apr 5, 2015 · 1 comment

Comments

@ThomasWaldmann
Copy link
Contributor

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.

@henryk
Copy link

henryk commented Apr 5, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants