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: Promoting metadata (Greg Titus)
2. Re: Suggestion for ease of use.. (Travis Bemann)
3. Re: Cipher change (JJ Furman)
4. Re: Promoting metadata (Daniel Phillips)
5. Re: Meaningless hits on metadata (Scott G. Miller)
6. Re: Promoting metadata (Scott G. Miller)
7. Re: Promoting metadata (Scott G. Miller)
8. Re: Suggestion for ease of use.. (Brandon)
9. Re: Suggestion for ease of use.. (Scott G. Miller)
10. Re: Cipher change (Scott G. Miller)
11. Re: Cipher change (Scott G. Miller)
12. Re: Suggestion for ease of use.. (Brandon)
13. Re: KHK authentication (David Hopwood)
14. Re: KHK authentication (David Hopwood)
15. Re: KHK authentication (JJ Furman)
16. Re: KHK authentication (Scott G. Miller)
17. Re: KHK authentication (Scott G. Miller)
--__--__--
Message: 1
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
Date: Tue, 27 Jun 2000 07:20:11 -0700
From: Greg Titus <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
> Simple, by inserting bogus metadata pointing to wrong information, then
> repeatedly using the metadata-promote message you propose to
artificially
> inflate its existance.
I don't think there is any metadata-promotion scheme that avoids
this. You can use signatures and a web-of-trust model (as discussed
in another thread) to try to minimize the amount of bogus metadata
that you need to deal with on each search, but because any particular
piece of metadata is small, no matter what method we use for
promotion a black hat is going to be able to keep their bogus
metadata "alive" with little difficulty.
The only thing that would increase this cost a bit would be to only
promote metadata when an actual document download occurs, which means
either (a) metadata has to be found with the actual document text, a
really bad idea for security, and/or (b) for things like updatable
documents (some day) the metadata will be pointing to an SVK which
just contains a CHK - so the "document" the metadata would be
attached to will potentially be even smaller and easier to download
than the metadata itself.
--Greg
--__--__--
Message: 2
Date: Tue, 27 Jun 2000 09:33:07 -0400
From: Travis Bemann <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Suggestion for ease of use..
protocol="application/pgp-signature"; boundary="T6xhMxlHU34Bk0ad"
Reply-To: freenet-dev at lists.sourceforge.net
--T6xhMxlHU34Bk0ad
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 26, 2000 at 12:28:45PM -0500, Scott G. Miller wrote:
> 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)
If you aren't an anarchist, please put on your asbestos longjohns:
<political statement>
But then, if we have a situation where the government is sending goons
to attack anyone using Freenet/running a Freenet node, we might as
well scotch the totalitarian state in the egg, which is essentially
overthrowing the government and replacing it with a new government or
no government at all. Note that I am talking about the US government
when I refer to government here. Note that overthrowing the US
government would probably require a bloody shooting war (the Second
American Civil War). Mao wasn't a real nice guy, but he was quite
correct when he said that political power comes out of the barrel of a
gun. All governments are based on violence and fear, and all attempts
to overturn governments require violence and fear because the
(previous) government will use violence and fear to maintain its power
and because the previous government has to be forced out of power or
has to be scared into giving up power (this is what happened to Marcos
when his Army switched sides).
</political statement>
--=20
Travis Bemann
Sendmail is still screwed up on my box.
My email address is really bemann at execpc.com.
--T6xhMxlHU34Bk0ad
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
owFtVU1vHEUQjRNxGTQSgQsHDqUgERvt2otFUNiQgB0+5Eg2INt8HHtnamc6numa
dPfseMWBKyeExBkBPwDBBQFHJJAi5R5+ARIgwYkz4tVsjO0YaVbana569areq95P
0gtL5y/O3v71p+qdbz5euvdHPPfie189flNcZBeHe/OGxxT5MK41lbHuGmWl8YHj
9TYMTcisTZOj2FdtaCTYaMWNybrKOj4+3PPGhSn74Wsuk9y6Ykx3WomcDxtvXTST
CsFp8qajbXEDutU6Wn9hQOuj0YhMpOfWx+tXx89feWubhqMro9GAdjOJkd5YpW1b
Veyp80Abp8kNep/DgGJpA01NVQVqXY7zWDIV7NibCm+CVDPOqfGCwjXJlC7tSM6a
ntuQyYz9/NIq0V4pbVHSFpnCM1NnY0ldKYxzCsbmgAW7vlhnAhmamJxszkaRJpyZ
NjDZSLU54KBfFJjYhDlFoal1OU0B7DhSYI/DQMuWB7RpC9pERyV7RbrdBlTxFhhI
y8Q5zmKPsEhefRYDJ+7Bc6khlE6AHUBdHqgQcWFF57s1pbm0ZDy7y5GMw2N8Bvpx
QE0FXkxNG0mchnkyYcIhSqBKXHFbShfGivJSIxV0zjDKEE3kGgrfSJPNNvZVB2Sn
1DGVZsYYCSzRGnUFJseeF0rohJ3mEUanLGGJBc80QV8mRpMdgN1cHFMb9PT1Ra9r
vnVOf5ujN+Qg3UAr1rYo0RYwOq5ADh7Jyr5glGjA2XiLpnvSOjE94aJAbmkRCCoc
QCZaGGeeJkoyll46LfcQbQPpPGMpMj2Esr03DDnuToYJ9HNyKhFPVcFbOzDswj+w
V03gd9C3NZHFHGl/90QeWlJBt1B0qnY+halzPYV4hvn+bpqcSOikrRb2x+bNgXmn
tV7FmvxeieRzCqVI1OTOeFpWhF2G7/I02ajZQ3pHN+3MVvSu8SsovW1EN6B3FeDg
DGczDKydD2jSKsN+QVAmYssy8V4d3LeEo+NVOnZWIx36zKSG6XUi2FGlMTFIrfQX
dqxoHWpvQOrj3oK6G2EB+w3PzaxU7EBFBZuy8YP+GyRQk3HdxIXj+om13p1COprL
GZD/dhuU0mS58YyQNqycFKXDxUQaczYb9XRJIz6wTlj0miZ6fgKYjmBPSW36O2DC
NBWfaY+L2SzGpXY7jggZRoH7yKlboBbkbJsHkcv9paX3lo69NE2DVYII8jW09JmE
B4bTqA1fwxEweFYiJOB+CyuruAbW/v8eSJPh8Pr6KE1w6c+Qvsm1cS5NdrHmaLvq
Vz7afkE9d4AEK0iFIhM5BPA2rsg+0OS5x0ZqgnoKTp30WK/wIWdNtgp3rH708oVH
lvQ/6+hP7OL5x54+99lT//z8/aP13R+ufiv7z3x++f6nOx/cO/fFj8nd+9d++fK7
3wbmw+LJrT+f+OvvW/8C
=Cgpo
-----END PGP SIGNATURE-----
--T6xhMxlHU34Bk0ad--
--__--__--
Message: 3
Date: Tue, 27 Jun 2000 08:31:28 -0700
From: JJ Furman <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Cipher change
Reply-To: freenet-dev at lists.sourceforge.net
"Scott G. Miller" wrote:
> 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.
I'm all for performance, but testing the speed of java can be a tricky thing.
Handles can slow down array lookups by quite a bit if you are on a non
optimized (non hotspot) JVM. It's unclear whether IBM 1.3 linux is going to
use pointers or handles. What system are you running on?
JJ
--__--__--
Message: 4
From: Daniel Phillips <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
Date: Tue, 27 Jun 2000 16:45:25 +0200
Reply-To: freenet-dev at lists.sourceforge.net
On Tue, 27 Jun 2000, Scott Gregory Miller wrote:
> > 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.
The attacker would have to do a little more work than just issue the promote
data message - they would have to do the search as well, otherwise the metadata
promote message won't work. Not that it makes much difference. The attacker
can achieve the same result without the help of promote messages.
The promote metadata message just extends the lifetime of a metadata item. The
attacker could accomplish the same thing by repeatedly inserting bogus
metadata, or perhaps by repeatedly searching for it.
Consider what happens when a normal user does a search: the heavily-promoted
bogus metadata shows up first in the list (probably) but the real metadata
is also shows in the list. The user does a data request, gets the wrong data,
recognizes it immediately and tries the next search result, which is then
promoted.
Or perhaps the bogus data is so insidiously crafted that normal users don't
recognize it immediately. Some user out there is going to figure it out, and
one is enough.
The correct response to bogus metadata is for users to notice it and
intentionally create hits on the real data to ensure that the real metadata
does not expire. Eventually the attacker will give up or be discovered.
--
Daniel
--__--__--
Message: 5
Date: Tue, 27 Jun 2000 11:03:05 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Meaningless hits on metadata
protocol="application/pgp-signature"; boundary="iFRdW5/EC4oqxDHL"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--iFRdW5/EC4oqxDHL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> > I here ya. That would be damn cool. I'm not sure if it's worth it thoug=
h,
> > since we'd have to leave everything in plaintext. Difficult
> > tradeoffs.
>=20
> How about: Metadata can be either plaintext or encyrpted. If it's plaint=
ext
> you can fuzzy match it (etc) and if it's encrypted only exact matching
> (against hash keys) is possible.
Now thats a good idea. =20
I don't *like* plaintext metadata, but it could be useful for things like
this.
--iFRdW5/EC4oqxDHL
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
iD8DBQE5WNA5pXyM95IyRhURAm7XAJ46EinTb4DVBLs6LKRFV0lBNVSAQQCfe3dL
LMs3gN5s/INWxVAsuTdfYnI=
=qwzy
-----END PGP SIGNATURE-----
--iFRdW5/EC4oqxDHL--
--__--__--
Message: 6
Date: Tue, 27 Jun 2000 11:05:03 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
protocol="application/pgp-signature"; boundary="hoZxPH4CaxYzWscb"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--hoZxPH4CaxYzWscb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> The attacker would have to do a little more work than just issue the prom=
ote
> data message - they would have to do the search as well, otherwise the me=
tadata
> promote message won't work. Not that it makes much difference. The atta=
cker
> can achieve the same result without the help of promote messages.
Okay, if you're talking about your message-memory based system, then this
is fine.
--hoZxPH4CaxYzWscb
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
iD8DBQE5WNCvpXyM95IyRhURAnLBAJ0RYQyOsOXPLijzHI5OlVYII8uWVQCgjVgp
/+Ib5xJ27DPKx93q1Qm3WOc=
=ch+k
-----END PGP SIGNATURE-----
--hoZxPH4CaxYzWscb--
--__--__--
Message: 7
Date: Tue, 27 Jun 2000 11:06:14 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Promoting metadata
protocol="application/pgp-signature"; boundary="wTWi5aaYRw9ix9vO"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--wTWi5aaYRw9ix9vO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> Each node gives its neighbours some private id's that only the node itsel=
f=20
> knows, and then just build the routing information from these, stored in =
an=20
> array, even better is that as the routing id's could be variable length=
=20
> there is no way to determine how far the packet has traveled.
>=20
> A typical routing id only needs to be log of the number of freenet=20
> connections a node has. What is this typically.. 3-6 bits for each step?
> A reasonably unique uniqueID (random number) is mostlikely longer than th=
e=20
> whole routing information put together.
>=20
Absolutely not. Any system that keeps tabs on every hop in the network is
just *not* going to happen. Even if it is obscured, these random ids are
vulnerable to a number of cryptanalytic attacks.
--wTWi5aaYRw9ix9vO
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
iD8DBQE5WND2pXyM95IyRhURAsTzAJ4rQY60Nnu+xg4CQvLXM10P/x+KbwCghlKa
qYXQgLZ6P1q++YMFE1lkLcs=
=zMdo
-----END PGP SIGNATURE-----
--wTWi5aaYRw9ix9vO--
--__--__--
Message: 8
Date: Tue, 27 Jun 2000 11:09:27 -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
> If you aren't an anarchist, please put on your asbestos longjohns:
>
> <political statement>
...
> </political statement>
Please keep political statements on freenet-philosophy.
--__--__--
Message: 9
Date: Tue, 27 Jun 2000 11:09:46 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Suggestion for ease of use..
protocol="application/pgp-signature"; boundary="ULyIDA2m8JTe+TiX"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--ULyIDA2m8JTe+TiX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> 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.
No, but if you can attack all the "freenet.yourdomains", then whats the
point of even having them? you'd have to assume they've already been
subverted because they are so visible.
> > > > 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.
>=20
> 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.
You can only find out about one layer of the nodes, and only if you have
access to the one node. Again, word-of-mouth isn't enough, but it is
better than any centralized, automated source.
> 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...
>=20
> As long as the 'public' nodes are just the tip of the ice berg, I think
> 'public' nodes is a good idea.
Yeah, thats fine. I fully intend to advertise my node as an entry point.
--ULyIDA2m8JTe+TiX
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
iD8DBQE5WNHKpXyM95IyRhURAj38AJ9ehZEQYJ9fi9+sd36zJcqwh4SFWgCbBzX2
8J0NPTD3R9nSX5N6TnMfZxM=
=ZVoo
-----END PGP SIGNATURE-----
--ULyIDA2m8JTe+TiX--
--__--__--
Message: 10
Date: Tue, 27 Jun 2000 11:10:43 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Cipher change
protocol="application/pgp-signature"; boundary="0z5c7mBtSy1wdr4F"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--0z5c7mBtSy1wdr4F
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> 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?
Yes, we are. There is no negotiation in the cipher-protocol, and I'm not
sure I'd want it there. But as long as it doesn't break the datastore, it
wuold be a fairly painless upgrade.
--0z5c7mBtSy1wdr4F
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
iD8DBQE5WNIDpXyM95IyRhURAhh0AJ0WZj1mFQN7K9H5NDZe96DgEZBB1ACdFzQ5
r5RFFzu9COZHp62wZ41GIrY=
=jQa/
-----END PGP SIGNATURE-----
--0z5c7mBtSy1wdr4F--
--__--__--
Message: 11
Date: Tue, 27 Jun 2000 11:11:28 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] Cipher change
protocol="application/pgp-signature"; boundary="WRT3RXLOp/bBMgTI"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--WRT3RXLOp/bBMgTI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
> I'm all for performance, but testing the speed of java can be a tricky thing.
> Handles can slow down array lookups by quite a bit if you are on a non
> optimized (non hotspot) JVM. It's unclear whether IBM 1.3 linux is going to
> use pointers or handles. What system are you running on?
Linux. Tested on both the IBM and Sun JDKs, with JIT on and
off. Rijndael just wins. If you want numbers I can compile them.
--WRT3RXLOp/bBMgTI
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
iD8DBQE5WNIwpXyM95IyRhURApmyAJ9CoeQtaRDuX3DoEPfLDgYlK6rKlwCgz1MT
MqYxATM9NsVegaJus0xO2/Q=
=pg04
-----END PGP SIGNATURE-----
--WRT3RXLOp/bBMgTI--
--__--__--
Message: 12
Date: Tue, 27 Jun 2000 11:24:07 -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
> No, but if you can attack all the "freenet.yourdomains", then whats the
> point of even having them? you'd have to assume they've already been
> subverted because they are so visible.
Definitely, all public nodes must assumed to be subverted or
monitored. That's okay though. The more nodes the better.
--__--__--
Message: 13
Date: Tue, 27 Jun 2000 03:45:25 +0100
From: David Hopwood <[email protected]>
Reply-To: hopwood at zetnet.co.uk
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK authentication
Reply-To: freenet-dev at lists.sourceforge.net
-----BEGIN PGP SIGNED MESSAGE-----
Oskar Sandberg wrote:
> But with JJs version (we have to make up an acronym here :-)) the
> document would also be signed by the "private" key which is available
> only to those who know the keystring. This prevents a node from
> sending a false reply to a request unless it has a dictionary of
> key->KHK so that it can generate the private key and sign the false
> reply. I don't see the below type of key doing that.
The fact that a node can't send a false reply to a request *without
detection by the client* depends only on using a MAC (or other integrity
check) with a key derived from the keystring. JJ's proposal uses a
signature instead of a MAC, but functionally it's the same, and I don't
see that it has any other advantages in this respect.
- --
David Hopwood <hopwood at zetnet.co.uk>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVgVHTkCAxeYt5gVAQGUYwgAq2yoAgiojWwrxGX3p1DI8khhdjOJTnnA
MqpXrlXmRFPTlSMPnVN4i7+kWBlGzn3ZDpRNmq6sZSEjfnkFil2Xrb4ojF4rIR5t
gFFw1Qxg2/t0YJTGbYvigqXu/xblK/bez+CqSgwp5NOu7d1k2bMkZWoLYOXmWlKl
F8PqINWmep+BvkiwLECnrbrqUy11HLZI/IgjaMPk+G+gKG3FeYA8+AHn0ZSHxU4u
UKzdoKxGlecxymGjUOSalEiZeM5hAVfreEiz+0JpJFZzdF8+CFG3WkE6E01wpqBT
zu0nmKUqp4TkYOUWqg7pZQ+3edwLl6KMsmtYeuJeB0VKi9JygAOFVw==
=lMD9
-----END PGP SIGNATURE-----
--__--__--
Message: 14
Date: Tue, 27 Jun 2000 04:00:05 +0100
From: David Hopwood <[email protected]>
Reply-To: hopwood at zetnet.co.uk
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK authentication
Reply-To: freenet-dev at lists.sourceforge.net
-----BEGIN PGP SIGNED MESSAGE-----
hal at finney.org wrote:
> Oskar writes:
> > But with JJs version (we have to make up an acronym here :-)) the
> > document would also be signed by the "private" key which is available
> > only to those who know the keystring. This prevents a node from
> > sending a false reply to a request unless it has a dictionary of
> > key->KHK so that it can generate the private key and sign the false
> > reply. I don't see the below type of key doing that.
>
> Yes, that's true. I was mistaken to overlook that aspect of it. JJ ties
> the data content to the knowledge of the readable keystring, by using
> a signature over the data based on a key derived from the keystring.
As do the symmetric-key proposals, using a MAC instead of a signature.
> No system based on hashes and conventional encryption can do this (I
> don't think). Any such system which allows for verification will also
> allow for substitution, because there are no secrets. Everything is
> out in the open.
>
> You have to use public key technology to get the desired effect where
> nodes can verify the package without being able to forge it.
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.
Nodes can only do a check that ensures that anyone who forges a package
does not have complete control over which node it will be routed to,
except by searching for a "close" hash (which requires work proportional
to the number of nodes in the network). PK algorithms are not needed for
this.
- --
David Hopwood <hopwood at zetnet.co.uk>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBOVgYcDkCAxeYt5gVAQFkawf+J7YH6y9bZzvMZAgNJy0sjbDgxaHAPeiA
8suz8+Lvn5iq/CWwXPH+n/oU2YcjqxEzA/tS2RyX0sWirKfONffq7hxXzlsgZ/P5
wTyjIrG6z4OpGSgPlfg6R2titSxrrtAJTP3k/NJI13K6yOd4DqiDa1/YZRVLr8fP
vLyM2iqTqMp6SPJy/u8lPZQN1kQczqon3fVy34yQ3vGxP3R97R6VMDuxzXjYOgjR
Y9EfsS957yb/5kL+dLzsagjTPrhVA8hLF1n0yOxJYr7pddvEgvS20THgs8lZ6LhX
iT3nyQsPFlu0clvWbqEJZBoCL5E+xIi82BpnjkpbOlcC1SCDYO0g1g==
=iYvD
-----END PGP SIGNATURE-----
--__--__--
Message: 15
Date: Tue, 27 Jun 2000 10:07:21 -0700
From: JJ Furman <[email protected]>
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK authentication
Reply-To: freenet-dev at lists.sourceforge.net
David Hopwood wrote:
> The fact that a node can't send a false reply to a request *without
> detection by the client* depends only on using a MAC (or other integrity
Yes, you are right. But the goal is not detection by the client, but by *each
node* as it travels from the server to the client. This way bad data doesn't
get propagated at all.
For them to verify that the doc is legit a way must be employed of verifying
the MAC (checksum, sig whatever) that is different from creating the MAC, thus
a public/private key pair is needed.
JJ
--__--__--
Message: 16
Date: Tue, 27 Jun 2000 12:07:59 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK authentication
protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--EVF5PPMfhYS0aIcm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> > But with JJs version (we have to make up an acronym here :-)) the
> > document would also be signed by the "private" key which is available
> > only to those who know the keystring. This prevents a node from
> > sending a false reply to a request unless it has a dictionary of
> > key->KHK so that it can generate the private key and sign the false
> > reply. I don't see the below type of key doing that.
>=20
> The fact that a node can't send a false reply to a request *without
> detection by the client* depends only on using a MAC (or other integrity
> check) with a key derived from the keystring. JJ's proposal uses a
> signature instead of a MAC, but functionally it's the same, and I don't
> see that it has any other advantages in this respect.
Well, a signature contains a MAC, so thats not really a difference, so
much as an addition. =20
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.
Scott
--EVF5PPMfhYS0aIcm
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
iD8DBQE5WN9vpXyM95IyRhURAmVIAKCd8/r/5TRO7eQmru7nu/FmG05bLACcC2bD
63yQsfH6QZN+cQso4g30thA=
=VjTw
-----END PGP SIGNATURE-----
--EVF5PPMfhYS0aIcm--
--__--__--
Message: 17
Date: Tue, 27 Jun 2000 12:09:12 -0500
To: freenet-dev at lists.sourceforge.net
Subject: Re: [Freenet-dev] KHK authentication
protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/"
From: "Scott G. Miller" <[email protected]>
Reply-To: freenet-dev at lists.sourceforge.net
--61jdw2sOBCFtR2d/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
>=20
> 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.
Thats not true at all. Because the public key is included with the
metadata, it can be used to do verifications without knowing the keystring
(ie the private key)
--61jdw2sOBCFtR2d/
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
iD8DBQE5WN+4pXyM95IyRhURAsPPAKDGj8ssm9PEfOMNBdPI6avdOVUuUQCfQ7GB
FQTm0t2O5ZE06oRwr4iH1Vs=
=7ZEH
-----END PGP SIGNATURE-----
--61jdw2sOBCFtR2d/--
--__--__--
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
End of Freenet-dev Digest
