linux-kernel - Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel version 2.6.20.1)

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: <000e01c76b99$769cbbe0$0864a8c0@scs1>
Date:	Wed, 21 Mar 2007 11:15:19 +0200
From:	"Tasos Parisinos" <t.parisinos@...ensis.com>
To:	"Indan Zupancic" <indan@....nu>
Cc:	"Francois Romieu" <romieu@...zoreil.com>,
	<herbert@...dor.apana.org.au>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel      version 2.6.20.1)

> Assuming you have a secure kernel binary that is tamper proof, why do you need
> slow and complex asymmetric encryption again? If you can write protect the kernel,
> you can also read protect it (or let the boot loader pass the key to the kernel).
> So what stops you from using a simple symmetric key cipher for signing?

In symmetric cryptography you would give away your key if one could read the kernel binary
while in assymetric one can only get the public key

Protecting a TripleDES key in high security standards is not as simple as making the kernel read protected, you need a whole lot and 
that also means hardware (cryptomemories e.t.c)
So you forget about all this overhead when you use assymetric

Also this is the way this is done in all implementations ranging from Linux platforms (see DigSig@...rceforge for an example, or in 
Debian, Fedora) and in Microsoft platforms as far as i know


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