From owner-freebsd-hackers Tue Sep 16 00:52:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA02066 for hackers-outgoing; Tue, 16 Sep 1997 00:52:07 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA02009 for ; Tue, 16 Sep 1997 00:51:56 -0700 (PDT) Received: (qmail 11006 invoked by uid 1000); 16 Sep 1997 07:51:56 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <341E2DC1.220444E7@ptway.com> Date: Tue, 16 Sep 1997 00:51:56 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Brian Haskin Subject: Re: Fast Encryption (in kernel) seeked Cc: FreeBSD-Hackers Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Brian Haskin; On 16-Sep-97 you wrote: ... > 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. Yup. We understand that. > 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. Forget about a pointer. Thnk about a cookie. I hand you a cookie and a key. With the key I can authenticate you and the cookie. If you passed the pair to someone else, that's fine. But the trichk is to know that the cookie is good. As I said, if I have to go look for the original where the cookie came from, than nothing was gained. A very simplistic example is to say: u_int32_t cookie = (uin32_t)something_else; u_int32_t token = ~cookie; Then we pass both cookie and token to userspace. When we get them back, sometime later, we do: if ( cookie == ~token ) all is well; else something bad; The only problem here, is that if you meliciously give me a bad cookie and a matching token, I will never know what hit me. One solution could be md5. If I could md5 the outgoing cookie and then md5 the incoming cookie, I would have a reasonable certainty the cookie is valid. This means I could give you the cookie but not the token, and carefully check the incoming cookie against a secret token. But this checking needs to reliable and FAST. ... > 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 This is why I posted a question... Thanx! --- Sincerely Yours, (Sent on 16-Sep-97, 00:27:21 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