Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - nslay

Pages: 1 ... 3 4 [5]
61
General Programming / [C] fdman
« on: December 09, 2006, 06:56:21 pm »
fdman (short for fd manager) is a short and simple callback driven file descriptor (fd) multiplexer.  It is useful when dealing with a large set of mixed types of descriptors.  This is another component of my free time project.  At the moment I'm working on a secure UDP communication library that uses fdman.  Since UDP isn't the only communication that daemon needs to do (it needs to do local (unix) domain communication for example), I need something that centrally manages the descriptors.

The header:
Code: [Select]
#include <sys/select.h>
#include <sys/types.h>

#ifndef FDMAN_H
#define FDMAN_H

#define FDMAN_MAX FD_SETSIZE
#define FDMAN_READ 0x01
#define FDMAN_WRITE 0x02
#define FDMAN_EXCEPT 0x04

struct fdarg {
int fd;
uint8_t opt;
void *arg;
void (*cb)( struct fdarg *fda );
};

struct fdman {
struct fdarg fda[FDMAN_MAX];
fd_set rfds, wfds, efds;
int maxfd;
};

void fdman_init( struct fdman *fdm );
void fdman_set( struct fdman *fdm, struct fdarg *fda );
void fdman_unset( struct fdman *fdm, int fd );
int fdman_select( struct fdman *fdm, struct timeval *to );

#endif

Parameters

Code: [Select]
struct fdarg {
int fd; /* Descriptor */
uint8_t opt; /* Option bit mask, can be OR'd FDMAN_READ, FDMAN_WRITE, FDMAN_EXCEPT */
void *arg; /* Arbitrary argument pointer ... useful for the callback function */
void (*cb)( struct fdarg *fda ); /* Callback function */
};

When used as a parameter for fdman_set, the opt bitmask is used to set desired events.  When used with the callback function, the opt bitmask reflects the events that occurred.

Functions

void fdman_init( struct fdman *fdm ); /* Initializes a fdman struct */
void fdman_set( struct fdman *fdm, struct fdarg *fda ); /* Sets or updates settings for a descriptor */
void fdman_unset( struct fdman *fdm, int fd ); /* Unsets the descriptor */
int fdman_select( struct fdman *fdm, struct timeval *to ); /* A front to select(), however it performs all the callbacks ... a negative return reflects an error */

Example

This is a simple example that uses two descriptors.  One for the keyboard, and one for an arbitrary TCP/IP connection.

Code: [Select]
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sysexits.h>
#include <fcntl.h>
#include "fdman.h"

struct chat {
int fd;
struct fdman *fdm;
};

void kbdcb( struct fdarg *fda ) {
struct chat *ch = (struct chat *)(fda->arg);
/* Read from keyboard here */
}

void botcb( struct fdarg *fda ) {
uint8_t opt = fda->opt;
ctruct chat *ch = (struct chat *)(fda->arg);
if ( opt & FDMAN_WRITE ) {
printf( "Connected!\n" );
fda->opt = FDMAN_READ;
fdman_set( ch->fdm, fda );
}
if ( opt & FDMAN_READ ) {
/* Read from socket here */
}
}

int main( int argc, char **argv ) {
int arg;
struct fdman fdm;
struct fdarg fda;
struct chat ch;

fdman_init( &fdm );

fda.fd = STDIN_FILENO;
fda.arg = &ch;
fda.opt = FDMAN_READ;
fda.cb = kbdcb;

fdman_set( &fdm, &fda );

ch.fdm = &fdm;
ch.fd = socket( AF_INET, SOCK_STREAM, IPPROTO_TCP );
if ( ch.fd < 0 ) {
perror( "socket()" );
exit( EX_OSERR );
}
arg = fcntl( ch.fd, F_GETFL );
fcntl( ch.fd, F_SETFL, arg | O_NONBLOCK );

fda.fd = ch.fd;
fda.arg = &ch;
fda.cb = botcb;
fda.opt = FDMAN_READ | FDMAN_WRITE;

fdman_set( &fdm, &fda );

/* Connect and other stuff here */

while ( fdman_select( &fdm, NULL ) >= 0 );

return 0;
}

62
Neat little article ... explains the situation with a very simple analogy.

Quote
We’ve been hearing a lot about the complaints from the security firms with regard to Microsoft’s new Vista operating system. While on the surface it looks like Microsoft is attacking its longtime partners, this is actually the result of nearly a decade of Microsoft being attacked by them and now responding to the threat. To understand this we need to go back to the beginning.

http://itmanagement.earthweb.com/entdev/article.php/3644576

As much as I dislike Windows, I hope for the average user that Vista is a "castle."  I feel bad for many of my friends who have to deal with spyware problems in particular.  The very system they rely on to keep them safe and functional doesn't presently do a very good job at it.

63
Unix / Linux Discussion / BSD is Dying: A Cautionary Tale of Sex and Greed
« on: November 06, 2006, 12:04:54 pm »
http://talks.dixongroup.net/nycbsdcon2006/
Quite funny, the Quicktime (QT) file seems be higher quality than the mp4.  I'm not quite sure the intent of the conference, but it seems they are mocking the trolls who claim BSD is dying.  It's certainly comical.  Enjoy :)

I love the evidence they cite that BSD's market share has decreased < 1%
"Number of ASP .NET pages served per hour" and as expected, none of the BSDs have served any ASP .NET pages! LOL

64
Unix / Linux Discussion / PC-BSD ... the next Linux?
« on: November 01, 2006, 03:52:12 pm »
I really doubt it ... until, at least ZFS is done being ported to FreeBSD!

Here's the article, as featured on FreeBSD.org's "In the Media"
Enterprise Unix Roundup: PC-BSD May Be the Next Linux

65
Unix / Linux Discussion / NetBSD is dying
« on: October 29, 2006, 05:10:25 pm »
From one of the former founders of NetBSD...
Here you have it
http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html

abstract:
The NetBSD Project has stagnated to the point of irrelevance.  It has
gotten to the point that being associated with the project is often
more of a liability than an asset.  I will attempt to explain how this
happened, what the current state of affairs is, and what needs to be
done to attempt to fix the situation.

66
Botdev / [C] Fancy configurations parser
« on: October 29, 2006, 04:55:07 pm »
This is very relevant to bots in general ... especially complicated ones.
http://www.x86labs.org:81/forum/index.php/topic,7733.0.html

67
General Programming / [C] Fancy configurations parser
« on: October 29, 2006, 04:49:53 pm »
I started writing a configurations parser yesterday for my current free-time project ... I finished it a couple hours ago.  It is a nested free format.  It offers variables, lists and comments as well.
It has the following format:
Code: [Select]
# Comment
"\"/var/log\"" = "escape characters"
"Nest 1" {
        "var" = "value"
        "var" = "duplicates work too"
        "list item 1" "list item 2"
        "list item 3"
        "list item 4"
        "Nest inside a nest" {
                # Another comment
        }
        "list item 5" "list item 6" "list item 7"
}
"Nest 1" {
        "a duplicate nest"     
}       
 
"cow" = "moo"

"Colors" {
        "Blue"
        "Green" "Purple" "Brown"
}

As I said, it is free format, so white space has no meaning.  Comments are the exception, they are delimited by # and new line.

This is the header:
Code: [Select]
#define CONF_COM  '#'
#define CONF_BEG        '{'
#define CONF_END        '}'
#define CONF_EQU        '='
#define CONF_QUO        '\"'
#define CONF_IGN        '\\'

#define CONF_ERR        -1
#define CONF_EOF        0
#define CONF_VAR        1
#define CONF_NEST       2
#define CONF_LIST       3

/* Results */
extern char *conf_name;
extern char *conf_value;

struct conf_node {
        char *nest;
        unsigned int pos;
};

struct conf_file {
        char *buff;
        size_t size;
        struct stack nests;
};

/* File operations */
int conf_init( struct conf_file *cf, FILE *file );
void conf_free( struct conf_file *cf );
int conf_flush( struct conf_file *cf, FILE *file );

/* Syntax operations */
int conf_readvar( struct conf_file *cf, const char *var, unsigned int n );
int conf_countvar( struct conf_file *cf, const char *var );
int conf_readlist( struct conf_file *cf, const char *list, unsigned int n );
int conf_countlist( struct conf_file *cf, const char *list );
int conf_opennest( struct conf_file *cf, const char *nest, unsigned int n );
void conf_closenest( struct conf_file *cf );
const char* conf_currentnest( struct conf_file *cf );
int conf_countnest( struct conf_file *cf, const char *nest );

File operations
Code: [Select]
int conf_init( struct conf_file *cf, FILE *file );
void conf_free( struct conf_file *cf );
int conf_flush( struct conf_file *cf, FILE *file );

This library doesn't directly touch files, instead it accepts a FILE* to load the file into a buffer.  The assumption is that the file is relatively small (e.g.  We shouldn't expect an ASCII configurations file to be megabytes in size).

int conf_init( struct conf_file *cf, FILE *file )  /* reads a file into the buffer */
void conf_free( struct conf_file *cf ) /* frees the buffer and stack of a struct conf_file */
int conf_flush( struct conf_file *cf, FILE *file ) /* flushes the buffer to file */

These functions return 0 for success, -1 for error ... The errors can be caused from anything from inability to seek, to inability to allocate memory, to bad syntax (sanity checks are done).

Syntax operations
Code: [Select]
int conf_readvar( struct conf_file *cf, const char *var, unsigned int n );
int conf_countvar( struct conf_file *cf, const char *var );
int conf_readlist( struct conf_file *cf, const char *list, unsigned int n );
int conf_countlist( struct conf_file *cf, const char *list );
int conf_opennest( struct conf_file *cf, const char *nest, unsigned int n );
void conf_closenest( struct conf_file *cf );
const char* conf_currentnest( struct conf_file *cf );
int conf_countnest( struct conf_file *cf, const char *nest );

No constraints are placed on the actual syntax usage.  These functions even handle cases where variables, nests and list items are duplicates. That is, they enable you to do things like read the 2nd occurrence of a variable named "moo".  To note, all results are stored in global variables conf_name and conf_value.  These are mainly for convenience and it is assumed that you don't have multiple threads using the library.  This library is meant to load settings at the very beginning of execution.  The reason I chose to use global variables to hold the resulting values is that I wrote a similar library last year in C++ where you provided it a pointer to store the results.  This made the functions more complicated and it burdended the programmer to free the memory afterwards.  Here, this is all taken care of automagically.

int conf_readvar( struct conf_file *cf, const char *var, unsigned int n ) /* Reads the n'th occurrence of var, if var is NULL it reads the n'th variable.  n = 0 implies first occurrence.  The results are stored in conf_name and conf_value respectively */

int conf_countvar( struct conf_file *cf, const char *var ) /* Counts the occurrences of variables named var, if var is NULL, counts the number of variables */

int conf_readlist( struct conf_file *cf, const char *list, unsigned int n ) /* Reads n'th occurrence of list, if list is NULL, it reads the n'th list item.  The results are stored in conf_name - This is useful for testing if a value is defined in a list, or simply to query the n'th list item */

int conf_countlist( struct conf_file *cf, const char *list ) /* This counts the occurrences of list, if list is NULL, it counts the number of list items */

int conf_opennest( struct conf_file *cf, const char *nest, unsigned int n ) /* This opens the n'th occurrence of a nest for reading, if nest is NULL it opens the n'th nest, this gives all the functions the nest's scope ... underneath these are managed with a stack.  The result is stored in conf_name */

void conf_closenest( struct conf_file *cf ) /* This closes the currently opened nest */

const char* conf_currentnest( struct conf_file *cf ) /* This returns the name of the currently opened nest */

int conf_countnest( struct conf_file *cf, const char *nest ) /* This counts the occurrences of nest, if nest is NULL it counts the number of nests */

These functions return 0 for success and -1 for failure.   The errors can be caused from the non-existence of the queried item or if memory couldn't be allocated for conf_name or conf_value.

There is room for adding write functions, in fact I have set it up so that adding such functions is not a terrible pain.  However, the problem with writing configuration files is that this library cannot recognize a configuration file style of format ... much like there are many different styles of writing C/C++ Java and many other languages.  As I said, I wrote a similar library in C++ and it introduced such write functions, but it got really ugly if many writes took place since it does not preserve the original style.

On a final note, everything is case sensative!

Here is the conf library, feel free to use it for anything (I put it under BSDL).
http://nslay.36bit.com/conf.zip

It comes with 4 files:
conf.h - The header to include
conf.c - The meat
stack.h - A header for a simple and generalized stack
stack.c - More meat

Example
Code: [Select]
struct conf_file cf;
FILE *file = fopen( "test.conf", "r" );
if ( file == NULL ) {
        perror( "fopen()" );
        return -1;
}

if ( conf_init( &cf, file ) ) {
        printf( "Could not read file, please check for syntax errors!\n" );
        return -1;
}

fclose( file );

if ( conf_opennest( &cf, NULL, 0 ) ) {
        printf( "Could not open first nest!\n" );
        return -1;
}

printf( "Opened %s\n", conf_name );

if ( conf_readvar( &cf, "moo", 2 ) ) {
        printf( "There is no 3rd occurrence of \"moo\"!\n" );
        return -1;
}

printf( "%s = %s\n", conf_name, conf_value );

conf_free( &cf );

EDIT: I added a memory check to conf_extract (not documented here, not for external use!) ... it is a function that extracts strings from quotes and strips the escape characters ... it allocates memory to store the variably sized data.  Previously this was not accounted for.  As a result, the conf_count* functions return int instead of unsigned int since it must return -1 if it cannot extract a string to compare.  Pedantic, but its for robustness.  conf.zip has been updated.

68
General Discussion / Evidence Theory and computer thought
« on: October 23, 2006, 02:43:28 pm »
I'm reading a paper on this arcaine topic, Evidence Theory.  It's basically a way to quantify support and plausibility of a set of evidence.  This paper creates some curious relationships between the two.  I can see this as a precursor for computer thought and reason as it gives a numerical foothold to practical reasoning (e.g. Is person A lying if blah blah ... ). Now, this is unlike probability, since probability measures the liklihood of A while this measures the plausibility and support of evidence for A.  It is a superset of probability theory.
If you're curious, the paper (or perhaps its a copy from a book) is:
"A theory of statistical evidence" by Glenn Shafer.

69
General Programming / Fortran is stupid
« on: October 18, 2006, 10:52:01 am »
In the scientific field, everyone uses Fortran ... I have no idea why.  They are having me write Fortran code at work and I tell you, its terrible.  Fortran, historically, is faster than C for mathematical operations.  Fortran takes advantage, of say, processor features that the C math library might not.  Fortran math functions are also built into the language, whereas C math functions are actual functions and potentially introduce overhead (unless they are perhaps inline'd ... but they'd still have to move values into math registers).  However, today, most Fortran compilers use the standard C library ... at least those made by GNU and GNU advocates ... so you gain no speed benefit at all.  The language is also a little inconsistent on syntax, minus say, the stupid column rules (for Fortran 77).

Code: [Select]
write (*,*) 'moo said the cow ', x, ' times.'
Now, I know what his mumbo jumbo (*,*) means, these are the file descriptor and format code label ... but this is the only place in the language where this syntax appears ... thats just an example of inconsistent syntax.  To make things worse, but there are no standard libraries that come with Fortran and those compilers that I've seen come with no documentation for Fortran functions.  I think that C and especially C++ are way better for research than Fortran.  Fortran 90 (the newest spaghetti!) boasts features C/C++ had since their inception years and years ago!  For example, Fortran 90 can make structs and do operator overloading now ... woo!
This language needs to die ...

70
Entertainment District / The Avenging Unicorn Play Set
« on: October 14, 2006, 02:01:41 pm »
This should speak for itself ...



71
Unix / Linux Discussion / Might move to NetBSD
« on: September 06, 2006, 12:57:02 am »
I might be moving my laptop to NetBSD for wireless driver stability.  NetBSD 4.0 is nearing its release, adding WPA and various other features that I would like.
The iwi driver, and well, any driver written by Damien (who is no longer working on the drivers) hold non-sleep locks in sleeping threads.  The code is massive, I printed out some 60 or 70 pages so it looks like finding a needle in a hay stack.  I might give patching it a crack, but it doesn't look promising.  I advise anyone with Intel Pro Wireless cards and Ralink Wireless cards to avoid FreeBSD until these issues are settled.

I recently setup a NetBSD test machine (one among many P2P VLAN test machines) and was quite impressed with it ... it has pretty extensive hardware support too ... its even got a driver for an Electronic Oboe.  How bizarre?

See:
http://damien.bergamini.free.fr/ipw/
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89926
http://www.netbsd.org/Changes/changes-4.0.html

72
General Discussion / The Exodus Decoded
« on: September 02, 2006, 11:49:34 pm »
The Exodus Decoded is airing again this coming Thursday at 10:00am EST on the History Channel.  I highly recommend it.  I was awe striken the first time it aired August 20th.  It will give you a very different perspective, whether you're secular or religious.

http://theexodusdecoded.com/

73
Entertainment District / Gummy Rubber Chicken candy...finally!
« on: September 02, 2006, 09:47:39 pm »
YES!!
http://www.stupid.com/stat/GMCK.html



The chicken hat and the rubber chicken (my avatar) are fun too!

74
Unix / Linux Discussion / ZFS on FreeBSD
« on: August 31, 2006, 11:31:21 am »
http://www.freebsd.org/projects/ideas/#p-zfs

This is freaking me out.  A better file system is certainly over due for the BSDs.  It looks like it might be in FreeBSD 7.

75
New Project Announcements / P2P VLAN
« on: August 11, 2006, 07:56:43 am »
Peer-to-peer (P2P) is a buzz word these days.  It is an umbrella term for any sort of communication that is decentralized from small scale direct-connect on AIM to large scale file sharing.  A Virtual LAN (VLAN) is a logical network that exists ontop of an existing network.  It is similar to a VPN but is independent of the real network.  It's usually used to network host and multiple virtual machines together, an invaluable test tool.
Combining the two ideas could yield an invaluable networking tool that transcends network topologies such as NATs and firewalls and yet is independent of dedicated servers.  It would allow friends and family to network their machines near and far.  A similar tool exists called Hamachi, however it isn't truly P2P.  It still relies on the vendor's server to coordinate networks.  However, a P2P VLAN has more powerful implications besides transcending network topologies.  It can have other features such as true anonymity, use multiple peers as one logical tunnel, and encrypt underlying communication between two nodes.
The concept of a P2P VLAN is based on a very simple and straightforward analogy.  Suppose there is a room full of people and suppose each person has friends.  Now suppose that each person has a concealed card from a standard 52 card deck.  Only the owner of the card knows his/her card.  Now, if one were to pass a message to the owner of the Ace of Diamonds (AD), one would need to know where to send data.  To solve this problem, one asks each of one's friends who has the AD and those friends repeat the process.  The owner of the AD can respond that he/she knows who has the AD without revealing that he/she has the AD.  Eventually that response reaches the original querier and most likely through multiple friends.  To note, one cannot conclude who has the AD since the response could have been forwarded.  Now the original queier can pass a message by having friends relay the message.  Remember, he/she may have many different routes and can randomize which friend he/she relays a message through.  The effect?  Nobody knows who has the AD yet communication can take place.  In this analogy, the friends are directly connected peers and the cards represent IP addresses.
To test this idea, I wrote a demonstration that uses the tun(4) psuedo network interface.  It intializes a tun interface and then attempts to connect to each peer, up to M peers in a list file.  The demonstration code does not choose an IP, one must manually configure the tun interface.  Since our primary concern is routing, I conducted a test with three machines and forced a specific network configuration.
Our three machines:
LIGHTBULB - 172.23.0.1
BLENDER - 172.23.0.2
BOTTLE - 172.23.0.3

I forced a configuration of:
BOTTLE <-> LIGHTBULB <-> BLENDER

I did this by stripping the peer list file from BOTTLE and BLENDER.  I chose this network configuration so BLENDER and BOTTLE are forced to route through LIGHTBULB when communicating with each other.  This would demonstrate the routing technique described in our analogy above.
In order to coordinate the network, I designed a simple protocol based on battle.net's message format.
Code: [Select]
/* This header defines various events.
 * Protocol format:
 * <uint8_t event><uint16_t size><void>
 * void is event specific ... all comments below refer to void format.
 * The protocol is still in development.
 */

#ifndef PROTO_H
#define PROTO_H

/* Authorization technique.
 * peer1 connects to peer2
 * peer1 -> uint8_t clientid
 * peer2 -> uint8_t clientid
 * peer2 -> P2PI_CLIENTINFOS
 * peer1 -> P2PI_CLIENTINFOR
 */

/* Other semantics not yet determined */

/* Non-existent Client ID */
#define P2PI_NULLCLIENT 0x00

/* These refer to the event byte */
#define P2PI_CLIENTINFOS 0x01 /* Client information exchange <struct client_info> */
#define P2PI_CLIENTINFOR 0x02 /* Response event <struct client_info> */
#define P2PI_WHOHASS 0x03 /* Route request <in_addr><void> ... void data is for anything arbitrary (e.g. public key) */
#define P2PI_WHOHASR 0x04 /* Route request <in_addr><void> ... void data is for anything arbitrary (e.g. public key) */
#define P2PI_PACKET 0x05 /* Send packet <in_addr><packet> */

#endif

The comments should be self explanatory.

The tun interface on FreeBSD has a mode (TUNSLMODE) that has if_tun prepends sockaddr to each packet.  I make use of this so that I can easily extract in_addr without examining the packet in anyway.  The struct in_addr is used for routing and route request instead of sockaddr_in as to not reveal the destination port (althought the demonstation does not encrypt the packets for simplicity).

To handle routing and route requests, the demonstration uses a hash table and struct route_info:
Code: [Select]
struct route_info {
int route; /* Can route */
int routereq; /* Route request in progress */
};

The hash table relates in_addr -> route_info.
Furthermore, each connection is associated with a struct con_info which holds the file descriptor, hash table and other miscellaneous necessary information.
Code: [Select]
struct con_info {
int fd, mode;
struct sockaddr_in sin;
struct client_info cname;
uint8_t cid, buff[P2PI_BUFF];
size_t buffsz;
struct hash_table route;
};

Upon recieving a route request, the connection requesting an address is hashed as requesting a route while the demonstration forwards the route request to peers.  Upon a response, the demonstration marks the address as routable on each connection that responded, forwards the response to all connections waiting for a route, and then unmarks the route request.  While this is happening, for sanity reasons, packets read from the tun interface destined for an unroutable address are simply discarded.  Queueing the packets and then sending them on response could have serious consequences since TCP might behave to the delays while a route is in pursuit and queue more packets that might confuse the destination when they are finally sent.
Once an address is marked routable, packets read from tun are dispatched through connections able to route to the destined address.  Peers who recieve the packets should also behave accordingly.

One might ask what would happen if a peer in between a route died.  Since each connection is associated with a hash_table that holds route_info, the hash table for that connection would have been cleared and the the packet would be discarded since it is no longer routable.  The peer will do the above method to try to establish a new route.

In the experiment, I did a simple a test by pinging BOTTLE from BLENDER.  The route was established through LIGHTBULB almost instantaneously and got ping times as low as 50ms.  I was even able to ssh to BOTTLE from BLENDER over this P2P VLAN, all the while LIGHTBULB is routing under the covers.  To test the above scenario with a dead route, I restarted BOTTLE's demonstration which killed the route to BOTTLE.  Soon after, ping packets routed to LIGHTBULB were discarded until LIGHTBULB re-established connection with BOTTLE and the route re-established between LIGHTBULB and BOTTLE.

Here is a picture of the transactions:


That experiment concludes the feasability of a P2P VLAN and demonstrates how one might structure the software to handle the routing.

The real software will probably use UDP since it is probably bad to encapsulate a reliable protocol TCP/IP into TCP/IP packets.  But the bigger issue is how to deal with liars.  A liar is a peer that behaves badly and wrongfully responds to requests and perhaps uses other malicious tatics to damage the network.

One of the major security tatics, aside of encryption, is to use multiple and random routes to prevent any one peer from accumulating all packets.  That said, we treat multiple peers as one logical tunnel.  Although, this serves multiple purposes aside of security, it allows for more robust communication, as well as distributes bandwidth usage among peers.  Most peers will not want to dedicate a large portion of their bandwidth to routing.

The first and foremost problem to be dealt with is automatic determination of a node's IP.  A node could ask its peers if an IP is in use, but a peer could lie.  To overcome this problem, a node could generate a public key, a timely process, and then take a hash of the key.  If we were to use the 10.x.y.z IP block, we would want a 24 bit hash, perhaps I will write a CRC24 method.  Although, 256 bit keys would have high collision rates on a 24 bit hash, the collision rate of IP addresses would be near one in sixteen million.  This method ensures a) Most likely a unique IP is chosen b) Easy validation of liar route responses (the public key is appended to responses) c) Difficulty to target any one specific IP address.  CRC24 might not be a good enough hash, a real cryptographic hash might have to be created to do the hashing since CRC can supposedly be reversed to a degree.  Even though collision rates between 256 bit keys and CRC hashes would be high, one could somehow possibly reverse the process and pick a 256 bit number from one of the possibilities.  But that only fixes one of many problems.

Other measures taken could be heuristics (using known information) and tolerance.  Tolerance assumes that a majority of peers are not liars.  It assumes that the majority of matching responses are the correct response, and if there is no majority response, the responses are discarded.  To note, this would require each peer to have a minimum of three direct peers.  However for small networks, this could be easily overcome.  As the network grows larger of fully functional peers, it can tolerate more liars.

I will compile a list of experiments to test each security measure or a combination of the security measures.  When I get more time, I will code the actual project with a friend.  It's lots of fun :)

A more interesting aspect of a P2P VLAN, is that it could be used not only for small things but for wide scale.  Perhaps it could be a full fledge virtual Internet ... all that would need be done is a p2p-driven DNS system.  Again, such a P2P VLAN ensures anonymity, security and privacy.

Please comment ... especially on how to deal with lying peers.
Until next time :)

See also
http://freenet.sourceforge.net/

Pages: 1 ... 3 4 [5]