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
