From owner-freebsd-hackers Tue Sep 16 00:40:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA29012 for hackers-outgoing; Tue, 16 Sep 1997 00:40:33 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA28996 for ; Tue, 16 Sep 1997 00:40:30 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA28916; Tue, 16 Sep 1997 00:39:28 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd028914; Tue Sep 16 07:39:23 1997 Date: Tue, 16 Sep 1997 00:38:42 -0700 (PDT) From: Julian Elischer To: Simon Shapiro cc: FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Fast Encryption (in kernel) seeked In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk To answer this question correctly, We need to know more details.. every algorythm has its day. It depends on what the situation is. For example, if there will be less than 100 of these 'pointers' outstanding at a time, different schemes would be used to the case where there are 100000 outstanding.. can you guarentee that each pointer given out will be 'returned'? will it be returned only once? what if a process dies while owning a pointer? when does the buffer become free? who allocates the buffers? I have code that does all this but it's only useful to you if what you want to do matches the goals of what I was designing for.. tell me more.. julian On Mon, 15 Sep 1997, Simon Shapiro wrote: > Hi! It's me again! > > I have a specific integer (actually a pointer to a structure) which, for > performance reasons, I want exported to userspace. What happens with this > pointer is that sometimes later it comes back to the kernel. > > I want a QUICK was to encrypt it so that a melicious user cannot send a bad > address into the kernel. > > The data comes and goes via special /dev entry in the form of READ, WRITE > and IOCTL. The pointer in question is to a small structure and the data in > the structure is safe from corruption. > > The reasonm for this mess is that the structure is created/anihilated via > malloc/free and the process returning it to the kernel may not be the one > that got it from the kernel. Instead of a key to search on, having the > address is much faster. The security issue is obvious. > > If I could have a FAST machanism by which to ``sign'' the address, It would > be advantageous way to handle it. If I put just a unique signature that I > have to then search for, well, I knwo how to do that, and actually already > do that. XORing the pointer can be safe from accidents, but too easy to > fake. > > If this sounds like harebrain idea, it probably is :-) > > --- > > > Sincerely Yours, (Sent on 15-Sep-97, 21:44:35 > by XF-Mail) > > Simon Shapiro Atlas Telecom > Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 > Shimon@i-Connect.Net Voice: 503.643.5559, Emergency: 503.799.2313 >