From: Eric Biggers <ebiggers@kernel.org>
To: Stefan Berger <stefanb@linux.ibm.com>
Cc: Roberto Sassu <roberto.sassu@huawei.com>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"zohar@linux.ibm.com" <zohar@linux.ibm.com>,
"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH v3a 00/11] ima: support fs-verity digests and signatures (alternative)
Date: Mon, 31 Jan 2022 20:24:34 +0000 [thread overview]
Message-ID: <YfhFgtg4X1DLJtAQ@gmail.com> (raw)
In-Reply-To: <b262cb06-37fd-9760-8f6e-1dcacbf738b4@linux.ibm.com>
On Mon, Jan 31, 2022 at 02:29:19PM -0500, Stefan Berger wrote:
> > > don't think I realized there was a more direct, PKCS#7-less way to do it and
> > > that IMA used that way.) However, it would be better to use this as an
> > > opportunity to move people off of the built-in signatures entirely, either by
> > > switching to a full userspace solution or by switching to IMA.
> > If what we sign remains the same, then we could support multiple
> > methods and use a selector to let fsverity_verify_signature() know
> > how it should verify the signature. I don't know what would be a
> > proper place for the selector.
> >
> > PKCS#7 seems ok, as it is used for kernel modules. IMA would be
> > also ok, as it can verify the signature more directly. I would also
> > be interested in supporting PGP, to avoid the requirement for
> > Linux distributions to manage a secondary key. I have a small
> > extension for rpmsign, that I would like to test in the Fedora
> > infrastructure.
> >
> > Both the PKCS#7 and the PGP methods don't require additional
> > support from outside, the functions verify_pkcs7_signature()
> > and verify_pgp_signature() (proposed, not yet in the upstream
> > kernel) would be sufficient.
>
> FYI: An empty file signed with pkcs7 and an ecc key for NIST p256 generates
> a signature of size 817 bytes. If an RPM needs to carry such signatures on a
> per-file basis we are back to the size increase of nearly an RSA signature.
> I would say for packages this is probably too much size increase.. and this
> is what drove the implementation of ECC support.
I am getting 256 bytes for an ECC signature in PKCS#7 format:
cd src/fsverity-utils
make
openssl ecparam -name prime256v1 -genkey -noout -out key.pem
openssl req -new -x509 -key key.pem -out cert.pem -days 360
touch file
./fsverity sign file file.sig --key=key.pem --cert=cert.pem
stat -c %s file.sig
Probably you accidentally included the whole certificate in the PKCS#7 message.
That's not required here.
There are definitely problems with PKCS#7, and it does have space overhead. But
the space overhead is not as bad as you state.
- Eric
next prev parent reply other threads:[~2022-01-31 20:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 18:46 [RFC][PATCH v3a 00/11] ima: support fs-verity digests and signatures (alternative) Roberto Sassu
2022-01-27 18:46 ` [RFC][PATCH v3a 06/11] fsverity: Introduce fsverity_get_formatted_digest() Roberto Sassu
2022-01-27 18:46 ` [RFC][PATCH v3a 07/11] fsverity: Introduce fsverity_get_signature() Roberto Sassu
2022-01-27 18:46 ` [RFC][PATCH v3a 08/11] fsverity: Completely disable signature verification if not requested Roberto Sassu
2022-01-27 18:46 ` [RFC][PATCH v3a 09/11] ima: Add support for fsverity signatures Roberto Sassu
2022-01-27 18:46 ` [RFC][PATCH v3a 10/11] evm: Include fsverity formatted digest in the HMAC/digest calculation Roberto Sassu
2022-01-27 19:35 ` [RFC][PATCH v3a 00/11] ima: support fs-verity digests and signatures (alternative) Eric Biggers
2022-01-27 19:39 ` Eric Biggers
2022-01-28 9:05 ` Roberto Sassu
2022-01-28 20:25 ` Eric Biggers
2022-01-31 15:12 ` Roberto Sassu
2022-01-31 19:29 ` Stefan Berger
2022-01-31 20:24 ` Eric Biggers [this message]
2022-01-31 20:51 ` Stefan Berger
2022-01-31 20:31 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YfhFgtg4X1DLJtAQ@gmail.com \
--to=ebiggers@kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roberto.sassu@huawei.com \
--cc=stefanb@linux.ibm.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.