#28 End to End Encryption (Freenet, GNUnet, IIP, I2P has it)

[S M]

Other anonymous p2p projects (Gnunet, Freenet, IIP,
I2P, and more) have it, its a good idea. If you want to
know how to do it look at I2P's implementation, its
BSD/GPL lisence.

Feature: Perfect Forward Security using Diffie-Hellman
Key Exchange Protocol. I believe mute has node to node
encryption but not end to end encryption (Diffie-
Hellman), which means that nodes can read messages
passing though it.

There is a few reasons why you'd want end to end
(Diffie-Hellman) encryption:

1) It is more secure.
2) People woudd be able to pass private content without
interception.
3) It would make it harder for people to be implicated
when their node helps 2 other nodes exchange material
(copyrighted works, etc.)

Here are some links (IIP uses Diffie-Hellman exchange, I
use it, it is open source, I2P also has it):

http://www.invisiblenet.net/iip/aboutMain.php

http://i2p.dnsalias.net/

http://en.wikipedia.org/wiki/Diffie-Hellman

[Nobody/Anonymous]

Logged In: NO

Oopse, I know now that it will be hard to implement this into
Mute as it is right now.

I asked Jrandom in #I2p on IIP how he put it in I2P but the
topology of i2p is complicated. I'll post some links on the
matter as soon as I have it resolved.

Thank you.

[Thomas Schürger]

Logged In: YES
user_id=39876

Right, MUTE has transport encryption, but no end-to-end
encryption. This is due to the fact that man-in-the-middle
attacks would be easy on the MUTE network, due to the
missing Public Key Infrastructure (PKI). Without a PKI, a man-
in-the-middle could intercept keys and exchange them for his
own, and voila, he would be able to decrypt the traffic. The
same is possible for Diffie-Hellman key exchange.

Because this doesn't really increase the security, Jason said
he wouldn't add it (at least not now).

[Thomas Schürger]

Logged In: YES
user_id=39876

Another note: RSA or DH would work perfectly fine if MUTE
was a read-only network. But of course, it isn't.

[fabiano]

Logged In: YES
user_id=690572

ok it is useless

[gabriel ramuglia]

Logged In: YES
user_id=608193

point 3 is important because it means that it makes it harder
to require intermediate nodes to filter content and makes
more solid the argument that they are simply "conduits" much
like isps and phone companies. If the user is inherently
incapable of determining the status of the content flowing
through it, and isn't expected to block everything, then they
can block nothing.

[Nobody/Anonymous]

Logged In: NO

Hi,
just stumbled upon this. The one reason I am not using MUTE
is that it does not have end-to-end encryption. Of course,
this does not add more security (maybe a little bit, because
a possible man in the middle has to program some additional
procedures to build up two seperate encryption tunnels and
can't just just a packet monitor), but it adds plausible
deniability.

If someone accuses me (static IP) of helping people pirating
music, disclosing gouvernment information or sharing child
porn, then I'm able to say, that I may indeed have helped
people do such things, but I had no way of knowing, since it
was end-to-end encrypted. As a non-programmer, I have no way
of intercepting the communication and therefore can not be
made responsible for what I'm forwarding to other nodes (at
least in Germany, which has sane legal laws ;-) ).

So please implement it, but make clear, that it only adds
some protection against being sued for fowarding illegal
stuff, but does not protect your sensitive data.

[Daniël Pelsmaeker]

Logged In: YES
user_id=629074

Jason describes why it is not possible to implement
end-to-end encryption:

http://mute-net.sourceforge.net/personInTheMiddle.shtml

But he is wrong. When Alice sends her public key along with
a query, and Bob has some results for Alice, then Bob can
use Alice's public key to encrypt the message and there is
no way that Eve can decrypt the message. And in the other
direction, Bob send his public key with the message he send,
so that Alice can use Bob's key to encrypt a message for
Bob. But Eve can intercept the message and replace Bob's
public key with her own (enabling her to read the replies of
Alice) and then re-encrypts the message from Alice to Bob
using Bob's public key.

However, when Bob encrypts the message using his own private
key first, and then using Alice's public key, when Alice
receives the message with Eve's public key (instead of
Bob's) attached to it, she won't be able to decrypt the
message. This way, Alice can be sure to have Bob's public
key (and not Eve's) because she can read the message.

Eve might try to replace Alice's public key in the initial
query with her own, but that won't work either. When Bob
receives the query and he encrypts his answer with his own
private key and with the received public key (Eve's public
key) then Eve can decrypt Bob's reply (using hey private key
and bob’s public key) and she might resend the reply to
Alice by encrypting the encrypted message, which Bob created
with his own private key, with Alice’s public key. When
Alice receives the message, she uses Bob’s public key
(provided with the message) to decrypt the message and then
when she replies (encrypted with Bob’s public key and her
own private key) only Bob can read the response and Eve just
lost her job.

End-to-end encryption...