Send Freenet-dev mailing list submissions to
freenet-dev at lists.sourceforge.net
To subscribe or unsubscribe via the web, visit
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
or, via email, send a message with subject or body 'help' to
freenet-dev-request at lists.sourceforge.net
You can reach the person managing the list at
freenet-dev-admin at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Freenet-dev digest..."
Today's Topics:
1. Re: Cipher change (hal at finney.org)
2. Re: KHK Metadata Proposal (Brandon)
3. Re: Promoting metadata (was: Meaningless hits) (Brandon)
4. Re: Promoting metadata (Brandon)
5. Re: Suggestion for ease of use.. (Fredrik Hubinette)
6. Re: Meaningless hits on metadata (Brandon)
7. Re: 0.3 Todo List (Brandon)
8. Re: Suggestion for ease of use.. (Brandon)
9. RE: 0.3 Todo List (Benjamin Coates)
10. Re: Promoting metadata (Carsten Svaneborg)
11. Re: Promoting metadata (Daniel Phillips)
12. Key index system over Freenet Was: Re: 0.3 Todo List (Travis Bemann)
13. Re: 0.3 Todo List (Travis Bemann)
14. Re: Promoting metadata (Daniel Phillips)
15. Re: Meaningless hits on metadata (Daniel Phillips)
16. Re: Promoting metadata (Scott Gregory Miller)
17. Re: Meaningless hits on metadata (Ian Clarke)
18. Re: Promoting metadata (Henry Hemming)
19. Re: Promoting metadata (was: Meaningless hits) (Travis Bemann)
--__--__--
Message: 1
From: [email protected]
Date: Tue, 27 Jun 2000 00:07:40 -0700
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Cipher change
Reply-To: freenet-dev at lists.sourceforge.net
Scott writes:
> I'd like to switch the default cipher in the devel server to
> Rijndael. Honestly, this is purely for efficiency reasons. Twofish and
> Rijndael perform very well... when implemented in C or assembly. However,
> Twofish has a large table it does very frequent lookups on. While this
> table should fit into the processor cache, for some reason the java memory
> access characteristics are negating this. For this reason, Rijndael is
> outperforming Twofish by a factor of 2.6. =20
> Since we aren't really nailing this down yet anyway (due to NIST not
> being done selecting an algorithm), and because I trust both ciphers, I'd
> like to go ahead and move to Rijndael so we can coax some extra speed on
> transfers.
I don't have any problem with Rijndael; as I wrote before there seems
to be a sense that it may have a very slight edge over the others as
a candidate for being selected as the AES cipher, although Twofish is
certainly popular as well.
Are we stuck with the fact that compatibility will break again once we
switch to AES (assuming we aren't lucky enough already to be using the
AES cipher at that time)? I'm not sure when the choice will be announced,
maybe 2-3 months from now?
Hal
--__--__--
Message: 2
Date: Tue, 27 Jun 2000 02:41:50 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK Metadata Proposal
Reply-To: freenet-dev at lists.sourceforge.net
> Amen. We have the advantage of not working under the pressure of a
> marketing department and adminstration pressing us for
> features and deadlines - lets not let the attention we have gained be
> that for us. We do this at the rate it comes to us - our only
> requirement that we do not compromise the goals of this project.
I feel that I have miscommunicated my intentions. I don't expect your and
Scott to stop working on what you're doing and start fixing up the
installation scripts and the GUI. Let me try a rephrasing.
I'm going to put together a new release which fixes some of the usability
problems in the current release. I'm going to make an easier installation
(maybe bundle the JRE) put in an icon to launch the GUI. Let me know if
there's anything which you feel it would be useful to merge into the
stable code now, like maybe the encryption so that the developer and user
releases can be compatible again. But if it's too much trouble or is going
to change again then don't worry about it.
Also, if anyone wants to volunteer to do some of this, let me know.
--__--__--
Message: 3
Date: Tue, 27 Jun 2000 02:48:51 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata (was: Meaningless hits)
Reply-To: freenet-dev at lists.sourceforge.net
> Did I make any invalid assumptions here? If not, this seems to me to be a
> robust and efficient way of handling metadata promotion.
This was very well reasoned and you understand the issues involved and
your proposal makes sense. I can't say whether it's overall a good idea or
a bad idea. It's pretty tough to judge. I can point out some things which
might be problematic. There is of course request flooding to promote
metadata to keep it around, make it more visible, or knock other things
out. This problem exists with data, too. But with data it consumes
resources in order to do a request (you have to download the file). Kind
of. You could perhaps just close the connection and open up a new
one. This would be pretty easy to detect as non-legitimate use,
however. With your metadata scheme, there is almost no resource usage to
flood (you just have to send the message).
But how difficult it is to flood data and what we're going to do about it
in general is still a very open question. So I don't know if we should do
this or not. But it's certainly an option.
--__--__--
Message: 4
Date: Tue, 27 Jun 2000 02:53:11 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
Reply-To: freenet-dev at lists.sourceforge.net
> Scanning through the (many) postings on metadata, it seems to me that metadata
> has keys, and that these keys can be used in the normal Freenet way. In fact,
> it would require extra work to make an exception. So simply returning the key
> shouldn't be a lot of trouble.
A single piece of metadata will have one or more keys. So if you get one
key, the metadata indexed under the other keys won't get promoted. Which
might be okay, actually. But we're not sure yet it it will have one or if
it will have more, as of yet.
--__--__--
Message: 5
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Suggestion for ease of use..
From: Fredrik Hubinette <[email protected]>
Date: 27 Jun 2000 00:56:30 -0700
Reply-To: freenet-dev at lists.sourceforge.net
"Scott G. Miller" <scgmille at indiana.edu> writes:
> > Even if you do run your own node, you will need to find a point of
> > contact, otherwise your freenet network will be somewhat limited.. :)
> > Having the freenet node look for freenet.yourdomain:19114 might
> > be a step towards eliminating 'inform.php'.
> Yes, this falls under the general unsolved problem of "Node
> discovery". Though I agree with whoever said that this was a bad idea
> because it makes it very easy to find freenet servers (ie, Big Brother
> just tries to connect to freenet.* in every domain, then sends goons)
Well, obviously freenet.yourdomain would not make up *all* nodes.
I beleive that if the system can be shut down just by knowing about the
nodes, then the system is not 'strong' enough. And since any malicious
node can find out about a fair amount of nodes anyways, I don't see
any real differance. Security by obscurity is rarely a good idea. IMHO.
> > > Obviously the end user has to find another freenet node *somehow*,
> > and relying on word-of-mouth only sounds awkward..
> Akward but effective, and very simplistically secure. I agree, we need
> another method.
Secure? You can still portscan, or if you know of *one* node, you can find
out about more nodes... I also beleive that promoting secrecy and security
by obscurity is a big mistake as it will make freenet just that: obscure...
Essentially, by making it a secret we're saying that anonymity is a bad
thing and we shouldn't *really* run nodes, but we do it secretly anyways.
This will definitely attract mp3-swappers, warez 3LI73 and other shady
characters, which will give Big Brother more public support for shutting
it down.
Somebody else suggested that the location of a node can be encoded into
a web page by the person running the node, this sounds like a pretty good
idea to me, but it has the same sort of problem as freenet.yourdomain as
Big Brother could just ask a search engine to find the freenet nodes...
As long as the 'public' nodes are just the tip of the ice berg, I think
'public' nodes is a good idea.
/Hubbe
PS: sorry about dragging it out... :)
--__--__--
Message: 6
Date: Tue, 27 Jun 2000 03:01:01 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Reply-To: freenet-dev at lists.sourceforge.net
> Yes, we can encrypt if we only allow exact matches. However, I wanted fuzzy
> matching,
I here ya. That would be damn cool. I'm not sure if it's worth it though,
since we'd have to leave everything in plaintext. Difficult
tradeoffs.
--__--__--
Message: 7
Date: Tue, 27 Jun 2000 03:02:30 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
> It's just a client feature - sorry for being vague.
>
> Then they post a key to the keyinform server under the name
> "Metadata:Title=Foo,Author=Fred,KHK=text/foo". Then clients could include
> a preliminary search feature, by simply downloading the key lists from the
> key servers, and searching through them for Metadata.
Cool. Seems like quite a bit of work for something we're going to throw
out later. But if you're volunteering... :-)
--__--__--
Message: 8
Date: Tue, 27 Jun 2000 03:07:33 -0500 (CDT)
From: Brandon <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Suggestion for ease of use..
Reply-To: freenet-dev at lists.sourceforge.net
> As long as the 'public' nodes are just the tip of the ice berg, I think
> 'public' nodes is a good idea.
Ah, yes, of course, you were talking about public nodes. A whole different
issue. Yes, public nodes should use port 19114 and be on
freenet.blah.com. A very good idea.
--__--__--
Message: 9
Date: Tue, 27 Jun 2000 05:13:18 -0400
From: Benjamin Coates <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: RE: [Freenet-dev] 0.3 Todo List
Reply-To: freenet-dev at lists.sourceforge.net
> From Brandon <blanu at uts.cc.utexas.edu>
>> Then they post a key to the keyinform server under the name
>> "Metadata:Title=Foo,Author=Fred,KHK=text/foo". Then clients could include
>> a preliminary search feature, by simply downloading the key lists from the
>> key servers, and searching through them for Metadata.
> Cool. Seems like quite a bit of work for something we're going to throw
> out later. But if you're volunteering... :-)
Is there any reason we shouldn't modify the keyservers to run over Freenet
itself? I mean, once updates are working (how many times has that phrase come
up?)
--
Benjamin Coates
--__--__--
Message: 10
Date: Tue, 27 Jun 2000 14:00:06 +0200 (CEST)
From: Carsten Svaneborg <[email protected]>
Subject: Re: [Freenet-dev] Promoting metadata
To: freenet-dev at lists.sourceforge.net
Reply-To: freenet-dev at lists.sourceforge.net
> A single piece of metadata will have one or more keys. So if you get one
> key, the metadata indexed under the other keys won't get promoted.
I'm not sure I understand the problem. But as nobody knows what will
actually be posted on the freenet, and thus what is needed to execute
a search for some particular data. It seems that inventing a metalanguage
for describing metadata is appropiate. Especially since pretty much any
search you do on the gnutella net drags up loads of unwanted stuff.
If the freenet has to be an effective way of distributing data, then an
effective context sensitive search method would be required.
One could do this in XML. Where appropiate DTD's could be defined for
describing different types of medias.
Say Mp3:
<metadata>
<composer>..</composer>
<composeryear>..</composeryear>
<mucisian>..</mucision>
<band>..</band>
<titleofcd>..</titleofcd>
<track>..</track>
<description>....</description>
:
</metadata>
Only some of these will make sense for a particular MP3 file. But if
a DTD for mp3 metadata is defined, and enough nodes in the network
knows about it, then one could make a search on "Bach music after 1700
played by Glenn Gould", and only receive the relevant hits, and this
would be an enormous benefit compared to searching the internet or
gnutella net.
Other DTD's would be required for books, programs, games, pictures,
videos, webpages, animations, movies, and whatever medias we have
yet to invent.
This also means that every node would know a certain number of DTD's,
in order for it to return query data. And they would require some
fallback scheme for DTD's that was unknown, and they could be a
simple keyword search through all the meta data.
--
Carsten Svaneborg
--__--__--
Message: 11
From: Daniel Phillips <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
Date: Tue, 27 Jun 2000 14:12:44 +0200
Reply-To: freenet-dev at lists.sourceforge.net
On Tue, 27 Jun 2000, Scott G. Miller wrote:
> > That happens normally on the net - it's another problem. This case is
> > helped
> > quite a lot by the method I suggested: when a data request fails, the
> > metadata
> > is not promoted and eventually expires. You could go further and demote the
> > metadata after a search fails, but that really would open up the
> > possibility of
> > a evil server doing significant damage.
>
> I agree. Thats the part about your thoughts that I do like. Metadata
> really shouldn't be promoted as a result of a search unless thats what the
> user selected. However, there are some technical difficulties with making
> that the case, both with routing and security.
There were four methods suggested for routing the promote message:
1) Rerun the search
2) Find the metadata by its metadata key
3) Store routing information in the metadata returned from the search
4) Record routing information along the path taken by metadata returned from the
search.
Originally I favored (2) but now I think (4) is better. I'll list the main
disadvantages of the first three.
1 - Re-running the search is expensive, doubling the cost of an already
expensive operation. It's not clear how you would prune the search to reduce
the cost. It's going to be tricky to implement and highly dependent on the
details of how the search is implemented.
2 - Finding the metadata by its metadata key requires that the metadata key be
publicly known, making it easier for a censor to localize metadata. Until the
network optimizes itself, considerable backtracking will occur.
3 - Appending the routing information to the search result would bulk up the
message and give away the precise location of the metatdata to every node along
the route.
Now a more detailed analysis of (4).
Each search result would carry a UniqueID. When a search result message passes
through a node the node remembers remembers a signpost consisting of the
UniqueID and the neighboring node the message came from. When the originating
node decides to promote the metadata (because the client followed up with a
request for the underlying data) the promote message is able to retrace the
route easily by following the signposts. The signposts all expire after a time
that depends on the depth of the search result at each node.
This method is the most efficient of the four since the absolute minimum number
of messages is required. The processing demands on intermediate nodes are also
trivial. In fact, this is almost identical to the way a Send.Data message is
routed., except for the requirement to expire the signposts.
This method is also the most secure because routing information is known only
locally, by each node. The originating node and the client learn nothing about
the location of the metadata. It is not even necessary to identify which piece
of metadata is being promoted.
It is not hard to add effective encryption to this message traffic, but this
post is already long enough...
Questions about the self-organization of metadata remain to be answered. Should
metadata migrate and/or replicate towards the searcher, the requestor, or both?
--
Daniel
--__--__--
Message: 12
Date: Tue, 27 Jun 2000 08:30:34 -0400
From: Travis Bemann <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: [Freenet-dev] Key index system over Freenet Was: Re: 0.3 Todo List
protocol="application/pgp-signature"; boundary="tsOsTdHNUZQcU9Ye"
Reply-To: freenet-dev at lists.sourceforge.net
--tsOsTdHNUZQcU9Ye
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 27, 2000 at 03:02:30AM -0500, Brandon wrote:
>=20
> > It's just a client feature - sorry for being vague.
> >=20
> > Then they post a key to the keyinform server under the name
> > "Metadata:Title=3DFoo,Author=3DFred,KHK=3Dtext/foo". Then clients could=
include
> > a preliminary search feature, by simply downloading the key lists from =
the
> > key servers, and searching through them for Metadata.
>=20
> Cool. Seems like quite a bit of work for something we're going to throw
> out later. But if you're volunteering... :-)
Actually, I am currently working on a key index system that runs over
Freenet in its current form. This is, of course, going to be disposed
for when searching appears in a stable release of Freenet, but it
would be useful at this point. To cater to all the newbies which are
probably pouring onto Freenet at this point, I'm going to right a
Freenet index Tkinter-based client in addition to a command line
Freenet index client. The Freenet index system which I'm writing
*does* have updating, but it is not secure, but luckily one can set an
index item so that it cannot be updated.
--=20
Travis Bemann
Sendmail is still screwed up on my box.
My email address is really bemann at execpc.com.
--tsOsTdHNUZQcU9Ye
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org
owFVVD2P3EQYvktEs5KFItFQ8eqaUyLbrO6EgIW9cJcECKcTQlmhdGhsv7s7OXvG
zMf6liYtFaKkCoKSij+AhCBFJH4BEqJDSNClouR57V2Oa1az45nneZ8P+8vk+u61
G6uP/nhaf/z9F7u//BV23nz45NEdawKbkM3WLU8o8EV4ta2VNm9RuVTOc5hGnylf
ap2Mtmfvat9ar4O2ZkLa1Nrw5cOZU8bP2WX3TGkrbRYT+jTawFXWOm2CKmocTkYf
GppFTumDaOjg9ZQOxuMxqUDjw8n4YHI4Pj6jbPzaeJzSCQAra6hzQJkko6PpwRi/
dET3w76nR9EHUlTWGuw0ZxWiY8rIW+fWNLeOCsYUtFKLyHl/8T+A2ZINhSWvCXoE
5RzLYGVLltrgekOe3YodRVPhVx4Z1fAAsHfGQVUqqMlMh5qnh3fftTY9jmFpnfxx
XKWn759i2Ts7t3YvH1iHeT2VNtbVNBnBx7KO1QZXUeu41o02CiI8K1cut9pSKrCl
m7ZeU2U7U1slNm+Hplp74M6dbQi42B0g5dGgxKcERzeow01n42IpCE3v2FZVfun2
HWvrnB4wNx4M54xQdWAMWuhAdk6ddef9XW8bDj1sx/tIYmF7CtuzdAJlY6BaBXY5
nWCp57S2UY6ubB1RIkZPFnme0yS7KVU5LkNUdb1O6T6phsroHKyDeuEUcJRjiE4j
ogvyax8gJCxRJxeNJwvRyQhhsGHwGdJi/AAjMzc5IRTtScMaaEEmaH56OXrBVPWd
5yoZichOIrw0ULUt1l6gFfm+44T8WHkWvA0zghO5IRl1ErqgRs/zWEvvg/C3IAwy
jKVSDBJuKB9Kx12h2YNaowvKIdbW2QJc0t7oBiNwYavzCii8228uBTm9WP74Hc78
3xbxbgZDQZwVGL3avlQiq6r6972fCAY1jVRoePOvIgx3ekeZrj7aBDMokHk6B1Cz
SEa3Ksv+Fi3VCp60qB52t3YhFTI2wO5yaL/UJ5bnGsKtYTglUUCLSUYDjxYWb4cG
AAAnBKDYYHOVS62yrK82vlcrMJwwFAHhAZuqUboWVh80zPel4w5mxFaK1qypsBcA
OFsT9wdhjWMv5UHm0lMQCdY7fMFlW+YwK//89vUXduVzu/3+3rj24ks7T9KjZ3tn
n73928+/T39Vt5/zG/oru/P16bff/PneP/sPX5n+9Lj6+/kPLz999sm/
=RV5Y
-----END PGP SIGNATURE-----
--tsOsTdHNUZQcU9Ye--
--__--__--
Message: 13
Date: Tue, 27 Jun 2000 08:33:21 -0400
From: Travis Bemann <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] 0.3 Todo List
protocol="application/pgp-signature"; boundary="FsscpQKzF/jJk6ya"
Reply-To: freenet-dev at lists.sourceforge.net
--FsscpQKzF/jJk6ya
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 27, 2000 at 05:13:18AM -0400, Benjamin Coates wrote:
> > From Brandon <blanu at uts.cc.utexas.edu>
>=20
> >> Then they post a key to the keyinform server under the name
> >> "Metadata:Title=3DFoo,Author=3DFred,KHK=3Dtext/foo". Then clients coul=
d include
> >> a preliminary search feature, by simply downloading the key lists from=
the
> >> key servers, and searching through them for Metadata.
>=20
> > Cool. Seems like quite a bit of work for something we're going to throw
> > out later. But if you're volunteering... :-)
>=20
> Is there any reason we shouldn't modify the keyservers to run over Freene=
t=20
> itself? I mean, once updates are working (how many times has that phrase=
come=20
> up?)
That wouldn't be secure at all, and don't expect updates to be
available any time soon. Don't worry, because I'm already working on
a key index system which works entirely over Freenet.
--=20
Travis Bemann
Sendmail is still screwed up on my box.
My email address is really bemann at execpc.com.
--FsscpQKzF/jJk6ya
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org
owFNVM+LHEUY3U0IwsKAe/MkHwFZF2bayUaJtu5uslmD67JGzRD2WtP19XS51VVt
/Zie9uZNPARPngT3LxBvnrx505unnEUQD4LkJCj4qmcmyWWoqfrqvfe971V/Nbi6
eWV7/tHvP+mH3z/a/PnPsPHW+bfbd60JbMJo0jWcU+BFeK3RQpm3qaiE8xz2ox8J
Xyg12FrXHivfWK+CsiYnZbQy/Oxw4oTxJbvRu6awUplZTp9GG1iOGqdMEFON4sHW
fUOTyEN6PxrauzWkvfF4TCLQ+I38xs38xpt3zmg0fn08HtIRm09ErQzdtSKwp9YB
LR9sHdAB3XO2piMwSmvonakWJt6OwWdFkUX0InzGMh6gdn9v3N84oEnFhkLFHaGH
QIIusAw2baWlMqV1NXl2c3YUjcRvOjKi5hXC9TMOQoog8okKmvdvHt+zdngnhsq6
9MexHJ6+d4plb2dp7fVsSVtoBYs8FTbq/cGWhHmFjnINLKhxrBV6Fa6DBOGKikoW
ITo4NcWWqhvdkbSt0VYkc9eySSsP4BJ+ADjtrjDT2bIZPyT4tIJdXnU2zqpUXBO6
pnVf2XOGwXWrM3rAXHuQXDCmqQJD61QFsiW11l30t72tOfTALe84ppntSWzP0y7B
bAykMUWX0RGWqqTOxlQ8tzoiP4yIzLIso3y0+0zEiU8aUSVMR46Fx7BbJl/BRml2
AtUIWtmtvVi1m6gd0mXTIDEUNgxrwgpTBc+6PCQ6oZqFGZI1BVNsZJ8xAbLUWOrg
1cq2VCfqoGqcVSLJQVSbygmfMDHPmle4sTncTfmepIp2LXAKtVzE1AIip/VyFAgt
znjRcBGeUkP1FMMTc6F0eiy0ZobB1mREx/0tqHMdQsGFiJ7pZKcGLryR3VPh1gCm
D4BCjBfkOx8w6bZSiFVrv3QXnhBHhcx1z7sUstTAaNR3hOc8Vx6PEA4A7wEbWUMZ
Yc8HpTX5wnHLEvpBSHVHU7sAwFlH3BcKKR17ny5AngbVtMe6zQsumiKDd9kXh1ev
baav0frztH1ldr5xefnrk/M/bv32zw+H+df/Pvns/t97H/61cfnNKx+/+Oj0pQ9e
fvzd490ff7n2+X8PX/gf
=JsJ0
-----END PGP SIGNATURE-----
--FsscpQKzF/jJk6ya--
--__--__--
Message: 14
From: Daniel Phillips <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
Date: Tue, 27 Jun 2000 15:26:38 +0200
Reply-To: freenet-dev at lists.sourceforge.net
On Tue, 27 Jun 2000, Scott G. Miller wrote:
> > If you recall, we were discussing the case where the server and client
> > reside
> > on the same machine, so unless you are concerned about the case where a user
> > wants to attack themselves, your comment is a non sequitur.
>
> Yes, we are discussing that, and no, it is relevant. We are talking about
> that user being the attacker.
>
> ...but it does have a lot to do with shooting down ideas that haveinherent
> security flaws.
Well, if an evil user controls a node it doesn't matter whether the node is on
the same machine as their client or not.
My burning question: where is the security flaw? IOW, how is the attacker
going to use the metadata promotion method I suggested to do harm to Freenet
or to gain useful information?
--
Daniel
--__--__--
Message: 15
From: Daniel Phillips <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Date: Tue, 27 Jun 2000 15:42:51 +0200
Reply-To: freenet-dev at lists.sourceforge.net
On Tue, 27 Jun 2000, Brandon wrote:
> > Yes, we can encrypt if we only allow exact matches. However, I wanted fuzzy
> > matching,
>
> I here ya. That would be damn cool. I'm not sure if it's worth it though,
> since we'd have to leave everything in plaintext. Difficult
> tradeoffs.
How about: Metadata can be either plaintext or encyrpted. If it's plaintext
you can fuzzy match it (etc) and if it's encrypted only exact matching
(against hash keys) is possible.
--
Daniel
--__--__--
Message: 16
Date: Tue, 27 Jun 2000 08:53:02 -0500 (EST)
From: Scott Gregory Miller <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
Reply-To: freenet-dev at lists.sourceforge.net
>
> My burning question: where is the security flaw? IOW, how is the attacker
> going to use the metadata promotion method I suggested to do harm to Freenet
> or to gain useful information?
Simple, by inserting bogus metadata pointing to wrong information, then
repeatedly using the metadata-promote message you propose to artificially
inflate its existance.
--__--__--
Message: 17
Date: Tue, 27 Jun 2000 14:59:13 +0100
From: Ian Clarke <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
Reply-To: freenet-dev at lists.sourceforge.net
> Yes, we can encrypt if we only allow exact matches. However, I wanted fuzzy
> matching,
If we are encrypting keywords in metadata then that leaves the whole
thing open to trivial dictionary attacks. I think that metadata (or
searchable keys or whatever) should be plaintext, but widely distributed
(because they will be small). This gets us back to giving small data
priority in the datastore.
Ian.
--__--__--
Message: 18
From: "Henry Hemming" <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
Date: Tue, 27 Jun 2000 16:00:45 CEST
Reply-To: freenet-dev at lists.sourceforge.net
Why not go for the storing routing information in the meta data reply?
As it might take quite some time to verify the data content the routing
information would have to be stored for a long time. And there is no
security risk involved in routing information being added to the meta data
reply.
Each node gives its neighbours some private id's that only the node itself
knows, and then just build the routing information from these, stored in an
array, even better is that as the routing id's could be variable length
there is no way to determine how far the packet has traveled.
A typical routing id only needs to be log of the number of freenet
connections a node has. What is this typically.. 3-6 bits for each step?
A reasonably unique uniqueID (random number) is mostlikely longer than the
whole routing information put together.
--typo
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
--__--__--
Message: 19
Date: Tue, 27 Jun 2000 08:54:03 -0400
From: Travis Bemann <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata (was: Meaningless hits)
protocol="application/pgp-signature"; boundary="EP0wieDxd4TSJjHq"
Reply-To: freenet-dev at lists.sourceforge.net
--EP0wieDxd4TSJjHq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 26, 2000 at 12:22:51PM -0500, Scott G. Miller wrote:
> > sent that retraces the route back to the metadata and promotes it. Thi=
s is
> > easily accomplished by including metadata keys with the metadata items
> > returned from a search request.
> >=20
> > Did I make any invalid assumptions here? If not, this seems to me to b=
e a
> > robust and efficient way of handling metadata promotion.
> Yes, there is the assumption that the server can be well behaved. The
> problem with your proposal is that it allows malicious nodes to falsely
> promote metadata, by spamming with these "metadata promote" messages.
>=20
> Honestly I really don't think we need any artificial
> metadata-life-lengthening messages. If people continue to need to search
> for an item, then those hits on the metadata will be enough. What might
> be a problem is the inverse, metadata may expire *too slowly* since it
> will be returned in searches even if the data it points to no longer
> exists.
I agree with this, but there is another solution to this problem
(which is much better than metadata-promoting messages). This
solution is favoring small files over large files when deleting
files. Large files which got requested in a pattern similar to a
smaller file would get deleted before the smaller file. The reason
for this is that, at least from my experience, documents are somewhat
short lived. Favoring deleting large documents over deleting smaller
documents would allow small files such as metadata, index items (what
I am currently working on), most text or html files, etc to stay in
existance for long periods of time, while someone's massive MPEG porn
collection would exist for a short period of time, if at all. This
would lessen the effect of spamming with BLOBs, and would keep small
and medium sized files in existance for a considerable amount of
time.
--=20
Travis Bemann
Sendmail is still screwed up on my box.
My email address is really bemann at execpc.com.
--EP0wieDxd4TSJjHq
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org
owFdVj2PHEUQvbMFwUor5IQAJKvkxB/aPdaLbImzzkaHPzjks418wpDRO1O707qe
7nF3z+4tASlEBkFAAgjEH4CAP4CQCPgH5EQmRCJDvOqevb0jub3t6XpV79Wrmv28
f3bzzLn5u3/+at778dnm78/jxhvv//D8LWcj2zg8WDa8TZGP4muNUdreoKJSPnDc
acNQhULrfm9197YOjQs6ame3SVujLa8fHnhlw5T98I4tXKntbJueti5yOWy8tlFN
DC73ew8t7Ts7oHdaS+PrAxqPRiNSka6Ot8fj7WtXH+3TcHRtNBrQ48LFSPe2aF8b
w54WHmjb/d5NukkBGSlWiPMcvSo44BuTd21kmqjikKJLJzVHVaqoSNmSGu9qYATS
cYvooNI7/R6+hIzJKmizJFUUrm6MDhWXNFmCZ2Fa4bPGOuRloIWO1ekUOnLdYaGq
1lsATJGSFOpVvqhw/LTlELfSpZ3xKF++rUvao1odMqqUhHNlcKRCaOtGxA5Usedb
RHtTsi4OkFYHYCKd8KxZ/k5ABgBdfjdpQ0ykeTrVhRa9FmpJbkoVTs0pPlkXJEqF
fcBBMiAjpEkM15VkzeUssJ+jKYWyNGFasDH4rNScyyQtCxJw0fU6S7V0rZcTOEiZ
jAwojSKNcYsA/gZ1ujaAYsmJ2FSZwGbZQUnrjmseSGtCo+pamKx6EZgu/I8VX0BM
CGrGQdh1or/tLPqAbu+hJyhgSaWzF4WZtodgQ5bRPOmG8lGLgMpI3Ap8aPSUh4bt
DFltFrNLkrrUsGsMU4HZ0LZN/UmI+MxWELCp80iRbJMEF3UdKFQ6BkpanzDXQieF
ia1rZxWyPBH5aj2romDhiTrWu2sbjMSY5MEapIYD+KjRaO2V6FALlDfLKxRgctxP
SKtExxbWtqsZTeE5qtTTBN95nhqH8U79so6MszP2gsNHOkTRvN/bIzXzzKs2afhr
0sa1xxRMjf8pONNml7ls8Y5Qv3dpUWnMD47qFp8TjhH34SC7bknn4hO9uJynHDN5
jAyEqZo7L9cCLGdoqg2IOTGzUX7G3cFC+lGyYUHs99Ih4O6fuiI1zVxczXUWC31Q
Uh5k07UGptDBXKZ0yCLBtHCtKWnGMeeQVcPwA+fZOnEzT5O4NDiLOpzP0nQDNJDd
afAw5lVTpwazx8AX6HzpirZmaY8CdnA1LxCEWirnEafzuN5dKbLi2ymxjk7yHD/t
6uv31hcynzTKp3QN0i4VTsyttiUf5V1Jl3I18EdNRes9oDCKC+cPJY2zl+FdB2ry
eiIwr2LdAQ+IY5HGKSpZmdh94jclPhaNxIckOrgyyNKLuoYc6JjJMmD+L8rOCQEa
0P6jO/fgYw+YwoFakbySOSXcPKuUZcuwa1TMg0pr7NhuORJlBs5jjCUMUAk5vbN2
7z/cBRfZ0znmkLnJAvZ7clpzqdsaTvpIXiZJUljsNFcleybokr28ZKGla63k6vek
vjSBw2FafHhHz/WHgXa5VhZkH7Mta6XTOg5RBj8UnhdI1TaygeCmiTsCwj5slS6q
svSgJQHd4pwkrDf5iIum2MK7c+vTW2df2JTfGKsfHefODJ9tfPfbg++/+uTj2fCl
b67/9fLX/zRf/vzi3Y1vB1/M/379/Kt/fPbK+En/QfXL7vmf/v0P
=pJ+R
-----END PGP SIGNATURE-----
--EP0wieDxd4TSJjHq--
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
