Re: Patch attestation RFC + proof of concept

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 
> (, 
> 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:

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.


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux