BMR + BRO = Bit Minion Remailer + Bitmessage Relay Overlay

Aug 9 18:12 [raw]

BMR + BRO = Bit Minion Remailer + Bitmessage Relay Overlay: Beyond Paranoid Security for Ultra-Sensitive Messages by gumshoe @ BM-2cTGkkyxyzFEY4bKnEdayPsuFwrPKBKSCr _______________________________________________________ [chan] gonk BM-2cUzscdDzAKZSr14PtCLMpcRFYMPQK3Fs3 _______________________________________________________ The Bitmessage protocol offers more security and anonymity than email. It automatically manages encryption keys and key publication with no need for key servers. The strong encryption coupled with lack of metadata (message headers) and fluffed flood routing strongly obfuscate message endpoints. Some entropy-building with proof-of-work, and path-time expansion could strengthen anonymity against pseudospoofing and traffic analysis. A proposed improvement is a Bit Minion Remailer via a Bitmessage Relay Overlay (BRO+BMR, hereafter referenced as 'BRO' and 'BMR'). The proposed BMR system is a cascade-cipher, remailer architecture overlaid on the Bitmessage protocol. The BMR inserts random time, packet shrinkage or payload resizing, and complexity to a message path. Additional cryptographic sleight-of-hand stacks enormous entropy against traffic analysis and pseudospoofing. Each Bitmessage peer would generate a temporary relay address and publish this address with its expiration time and corresponding public key to all peers in the flood protocol. This address would receive messages and never send. Once many BRO keys are published peers would publish their BRO keys via other remailers instead of directly into the protocol message stream - BRO keys will propagate in the same paranoid path as BRO messages (with much shorter delays), described below. The remailer is a ultra-high-latency envelope tunnel similar to the old mixminion multi-envelope encryption, also used in low-latency onion routing. A message is cascade-crypted to a recipient - it is envelope encrypted with keys from a chain of intermediaries and sent to the first intermediary peer in the chain. The first peer decrypts the outer envelope which reveals another encrypted envelope and a single routing instruction with a delay flag. The peer adds its own random delay to the delay flag and holds the object until the delay timer has run. Then it forwards to protocol stream, where the object finds the next peer in the chain, and the next peer repeats the process. By the time the message moves to the exit of the chain the random delays, the circuitous route, and the change in message size from removing padding each step, the sender is sanitized. Timing attacks and pseudospoofing are out of the question. To send a bitmessage via the BMR, the sending peer (origin) selects a chain of two to seven remailer keys from intermediary peers (hops). The sender encrypts a message to the recipient with sufficient time-to-live to survive the prolonged transit through the remailer tunnel. The sender generates a temporary address for each encryption to each BRO peer, unlinking his real address from the addresses used to encrypt to the remailers. The sender could also destroy the key used to encrypt the recipient payload, unlinking himself from the recipient. The sender encrypts the recipient's encrypted blob to the address of the exit peer. Then the encrypted blob is wrapped in several layers of encryption--one layer for each prior hope in the peer chain, performing necessary proof-of-work on each payload with a different encrypting address key for each link in the chain. After the proof of work and encryptions are complete the sender releases the payload into the network in the usual way. It looks no different than any bitmessage object. This payload makes its way throught the random network paths until the first BRO recipient decrypts the first envelope. This BRO recipient holds the next payload for a random delay before releasing it to the network. To a eavesdropper it simply appears as a message object of no special importance. The cryptographic 'onion peeling' continues at each BRO peer in succession until the final hop removes the last layer of encryption. It unfolds like a Tor circuit in ultra-slow motion with many more hops from origin to sender than Tor provides. After delay the exit peer releases the payload to the network to find yet another random 'fluff route' to the final recipient, which is able to decrypt the core of the message 'onion'. A hop peer should withhold a remailer object for a duration that causes its apparent order to get lost in the shuffle with other messages of like size. To make this easier, random, PoW'd, single-use padding payloads could be enclosed during each envelope encryption. This empowers a hop node with more chances to resize the 'payload burst' to peers, so the payload transmission size is equal or approximate to that of other payloads it fowards. This will add to resistance against traffic analysis. Padding is not mandatory but beneficial. It enables faster transit times by allowing BRO peers to bluff the object size to an observer, apparently mixing it with unrelated objects. In this way the same message will appear to grow or shrink at each hop, adding more confusion to traffic analysis. To mitigate asymmetric work attack, the sender would compute significantly higher proof-of-work for every element and padding packet. This proof of work would of necessity be much higher than any proof-of-work performed by the remailers for padding generation. A message may be broken into shards and each shard sent via a separate chain of remailers at different times. This would provide additional security against malicious remailers. A short time-to-live and high key generation time would mitigate malicious Sybil nodes drowning out other remailers with pseudospoofing. The BRO mailer concept has a marked improvement over the mixmaster and mixminion remailers. 1. In cypherpunk / mixminion type remailers, the phyical location and IP address of remailers is generally known, subject to intervention, confiscation, and compromise; 2. In the Bit Minion Remailer concept nothing can be done to discern the location of a remailer in the chain. The remailers are as anonymous as the sender and receiver (slightly more anonymous). Here is a recap of the concepts that BRO uses to defend message anonymity: 1. random packet resizing - growth and shrinkage of padding at each hop. 2. random size matching - packet resizing to match the size of unrelated payloads. 3. unlinked random time expansion - both sender and remailers add delays. 4. path fracturing - the payload's path to final endpoint is fractured 2-7 times. 5. remailer obfuscation - it is impossible to physically locate any remailer. 6. remailer anonymity - the remailers are slightly more anonymous than the sender; the recipient will have no knowledge of any remailer in the chain; the recipient will not be able to distinguish between a remailed message and a direct message. 7. message sharding - sending parts of the message on separate routes at separate times in random order. 8. indistinct payloads - every step of the chain a BRO message looks like any other message. 9. ultra-high latency - origin to destination can take hours if desired by sender time flags. 10. remailer cycling - all remailer keys expire, defeating pseudospoofing and remailer location analysis. 11. address unlinkability or unlinked keys - each hop in the chain is encrypted from a different, temporary address that will not be re-used, breaking the link between sender's real address and the remailers. The Bit Minion Remailer concept has potential benefit where absolute anonymity is required: 1. communication between persecuted minorities. 2. intelligence communications. 3. revolutionary activities. 4. sensitive journalism. 5. whistleblowing and political criticism in hostile environments. 6. leaking criminal behavior in organizations or state bodies. 7. anonymous exchange of crypto-currencies. 8. corporate communications The Bit Minion Remailer need not be confined to Bitmessage. BMR could be overlaid on any message transmission protocol that uses anonymous addressing and route obfuscation, generating significantly increased anonymity and absolute unlinkability to the sender. X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X

Aug 9 18:55 [raw]

scam !

Aug 10 10:44 [raw]

Maybe worth to mention... People using Remailers, like Mixmaster, can already send messages to a BM address when the BM user right clicks on his address and sets up an email address via the mailchuck email gateway. If mailchuck would allow also payment with Monero, instead of Bitcoin, one could then send also outfiles, created with Mixmaster to the Remailer Network, because the message size of a Mixmaster message fits, if i'm not mistaken, into a BM message.

[chan] bitmessage

Subject Last Count
BM Nov 20 04:26 2
Vuvuzela - anonymous messaging that scales to millions of users Nov 19 11:56 25
How do I benchmark bitmessage PoW Nov 15 22:13 3
Support request -- GPUs (Intel(R) HD Graphics IvyBridge M GT1) did not calculate correctly Nov 15 17:04 2
Spam... Nov 15 17:02 4
Ebola on the rampage in USA again Nov 13 06:47 1
ending the waffle Nov 13 04:56 7
forwarding in BM Nov 12 15:04 5
Dear Freemasons Nov 12 07:13 2
CSS3 in Bitmessage interface Nov 12 06:56 1
Pastwatch & Aqua Distributed Version Control Nov 11 11:56 1
SOLUTION for spam Nov 11 11:56 23
Vuvuzela - Metadata-private messaging Nov 11 11:56 1
tes Nov 9 11:19 2
I'm back Nov 9 03:35 8
Bitmessage Network Health Report Nov 7 23:48 12
nodejs clientr KEWLIO Nov 7 07:26 4
Scalability Idea Nov 7 07:24 7
Do NOT spam Nov 7 03:09 8
here is the trick to run pyBM on a server without trouble Nov 5 18:41 8
Scalability Question?? Nov 5 09:09 3
re Re: Scalability Question?? Nov 5 08:21 1
aaa Nov 5 02:48 1
Bitmessage Plugins Nov 3 21:33 3
Any nodejs interface to the bitmessage api yet? Nov 3 19:12 2
Recent API status bug Nov 2 12:38 9
zero bundle -- 0net Nov 2 10:41 4
zero git on 0net Nov 1 12:43 6
(no subject) Nov 1 02:48 5
greetings Oct 31 23:05 3
Re: Oct 31 22:25 1
{ ^ } break { ^ } Oct 31 22:11 1
(no subject) Oct 31 14:33 4
INVALID FORMAT Oct 31 12:12 6
hello world Oct 31 07:40 1
Is there anybody out there? Oct 30 08:03 1
join the darknet - be badass at leakswldjpesnuvn.onion Oct 29 20:33 5
more cores, slower pyBM Oct 29 01:36 15
new bitboard thread Oct 27 17:17 3
http://leakswldjpesnuvn.onion seems stable Oct 27 16:36 1
spot the spammer Oct 27 09:37 3
oniontkryve46opu.onion Oct 27 09:01 2
3 BM websites and all fucked Oct 26 21:00 12
Newcomer Oct 26 18:36 10
135453 Oct 25 22:06 1
Stay in touch Oct 25 13:06 1
new BM site online Oct 25 10:39 3
134730 Oct 25 09:59 1
BM is flatlining : Oct 25 08:13 9
a new bitboard went online Oct 25 02:10 4
BM is flatlining : Oct 25 00:23 1
sql Oct 24 22:44 1
how I hacked BM Oct 24 22:11 3
--curses mode with bitboard crashy Oct 24 21:30 5
BMF bug Oct 24 04:21 1
onion4442sx7tvvk.onion ONION 444 new website for BM ! hot shit ! Oct 24 04:21 3
running pyBM as daemon on a remote server Oct 24 04:21 9
post with \ backskash Oct 24 04:21 1
BM is flatlining : 1200 bytes the average object Oct 24 04:17 2
how I hacked BM Oct 24 04:17 3
secret bin for Bitmessage people Oct 24 04:16 2
post with \ backskash Oct 24 04:11 1