Re: SILC Channel for the Paranoid?
Pekka Riikonen <[email protected]> Mon, 30 Oct 2006 18:10:22 +0100 (CET)
| Newsgroups | gmane.network.silc.user |
|---|---|
| Message-ID | <[email protected]> |
On Sun, 29 Oct 2006, Martin Albrecht wrote: : interaction of this kind like using the public keys. I was under the : impression that option "+C" performs this but I seem to be wrong about : this, am I? : +C only sets public keys of those users that are able to join the channel. : To clarify, here's my use-case: A,B,C need to talk privately and have : their public keys exchanged and trusted. A creates "ad-hoc-channel" with : psiC (private, secret, invitation only, public key) and invites B and C : using their public keys. If the server was hacked could an attack read : messages on the channel? If these messages are not secure against the : server is there any way to make them secure against the server when all : parties sit behind NAT? : Currently the only possible way to secure channel messages so that compromised server or router cannot see them is to use the +k, channel private key mode and /KEY command. None of the clients or SILC Toolkit support public key encryption with channel messages or with private messages for that matter. You have to consider that in case of channel messages only one recipient would be able to decrypt the message, as only one person on the channel has the correct private key. To make public key encryption work on channel all channel members would have to share the same private key, or you would have to separately encrypt and send the message to all channel members. With 10 users on the channel this would mean sending 10 messages to just deliver one message to everyone. (As a technical side note for SILC Public Key pair SILC specifications does not currently define how a message would be encrypted with public key.) In your use case a compromised server might compromise your messages and NAT would not help it in any case. Using +k mode would be the only guard against it. Of course the only elegant solution to this would be some kind of group key exchange protocol that would be executed on channel and would result on shared secret key. It's been couple of years since the last time I've looked at that problem, and I don't have anything concrete on that at this time. Pekka ________________________________________________________________________ Pekka Riikonen priikone at silcnet.org Secure Internet Live Conferencing (SILC) http://silcnet.org/ _______________________________________________________________ Info: https://lists.silcnet.org/mailman/listinfo/silc-users Archive: https://lists.silcnet.org/pipermail/silc-users FAQ: http://silcnet.org/support/faq/