Date: Tue, 16 Sep 1997 00:51:56 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Brian Haskin <haskin@ptway.com> Cc: FreeBSD-Hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: Fast Encryption (in kernel) seeked Message-ID: <XFMail.970916005156.Shimon@i-Connect.Net> In-Reply-To: <341E2DC1.220444E7@ptway.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970916005156.Shimon>