[email protected], [email protected], [email protected]
The following four patches add support for DSA keys to the in-kernel key
management system.
In-kernel dsa keys allows a process to use the request_key mechanism to
request such keys on demand. One such example is a backup script that,
when done, could issue a request for an appropriate ssh key. The request
would then be forwarded by /sbin/request-key to the appropriate user who
could supply the key which is in turn used by the backup script to transfer
the results to a backup server. This allows for much more flexible and
interesting solutions than passwordless ssh key files or shared ssh
agents would ever be able to support. (I have a separate patch for
openssh which allows ssh-add and ssh to work with in-kernel keys).
In addition, the in-kernel keys have the advantage of being non-ptraceable,
will not be swapped out to disk, and does not run the risk of being included
in coredumps.
The patch is split into four sub-patches:
1) Adds the multi-precision-integer maths library which was originally taken
from GnuPG and ported to the kernel by David Howells in 2004
(http://people.redhat.com/~dhowells/modsign/modsign-269rc4mm1-2.diff.bz2)
2) Adds dsa cryptographic operations. Since a dsa signature is always two
160-bit integer, I've modeled the dsa crypto as a hash algorithm.
3) Changes the keyctl syscall to accept six arguments (is it valid to do so?)
and adds encryption as one of the supported ops for in-kernel keys.
4) Adds the dsa in-kernel key type.
This is quite some lines of code and may be controversial, so I've donned my
finest asbestos underwear.
Regards,
David H?rdeman <[email protected]>
crypto/Kconfig | 15
crypto/Makefile | 2
crypto/dsa.c | 230 +++++
crypto/mpi/Makefile | 31
crypto/mpi/generic_mpi-asm-defs.h | 10
crypto/mpi/generic_mpih-add1.c | 65 +
crypto/mpi/generic_mpih-lshift.c | 66 +
crypto/mpi/generic_mpih-mul1.c | 60 +
crypto/mpi/generic_mpih-mul2.c | 63 +
crypto/mpi/generic_mpih-mul3.c | 64 +
crypto/mpi/generic_mpih-rshift.c | 66 +
crypto/mpi/generic_mpih-sub1.c | 63 +
crypto/mpi/generic_udiv-w-sdiv.c | 108 ++
crypto/mpi/longlong.h | 1502 ++++++++++++++++++++++++++++++++++++++
crypto/mpi/mpi-add.c | 247 ++++++
crypto/mpi/mpi-bit.c | 255 ++++++
crypto/mpi/mpi-cmp.c | 72 +
crypto/mpi/mpi-div.c | 350 ++++++++
crypto/mpi/mpi-gcd.c | 62 +
crypto/mpi/mpi-inline.c | 32
crypto/mpi/mpi-inline.h | 128 +++
crypto/mpi/mpi-internal.h | 265 ++++++
crypto/mpi/mpi-inv.c | 190 ++++
crypto/mpi/mpi-mpow.c | 138 +++
crypto/mpi/mpi-mul.c | 203 +++++
crypto/mpi/mpi-pow.c | 325 ++++++++
crypto/mpi/mpi-scan.c | 143 +++
crypto/mpi/mpicoder.c | 390 +++++++++
crypto/mpi/mpih-cmp.c | 59 +
crypto/mpi/mpih-div.c | 548 +++++++++++++
crypto/mpi/mpih-mul.c | 545 +++++++++++++
crypto/mpi/mpiutil.c | 237 +++++
include/linux/compat.h | 4
include/linux/dsa.h | 39
include/linux/key.h | 11
include/linux/keyctl.h | 1
include/linux/mpi.h | 154 +++
include/linux/syscalls.h | 5
security/Kconfig | 8
security/keys/Makefile | 1
security/keys/compat.c | 9
security/keys/dsa_key.c | 372 +++++++++
security/keys/keyctl.c | 72 +
43 files changed, 7201 insertions(+), 9 deletions(-)
On Mon, Jan 23, 2006 at 09:42:32PM +0100, David H?rdeman wrote:
>The following four patches add support for DSA keys to the in-kernel key
>management system.
[...]
>1) Adds the multi-precision-integer maths library which was originally taken
> from GnuPG and ported to the kernel by David Howells in 2004
> (http://people.redhat.com/~dhowells/modsign/modsign-269rc4mm1-2.diff.bz2)
And in case that patch is caught by any size restrictions, it's also
available at:
http://www.hardeman.nu/~david/lkml/01-add-mpilib.patch
Re,
David
David H?rdeman <[email protected]> wrote:
> The following four patches add support for DSA keys to the in-kernel key
> management system.
Can you copy your emails to key management mailing list please:
[email protected]
http://linux-nfs.org/cgi-bin/mailman/listinfo/keyrings
David
David H?rdeman <[email protected]> wrote:
>
> 3) Changes the keyctl syscall to accept six arguments (is it valid to do so?)
> and adds encryption as one of the supported ops for in-kernel keys.
The asymmetric encryption support should be done inside the crypto/
framework rather than as an extension to the key management system.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Jan 27, 2006 at 12:22:31PM +1100, Herbert Xu wrote:
>David H?rdeman <[email protected]> wrote:
>>
>> 3) Changes the keyctl syscall to accept six arguments (is it valid to do so?)
>> and adds encryption as one of the supported ops for in-kernel keys.
>
>The asymmetric encryption support should be done inside the crypto/
>framework rather than as an extension to the key management system.
It is done inside the crypto/ framework. crypto/dsa.c implements the DSA
signing as a hash crypto algorithm (since a DSA signature is two 160-bit
integers, the result has a fixed size).
The above patch just adds the syscall to tell the in-kernel system that
you wish to encrypt/sign something with a given key. In the case that
the type of the given key is a DSA key, security/keys/dsa_key.c uses the
dsa crypto alg from crypto/dsa.c to satisfy that request.
Regards,
David
On Fri, Jan 27, 2006 at 08:23:45AM +0100, David H?rdeman wrote:
> On Fri, Jan 27, 2006 at 12:22:31PM +1100, Herbert Xu wrote:
> >David H?rdeman <[email protected]> wrote:
> >>
> >>3) Changes the keyctl syscall to accept six arguments (is it valid to do
> >>so?)
> >> and adds encryption as one of the supported ops for in-kernel keys.
> >
> >The asymmetric encryption support should be done inside the crypto/
> >framework rather than as an extension to the key management system.
>
> It is done inside the crypto/ framework. crypto/dsa.c implements the DSA
> signing as a hash crypto algorithm (since a DSA signature is two 160-bit
> integers, the result has a fixed size).
Right. I mistook the name encrypt to mean generic asymmetric encryption.
Now I see that it is simply an interface to the signature algorithm.
This is fine by me. However, wouldn't "sign" be a better name for it?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Jan 27, 2006 at 11:28:56PM +1100, Herbert Xu wrote:
>On Fri, Jan 27, 2006 at 08:23:45AM +0100, David H?rdeman wrote:
>>On Fri, Jan 27, 2006 at 12:22:31PM +1100, Herbert Xu wrote:
>>>The asymmetric encryption support should be done inside the crypto/
>>>framework rather than as an extension to the key management system.
>>
>> It is done inside the crypto/ framework. crypto/dsa.c implements the DSA
>> signing as a hash crypto algorithm (since a DSA signature is two 160-bit
>> integers, the result has a fixed size).
>
>Right. I mistook the name encrypt to mean generic asymmetric encryption.
>Now I see that it is simply an interface to the signature algorithm.
>This is fine by me. However, wouldn't "sign" be a better name for it?
>
I don't know, the function which is performed upon the data is
keytype-specific (i.e. with the dsa key the data is signed, with another
key type it might be encrypted, etc). So perhaps the operation should be
given a more generic name such as "crypto".
Re,
David