Date: Tue, 16 Sep 1997 02:57:05 -0400 From: Brian Haskin <haskin@ptway.com> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: FreeBSD-Hackers <freebsd-hackers@freebsd.org> Subject: Re: Fast Encryption (in kernel) seeked Message-ID: <341E2DC1.220444E7@ptway.com> References: <XFMail.970915215746.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :-) > First let me say that I have not done any kernel programming so I don't know what services you have available. Ok one thing, even if the rest of this doesn't apply at all, no matter how you encrypt it EVEN if you went and implemented DES it won't do you any good if you use the same key every time or a readily determinable key. Forgive my ignorance but looking at your message I'm not sure if you want to encrypt the pointer, in which case the process your handing it to won't be able to access the structure, or if you just want to make sure that the structure your getting handed back is the same one that you handed out. If it's the latter and the content's are truly safe from being read by unauthorized processes then simply stuffing some random data in a signature field (preferably from dev/random. Not time of day, processes running, etc.) should be sufficient. If you really want to do the former it would probably be easier, and more secure, to simply pass a token (again consisting of random data) than the pointer, encrypted or not. But somehow I have the feeling the more I look at it that none of this is what you really want to do. :) If for some reason you really, really, want to and insist on passing an encrypted pointer please don't make up your own algorithm. There's plenty of good secure, peer reviewed ones out there to do the job. A good place to go for help in this situation would be coderpunks@toad.com Hope something I said can be of help. Brian Haskin <haskin@ptway.com> disclaimer: if any or all of the above makes no sense, is totally off topic, has glaring flaws, helps out in no way whatsoever and simply adds confusion and bloat to the discussion. I blame it all on sleep deprivation. Well most of it anyway. :}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?341E2DC1.220444E7>