Re: [cryptography] Bitmessage
>If store and forward, cannot be forward secrecy. >Suppose that human readable messages, messages that might contain important secrets, are only exchanged when the sender and the final recipient are both online at the same time, then forward secrecy no problem. Both parties set up a shared transient secret session key, as usual, which goes away when offline, reboot, or timeout. Suppose when Alice firsts sends a message to Bob she also includes a short term public key. Bob takes the short term public key and encrypts symmetric_key_1 ("SK1") and also encrypts a message with SK1 and sends the encrypted SK1 and the encrypted message to Alice. Alice decrypts the encrypted SK1 with her short term private key and then uses SK1 to decrypt the message. The short term public key pair can now be deleted. When Alice replies, she sends the message and a new SK2, encrypted with SK1, to Bob. Bob will decrypt with SK1 and store SK2. When he sends a message, he encrypts his message along with a new key, SK3, with SK2. This continues with a new symmetric key each time. Both parties must remember the last SK that they suggested to the other party, and also the last SK that they received from the other party. All others can be deleted. One might call the symmetric keys 'one time use' keys except that they can be used several times if one person replies to the other several times in a row. Thus the first initial message from Alice to Bob is not forward-secret, and the last several messages between them are not forward-secret, but all other messages are. Am I mistaken? Although I think I'd rather work on piggy-backing on an existing anonymity network to do forward secret instant messaging before all of that above. -Jonathan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Bitmessage
>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,
Re: [cryptography] Bitmessage
> Having an explicit motivation ("threat model" in security protocol parlance) would help in analyzing if this feature provides the desired benefits. You should also figure out what problems the cluster model doesn't solve and explicitly identify them. For an example of a threat model see section 3.1 of https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf I do have something similar to this written in Section 7 (on page 13) here: https://bitmessage.org/Bitmessage%20Technical%20Paper.pdf It has no threat model for the stream scalability design; this would depend on when spilling into new streams would be warranted (too much CPU usage? Disk IO? Sync time after being offline for two days?) I'm not yet sure which it will be. > The "proxy ack" feature you describe in section 7 is a single-hop fixed-usage onion routing mode. How about extending it to arbitrarily nested messages (with a separate proof-of-work on each one, of course)? Do you mean for including other types of messages like broadcast or public key messages? If yes, it can already be used for this and indeed msg messages can be nested within each other an unlimited number of times. > Why not include an auto-adjusting network difficulty factor like Bitcoin rather than requiring a client upgrade? The upgrade path you've described is indeed what would have to happen. The difficulty doesn't adjust automatically because spam is subjective. Using the number of messages broadcast through the stream/cluster to set the difficulty might be viable although it would leave new and rather empty streams susceptible to much more spam. This would have the effect of allowing users to choose the balance between spam protection and PoW time but it would be much easier for them to simply set a "demanded PoW" value and attach it to their public key and messages. > Have you considered replacing your bespoke PoW system with simply including Bitcoin postage on messages? The original creator of Bitcoin had this idea as well but the current lead developer believes that Bitcoin isn't actually very well suited for large volumes of micropayments because of scalability concerns. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Bitmessage
Hello everyone, I would like to introduce you to a communications protocol I have been working on called Bitmessage. I have also written an open source client released under the MIT/X11 license. It borrows ideas from Bitcoin and Hashcash and aims to form a secure and decentralized communications protocol which also doesn't rely on trust. Criticism of the X.509 certificate system is understandably common in this listserv (and also increasingly common in more public forums); Bitmessage instead uses Bitcoin-like addresses for authentication. It has a 'broadcast' and 'subscription' feature which other people have described as a decentralized Twitter and also aims to hide "non-content" data, like the sender and receiver of messages, from passive eavesdroppers like those running warrantless wiretapping programs. It may also be possible to be strong against active attackers although I'm not yet making that claim. 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. I'm sure that there is quite a bit of demand for such a program and protocol although I am currently not actively promoting it because it has not been independently audited. I would be interested to hear your comments. The website https://bitmessage.org links to various resources like a short whitepaper describing how the protocol works and what its goals are ( https://bitmessage.org/bitmessage.pdf ) and the source code on Github ( https://github.com/Bitmessage/PyBitmessage ). The main source code file is bitmessagemain.py. Bitmessage is written in Python and uses an OpenSSL wrapper called pyelliptic (written by a different individual) to implement ECIES and ECDSA. Again I look forward to hearing comments; it is always easier to change or add to a protocol earlier than it is later. All the best, Jonathan Warren ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography