--On fredag den 11 mars 2005 11:22 +0100 Gustaf Räntilä <[email protected]> wrote:

2) No perfect forward secrecy - lose the key to someone and any
recorded data can be decrypted (authorities spring to mind)

Lose how? The symmetric keys are temporary for each session/connection,
and never stored. How the assymetric keys are locally stored, can be made
safe quite easily. However, this problem occurs to any program
implementing asymmetric ciphers. In Unix you depend on filesystem rights
for the private keys etc.

Even if you lose your private key, the data transfered up to that point should not be compromised. This is what PFS is. An example of a protocol using PFS is IPSEC, using the Diffie-Hellman key-exchange in it's OAKLEY (RFC 2412) protocol.

See <http://www.itsecurity.com/asktecs/may201.htm> and <http://www.faqs.org/rfcs/rfc2412.html> for more info.

Surely one would like Some sort of negotation though, I fully agree on
that.

If nothing else, you want to be able to choose a new algorithm should AES be compromised.

What packetfilter problems? Sure it's identifyable unless one uses a
common cipher-handshake such as ssl/tls gives you. I don't have an
opinion on whether this is an issue or not... Unless 'they' can read the
traffic, do we care if they know what it's for? Maybe.

If they can separate it, they can shape or block it. We're not just aiming for privacy here - a huge part of the purpose is to make it harder for ISPs to block DC, by saying, for example, "OK, we've just made DC look exactly like HTTPS or IPSEC traffic. Now it's up to you - block or shape all traffic that looks like this, or accept the fact and move on."

Only support encrypted connections is by far the easiest way.

I agree, and I think this is the way to go. Less complexity, better privacy.

I personally just dislike the so called 'certificates' that are being
generated. I'm not sure they fit a p2p system. They depend on dns names
and so on iirc...

Nothing says you have to use X.509 just because you want to use SSL, although it's much easier that way. :)

Also, you don't have to interpret that field in the certificate as a host name if you don't want to - use it to store the CID instead?

/fnord