BitMessage protocol modifications discussions to restore Anonymity at sending messages.

[chan] Crypto-Anarchist Federation
Jun 20 23:39

Session-less forward secrecy and cryptographic deniability using Triple Diffie-Hellman #1015 Open viralpoetry opened this issue 2 days ago · 4 comments Comments Assignees No one assigned Labels None yet Projects None yet Milestone No milestone Notifications Unsubscribe You’re receiving notifications because you commented. 3 participants @viralpoetry @PeterSurda @stman @viralpoetry viralpoetry commented 2 days ago • edited I would like to start a discussion how to change (or extend) current encryption protocol so we can use short therm ephemeral keys. This leads to a better security in an event of the long term key compromise. I propose, that we can create new pubkey object version which will contain long term key bundled with the short term session key, and publish this object to the network more frequently. Everyone can then create ephemeral key and compose a message based on the information already available on the network. The only requirements is, that the recipient must cache private parts for some time. My textbook example using BM pyelliptic: import hashlib import pyelliptic ''' Bob's identity key IKB Bob's signed prekey SPKB Bob's prekey signature Sig(IKB, Encode(SPKB)) ''' # This should be in the Pubkey message broadcasted by Bob IKB = pyelliptic.ECC(curve='sect571r1') # Bob's identity key SPKB = pyelliptic.ECC(curve='sect571r1') # Bob's signed prekey SigSPKB = IKB.sign(SPKB.get_pubkey()) # prekey signature # Alice keys # Alice verifies the prekey signature and aborts the protocol if verification fails. # Alice then generates an ephemeral key pair with public key EKA. IKA = pyelliptic.ECC(curve='sect571r1') # Alice's identity key EKA = pyelliptic.ECC(curve='sect571r1') # Alice's ephemeral key ''' Alice compute shared secret SK (with mutual authentification, as a result of IKA, IKB usage): DH1 = DH(IKA, SPKB) DH2 = DH(EKA, IKB) DH3 = DH(EKA, SPKB) SK = KDF(DH1 || DH2 || DH3) ''' DHA1 = IKA.get_ecdh_key(SPKB.get_pubkey()) DHA2 = EKA.get_ecdh_key(IKB.get_pubkey()) DHA3 = EKA.get_ecdh_key(SPKB.get_pubkey()) SKA = hashlib.sha256(DHA1 + DHA2 + DHA3) print 'Alice has:', SKA.hexdigest() # Bob compute DHB1 = SPKB.get_ecdh_key(IKA.get_pubkey()) DHB2 = IKB.get_ecdh_key(EKA.get_pubkey()) DHB3 = SPKB.get_ecdh_key(EKA.get_pubkey()) SKB = hashlib.sha256(DHB1 + DHB2 + DHB3) print 'Bob has:', SKB.hexdigest() # use SKA( == SKB) key as usual For more info on this protocol, check Bitmessage is by nature async protocol, so we should use this kind of construction instead of session based, like proposed in and,2981.0.html (which are also interesting!) This will solve the issues #563 #454 If somebody wants to test this, we should start collecting dependencies. @PeterSurda Member PeterSurda commented 2 days ago Since mirrorwish's post, I read more about how this is addressed, for example the double ratchet algorithm or puncturable encryption. I would like to use something like that. @viralpoetry viralpoetry commented 3 hours ago • edited My proposed key exchange is actually derived from one used by the Signal protocol. I was thinking whether it's not better to use session-less version where we do offline key exchange "trick". Thus every message is standalone with new key, we do not have to ratchet the symmetric keya as in the instant messaging protocols. Looking forward to see other implementation. @stman stman commented 6 minutes ago Hello. My two cents in this important discussion. I think it is essential to restore the most important original (initial) BitMessage specification characteristics : BitMessage shall stay a pure P2P broadcasting network with NO ROUTING. This is absolutely mandatory in order to allow Anonymity at sending and receiving messages, so that no passive eavesdropping on telecommunication networks could allow to discover who is sending messages to who. It is not the only thing to do in order to have Anonymity both at sending and receiving messages, but it is one of the main ingredients to have. In order to do what I said earlier, it is absolutely mandatory to stick, with no exception, to the original BitMessage White paper specifications saying that NO META DATA shall be expressed in clear text, even public encryption keys when using PKI. The whole messages must be fully ciphered, and as specified in the white paper, each client must "try to decipher" all the messages going through his node with all the private keys he has. Adding public key informations in clear text side-by-side with all the rest of the message+META DATA ciphered, definitely breaks the possibility to have anonymity at sending messages. Another important point I have already discussed with Peter, is that still, in order to ensure Anonymity both at sending and receiving messages is that BitMessage protocol must be corrected in order to make it a "Side & Hidden channel safe protocol". This constraint allow us to block all the identification technics based on fingerprints to work with TOR/VPN's. Doing so is absolutely mandatory too. Still, it is not enough to garantee Anonymity at sending messages. There is a third thing to do to remain Anonymous at sending messages : We are going to be obliged to implement something similar to what TOR does, but at the BitMessage protocol level : When posting a message to a chan, or to a user, the message shall not directly reach its target, we must implement the equivalent of the Onion strategy : When sending a message, you first do it to reach a first "random" user who's public key is already known by the sender, when the targeted user gets the message, it deciphers it, and realize that it has to relay it to another user, using the same process, etc ... Doing so at least 3 or 4 times, it finaly reaches a user who will relay the message to the final user / chan. What I have just said above is not very hard to build on top of what is already implemented in BitMessage : It means adding a kind of Onion Relaying functionnality in clients. We have to define how a client makes the difference between a message that was really destinated to him, from the message he has to relay to intermediate user. This is the only way to restore Anonymity at sending messages, both to Chans, and to specific users. Please note that in the end, it is not that much TOR that provides true Anonymity at sending message, but this internal relaying protocol. Using TOR with BitMessage is only a good way to bypass firewalls and cipher the whole trafic of a peer from an attacker that would be monitoring your personnal internet access. I don't know if my explainations were understood, but I am okay to plan a Mumble session with both of you to explain this to you. Restoring Anonymity at sending messages, military grade, is the most difficult thing to do. It cannot be solved with a single strategy. It need several tricks that combined, offer true Anonymity at sending messages. Kind regards, Stman. BM-2cWZW87PJN5VZjtJCpk3hXcYefhNCxdjU6 @stman stman commented 20 seconds ago Of course, doing so makes sending those messages in "Full Anonymity Mode" much slower, because of all the added delay due to relaying, but it worth it because all know "network trafic & timing analysis based" identification technics to fail. We could make this "Full Anonymity" option "selectable" through a new button on the user interface that handles composing new messages to send. Restoring Anonymity at sending messages, provenly, through combined tricks, is something that is going to please all users of BitMessage.

[chan] Crypto-Anarchist Federation
Jul 4 22:47

Perhaps this method should be used to invoke request for a second prekey from the recipient, and halt the send protocol until recipient responds with unique key encrypted with prekey. In other words every message sent between private addresses would be encrypted using unique keypairs *for that message* on each end. It would take longer, waiting for recipient response but would be much more secure. The scheme could have both options: what was proposed below, or the paranoid option I just proposed. The interface could have a settings option: "Force bitmessage to use unique encryption keys for every message."

[chan] Crypto-Anarchist Federation

Subject Last Count
The Real Ed Snowden Is a Patsy, a Fraud and a Kremlin-Controlled Pawn Oct 21 22:06 1
Flat earth We didn't land on the Moon Former NASA Scientist admits Game over for NASA Oct 21 21:53 1
Scientist Shows Proof That Rockets Do Not Work In The Vacuum of Space Oct 21 21:48 1
Do You Believe In Magic? Apollo - Soyuz Oct 21 21:41 1
Active measures (Russian: активные мероприятия) is a Soviet term for the actions of political warfare conducted by the Soviet security services (Cheka, OGPU, NKVD, KGB) to influence Oct 21 21:39 1
Neil deGrasse Tyson Exposed - Hollywood Actor Oct 21 21:32 1
Richard Spencer and His Kook-Right Ilk Are Agents of Russian Influence Oct 21 21:29 1
This man is Johnny Cash reincarnated.. and he's a flat earther this time. Oct 21 21:26 1
British Subversion of the United States: The militias and Pentecostalism Oct 21 21:25 1
Interview w/ Former NASA Employee Turned Flat Earther Oct 21 20:57 2
Flat Earth Man sings a song to you - Photoshop Cartoon Earth Photos Oct 21 20:43 1
A Flat Earth Song: "Puppet Show" YOU HAVE TO HEAR THIS!! Oct 21 20:33 1
Google Project Loon Proves Flat Earth Oct 21 20:23 1
Former NASA Scientist Confirms the Flat Earth What he said will Amaze You Oct 21 20:14 1
NASA Insider Exposes the Flat Earth! Oct 21 20:05 1
Neil Disgrace Tyson is Falling Faster Than The Globe Oct 21 19:57 1
Message to Julian Assange Oct 21 19:25 6
Wall Street Market's IP address is exposed Oct 20 21:04 1
Thougths about Crypto-Anarchism, and the Cyber-Space paradox with the meat space. Oct 20 06:48 2
Aes encryption algorithm life time [closed] Oct 18 21:00 3
Julian Assange and Pedophile Baby Farms Oct 18 20:53 1
Wikileaks - Made By The NSA Oct 18 19:20 1
cast: CHANBOT Response Oct 17 17:47 4
help: CHANBOT Response Oct 17 09:26 3
OTP talk by Frank Rieger at 19c3 (mp3/mp4) Oct 17 08:36 1
new chanbot 'cast' command Oct 16 19:15 1
VPN & Firefox (+ other Gecko browsers)* rev. 0.3.10 Oct 16 14:55 1
OMEGA release 38 is available for download Oct 16 10:10 1
Tribler Makes BitTorrent Impossible to Shut Down Oct 16 09:43 1
Your privacy - VPN & Firefox (+ other Gecko browsers)* rev. 0.3.9 Oct 15 09:18 1
Message by Julian Assange. Oct 10 05:31 1
They can knock all of my TORs down, I won't say a word Oct 8 20:21 2
Message to a friend, with copy for Julian Assange Oct 8 17:22 1
most secure darknet Oct 6 13:01 2
i2p anonymity can be compromised by controlling only 2% of the network. Oct 6 05:54 3
Rogue NSA-controlled Tor nodes Oct 5 17:26 1
Steganography against security Oct 5 17:22 1
One of the most important papers of contemporary cryptohraphy. Oct 5 17:11 1
twister micro blogging Oct 4 18:28 5
One of the most important papers of contemporary cryptology Oct 4 15:09 1
crypto currencies Oct 4 03:15 14
OMEGA release 37 is available for download Oct 3 23:01 1
Unique non-mainstream non-political-correct cryptographic source code Oct 3 19:44 2
World's Most Secure OS now FOSS Sep 30 23:45 1
Gang Stalking & NWO - The begining Sep 30 15:36 1
addon to pyBM : otp crypter -- soon to be integrated into BM for extra safety ! Sep 29 09:56 2
Best? Sep 29 08:13 5
How long have you been using BM? Sep 29 07:23 6
tor browser sandbox 0.0.20 r48240 Sep 29 02:17 1
Feature Mashup Sep 29 02:02 1
Your privacy - VPN & Firefox (+ other Gecko browsers)* rev. 0.3.7 Sep 28 00:21 2
WHATSAPP ENCRYPTION <<<<<<<<<<< Sep 27 23:44 5
shadowchat vs. BM comparison Sep 27 00:32 2
Improving Stateless Hash-Based Signatures Sep 25 13:11 1
UPDATED : Rewarded help needed for scanning old amazon (Or any other website) shipment barcodes (Reward 10€ in Bitcoin per scan). Sep 24 14:41 1
Just like Christmas - Old Windows source code + KAV8 source code Sep 24 13:46 1
NATO member Turkey boast that Russian S-400 SAMs can take out American B-52s, F-22s and Tomahawks Sep 24 08:07 1