Re: Looking for programing partners

No, I can't explain it much more clearly, I actually need help as I
mentioned in my original post. I'm in the process of writing a more
comprehensive summary at the moment and putting it up somewhere.

To answer your question, it is not intended to do anything IPSEC is
supposed to handle. This "tunnel" type will be based off of the a
library I am calling 'Crush' (website coming soon) which has the basic
goal of seperating data from data formats, including data in
recognizable IP streams. Once the data is seperated it can be
consolidated too ther identical data reducing the amount of duplicate
data on a storage device, or being sent over an IP stream.

Yes, verification of the data is mandatory before it is considered
cached, which removes the error that hash collision could bring into
this technique.

You could use IPSEC to secure the tunnelled data, infact it the IPSEC
related facilities in the Linux and BSD kernel are an integral part of
the project.

On 4/25/07, Beau V.C. Bellamy <beau@stellarnetservices.net> wrote:
> So is this meant as an encrypted transport for network filesystems or a
> generic trunnel? And why would CIFS/NFS/SMB/HTTP/etc over IPSEC not
> suffice?
>
> I guess I'm confused. Could you explain your goal a little more clearly?
> What exactly is it going to do? Why are existing and established protocols
> (or a combination of those) not ideal?
>
> - Beau
>
> On Monday 23 April 2007 16:49, Shane Spencer wrote:
> > Yo,
> >
> > I am trying to find some programming partners to help make decisions
> > and implement an augmented IP tunnel in userspace which also uses some
> > kernel space facilities (cryptoapi). I need some assistance nailing
> > down enough information for a website of project as well.
> >
> > This program, similar to how openvpn and vtun uses Universal TUN/TAP
> > devices, is an attempt to make a cached and compressed IP tunnel by
> > modifying streams of packet data, specifically streams of understood
> > protocols like CIFS/NFS/SMB/HTTP and of course SMTP. The plan is to
> > replace large data segments of individual transfer streams with a
> > digest of the data, and store the data block on a local filesystem for
> > the destination to retrieve later. Once the destination recieves a
> > "cache" packet containing the original packet headers and a reference
> > to the data block by digest it will attempt to find a locally stored
> > copy of the digest, retrieve from the remote side and store locally.
> > Cache data should be expired based on either a hard disk quota or
> > other cache maintainer algorithms similar to Squid. Cached data should
> > also be stored and encrypted based on a randomly negotiated pre shared
> > key if desired.
> >
> > Won't this be slow? Not really, SHA1 and SHA256 are fast, and
> > commonly used by hardware compression boards.
> >
> > This concept is also known as WanFS to many commercial companies. I
> > want to make it open to the world to use.
> >
> > Lemme know if interested, Python and C.
> >
> > Shane
> > ---------
> > To unsubscribe, send email to <aklug-request@aklug.org>
> > with 'unsubscribe' in the message body.
>
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Apr 25 13:39:04 2007