blocks-development — Main mailing list for Blocks

Re: [Blocks-development] fake local networks? Blocks as a backend for other services?

[Blat F. <pet...@ho...>]

>From: "Spencer Jr., Michael" <sp...@ac...>
>To: "'Blat Froop'" <pet...@ho...>,        
>blo...@li...
>Subject: [Blocks-development] fake local networks?  Blocks as a backend for 
>other services?
>Date: Fri, 4 Aug 2000 09:18:25 -0500
>
>It's looking like these Blocks servers won't be lightweight
>connect-search-disconnect clients.  A significant number (but not a
>majority) will probably be run by people with bandwidth and clue.
>
>With that in mind, here's a silly idea that I haven't given much thought 
>to:
>
>for anonymity, eventually, maybe when we make Blocks client/server, if we
>choose to go that route...why not make it an option to run multiple Blocks
>server locally, and manage them all in one GUI!  You could even add fake
>latency and bandwidth between the local servers, so they appear to be on
>other machines.

Hmmm... that would be a nice feature but probably the effort would
outweight the benefits.

>
>
>While I'm at it...
>if all of this web-of-trust stuff gets implemented well sometime down the
>road...I suppose you could have a closed network of clients merely used as 
>a
>distributed 'disk dump' for a different service:  you connect to an FTP
>server and download files, and the files are coming from a closed Blocks
>network for example.
>
>Filesystem driver for Blocks?  (mount -t blocksfs -o
>cache=4,rate=32768,listen=9912 /home/ftp 209.180.104.202:91)
>
>Perhaps have an /unsigned directory for content that hasn't been signed, 
>and
>have people 'own' certain directories with crypto keys...and files are
>assigned to directories by signing the files.  I don't know...could be 
>cool.
>And these directory and key assignments could be made per-server in
>/etc/blocksfs.conf or something like that.  :)

A filesystem based on DAV ( http://www.webdav.org ) is a possibility,
everything else would be heavily non-portable. That would let
WIN32 people use native 'Web Folders', and, if there isnt a way to
mount it on Linux Im sure there will be eventually.

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] fake local networks? Blocks as a backend for other services?

[Spencer Jr., M. <sp...@ac...>]

It's looking like these Blocks servers won't be lightweight
connect-search-disconnect clients.  A significant number (but not a
majority) will probably be run by people with bandwidth and clue.

With that in mind, here's a silly idea that I haven't given much thought to:

for anonymity, eventually, maybe when we make Blocks client/server, if we
choose to go that route...why not make it an option to run multiple Blocks
server locally, and manage them all in one GUI!  You could even add fake
latency and bandwidth between the local servers, so they appear to be on
other machines.


While I'm at it...
if all of this web-of-trust stuff gets implemented well sometime down the
road...I suppose you could have a closed network of clients merely used as a
distributed 'disk dump' for a different service:  you connect to an FTP
server and download files, and the files are coming from a closed Blocks
network for example.

Filesystem driver for Blocks?  (mount -t blocksfs -o
cache=4,rate=32768,listen=9912 /home/ftp 209.180.104.202:91)

Perhaps have an /unsigned directory for content that hasn't been signed, and
have people 'own' certain directories with crypto keys...and files are
assigned to directories by signing the files.  I don't know...could be cool.
And these directory and key assignments could be made per-server in
/etc/blocksfs.conf or something like that.  :)

--Michael Spencer
bl...@ms...

-----Original Message-----
From: Blat Froop [mailto:pet...@ho...]
Sent: Friday, August 04, 2000 8:34 AM
To: blo...@li...
Subject: [Blocks-development] V0.15 readvertisement of locally cache
files


Here is an idea...

at the moment the V0.15 is going to readvertise the most
recent 1024 non-local file advertisements to newly connected
servers. Local files are not rebroadcast in order to stop
people connecting to see what you are serving directly.

So, what if I change it so that V0.15 makes up a bogus random
single character route for each locally cached file. Then
connecting clients wont be able to tell if the server has it
itself, or one immediately adjacent to it. The bogus route
will be valid since the server will intercept requests it
can furfill out of cache.

Comments?

ttfn

PG.

PS Other than this, and a quick check it still works on Solaris,
   V0.15 is pretty much done :)
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

RE: [Blocks-development] V0.15 readvertisement of locally cache f iles

[Blat F. <pet...@ho...>]

>From: Paul Kalupnieks <pa...@nk...>
>To: "'Blat Froop'" <pet...@ho...>,        
>blo...@li...
>Subject: RE: [Blocks-development] V0.15 readvertisement of locally cache f 
>iles
>Date: Fri, 4 Aug 2000 10:17:49 -0400
>
>It will be a random route, based on current existing routes? So not to
>"fake" it by advertising a route to the file that isn't real to begin with.

I was thinking of just a bogus route since I dont think it adversely
affects anything else. That would give the people doing statistical
analysis a bit of a headache :)

But copying a real route is a possibility tho... just slightly
more complex in exceptional situations where there are few or
no 'appropriate' existing choices.

ttfn

PG.

PS V0.15 now compiles clean on Solaris :-)
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

RE: [Blocks-development] V0.15 readvertisement of locally cache f iles

[Paul K. <pa...@nk...>]

It will be a random route, based on current existing routes? So not to
"fake" it by advertising a route to the file that isn't real to begin with.

-----Original Message-----
From: Blat Froop [mailto:pet...@ho...]
Sent: Friday, August 04, 2000 9:34 AM
To: blo...@li...
Subject: [Blocks-development] V0.15 readvertisement of locally cache
files


Here is an idea...

at the moment the V0.15 is going to readvertise the most
recent 1024 non-local file advertisements to newly connected
servers. Local files are not rebroadcast in order to stop
people connecting to see what you are serving directly.

So, what if I change it so that V0.15 makes up a bogus random
single character route for each locally cached file. Then
connecting clients wont be able to tell if the server has it
itself, or one immediately adjacent to it. The bogus route
will be valid since the server will intercept requests it
can furfill out of cache.

Comments?

ttfn

PG.

PS Other than this, and a quick check it still works on Solaris,
   V0.15 is pretty much done :)
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

[Blocks-development] V0.15 readvertisement of locally cache files

[Blat F. <pet...@ho...>]

Here is an idea...

at the moment the V0.15 is going to readvertise the most
recent 1024 non-local file advertisements to newly connected
servers. Local files are not rebroadcast in order to stop
people connecting to see what you are serving directly.

So, what if I change it so that V0.15 makes up a bogus random
single character route for each locally cached file. Then
connecting clients wont be able to tell if the server has it
itself, or one immediately adjacent to it. The bogus route
will be valid since the server will intercept requests it
can furfill out of cache.

Comments?

ttfn

PG.

PS Other than this, and a quick check it still works on Solaris,
   V0.15 is pretty much done :)
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] Secure hash discussion...hopefully easy-to-read this time! ^_^

[Spencer Jr., M. <sp...@ac...>]

I'm remaking an argument I promised I would leave until later...being
grateful enough for just the content hash...but we can look at it now in the
discussion of securely resuming files.

SECURE HASH  --  WHY USE IT?

The only problem with resuming files by hash is if you have a malicious
client.  The malicious client could advertise a file with a certain
hash...but the hash doesn't really match the content.  With the current
hashing algorithm, you can't possibly know that the hash doesn't match the
content until you have the whole file -- and then it's too late.

This could be even more evil with automatic resumes:  if I'm a malicious
client, I just listen for file advertisements, and readvertise a file of my
own that doesn't really exist, but has the same content hash as the original
file.  People would then try to resume from me, but I'm going to send them
bogus data instead of the file they think they're requesting.

As I understand the transfer of blocks and the file header, when the clients
retrieve the file header, they have a list of block ID's to request.  So is
it possible for a malicous client to construct a block that the client will
download and accept, and not realize it's a bogus block until they
reconstruct the whole file at the end?  If that is possible...then this
could open us up to a wider-scope file sharing attack.

SECURE HASH  --  OK, WHAT IS IT THEN?

In my opinion, a 'secure hash' is a hash that you can verify WHILE STILL
DOWNLOADING the file, and an 'insecure hash' is a hash that you cannot
verify until you have the whole file.

From here, you guys are free to make up your own secure hash.

My idea for a secure hash:  for each block of the file (not the encrypted
file, the unencrypted original) create a hash (RIPEMD-128 perhaps) and store
it in a block-of-hashes.  Once you have that big ball of hashes, all put
into a file end-to-end, hash that file.

UPLOADING:  When you upload, you create your normal file-header block (just
like we're doing now) and also create a block-of-hashes.  Create another
hash of the block-of-hashes, and put THAT hash in the file advert you send
out.

DOWNLOADING:  When you download, you obtain the normal file-header block
(just like we do now) and also obtain the block-of-hashes.  Compare the
block-of-hashes against the hash that was advertised in the file advert (as
if the block-of-hashes is a file).  If the block-of-hashes doesn't match the
file advert's hash, one or the other is corrupt (deliberately or
accidentally) -- HALT THE DOWNLOAD.  Otherwise, continue.  Request the first
block of data...and compare the block of data against the first block in the
block-of-hashes.  If that hash doesn't match the downloaded block, again one
or the other is corrupt -- HALT THE DOWNLOAD.  Otherwise, repeat until the
file's complete.

WHY IT WORKS

That malicious client advertising bogus files can be detected and defeated
(people will still waste those two blocks worth of transfer, but their
download will eventually continue, and it won't get corrupted.  This is
because you can tell you're downloading bogus data once you have a whole
block, not the whole file.  (And if you wait until you have the whole file
to decide your data is bogus, you've pissed off a user.)


NECESSARY PLUG FOR THE AUTHOR

This is a cool feature to implement, and even without the web-of-trust, this
would help make resumes safer against malicious users or spammers.

But this is freakin 0.14!  :)  I don't know about the rest of us...but I'm
very impressed with the extreme amount of work our coder is pumping out, and
I'll be the last person in the world to rush him.  Maybe around 0.25 or
something, we can start to implement this.  But maybe we can discuss it now.
:)


--Michael Spencer
bl...@ms...


-----Original Message-----
From: Blat Froop [mailto:pet...@ho...]
Sent: Thursday, August 03, 2000 10:02 AM
To: blo...@li...
Subject: [Blocks-development] V0.15 progress update


so far Ive done the following...

1) Fix timeouts and problems when uploading &
   downloading at the same time.

2) All whole now multiple uploads capability for
   bulk uploading.

3) Add content hash to adverts and header blocks,
   and display this in the serach window.

4) Increase the smartness of the 'bad route' logic
   so that search results are more accurate.

5) Change readvertisement logic so that it now
   readvertises most recent 1024 non-local ads.

6) Increase netcode efficiency (might reduce CPU,
   and increase throughput on unlimited connections).

The one outstanding thing to look at was the automatic
switching of routes on failed downloads. Im not sure
about this, on one hand it seems like a nice feature,
but on the other, it would be nice to investigate
downloading errors during the testing phase, so I may
leave this out for now.

Now, we need a plan on an upgrade strategy... I think
we're probably still small enough to simply switch
everything from V0.14 to V0.15 simulateneously, but do
we want to keep a V0.14 public server running until
we can verify that V0.15 is reasonably stable?

Any comments?

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

Re: [Blocks-development] V0.15 progress update

[Blat F. <pet...@ho...>]

>From: "Erik Moeller" <mo...@sc...>
>To: blo...@li...
>Subject: Re: [Blocks-development] V0.15 progress update
>Date: Thu, 3 Aug 2000 18:22:17 +0200
>
>On 3 Aug 2000, at 15:02, Blat Froop wrote:
>
> > 5) Change readvertisement logic so that it now
> >    readvertises most recent 1024 non-local ads.
>
>Doesn't that mean that older files are no longer advertised?
>Shouldn't it "cycle through" the adverts instead?

Yes, over time it should probably crawl through all the
ads and readvertise, but it doesnt do this yet. At least
firing a block of ads at new connections will let people
bring servers up and down without having to wait too long
to see files. This is especially important for newbies.

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] V0.15 progress update

[Erik M. <mo...@sc...>]

On 3 Aug 2000, at 15:02, Blat Froop wrote:

> 5) Change readvertisement logic so that it now
>    readvertises most recent 1024 non-local ads.

Doesn't that mean that older files are no longer advertised? 
Shouldn't it "cycle through" the adverts instead?

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

RE: [Blocks-development] V0.15 progress update

[Paul K. <pa...@nk...>]

I say we just switch it. =) It's better to have a group do "real world"
testing anyway, so why not let the small community we are do so, and report
bugs?

-----Original Message-----
From: Blat Froop [mailto:pet...@ho...]
Sent: Thursday, August 03, 2000 11:02 AM
To: blo...@li...
Subject: [Blocks-development] V0.15 progress update


so far Ive done the following...

1) Fix timeouts and problems when uploading &
   downloading at the same time.

2) All whole now multiple uploads capability for
   bulk uploading.

3) Add content hash to adverts and header blocks,
   and display this in the serach window.

4) Increase the smartness of the 'bad route' logic
   so that search results are more accurate.

5) Change readvertisement logic so that it now
   readvertises most recent 1024 non-local ads.

6) Increase netcode efficiency (might reduce CPU,
   and increase throughput on unlimited connections).

The one outstanding thing to look at was the automatic
switching of routes on failed downloads. Im not sure
about this, on one hand it seems like a nice feature,
but on the other, it would be nice to investigate
downloading errors during the testing phase, so I may
leave this out for now.

Now, we need a plan on an upgrade strategy... I think
we're probably still small enough to simply switch
everything from V0.14 to V0.15 simulateneously, but do
we want to keep a V0.14 public server running until
we can verify that V0.15 is reasonably stable?

Any comments?

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

[Blocks-development] V0.15 progress update

[Blat F. <pet...@ho...>]

so far Ive done the following...

1) Fix timeouts and problems when uploading &
   downloading at the same time.

2) All whole now multiple uploads capability for
   bulk uploading.

3) Add content hash to adverts and header blocks,
   and display this in the serach window.

4) Increase the smartness of the 'bad route' logic
   so that search results are more accurate.

5) Change readvertisement logic so that it now
   readvertises most recent 1024 non-local ads.

6) Increase netcode efficiency (might reduce CPU,
   and increase throughput on unlimited connections).

The one outstanding thing to look at was the automatic
switching of routes on failed downloads. Im not sure
about this, on one hand it seems like a nice feature,
but on the other, it would be nice to investigate
downloading errors during the testing phase, so I may
leave this out for now.

Now, we need a plan on an upgrade strategy... I think
we're probably still small enough to simply switch
everything from V0.14 to V0.15 simulateneously, but do
we want to keep a V0.14 public server running until
we can verify that V0.15 is reasonably stable?

Any comments?

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] Blocks master server has moved

[Blat F. <pet...@ho...>]

Michael is now running on 209.180.104.202:91 this will be on the web page 
shortly.

Luke could you point your server at that one. thanks.

ttfn

PG.


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Blocks-development] Volunteers

[Blat F. <pet...@ho...>]

While Im coding away I was thinking.. Is anyone interested in
taking over the primary role of doing the web page?... its only
one page at the moment and its not very flash. Benjamin might
be an obvious choice since he hosts the site.

Also, Blocks needs a simple FAQ/guide so that people need to
know what it does. I think a lot of people are discouraged
from running publically accesible servers because they think
its just like running a public FTP server, when in reality
public servers probably never serve data and only use a small
amount of bandwidth.

Oh, an going forward we need someone to don the marketing hat
<;-)

ttfn

PG.


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] Alternative to ActiveX: TCP/IP! ^_^

[Blat F. <pet...@ho...>]

>From: lu...@et...
>To: "Spencer Jr., Michael" <sp...@ac...>,        
>blo...@li...
>Subject: Re: [Blocks-development] Alternative to ActiveX:  TCP/IP!  ^_^
>Date: Wed, 2 Aug 2000 17:53:56 -0400
>
>* Spencer Jr., Michael wrote:
> > This is for WAY down the road...but when we are ready to start making a
> > 'pretty' GUI client...
> >
> > Make it client/server!
>
>I was thinking about this as well and like it a lot.  I was having a
>non-trivial time compiling fltk so couldn't get the blockgui up on my
>Solaris box.  I got blockd up, though, but couldn't really communicate
>with it easily.  I would have loved to been able to fire the gui up on
>my NT box and connect it to the Solaris server.

I can punt you a Solaris binary at somepoint if you want. Unfortunately the 
code is in the middle of being mangled for
V0.15... and its quite a big change, so it doesnt work right now :)
Still looking good for early next week.

>
>Having the gui be able to talk to any server would be quite nifty.

Ah... the things that could have been if blockgui wasnt just
hacked together :)

But, it was intended to be a prototype after all.

ttfn
PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] Alternative to ActiveX: TCP/IP! ^_^

[<lu...@et...>]

* Spencer Jr., Michael wrote:
> This is for WAY down the road...but when we are ready to start making a
> 'pretty' GUI client...
> 
> Make it client/server!

I was thinking about this as well and like it a lot.  I was having a
non-trivial time compiling fltk so couldn't get the blockgui up on my
Solaris box.  I got blockd up, though, but couldn't really communicate
with it easily.  I would have loved to been able to fire the gui up on
my NT box and connect it to the Solaris server.

Having the gui be able to talk to any server would be quite nifty.

-Luke

[Blocks-development] Alternative to ActiveX: TCP/IP! ^_^

[Spencer Jr., M. <sp...@ac...>]

This is for WAY down the road...but when we are ready to start making a
'pretty' GUI client...

Make it client/server!

It can still be just as secure and transparent:  only accept connections
from localhost, start and stop the daemon transparently when the GUI starts
and stops, etc.

I have all sorts of evil ideas for a GUI:  'select assistance level' just
like IBM's great text interfaces (no, I'm serious...I admire IBM's text
interfaces), pretty graphs for complex networks...

the reason a good GUI will be necessary is because this web-of-trust thing
will live and die on the decisions of the keyholders.  If all the
top-level-key holders go and get in a fight and stop cooperating, or people
with lots of network trust start getting gullible or stupid, the
web-of-trust loses its meaning.  Maybe we can help them make good decisions
with a GUI that helps illustrate the affect of their actions.  (That
is...the GUI will only remind them of this when they select a non-expert
assistance level.)

And the 'basic' assistance level should be as simple, idiot-proof, and
Napster-like (interface-wise) as possible.  :)

--Michael Spencer
bl...@ms...

Re: [Blocks-development] Authenticaion, Ratings, WoT

[Blat F. <pet...@ho...>]

>From: "Benjamin M. Brewer" <br...@kr...>
>To: Blat Froop <pet...@ho...>
>CC: blo...@li...
>Subject: Re: [Blocks-development] Authenticaion, Ratings, WoT
>Date: Tue, 1 Aug 2000 13:49:32 -0400 (EDT)
>
>
>
>On Tue, 1 Aug 2000, Blat Froop wrote:
> > Remember Blocks currently has a hardcoded filename limit of ~85 
>characters.
>
>Why? Is this for any specific reason, or just coded that way?

The 'block' size os hardcoded to 64Kb like this...

typedef struct _block_struct
{
    unsigned char block_type; // 'D' => data, 'H' => header        unsigned 
char send_route[10];
    unsigned char return_route[10];
    unsigned char text[87]; // <==== filename
    unsigned char size[4]; // bigendian uint32 => num bytes in file
    unsigned char key[16]; // key to decrypt data blocks
    union _payload
    {
        unsigned char data[65408];
        unsigned char block_ids[4088][16];
    } payload;
} BLOCK;

Bigger filenames mean less data block IDs in the header blocks
playload... every eatr 16 bytes of filenames reduces the maximum
filesize by 64Kb.

A better design would probably involve having possibly multiple
header blocks allowing files of unlimited size. I have no plans
to change this right now tho.

>
> > Also, you want me to display the hash in the serach window... do
> > you want to see the full thing?... 32 chars is quite long for
> > human readers (and makes the listbox pretty wide).
>
>I'm thinking that once a user 'highlights' (clicks on...) one of the files
>in the search window, the hash value should be displayed in its own little
>'hashbox'.

or in the title bar or somewhere reasonably inconspicuous. If I used
a textbox it would be swipeable which is probably desirable :)

ttfn

PG.


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] Authenticaion, Ratings, WoT

[Benjamin M. B. <br...@kr...>]

On Tue, 1 Aug 2000, Blat Froop wrote:
> Remember Blocks currently has a hardcoded filename limit of ~85 characters.

Why? Is this for any specific reason, or just coded that way?

> Also, you want me to display the hash in the serach window... do
> you want to see the full thing?... 32 chars is quite long for
> human readers (and makes the listbox pretty wide).

I'm thinking that once a user 'highlights' (clicks on...) one of the files
in the search window, the hash value should be displayed in its own little
'hashbox'.

-Ben

[Blocks-development] Authenticaion, Ratings, WoT

[Blat F. <pet...@ho...>]

>From: "Spencer Jr., Michael" <sp...@ac...>
>To: 'Blat Froop' <pet...@ho...>, 
>blo...@li...
>Subject: RE: [Blocks-development] Doh!
>Date: Tue, 1 Aug 2000 10:40:50 -0500
>
>Quick summary:
>
>I want to start off by restating...I want this file verification stuff to
>have *minimal* impact on how the network functions.  Here at first, none of
>us are even sure a web-of-trust is even the right thing to do.
>However...all I need from the network right now is an identifying hash --
>I'm not asking anyone to code a web-of-trust without any proof that it'll
>work.  I'll make the web-of-trust myself, using command-line tools and
>uploading 'key material' files into the network.  Then once I get things
>figured out a bit, I'll write up procedures and we can all walk through 
>this
>web-of-trust by hand.  If and only if we all see how it works and we like
>it, we might add some code to the Blocks client to do the gpg stuff
>automatically.

This sounds like a promising approach.

>
>OK, here's how I *think* the file verificaton stuff would need to work:
>
>LAYER OF PROTOCOLS
>
>I think to get file verification information in a secure way, the system
>needs to be multi-layered...so the network protocol can stay as simple as
>possible, and all this extra stuff can be done by custom client code.  That
>is...I think the network layer (which I am NOT an expert in the design of)
>needs to stay as simple as possible, and as close to the existing design as
>possible.  If someone wants to run an old legacy client they should be able
>to...but they will see a bunch of strange files 'Blocks-filesig-XXXXXXXXXX'
>and 'Blocks-pubkey-XXXXXXXXXX' and all that.  And they won't be able to
>verify content automatically.

Remember Blocks currently has a hardcoded filename limit of ~85 characters.

>
>NETWORK LAYER
>
>The network layer should be almost completely unchanged, in my opinion.  I
>can see how we want to make content verification as simple as possible, and
>bundling verification data with the data files makes the search faster and
>easier.  BUT...I don't feel that we should bundle the verification data 
>with
>the files because for the system to be truly secure, *anyone* needs to be
>able to advertise data about *anyone else's* files.
>
>I do feel that we need to be able to have some kind of persistant hash of
>each file on the network.  I think Peter was OK with adding a few dozen or
>so extra bytes to the file adverts.  I think those bytes should contain a
>file hash which of the original data, not a hash of the encrypted data
>(which is different each time a file is uploaded).  I was talking before
>about block hashes and a separate hash of the block hashes...but that's 
>only
>needed if we need to face corrupted clients that send out false hashes.  We
>can do that stuff later.

How much hash do you want. 128bits is available but the current
advert mechanism encodes everything as hex (hey, it was easier
to debug :-) so it would add at least 32+1 chars to the advert
size... which is probably not significant.

Also, you want me to display the hash in the serach window... do
you want to see the full thing?... 32 chars is quite long for
human readers (and makes the listbox pretty wide).

>
>'CRYPTO' LAYER  -- A TRUSTED MESSAGE BOARD
>
>Remember that public-key crypto lets you publish trusted information in an
>untrusted space.  So if you have a known-good copy of Peter Gunn's public
>key, then Peter Gunn can make a statement, publish it on Blocks...you don't
>need a central server, and you don't need to care who you download it from.
>In all other cases, the content *could* be bogus because you don't know who
>you're downloading from...but because Peter Gunn signed his statement with
>his private key, you can verify the content with Peter Gunn's supposed
>public key and trust that the content really was said by him.  So if that
>statement-by-Peter-Gunn is an automatically-processed message saying
>"1.2.3.4 is a malicious client...do not connect there" you can completely
>trust that statement.
>
>On IRC last night, some of us had some very good ideas for
>content-protection things we could do with a central, trusted message board
>or server somewhere.  This public-key crypto lets you have that message
>board, but makes it fault-tolerant.  You can scatter the crypto stuff out 
>to
>the winds, and as long as you can search for it and find it when you need
>it, you can put it all together again and make a trusted message out of it.
>
>So I'm saying that centralization is bad -- we shouldn't really have a
>central server -- we should take those messages and turn them into crypto
>files and store them on the Blocks network.  But a message board is good --
>we had a lot of good ideas about what we could do if we had a central
>server.  What I'm saying is...if we use pub-key cryptography instead of a
>message board, all those cool ideas will still work.  And you can't sue or
>shut down a tree of crypto data...you can shut down or hack a single 
>server.
>
>VERIFICATION STUFF
>
>Once we have a trusted message board, we can post useful 'automated
>certificates' on it.  This is where my idea ends -- I just think that 
>Blocks
>can offer what no other network can offer right now, if it implements that
>shared message board stuff.  It's up to you guys what to do with the shared
>message board:  post human-readable comments perhaps, or just post 
>automatic
>certificates that the clients out there should use.  Some neat uses could
>be:  warnings about flooding clients or content, content spam-ratings,
>content usefulness-ratings, human-readable reviews and comments about
>content, etc.
>
>Everone else in IRC last night had better ideas about how to use this than 
>I
>did.  I'll leave this part to you guys.

I would also like to make sure that Blocks is useable without having
to rely on the WoT... since a significant number of people wont
really want to validate output all the time. Guess that just boils
down to another 'option', but I thought I'd say it anyways.

>
>BUT TO SUMMARIZE...
>
>Right now all I need to make this happen is content hashes.  I know 
>protocol
>changes are a bitch, but I propose a one-time change:  just lengthen the
>file advert data to include a bunch of bytes.  Compute a content hash
>(RIPE-MD128?) of the original file data, not the encrypted data, and 
>include
>it with the file advert.  Make the extra data twice as long, though, for a
>'reserved field'.  (Later on I'll make a convincing argument for the hash 
>of
>block-hashes...but since we're not likely to have to fight against bogus
>client programs for a while now, we can put this off.  Famous last words?
>:) )

Ok, I think I know how to add the content hash to the advert
in a backwardly compatible fashion, it will still take a little
fiddling though.

>
>So does this make sense?  I'd love to have questions to answer or 'devils
>advocate' scenarios to play with.

Im sure this discussion will go on for a while. Hopefully I can
get a new version of Blocks out next week sometime with half
a dozen of the suggested 'tweaks' in it.

ttfn

PG.

PS Sensible titles for the archive please :-)

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] Doh!

[Benjamin M. B. <br...@kr...>]

Nope. EFnet is a virtual free-for-all. It is known for two things:
1) Smart people in regard to computers
2) DoS kiddies in the 'hacker' channels

We shouldn't have a problem, because no one is trying to prove anything,
unlike those in the 'hacker' channels.

-Ben

P.S. Undernet has channel-service features in the sense of two 'bots' X &
W. They work excellent when they are working - they have levels of
access/control, suspend commands, etc.

On Tue, 1 Aug 2000, Erik Moeller wrote:

> On 1 Aug 2000, at 1:39, Blat Froop wrote:
> 
> > 6) IRC
> > 
> >    As long as Flaggovic hold #blocks open on DALNet I'll
> >    keep it listed. I may change the order to list EFNet first
> >    if its more popular.
> 
> I just held it in case someone stopped by there first to redirect 
> them to EFNet. The EFNet channel should be the only one listed on 
> the homepage. There should be no availability problems since IRC is
> distributed.
> 
> Is someone else IRC-experienced enough to tell me whether EFNet has
> ChanServs and NickServs? If they do, we don't need the bot.
> 
> Regards,
> Erik Moeller
> -- 
> Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
> Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
> The Origins of Peace and Violence: <http://www.violence.de>
> Please donate free food NOW: <http://www.thehungersite.com>
> 
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development
> 

RE: [Blocks-development] Doh!

[Spencer Jr., M. <sp...@ac...>]

Quick summary:

I want to start off by restating...I want this file verification stuff to
have *minimal* impact on how the network functions.  Here at first, none of
us are even sure a web-of-trust is even the right thing to do.
However...all I need from the network right now is an identifying hash --
I'm not asking anyone to code a web-of-trust without any proof that it'll
work.  I'll make the web-of-trust myself, using command-line tools and
uploading 'key material' files into the network.  Then once I get things
figured out a bit, I'll write up procedures and we can all walk through this
web-of-trust by hand.  If and only if we all see how it works and we like
it, we might add some code to the Blocks client to do the gpg stuff
automatically.

OK, here's how I *think* the file verificaton stuff would need to work:

LAYER OF PROTOCOLS

I think to get file verification information in a secure way, the system
needs to be multi-layered...so the network protocol can stay as simple as
possible, and all this extra stuff can be done by custom client code.  That
is...I think the network layer (which I am NOT an expert in the design of)
needs to stay as simple as possible, and as close to the existing design as
possible.  If someone wants to run an old legacy client they should be able
to...but they will see a bunch of strange files 'Blocks-filesig-XXXXXXXXXX'
and 'Blocks-pubkey-XXXXXXXXXX' and all that.  And they won't be able to
verify content automatically.

NETWORK LAYER

The network layer should be almost completely unchanged, in my opinion.  I
can see how we want to make content verification as simple as possible, and
bundling verification data with the data files makes the search faster and
easier.  BUT...I don't feel that we should bundle the verification data with
the files because for the system to be truly secure, *anyone* needs to be
able to advertise data about *anyone else's* files.

I do feel that we need to be able to have some kind of persistant hash of
each file on the network.  I think Peter was OK with adding a few dozen or
so extra bytes to the file adverts.  I think those bytes should contain a
file hash which of the original data, not a hash of the encrypted data
(which is different each time a file is uploaded).  I was talking before
about block hashes and a separate hash of the block hashes...but that's only
needed if we need to face corrupted clients that send out false hashes.  We
can do that stuff later.

'CRYPTO' LAYER  -- A TRUSTED MESSAGE BOARD

Remember that public-key crypto lets you publish trusted information in an
untrusted space.  So if you have a known-good copy of Peter Gunn's public
key, then Peter Gunn can make a statement, publish it on Blocks...you don't
need a central server, and you don't need to care who you download it from.
In all other cases, the content *could* be bogus because you don't know who
you're downloading from...but because Peter Gunn signed his statement with
his private key, you can verify the content with Peter Gunn's supposed
public key and trust that the content really was said by him.  So if that
statement-by-Peter-Gunn is an automatically-processed message saying
"1.2.3.4 is a malicious client...do not connect there" you can completely
trust that statement.

On IRC last night, some of us had some very good ideas for
content-protection things we could do with a central, trusted message board
or server somewhere.  This public-key crypto lets you have that message
board, but makes it fault-tolerant.  You can scatter the crypto stuff out to
the winds, and as long as you can search for it and find it when you need
it, you can put it all together again and make a trusted message out of it.

So I'm saying that centralization is bad -- we shouldn't really have a
central server -- we should take those messages and turn them into crypto
files and store them on the Blocks network.  But a message board is good --
we had a lot of good ideas about what we could do if we had a central
server.  What I'm saying is...if we use pub-key cryptography instead of a
message board, all those cool ideas will still work.  And you can't sue or
shut down a tree of crypto data...you can shut down or hack a single server.

VERIFICATION STUFF

Once we have a trusted message board, we can post useful 'automated
certificates' on it.  This is where my idea ends -- I just think that Blocks
can offer what no other network can offer right now, if it implements that
shared message board stuff.  It's up to you guys what to do with the shared
message board:  post human-readable comments perhaps, or just post automatic
certificates that the clients out there should use.  Some neat uses could
be:  warnings about flooding clients or content, content spam-ratings,
content usefulness-ratings, human-readable reviews and comments about
content, etc.

Everone else in IRC last night had better ideas about how to use this than I
did.  I'll leave this part to you guys.

BUT TO SUMMARIZE...

Right now all I need to make this happen is content hashes.  I know protocol
changes are a bitch, but I propose a one-time change:  just lengthen the
file advert data to include a bunch of bytes.  Compute a content hash
(RIPE-MD128?) of the original file data, not the encrypted data, and include
it with the file advert.  Make the extra data twice as long, though, for a
'reserved field'.  (Later on I'll make a convincing argument for the hash of
block-hashes...but since we're not likely to have to fight against bogus
client programs for a while now, we can put this off.  Famous last words?
:) )

So does this make sense?  I'd love to have questions to answer or 'devils
advocate' scenarios to play with.

--Michael Spencer
bl...@ms...


-----Original Message-----
From: Blat Froop [mailto:pet...@ho...]
Sent: Tuesday, August 01, 2000 8:41 AM
To: blo...@li...
Subject: Re: [Blocks-development] Doh!


>From: "Benjamin M. Brewer" <br...@kr...>
>To: Blat Froop <pet...@ho...>
>CC: blo...@li...
>Subject: Re: [Blocks-development] Doh!
>Date: Mon, 31 Jul 2000 22:01:21 -0400 (EDT)
>
>Comment are below in the 'correct sections'.
>
>On Tue, 1 Aug 2000, Blat Froop wrote:
>
> > Hi,
> >
> > well I thought it was getting a bit quieter on the email front...
> > I didnt realise that I actually had to *join* the mailing list
> > after I set it up! But Im here now :-)
> >
> > Ive had a quick look through the archive and heres some brief
> > comments :-
> >
> > 1) We need that ability to upload multiple files.
> >
> >     Agreed. I also need to fix the problem that everything stops
> >     while a file is uploaded. Another possibility is a(possibly
> > command line based) injection tool for injecting content into
> >     servers.
> >
>Perhaps if there was a simple 'upload' directory within the blocks
>dir? You could just mv/cp files into the directory at one time, and then
>hit a button within the blocksgui to READ that upload dir to see if any
>files were in there?

More likely I'll try and add a 'choose directory to upload' menuitem until I

can get around to building an upload widget.

>
> > 2) Sticky local files.
> >
> >    Seems so obvious I wonder why I never thought of it. I dont
> >    want to have too much complexity on the cache maintenance side
> >    if I can avoid it, but adding a sticky bit is a possibility.
> >
> > 3) Should we readvertise proxied files?
> >
> >    Well it does at the moment. If you switch off 'readvertise files'
> >    people cant connect and browse your cache anyway. 'Deniablilty'
> >    is always there since you didnt upload these files anyway...
> >    its the same problem if you were to run a public HTTP Proxy
> >    (Squid or whatever). Routes do get 'unadvertised' when a
> >    connection is broken so content may become inaccssible.
> >    I could add another option covering this but would it really be
> >    useful?
>
>Yes. Although this system is NOT designed for the modem users, they will
>obviously become interested in the protocol / application, so they can get
>their mp3 'fix'. :)  We should _not_ leave them out, even though their
>usage of the network may not be desirable on their end.

Hmmm... dunno modemers simply dont have the bandwidth for
to broadcast file advertisements, and all the joining and
disconnecting creates a lot of routing traffic.

>
> > 4) Authentication and Ratings
> >
> >    Im quite interested in crypto, and a rating system is an
> >    interesting idea. However, I dont want to increase the size
> >    of File Adverts by including public keys, descriptions, and
> >    so on. Now, if there were a seperate system (maybe even
> >    web based) that Blocks could access information from
> >    using the file ID (hash sent with ad) that would be a very
> >    different story. Another possible future option would be
> >    to seperate out the server code and build something like
> >    a library (maybe even ActiveX control) to allow much more
> >    complex custom front ends (you might have noticed they
> >    arent really my speciality) that allow extended functionality.
>
>Idea! I was just playing with gnoRPM (A gnome frontend to the RPM package
>format) and I liked how it worked. When you clicked on a file, and quickly
>connected to that location and downloaded information about the file in
>question. Blocknet could do the same thing. This request for information
>would only be sent to the sender of the file, and since the sender will
>get 'connected to' anyways to download the file, we are not losing any
>privacy that we currently have.
>
>Have it so you highlight a file in the search list, and then hit the 'more
>info' button, or something similar, and THEN the varifying information can
>be sent - per request.

How much information (in bytes) do you estimate would be required
as a minimum to be associated with File Adverts to add public keys
and whatever else would be needed?

There is the option of having a second block of descriptive info.

I still have to get my head around how these things would work.

>
> > 5) Logos
> >
> >    The 2 Logos on the web page are the winners. These are now
> >    the Blocks logos for the foreseeable future.
>
>Not sure if you noticed the colorized version of the 'other logo' (the one
>that isn't mine...), it is much better, and if you wish, I can add that
>one instead...

Done.

>
> > 6) IRC
> >
> >    As long as Flaggovic hold #blocks open on DALNet I'll
> >    keep it listed. I may change the order to list EFNet first
> >    if its more popular.
> >
>
>DALNet is crap =\ I think it should mainly be based on EFnet, but that's
>just personal opinion.

DALNEt is dead, long live EFNet.

>
>PS, did you get those linux-binaries?

On new page!

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

[Blocks-development] other similar 'sharing' systems

[Paul K. <pa...@nk...>]

http://www.mojonation.net/

This looks to work on a similar level. I thought it would be worth
mentioning since it's gone into 'beta' today. 

It doesn't appear to have the same sort of allowances for anonymity, but the
concept to avoid "the tragedy of the commons" seems to be a valid concept.
Obviously it doesn't fit in with blocks, but some of the resource sharing
ideas I like, and in fact, thought blocks itself did to an extent.

I don't like the "8 chunks" idea that they use, as it seems to be awfully
limiting. Large files would make for really large chunks.

The one thing that I thought to be interesting is the specialized
applications idea. Not every host on the network serves content the same
way. Some serve it directly, some serve the metadata and some just act to
relay it. Maybe this is an idea we could explore more.

I'll be thinking about it today and see if I can come up with anything
useful for discussion later or on irc.

--
Paul Kalupnieks - atomicDee - payl  | "George Clinton and Kraftwerk stuck 
 html developer - NKaos Interactive |     in an elevator with only a  
  & linux nerd  - pa...@nk...   |   sequencer to keep them company."
        p: 416.504.8931 x.224

Re: [Blocks-development] Doh!

[Blat F. <pet...@ho...>]

>From: "Benjamin M. Brewer" <br...@kr...>
>To: Blat Froop <pet...@ho...>
>CC: blo...@li...
>Subject: Re: [Blocks-development] Doh!
>Date: Mon, 31 Jul 2000 22:01:21 -0400 (EDT)
>
>Comment are below in the 'correct sections'.
>
>On Tue, 1 Aug 2000, Blat Froop wrote:
>
> > Hi,
> >
> > well I thought it was getting a bit quieter on the email front...
> > I didnt realise that I actually had to *join* the mailing list
> > after I set it up! But Im here now :-)
> >
> > Ive had a quick look through the archive and heres some brief
> > comments :-
> >
> > 1) We need that ability to upload multiple files.
> >
> >     Agreed. I also need to fix the problem that everything stops
> >     while a file is uploaded. Another possibility is a(possibly
> > command line based) injection tool for injecting content into
> >     servers.
> >
>Perhaps if there was a simple 'upload' directory within the blocks
>dir? You could just mv/cp files into the directory at one time, and then
>hit a button within the blocksgui to READ that upload dir to see if any
>files were in there?

More likely I'll try and add a 'choose directory to upload' menuitem until I 
can get around to building an upload widget.

>
> > 2) Sticky local files.
> >
> >    Seems so obvious I wonder why I never thought of it. I dont
> >    want to have too much complexity on the cache maintenance side
> >    if I can avoid it, but adding a sticky bit is a possibility.
> >
> > 3) Should we readvertise proxied files?
> >
> >    Well it does at the moment. If you switch off 'readvertise files'
> >    people cant connect and browse your cache anyway. 'Deniablilty'
> >    is always there since you didnt upload these files anyway...
> >    its the same problem if you were to run a public HTTP Proxy
> >    (Squid or whatever). Routes do get 'unadvertised' when a
> >    connection is broken so content may become inaccssible.
> >    I could add another option covering this but would it really be
> >    useful?
>
>Yes. Although this system is NOT designed for the modem users, they will
>obviously become interested in the protocol / application, so they can get
>their mp3 'fix'. :)  We should _not_ leave them out, even though their
>usage of the network may not be desirable on their end.

Hmmm... dunno modemers simply dont have the bandwidth for
to broadcast file advertisements, and all the joining and
disconnecting creates a lot of routing traffic.

>
> > 4) Authentication and Ratings
> >
> >    Im quite interested in crypto, and a rating system is an
> >    interesting idea. However, I dont want to increase the size
> >    of File Adverts by including public keys, descriptions, and
> >    so on. Now, if there were a seperate system (maybe even
> >    web based) that Blocks could access information from
> >    using the file ID (hash sent with ad) that would be a very
> >    different story. Another possible future option would be
> >    to seperate out the server code and build something like
> >    a library (maybe even ActiveX control) to allow much more
> >    complex custom front ends (you might have noticed they
> >    arent really my speciality) that allow extended functionality.
>
>Idea! I was just playing with gnoRPM (A gnome frontend to the RPM package
>format) and I liked how it worked. When you clicked on a file, and quickly
>connected to that location and downloaded information about the file in
>question. Blocknet could do the same thing. This request for information
>would only be sent to the sender of the file, and since the sender will
>get 'connected to' anyways to download the file, we are not losing any
>privacy that we currently have.
>
>Have it so you highlight a file in the search list, and then hit the 'more
>info' button, or something similar, and THEN the varifying information can
>be sent - per request.

How much information (in bytes) do you estimate would be required
as a minimum to be associated with File Adverts to add public keys
and whatever else would be needed?

There is the option of having a second block of descriptive info.

I still have to get my head around how these things would work.

>
> > 5) Logos
> >
> >    The 2 Logos on the web page are the winners. These are now
> >    the Blocks logos for the foreseeable future.
>
>Not sure if you noticed the colorized version of the 'other logo' (the one
>that isn't mine...), it is much better, and if you wish, I can add that
>one instead...

Done.

>
> > 6) IRC
> >
> >    As long as Flaggovic hold #blocks open on DALNet I'll
> >    keep it listed. I may change the order to list EFNet first
> >    if its more popular.
> >
>
>DALNet is crap =\ I think it should mainly be based on EFnet, but that's
>just personal opinion.

DALNEt is dead, long live EFNet.

>
>PS, did you get those linux-binaries?

On new page!

ttfn

PG.

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

RE: [Blocks-development] (no subject)

[Spencer Jr., M. <sp...@ac...>]

Oops, sorry...

I guess I was just afraid of letting something slip about this being only
useful for piracy, and then seeing that part and nothing else quoted out of
context in a news article.  And when it comes to high-tech, we know some of
those media guys can be pretty clueless, grasping for single statements
instead of understanding the whole, and publishing anything people will
read.

So disregard all that.  But it's good to know someone's reading my longish
posts.

BTW, I got a helpful hint about how I should start structuring my longish
emails from now on.  So expect my explanations to be easier to read from now
on. :)

--Michael Spencer
bl...@ms...

-----Original Message-----
From: Erik Moeller [mailto:mo...@sc...]
Sent: Tuesday, August 01, 2000 8:19 AM
To: blo...@li...
Subject: Re: [Blocks-development] (no subject)


On 31 Jul 2000, at 11:45, Spencer Jr., Michael wrote:

> (Just in case this project becomes famous later down the road...if you
> are press or media viewing mailing list archives, these comments are
> owned by me and I do *not* license anyone to snip bits and pieces of
> this post, looking for things to quote out of context. 

Actually, AFAIK, you cannot stop anyone from quoting you and snipping 
bits and pieces out of your posts. Reasonable amounts of quoting 
should be unquestionably covered by the fair use doctrine.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

Re: [Blocks-development] (no subject)

[Erik M. <mo...@sc...>]

On 31 Jul 2000, at 11:45, Spencer Jr., Michael wrote:

> (Just in case this project becomes famous later down the road...if you
> are press or media viewing mailing list archives, these comments are
> owned by me and I do *not* license anyone to snip bits and pieces of
> this post, looking for things to quote out of context. 

Actually, AFAIK, you cannot stop anyone from quoting you and snipping 
bits and pieces out of your posts. Reasonable amounts of quoting 
should be unquestionably covered by the fair use doctrine.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

Re: [Blocks-development] Doh!

[Erik M. <mo...@sc...>]

On 1 Aug 2000, at 1:39, Blat Froop wrote:

> 6) IRC
> 
>    As long as Flaggovic hold #blocks open on DALNet I'll
>    keep it listed. I may change the order to list EFNet first
>    if its more popular.

I just held it in case someone stopped by there first to redirect 
them to EFNet. The EFNet channel should be the only one listed on 
the homepage. There should be no availability problems since IRC is
distributed.

Is someone else IRC-experienced enough to tell me whether EFNet has
ChanServs and NickServs? If they do, we don't need the bot.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>