Store salt in the file, not manifest

[grke]

From the mailing list:

we are using burp to backup various servers in here and it works
flawlessly. One server, however, contains über-sensitive data and we
make an encrypted backup with it (which in turn is then backed up to
some off-site location within the organization).

When playing through various case scenarios, we examined what happens
if for some reason the backup's manifest file is damaged.

Scenario 1: (unencrypted backups): Just copy the file off the backup's
folder structure and run it through gzip and vss_strip et voilà, you
have your file. It would be easy to run that procedure through the
whole folder structure to reconstruct all the data (at the loss of
meta-data like modification dates and attributes, but we can live with
that)

Scenario 2: (encrypted backups): No way we could ever decrypt these
files, even with the encryption password, as the salt is buried in the
manifest file which - per our scenario - is
damaged/unavailable/unusable.

So, in consequence, this means we must encrypt the backup set file by
file between burp-ing locally and sending it to off-site storage. Else
we'd be sitting on a load of garbled data if Murphy strikes.

It would be really neat if in future versions the encryption salt
would be stored in the file as done by standard and well-documented
openssl procedures:

"openssl enc -aes-256-cbc -in some.pdf -out some.pdf.enc" and "openssl
enc -d -aes-256-cbc -in some.pdf.enc -out some-new.pdf" to en- and
decrypt files.

The salt would be stored along with the file:
[code]
hexdump -C some.pdf.enc | head
00000000 53 61 6c 74 65 64 5f 5f a7 b1 32 57 3a 12 a5 e6 |Salted__..2W:...|
00000010 8c 41 72 83 be b8 c4 42 a6 2f 22 3c 8c d9 bf c0 |.Ar....B./"<....|
00000020 a5 be d9 c1 84 37 b2 6a 79 35 d7 21 f2 df 00 78 |.....7.jy5.!...x|
00000030 1f 05 fc 0a b3 5c 94 ff b4 89 72 64 db 86 8e a1 |.........rd....|
00000040 76 83 58 62 9b 99 bb 74 5a f1 9a c3 c2 0c 11 66 |v.Xb...tZ......f|
...
[/code]

I might, of course, be missing something obvious. But as I can see it,
for encrypted backups, the manifest file is the Achilles Heel of an
otherwise intact backup set. For unencrypted backups, burp's method is
flexible and resilient unlike many other backups.

[jacky35]

Hello,
I don't know if it's fair or not.

But on many sites it is now indicated that it is necessary to use -pbkdf2

openssl enc -aes-256-cbc -pbkdf2 -iter 100000