[Cryptography] Cryptographically securing a two-phase commit

Peter Gutmann pgut001 at cs.auckland.ac.nz
Wed Jul 29 00:23:07 EDT 2020


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.

In general this is fine since a failed signature check results in a rollback
and no damage is done.  However it's vulnerable to a DoS attack in which an
attacker feeds in a blob for which the signature check will eventually fail,
forcing the target to go through the 2PC prepare/abort overhead each time.

Can anyone suggest a means of avoiding this overhead that doesn't require
inventing a custom protocol or format for the purpose?  In other words that
works within the PGP or S/MIME format to try and avoid this issue?  One
obvious solution that doesn't work is to precede the blob with a signed token
saying "the blob that follows is legit", but since there's no way to
cryptographically tie it to the blob that follows it's still vulnerable to a
spoofing attack, capture and/or replay a signed token and follow it up with a
dummy blob to force the 2PC overhead.

Again, it needs to be achievable using a standard format like PGP or S/MIME,
inventing a new protocol or format to do it isn't an option.  Breaking the
single blob up into lots of little sub-blobs, each individually authenticated
and hash-chained together, is possible as a last resort but anything better
would be preferable.

Peter.


More information about the cryptography mailing list