From owner-freebsd-hackers Tue Sep 16 12:46:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA15537 for hackers-outgoing; Tue, 16 Sep 1997 12:46:37 -0700 (PDT) Received: from ptway.com (apollo.ptway.com [199.176.148.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA15530 for ; Tue, 16 Sep 1997 12:46:33 -0700 (PDT) Received: from brianjr.haskin.org (222R1.ptway.com [199.176.148.89]) by ptway.com (8.7.1/3.4W4-PTWAY-sco-ODT3.0) with ESMTP id PAA25896; Tue, 16 Sep 1997 15:20:56 -0400 (EDT) Message-ID: <341EDD69.9EA2140E@ptway.com> Date: Tue, 16 Sep 1997 15:26:33 -0400 From: Brian Haskin X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Simon Shapiro CC: FreeBSD-Hackers Subject: Re: Fast Encryption (in kernel) seeked X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > Snip responses to my mad ravings ;) > > 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. > > ... [SNIP] Ok, now I see what your trying to do. If you have access to md5 instead of just hashing the pointer hash the pointer and some random data K. then hand this hash and the pointer off of course saving K. When it comes back just hash the pointer and K again and make sure it matches. The same K can be used for all pointers handed out. Hope I got what your trying to do right this time. Brian Haskin