IVs (nonces) generation #22
Labels
Milestone
Comments
|
See also: jborg/attic#270 |
Closed
textshell
added a commit
to textshell/borg
that referenced
this issue
Jul 25, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect about evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. Fixes borgbackup#22
textshell
added a commit
to textshell/borg
that referenced
this issue
Jul 25, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect about evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. Fixes borgbackup#22
textshell
added a commit
to textshell/borg
that referenced
this issue
Jul 26, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect about evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. Fixes borgbackup#22
textshell
added a commit
to textshell/borg
that referenced
this issue
Jul 27, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect about evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. Fixes borgbackup#22
textshell
added a commit
to textshell/borg
that referenced
this issue
Jul 27, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect about evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. Fixes borgbackup#22
textshell
added a commit
to textshell/borg
that referenced
this issue
Jul 27, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect about evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. Fixes borgbackup#22
ThomasWaldmann
modified the milestones:
1.2 crypto and sequential threading,
2.0 - future goals
textshell
added a commit
to textshell/borg
that referenced
this issue
Aug 22, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect about evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. Fixes borgbackup#22
textshell
added a commit
to textshell/borg
that referenced
this issue
Aug 25, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect about evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. Fixes borgbackup#22
textshell
added a commit
to textshell/borg
that referenced
this issue
Aug 27, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect against evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. With a real counter mode cipher protection for the multiple client case with an actively evil repository is not possible. But this still protects against cases where the attacker can not arbitrarily change the repository but can read everything stored and abort connections or crash the server. Fixes borgbackup#22
textshell
added a commit
to textshell/borg
that referenced
this issue
Aug 27, 2016
Reusing the nonce totally breaks AES-CTR confidentiality. This code uses a reservation of nonce space and stores the next nonce available for a future reservation on the client and in the repository. Local storage is needed to protect against evil repositories that try to gain access to encrypted data by not saving nonce reservations and aborting the connection or otherwise forcing a rollback. Storage in the repository is needed to protect against another client writing to the repository after a transaction was aborted and thus not seeing the last used nonce from the manifest. With a real counter mode cipher protection for the multiple client case with an actively evil repository is not possible. But this still protects against cases where the attacker can not arbitrarily change the repository but can read everything stored and abort connections or crash the server. Fixes borgbackup#22
ThomasWaldmann
modified the milestones:
1.1b1 - near(er) future goals,
1.2 crypto and sequential threading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current borg code uses AES in CTR mode, which requires an IV that never repeats.
That can be either a COUNTER (thus the "CTR" in the mode name) or a RANDOM value.
COUNTER: this is the way the current code works: load a counter from repo manifest, encrypt stuff (and keep incrementing the counter), at the end: save the counter to repo manifest.
Pro:
a) no birthday paradox
b) no collisions / repetition - IF correctly managed
Problems:
a) if a backup crashes and the manifest is not written, the next backup will reuse same counter start value - and that is a encryption security issue.
b) if encryption code runs in parallel (e.g. threads), it needs management of the different counter start values for the different workers.
RANDOM: future way of doing things?
Pro:
a) no "management" of counter start values, no problem for parallel execution
b) no storage of highest counter needed
Problems:
a) needs good randomness source (we also need that for key generation already)
b) source needs to keep up with demand
Needs many random bits to avoid collisions ("birthday problem"), NIST recommends a fixed value + lots of random bits as IV.
Related idea: create a new encryption key per chunk and always start CTR from 0.
Related idea: create a new encryption key per backup (if multithreaded: per crypter worker thread) and start ctr from 0 in each backup (in each worker thread).
https://www.bountysource.com/issues/16559386-ivs-nonces-generation
The text was updated successfully, but these errors were encountered: