linux-kernel - Re: [RFC PATCH] integrity: Use a new type for asymmetric signature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130314203028.GE24238@redhat.com>
Date:	Thu, 14 Mar 2013 16:30:28 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH] integrity: Use a new type for asymmetric signature

On Thu, Mar 14, 2013 at 10:05:59PM +0200, Kasatkin, Dmitry wrote:
> On Thu, Mar 14, 2013 at 8:28 PM, Vivek Goyal <vgoyal@...hat.com> wrote:
> > Hi Dmitry/Mimi,
> >
> > Here is an RFC patch. I am playing with exporting some functions from
> > ima/integrity and make reuse of IMA signature format and reuse of some
> > of IMA verification code.
> >
> > One of the things required is that caller wants trusts only certain
> > type of signatures. For example, it might not trust DIGEST or HMAC
> > but might trust only digital signatures. So caller needs to know what
> > kind of signature are stored in IMA security attribute (if any) and
> > decide what to do.
> >
> > Currently there seem to be two types of digital signatures. Old one and
> > that is RSA and new one which is being called asymmetric. Right now they
> > both fall in the categorty of EVM_IMA_XATTR_DIGSIG and one differentiates
> > between two using signature version. Version 1 is old type and version 2
> > is new type.
> >
> > How about asymmetric signature using a new type say
> > EVM_IMA_XATTR_DIGSIG_ASYMMETRIC. And version numbering can be used for
> > structure variation with-in signature type.
> >
> 
> Hello Vivek,
> 
> This was exactly the way how I initially implemented asymmetric key support.
> But then thought that we might have new versions of signature formats
> in the future and there is
> not point to create new xattr type for every signature format.
> 
> What prevents just using of signature version?

I thought explicitly using signature format is more intutive. Exporting
signature version is not. I personally associate versioning with minor
changes like addition of some fields etc. Exporting that to caller sounds
odd to me.

If I export signature version separately, then it becomes two calls. First
call for signature type and second call for signature version. As not all
formats have versions, caller also needs to be aware of that. This is like
exposing too much internal detail to caller.

Hence I felt exposing seprate signature format as separate type becomes
easy for the caller of the API. Even in user space we don't ask user the
version of signature to be generated. What is more intutive is what kind
of signature one wants to generate. Versioning info sounds more like an
internal detail to the subsystem.

Having said that, I am not very sure what's the fundamental difference
between two digital signature formats. (Exising RSA one and new one 
which is being called ASYMMETRIC). And how many possible formats are
there. What's wrong with keep on increasing the enum value as new
signature formats show up. 

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/