#180 Option to sign hash of data rather than encryption key

[xloem]

The man page describes the signing algorithm as signing the hash of a randomly generated encryption key.

But this means anybody who can decrypt and re-encrypt the data can change it without invalidating the signature !!

It would be great to have an option to actually hash the data and sign the hash.

[Denis Corbin]

the signing is also applied to the catalogue, modifying the archive content without changing CRC nor catalogue give very little room to tampering. This is also only possible for archive that are encrypted for several recipients... not anybody.

The problem with the global hashing is that restoring an (huge) archive you either need to scan it a first time to check its validity and give again the slice a second time for archive extraction, or you extract and know only at the end of the operation that the archive you've just restored and overwrote files with was ... corrupted.

[xloem]

That's a good point, that verifying such an archive would take two passes.

But without hashing the actual data, somebody who has the recipient decryption key but not the signing key could replace all your backups with random data by solving the inverse of the CRC function, and they would still validate and have correct signatures. Then all your data is wiped when you restore.

Perhaps a better solution would be to use cryptographic hashes in the catalogue, rather than CRCs, so that the signature on the catalogue is also a signature on all the data. You'd want to be sure there are no small pieces of metadata which are not recorded in the catalogue.

[Cálestyo]

Some random addition to this (beware, I'm not a crypto expert):

In disk encryption (i.e. dm-crypt/LUKS/etc.) there was until recently (when dm-integrity was added to the linux kernel) no real cryptographic integrity protection.

At first this means of course: any attacker can modify a ciphered block, and it will be decrypted (in our case by the signed key) to some (of course wrong) clear text block.

The clear text block could be just garbage (with some chance to notice this) or maybe there are even smarter crypto attacks, which allow an attacker to properly craft some cipher block (even without know the key) .... I don't know whether this is possible or not.

I assumed then, that I'd be still safe by the checksumming done by btrfs (or by my own XATTR hash sums I attack to files, and verify from time to time)...
However, I was told on some mailing lists.. that this is in fact not cryptographically safe (for reasons I didn't understand ;-) ).

So the current way of relying that it's enough to sign the cipher key, and that a wrong cipher key would lead to wrong CRCs and thus attacks detected... might be wrong... but again... I'm really no crypto expert... and someone with some decent knowledge should be asked about this.

[Denis Corbin]

Hi,

the weakness here concerns archive signing (not archive encryption) and only when the encryption has several gnupg recipients.

I've copied the existing note on that weakness in the usage_notes.html and proposes some workaround:

• sign the archive out of dar (run gnupg on each slice, either manually or automatically by mean of -E option
• generate a hash of each slice (--hash option) and sign this hash only by manually or here too my mean of -E option

Regards,
Denis

[Denis Corbin]

documentation updated with just released version 2.6.0 closing this case