[Cryptography] Cryptographically securing a two-phase commit

[jamesd at echeque.com]

On 2020-07-29 14:23, Peter Gutmann wrote:
> Let's say you have a computationally somewhat expensive operation that's
> performed as a two-phase commit (2PC).  The details aren't important, but in
> crypto terms think of it as receiving a large blob of signed data in PGP or
> S/MIME format where you can't tell until you reach the signature at the end
> whether it's valid or not.  The prepare portion of the 2PC is receiving and
> saving the blob, the commit/abort operation is checking the signature at the
> end and either discarding it or acting on it.

Doctor doctor, it hurts when I do that.

Patient, patient, don't do that.

Why don't you just store the bundle and do any expensive computation
when it has all arrived.

You do a few public key operations to generate a shared secret when the
pile of stuff begins, as every protocol does, you do symmetric
decryption as it comes through, as every protocol does, and when you
have a pile of stuff at the end, check it for validity, as every
protocol does.

Well, I guess you have a terribly expensive test for validity, something
like a blockchain block which is an enormous pile of public key
operations, and until you have done the last one, you do not know if you
have a valid block until you have done a huge number of public key
operations and database lookups, one public key operation and one
database lookup every thirty two bytes or so.

OK, the communication starts with the sender ID, you blacklist people
who send you bad blocks, greylist people who send other people good
blocks, whitelist people who send you good blocks, and you have a rule
prohibiting ridiculously big blocks.