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] [day] [month] [year] [list]

Date:	Thu, 22 Mar 2007 14:15:58 +0100 (CET)
From:	"Indan Zupancic" <indan@....nu>
To:	davids@...master.com
Cc:	"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)

(Please don't trim me from the CC list if you're replying to what I've said,
thanks.)

On Thu, March 22, 2007 00:31, David Schwartz wrote:
>> If you can't read protect your kernel, you can't write protect it
>> either.
>
> This is so misleading as to basically be false.

Please elaborate. Short of ROM I don't see how you'd achieve it.
Looks more like a misunderstanding than misleading going on here.

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

I wasn't talking about a single security scheme, I was talking about the
possible schemes. Would you trust someone to protect your account if he says
he's able to write protect your account, but not read protect it? And keep
in mind I'm talking about technical abilities, not cases where one access
is chosen to be allowed.

Purposely allowing the one and disallowing the other is a different case.
But there's a difference between opening your door and having a door with
a bad lock.

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

Maybe, maybe not. The signature won't stop people from modifying the loaded
kernel, something else has to. And if that 'something' can stop modifications,
it most likely can also read protect a part of kernel RAM too, with little
tweaking. If it can't, I wouldn't trust it to write protect the kernel either.

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

My point is valid, but you seem to confuse it with scenarios where you want to
allow the one and disallow the other, and using that as an argument that my
point isn't valid.

I already said in another email that symmetric key encryption is only as secure
as RSA if each device has its own key, in the case of signed binaries. I'm also
not trying to argue that all asymmetric crypto uses can be replaced with
symmetric ones, in case you wonder.

What I do try to make clear is that for certain cases there are alternatives
which are as secure as RSA, and that a lot apparent weaknesses of that approach
are also present with RSA, and that no matter what you use, you need to have
the same basic security in place for both.

Greetings,

Indan

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