-----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 <[email protected]> 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 [email protected] >> 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-----
0xA3BFAF31.asc
Description: application/pgp-keys
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
