On Sat, Apr 15, 2006 at 07:27:43PM -0400, Gregory Maxwell wrote:
> I noticed on http://wiki.freenetproject.org/FreenetZeroPointSevenSecurity
> that there are plans to use JFKi. I was wondering why the choice of
> JFKi vs JFKr. Both are similar from a security, complexity, and a DOS
> resistance perspective but JFKr has the advantage that a passive
> eavesdropper learns nothing of the identity of the peers, and that the
> exchange itself doesn't produce any nonrepudable signatures.
Even if we use JFKi the attacker will learn nothing as I expect to
superencrypt the authentication packets with the symmetric key in each
node's reference. I don't know how this will work for opennet
introduction-from-seednodes though; for all other use cases it will be
fine. We already do this with Diffie-Hellman.
My recollection was that JFKi is just better in general, but I will
reexamine it closer to the time of implementation. However, I propose to
implement a simple signed D-H implementation in the near term; JFK would
be a lot more work and we don't need it yet.
>
> For the 0.7 darknet mode, we could achieve a substantial degree of DOS
> resistance at a fairly low computational cost while improving security
> overall, which could be used in addition to DH style methods for PFS.
JFK is a DH variant.
>
> It would work like so,
> After two nodes (I,T) first establish an encrypted and authenticated
> link, they exchange random secrets (Is,Ts). Both nodes remember the
> secrets. E(key,data) is encrypt with a symetric cipher (in at least
> CBC mode).
>
> Then when node I initiates a connection to T in the future he computes
> and sends E('freenet',nonce|H(Is | Ts))|E(Ts,nonce2 |
> 'freenet')|standard DH stuff.
Not necessary, we have an encryption key in the node reference already,
which is used to prevent the DH exchange from leaking any information.
It's just random data as far as an attacker can tell, unless he's seen
both references.
>
> T can cheaply tell if he's talking to I (worst case he just has to
> perform two symmetric decryptions)... The nonce is in there so that
> the message never contains any static content that would make freenet
> conversations easier to identify. Nonce2 should be either used to
> encrypt the DH exchange, or mixed with the key that DH produces.
Yes. We already do this, with fixed keys in the noderefs. Iff the
attacker knows the noderefs, he can decrypt the DH exchange.
>
> Once all of a nodes configured peers have connected at least once, the
> node can reject any request which doesn't complete the above exchange.
>
> This improves security because it is DOS resistant (doesn't depend on
> public key operations, doesn't add round trips), MITM resistant
> (presuming that the initial connection was secure), and protects the
> identity of the peers (only information about the per-edge secrets is
> potentially leaked).
Public key cryptography is necessary to prevent MITMs. At least it is
the first time. What you are suggesting is essentially that we have a
quick restart protocol which simply consists of remembering the last
session key. We could do that; it's not really necessary though. The
threat of DoS is pretty low, since the attacker must know the noderef in
advance. On opennet things are different though, and there will need to
be some serious thought on how to secure that...
>
> This could be straightforwardly extended with a user provided per-peer
> secret which would be used for the initial exchange. If we can assume
> the users have a secure way to exchange a per-peer secret (why not, we
> expect them to be able to secretly exchange references) we can have a
> system which retains some security even if the DHP is someday proven
> weak.
We already do. :)
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20060421/856206b9/attachment.pgp>
