gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Adding a mix network layer?


From: M. Klehr
Subject: Re: [GNUnet-developers] Adding a mix network layer?
Date: Fri, 01 Aug 2014 13:38:14 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks for the nice feedback and clarifications about the conflicting
goals of connectivity vs. anonymity. This is a very interesting topic.

I'm inclined to say that all communication should be anonymous by
default. If you'd like to be identifiable you can always sign it with
a private key of some kind. I think this is favorable over a world
where people that want to be anonymous have to use a separate network
on top of the other.
However, I look forward to proposals for an anonymity layer, which
hopefully integrates as deeply with the connectivity layer as
possible, allowing you to use every ordinary node as a mixing relay
for your connection, and to transparently access hidden services, even
if you're not connecting through an onion-routed channel.
I'll also give some thought to this myself.

cheers,
Marcel

Bart Polot:
> Just to expand Christian's answer little bit.
> 
> Our decision is deliberate. We have decided to keep onion routing
> out of CADET for various reasons: - CADET is a connectivity
> service. We try to keep different functions in separate services,
> thus CADET only takes care of connectivity. Encryption comes in
> because we put security first and we try to do everything in GNUnet
> is as secure (encrypted) as possible. - Anonimity doesn't come for
> free. Anonimity requires a minimum of three intermediate nodes,
> which increases the traffic in the network and the latency in the
> connection. If CADET can connect two peers directly (zero hops, in
> a non-restriced scenario), it tries does so. - Anonimity is hard to
> get perfect. The three intermediate hops is just a bare minimum.
> You also have to select those peers "correctly", worry about timing
> correlation, and many other details. - Conflicting requirements:
> Peer selection is directly oppsed to CADET's goals. For CADET you
> want to have the least possible hops, on the "directest" path
> between you and your target. For anonimity you need to have them as
> spread as possible (ideally the global network) and with a high
> minimum number of them. - If you need anonimity, you can always put
> it on top of other layers, we are not rejecting it. If you replace
> IP by GNUnet, you can still run a Tor-like system (or maybe just
> Tor) pretty much unmodified. We do plan and have in our TO-DO list
> to build an anonimity layer, so the applications that need it can
> have it, it's just that we don't have the manpower to do it right
> now. We do accept code contributions, tho ;)
> 
> Bart
> 
> Bart Polot
> 
> 
> On 25 July 2014 14:08, M. Klehr <address@hidden> wrote:
> 
> Hello,
> 
> I think GNUnet is a very valuable effort in "fixing" the internet
> and I would like to thank everyone involved with it.
> 
> I really enjoyed reading the CADET paper and I'm not sure if GNUnet
> is a direct implementation of CADET, but here are some thoughts
> about CADET that I would like to throw in for discussion. Please do
> tell me if I'm wrong. I understand that there's link encryption
> between participants to maintain message integrity and anonymity on
> the basic layer. Then there's end-to-end encryption and connection
> redundancy (leaving aside the multiplexing layer for now). However,
> it seems to me a relaying node can still intercept a fair amount of
> meta data through path information that's being sent along with
> messages. I understand that this is intentional since the protocol
> is designed for restricted route scenarios and nodes are able to
> learn the network topology very quickly this way, but I believe 
> that using these connectivity paths for direct (albeit encrypted) 
> communication is a privacy flaw and invites censorship, because
> any relaying node can learn who you're communicating with. What
> I've been thinking about is the role a mix network layer 
> reminiscent of Tor could play in GNUnet.
> 
> What do you think?
> 
> cheers, Marcel
>> 
>> _______________________________________________ GNUnet-developers
>> mailing list address@hidden 
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>> 
>> 
> 
-----BEGIN PGP SIGNATURE-----

iQEVAwUBU9uYRlcsPFejv68xAQrAfAf/axOFgdXyTxUhX91vEMIAGTEOriNzSM47
QMqUTg6CYDwzhghQfQCpph1lScerMUEoJx0F3zDYHhNS5G/6A7ubspeoQLc9tdyU
vT/KIQoZZgQvTba3hKkTCmGEdZPHDkfDavsahYZS0o8h/tNcZHef4x5J7uGct6Yb
nyPMRUyrYezYyoWkcWlffdS7nQ0Sh6HMz3rNOPX9hVPwT9Zlk1nhDDP1uBwL/l8g
feiVW7yZSYjUsU8P4eLCcf4ze/lEzCC3zcUOVwJ3fmSvRqi94/AOI7qOcCSRHrLG
ZQLRjhesLhh3aAyL5UAOxdbtxYNMe5JCRu2i+Iy5C5KjY/yCjuX6DQ==
=FfxI
-----END PGP SIGNATURE-----

Attachment: 0xA3BFAF31.asc
Description: application/pgp-keys


reply via email to

[Prev in Thread] Current Thread [Next in Thread]