>IMO you might want to do something about forward secrecy (aka backward >security) and forward anonymity, or you arguably end up with the same issue as >reply blocks: a subpoena plus suspicion can force decryption (you won’t have >the decrypt the reply-block via repeated subpoenas down the chain, but the >participants are known or suspected, just coerce them to decrypt!) It is >tricky to get forward secrecy for store-and-forward messaging [2], but perhaps >you could incorporate rekeying into your protocol in some convenient way.
It is tricky indeed. The handshaking necessary to set up the session key could piggyback on the first couple messages that users send to one another although those first several messages would not be forward-secret. I suppose that the session key could then be replaced with each message sent: The sender of a message would keep track of two session keys- one that the other party used previously (so that you can receive consecutive replies) and a new one that you are encouraging them to use on the next message. I think it would work. I’ve written out a message sequence chart and it appears that only the first message from Alice to Bob would be non-forward-secret. If a party is compelled to give up the keys, that very first message and also the last couple messages in a conversation would be exposed. It will be very difficult to explain this property to most people. If ever I have a mode for Instant Messaging (the thought is to give up anonymity for some addresses in exchange for the ability to send large files and not do any proof of work) then I will be sure to implement forward secrecy. >And maybe a way to steganographically tunnel connections to participate This is very difficult. I will leave this to Tor; Bitmessage can use Tor with only a few clicks. >Couldn't the protocol be sped up by implementing something similar to the way >DNS work's i.e. but having trusted servers acting as re-distribution points. Yes, that would work. If more people want that feature it could be added. The address and corresponding QR code would be the same size- it would just be a hash of 2 signing and 2 encryption keys rather than just one of each. But Bitmessage (just like Bitcoin) would enjoy greater user enthusiasm if an individual can run a full node on their own without relying on a server. >2) What happens if someone/thing takes the whole of stream 1 off line >permanently? can 2 and 3 re-join or have you got a net-split type event? I’m not sure how you would take stream 1 offline. I think of Bitcoin nodes as being all in their own stream 1. In Bitmessage, Stream 1 exists because nodes consider themselves to be part of stream 1 (and likely other streams as well). If you were to eliminate all of those nodes then stream 1 would become empty and remaining clients would start creating new addresses in stream 1 thus those nodes would become members of stream 1. The streaming concept doesn’t affect the possibility of net-splits. Net-splits in Bitmessage and Bitcoin have the same potential causes (i.e. A government disconnecting the country from the Internet) although are less serious in Bitmessage because there is no blockchain. >If the police break down my door grab my private key, they have a copy of >every message I've ever sent Yes. Forward secrecy as discussed above is something I would like. This gives me more reason to want to create an IM interface. >BTW as I assume you're using it currently, how network heavy is it? I wonder >if it's something that could be ported (as in running in parallel) to I2P? Someone went around advertising it on Reddit and there are currently tens of people running it which is still low. For I2P, it appears that the protocol would need to be modified to support the multi-hundred byte destinations, but I see no reason why it wouldn’t work. Once it is on I2P, it would be quite easy to make junction points between clients on the normal Internet and I2P. >“A primary goal has been to make a clean and simple interface so that the key >management, authentication, and encryption is simple even for people who do >not understand public-key cryptography.” >This is of course, the hard problem. I feel that those things are easy but anonymity is hard.. as long as people can accept using a human-unfriendly address. By the way, if anyone is aware of any distributed-network projects besides Namecoin which can securely link human-friendly names with human-unfriendly data, I would be interested to hear it. Namecoin gives me hope that something (or an improved Namecoin) will exist some day. >So no one has anyone to talk to, nor anything to talk about, and if they did, >they would have trouble recollecting who they were talking to, since all >truenames look like gibberish, thus all truenames look alike. ... Seems to me >that you need something like public web pages, and something like a favorites >list / bookmarks list, where when you add something or someone to your list, a >petname/truename pair is added to your bookmark list. The user interface has a functional address book which allows you to label Bitmessage addresses. The address is then labeled in your inbox and the Bitmessage address is hidden. >A link in the webpage would be nickname/truename pair, thus clicking on such a >link, you would be guaranteed to go to where the author the web page intended >(trusted path) and the destination would be capable of being added to your >bookmarks list. The long random gibberish true name would almost always be >hidden behind nicknames, petnames, and trusted path links. That’s a good idea. I haven’t worked on a URI format yet. -Jonathan _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
