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 (Adam Langley)
2. Simple proposal to improve performance (Ian Clarke)
3. Re: Cipher change (Scott G. Miller)
4. Re: Simple proposal to improve performance (Scott G. Miller)
5. Re: KHK authentication (hal at finney.org)
6. Re: KHK authentication (hal at finney.org)
7. RE: 0.3 Todo List (Brandon)
8. Re: 0.3 Todo List (Brandon)
9. Re: 0.3 Todo List (Brandon)
10. Re: Simple proposal to improve performance (Travis Bemann)
--__--__--
Message: 1
Date: Tue, 27 Jun 2000 18:40:24 +0000
From: Adam Langley <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Cipher change
protocol="application/pgp-signature"; boundary="s/l3CgOIzMHHjg/5"
Reply-To: freenet-dev at lists.sourceforge.net
--s/l3CgOIzMHHjg/5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 26, 2000 at 10:37:32PM -0500, Scott G. Miller wrote:
> I'd like to switch the default cipher in the devel server to
> Rijndael. =20
What kind of Rijndael? I mean what block size and key length are you using?
AGL
--=20
There is no grief which time does not lessen and soften.
--s/l3CgOIzMHHjg/5
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjlY9RgACgkQc/sOPsJbMv3EJwCgjg1uGFoUxayqkbv7euXBrhcG
2SsAoJFfMC0zvl18zquaxpnJf82zRNnF
=OZjq
-----END PGP SIGNATURE-----
--s/l3CgOIzMHHjg/5--
--__--__--
Message: 2
Date: Tue, 27 Jun 2000 18:32:22 +0100
From: Ian Clarke <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: [Freenet-dev] Simple proposal to improve performance
Reply-To: freenet-dev at lists.sourceforge.net
I propose that every so often (maybe with 5% probability) an incoming
request spawns two outging requests. Whichever returns first will be
taken and the node which returned it will be cached. The other will be
ignored when it returns.
To facilitate this we will need to ensure that a datareply which is
aborted is handled neatly back up the chain.
This simple modification will create a slight pressure towards a more
efficient topology - yet because of the low probability of a split it
won't cause a cascade effect.
Thoughts?
Ian.
--__--__--
Message: 3
Date: Tue, 27 Jun 2000 13:05:12 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Cipher change
protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> What kind of Rijndael? I mean what block size and key length are you usin=
g?
128/128
--J2SCkAp4GZ/dPZZf
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5WOzYpXyM95IyRhURAnVYAJ9jdKOsswe/8n9x5SsMb3B3AOy44QCgnWAL
L+7RiTPgT261An3+hByUs/Q=
=7EEJ
-----END PGP SIGNATURE-----
--J2SCkAp4GZ/dPZZf--
--__--__--
Message: 4
Date: Tue, 27 Jun 2000 13:06:46 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Simple proposal to improve performance
protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--/WwmFnJnmDyWGHa4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> I propose that every so often (maybe with 5% probability) an incoming
> request spawns two outging requests. Whichever returns first will be
> taken and the node which returned it will be cached. The other will be
> ignored when it returns.
Two outgoing requests to where? The closest and next-closest, or closest
and random?
> To facilitate this we will need to ensure that a datareply which is
> aborted is handled neatly back up the chain.
>=20
> This simple modification will create a slight pressure towards a more
> efficient topology - yet because of the low probability of a split it
> won't cause a cascade effect.
>=20
> Thoughts?
I like it, since it might occasionally find more efficient routes, rather
than just key-routes.
Scott
--/WwmFnJnmDyWGHa4
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5WO02pXyM95IyRhURAk6+AKCfiTfMROCVoxTpekFyluVnzeJp/QCfb4oH
Bzz3duINXaXVtcS0s9NjcKg=
=/9HZ
-----END PGP SIGNATURE-----
--/WwmFnJnmDyWGHa4--
--__--__--
Message: 5
From: [email protected]
Date: Tue, 27 Jun 2000 11:39:16 -0700
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK authentication
Reply-To: freenet-dev at lists.sourceforge.net
David Hopwood writes:
> A node can't verify the package in the sense of being sure that whoever
> generated the package knows the keystring, in *any* of the proposals. Only
> someone who knows the keystring (e.g. the client) can do that.
I don't believe that's true. JJ's proposal does allow for this.
JJ's idea, as I slightly modified it, sets a public key as
g^hash(keystring). This, or its hash, is used as the routing key.
In addition, the message data is signed using this key.
Each node can verify that the message is correctly signed, and that proves
that the signer knew the corresponding private key, hash(keystring).
Therefore a node *can* confirm that whoever generated the package
knows the keystring.
(Technically, it only shows that they know hash(keystring), but this
doesn't matter, for two reasons: first, both keystring and hash(keystring)
are secret and it is essentially no easier to guess one than the other.
Second, the hash doesn't have to be crypto strong here and could in
principle be reversible, hence knowing hash(keystring) and knowing
keystring would be equivalent. All that is necessary is that the hash
produce a number of about the right size and incorporate as much of the
entropy of the keystring as possible.)
Hal
--__--__--
Message: 6
From: [email protected]
Date: Tue, 27 Jun 2000 11:43:05 -0700
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK authentication
Reply-To: freenet-dev at lists.sourceforge.net
Scott writes:
> There is an advantage of efficiency as well. The nodes need only do a
> signature verification, rather than multiple expensive hashes. Likewise,
> on key creation, only a single modulo exponentiation must be performed.
Actually (short) hashes are faster than exponentiation. David's system
would be more efficient, but it is not quite as functional as JJ's.
Hal
--__--__--
Message: 7
Date: Tue, 27 Jun 2000 13:53:12 -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
> 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?)
Sure, once updates are working we'll do that.
Of course once searching is working we'll just give rid of them
probably. Although if you wanted an over-Freenet keyserver, you could of
course have one.
--__--__--
Message: 8
Date: Tue, 27 Jun 2000 13:57:24 -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
> I'm suggesting an extension to the key-inform servers we have now. In fact,
> we don't even need to change the key-inform servers. For example, if a user
> creates metadata like:
> Title=Foo
> Author=Fred
> KHK=text/foo
I'm sorry. I'm so silly. I already implemented metadata requests over
Freenet a while ago. It's not in because in order for it to work I need to
change the clients up and before I did that I wanted to rework the
structure of the clients and that work got put on the back burner because
of working and the large increase in the amount of time I spend writing
proposals, debating proposal, and generally e-mailing.
But I actually have a compiling reworked version of Request. So if anyone
wants to volunteer to help me debug, I could get this out faster. I
reworked most everything so there is a lot of debugging to be done.
--__--__--
Message: 9
Date: Tue, 27 Jun 2000 13:59:40 -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
> 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.
Don't you want to talk about it on the list? It would be a shame if you
implement something cool and we don't accept it into the code. Which is
why we spend so much time arguing over proposals. Of course if it's all
client side you could just have your own competing non-official client.
--__--__--
Message: 10
Date: Tue, 27 Jun 2000 14:01:49 -0400
From: Travis Bemann <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Simple proposal to improve performance
protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Reply-To: freenet-dev at lists.sourceforge.net
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 27, 2000 at 06:32:22PM +0100, Ian Clarke wrote:
> I propose that every so often (maybe with 5% probability) an incoming
> request spawns two outging requests. Whichever returns first will be
> taken and the node which returned it will be cached. The other will be
> ignored when it returns.
>=20
> To facilitate this we will need to ensure that a datareply which is
> aborted is handled neatly back up the chain.
>=20
> This simple modification will create a slight pressure towards a more
> efficient topology - yet because of the low probability of a split it
> won't cause a cascade effect.
>=20
> Thoughts?
I like this idea because it would allow for things such as the
discovery of faster routes, alternate routes to account for things
such as temporary network outages, etc. I do think that the
probability should be increased from 0.05 to 0.1 to increase the
probability of discovery of alternate routes. I don't think that such
an increase would have a too dramatic effect on bandwidth usage.
--=20
Travis Bemann
Sendmail is still screwed up on my box.
My email address is really bemann at execpc.com.
--PEIAKu/WMn1b1Hv9
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
owFdVLGOHEUQvbNFsvIiOSFEJSQEyLvLeC2D2JN9yAfBIVmAboUREkHtTM1Oe3u6
57p7bm4jEgJHCPEDIBOREZJBQGCJmE8gQfcJBLya3TuvHc1MV9WrV/Xe9PfD6/vX
bp59/s+f9otfv9v/69+098GXFzeOvEvi0ni+bmRGSc7Tu41l4w4orzhESffaOOaY
GzMcXOZ+ZGLjo0nGuxkZZ42T58F5YBdLCeOPXe4L45YzOm19kmLcBOMSLyySh4NP
Hc1bGdEnraPp+yOaZllGnCh7b3ZnOptOP3tIt7LbWTaiY3Z0ZDmshLoAoNlwcJ+O
qQkeJIRShSo5k7Cm6MmXIEFv17xeIN2kiu6+qakLXhhr0vodApoBsxrMFCjIaSsx
UWy4c5FSB4w2LRG9DMUJ0aPK5JU2wWFqAxJLE1DVGWtpIQqUeIXO7AowEnK+QH+t
2lZIQeYqn3IGXAHgOXI9CsIulFk6H1DQVUBE1bbnBLF700wz5p5KznUiTroCE6mT
DYQTVCZP4mIbtuthKjhxkMaut6RMVBhe+JCUWaQKzC1enXBC1oLzFbVNPwuMYNxu
c20XTd1YoRoSlyZn9cKmfx5EOTFFa5ZVwvIlbpj4jkMREakxnQJJiVID0yDWeOuX
axrTWhLWkHMLbX3ZE7C+29VQjwHf4B3bUaDOu7cSbWoYz5gz1g94ydMLxH0LSvFQ
DXhM1qy2uzOF8FVTlcm3tiC22rj0QZPcEjO32BxH5TQcFCbmvrcd6JQck5oD1pE4
QiW+nK5hc6J6cJ77FqM+xxsOrgClbnxgYDmBA8NKPchLhZKUwybHVPi+arURtGew
u5JY9ZRhLZgbCkRIWQZfUzbJ7mr7bHJbH5dRIPxx8BIG5nhhqJen2PLQVe9Q0RmG
g81ftYHebK/iMxUjeU9F4BoOybeKEKyygN06U+D/bCMGnagi43GvEy6QM2jyQGp2
bjg4EVfUbKyaNCZ1WESfDvPBnkCqYVZ/DoCHa5I+kYtCPacFIGTVzT3Wh3IueZNP
8PNPnhxef2Vf77/LC/Hmtelvez+Wz56e/H76+Ksfbrz6+uHJf9PXRhff7v3088Wz
b+zfX9/ngydvPDos7/zy9Gj0Pw==
=Mmus
-----END PGP SIGNATURE-----
--PEIAKu/WMn1b1Hv9--
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
