Re: Patch attestation RFC + proof of concept

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Feb 26, 2020 at 12:25:02PM -0500, Konstantin Ryabitsev wrote:

> ### Three hashes per patch
> 
> If you look at the contents of the patch attestation message 
> (https://lore.kernel.org/signatures/202002251425.E7847687B@keescook/), 
> you will notice a yaml-style formatted document with a series of three 
> hashes. Let's take the first one as example:
> 
> 2a02abe0-215cf3f1-2acb5798:
>   i: 2a02abe02216f626105622aee2f26ab10c155b6442e23441d90fc5fe4071b86e
>   m: 215cf3f133478917ad147a6eda1010a9c4bba1846e7dd35295e9a0081559e9b0
>   p: 2acb5798c366f97501f8feacb873327bac161951ce83e90f04bbcde32e993865
> 
> The source of these hashes is the following patch:
> https://lore.kernel.org/kernel-hardening/20200225051307.6401-2-keescook@chromium.org/

If you define an alternative message signature algorithm like this,
then is there still value in detatching the PGP signature from the
patch email?

The usual PGP signature computes a hash of the message in a certain
way (with unquoting etc). If you instead replace that with your method
and then just generate the normal base64 blob using:

  msg_hash = HASH(HASH(i) || HASH(m) || HASH(p))
  sig = RSA_Sign(msg_hash)

Then the base64 of the sig can just be dropped at the end of the
message, and doesn't need to be detached, or need the various ---BEGIN
PGP--- overheads

The magic I see here is defining a way to compute the message hash of
a patch email that doesn't cause a big mess.

Jason