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@xxxxxxxxxxxx/ 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
