| 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
| ||
|
Message-ID: <MDEHLPKNGKAHNMBLJOLKMEBICHAC.davids@webmaster.com> Date: Wed, 21 Mar 2007 16:31:52 -0700 From: "David Schwartz" <davids@...master.com> To: "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org> Subject: RE: [PATCH RESEND 1/1] crypto API: RSA algorithm patch (kernel version 2.6.20.1) > If you can't read protect your kernel, you can't write protect it > either. This is so misleading as to basically be false. It is true that any security scheme that can prevent people from taking money out of my account can also prevent people from putting money in. However, the set of people I allow to put money in my account might include people I don't want to be able to take money out. As a more concrete counter-example, consider a signed kernel module that I wish to publically distribute. I can't stop anyone from reading it. I can certainly keep people from changing the copy running on my machine. Your point is not even valid about keys residing in RAM. There are perfectly sensible scenarios in which the same key needs to be in several different places, some very secure, some not so. Using a symettric key means that the securest use can be compromised by a break of the least-secure use. Consider data that is signed by the kernel and verified by a user-space program. DS - 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/
Powered by blists - more mailing lists