To ensure the confidentiality of its backup data, each computer should encrypt its data before sending it to its partners using symmetric cryptography with a secret key known only to it. Because this and the other keys described below are needed for restoration, they should be added to the current-partners list that is manually taken off-site.
Ensuring backup integrity requires three steps. First, third parties must be prevented from impersonating a computer to one of its partners so that they can overwrite that computer's data. This requires pairwise authentication. At partnership formation time, the two partners can use Diffie-Hellman to establish a shared secret key, which they can then use later to authenticate write messages by attaching a sequence number and keyed cryptographic hash to each message.
Second, partners must be stopped from modifying a computer's data by altering a block's data then fixing up its checksum. This can be prevented by substituting a keyed cryptographic hash for the simple checksum used by the simplified scheme. So long as a computer keeps this hash key (an integrity key) secret, no other party will be able to modify or generate new valid blocks. Like with the encryption key, there is no need to have separate integrity keys for each partner.
Third, the ability of a computer's partners to conspire to replace
one valid block with another must be limited. Computing a block's
cryptographic hash over the partner ID and block offset where that block
is stored in addition to its portion of the backup data and version
number will prevent all substitutions except those involving an earlier
version of the same logical-disk block. By storing the date and version
number of each snapshot in the master block and refusing to accept
earlier versions at restoration time, a computer can ensure that
conspirators can not selectively revert parts of a snapshot. A
conspiracy of at least 
partners can still revert the entire snapshot
to a previous version; the only possible defense is to print the date of
the actual snapshot being restored in the hope that the owner will
notice the reversion.
The order in which encryption and checksum attachment are done matters. The correct order is to (1) generate the redundancy blocks, (2) encrypt each block, (3) attach the version number, (4) compute a cryptographic hash for each block (over the encrypted data, version number, partner ID, and block offset), and (5) attach the appropriate cryptographic hash to each block. This order allows a block's validity to be checked without having to decrypt it. More importantly, it ensures that there is no exploitable redundancy available to attackers: if encryption was done before generating redundancy blocks, a partner could save space by using the erasure-correcting code to reconstruct the data he was supposed to store from the data stored at the other partners. While good for him, that leaves the backup with lower redundancy.