blob: 50604d0555b6b81c1a20b7a9b83168874eb24d92 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
# bb: basic backup
Incremental encrypted backup system
## Current design
1. cksum original (sha256)
2. compress (gzip)
2. encrypt (aes256)
3. split in cksumed chunks. chunks are named from the hmac of
encrypted+compressed
4. build index of chunks
5. compress (gzip) and encrypt (aes) index
6. return index cksum
Good:
- chunks are named from their compressed/crypted hmac.
Problems:
- the salt (or iv in aes) must be set to 0. Weak encryption.
- dedup occurs only for append only files. The same chunk content will lead to
a different hmac if located at a different offset.
To fix:
- chunk before compression
- name chunks from cksum of uncompressed/unencrypted data.
- then compress and encrypt (in this order).
Chunk encryption can use randomized cipher, but a hmac must be added at end of
file (before encrypt) to check integrity without having to decrypt/decompress.
## What tarsnap is doing
1. cksum original (sha256)
2. build chunks of variable size
3. cksum uncompressed unencrypted chunks
4. compress chunk (deflate)
5. encrypt chunk (rsa2048) + HMAC
## References
- tarsnap: https://www.tarsnap.com https://github.com/tarsnap/tarsnap
- chunker: https://github.com/karinushka/chunker
- borg: https://borgbackup.org
- rclone: https://rclone.org
|
