BMR + BRO = Bit Minion Remailer + Bitmessage Relay Overlay

Aug 9 17:56 [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

[chan] Crypto-Anarchist Federation

Subject Last Count
1 Sep 19 13:20 2
111 Sep 18 22:09 1
eita Sep 14 20:36 1
ankw Sep 14 20:36 1
ltd Sep 14 20:36 1
ycy Sep 14 20:36 1
bzgk Sep 14 20:25 1
imy Sep 14 20:25 1
pmrc Sep 14 20:14 1
vgz Sep 14 20:11 1
npjyr Sep 14 20:08 1
puij Sep 14 20:05 1
yml Sep 14 20:03 1
vcw Sep 14 20:02 1
kbkz Sep 14 19:58 1
byfx Sep 14 19:58 1
vdqqy Sep 14 19:57 1
ngcj Sep 14 19:56 1
ficeu Sep 14 19:54 1
gduv Sep 14 19:46 1
yczg Sep 14 19:46 1
jiy Sep 14 19:45 1
xun Sep 14 19:44 1
zft Sep 14 19:44 1
eto Sep 14 19:44 1
mqtjx Sep 14 19:44 1
uow Sep 14 19:43 1
odo Sep 14 19:43 1
bjzd Sep 14 19:41 1
pczer Sep 14 19:23 1
dob Sep 14 19:23 1
dni Sep 14 19:23 1
xldp Sep 14 19:23 1
ukzj Sep 14 19:20 1
yhx Sep 14 19:15 1
egjo Sep 14 19:12 1
zxg Sep 14 19:07 1
gihxd Sep 14 19:07 1
rqow Sep 14 19:07 1
sgaj Sep 14 19:07 1
mvttv Sep 14 19:06 1
lakyj Sep 14 19:04 1
jxns Sep 14 19:03 1
sbxp Sep 14 19:00 1
sgqic Sep 14 18:59 1
cxr Sep 14 18:58 1
cur Sep 14 18:56 1
malxq Sep 14 18:56 1
hhjf Sep 14 18:56 1
gyei Sep 14 18:50 1
dhfiw Sep 14 18:48 1
qkz Sep 14 18:32 1
zqzc Sep 14 18:31 1
aanp Sep 14 18:29 1
llezn Sep 14 18:25 1
ybqir Sep 14 18:10 1
orl Sep 14 18:10 1
tfbhw Sep 14 18:00 1
wha Sep 14 17:48 1
ovv Sep 14 17:48 1
rch Sep 14 17:44 1
rdxp Sep 14 17:44 1
zom Sep 14 17:40 1
vmdk Sep 14 17:37 1
pxvwp Sep 14 17:34 1
kkrdt Sep 14 17:31 1
ukbw Sep 14 17:30 1
gzsh Sep 14 17:29 1
yilmg Sep 14 17:19 1
rtpqj Sep 14 17:17 1
egxt Sep 14 17:12 1
shymw Sep 14 17:12 1
lgn Sep 14 17:08 1
cga Sep 14 17:08 1
rmlc Sep 14 17:08 1
jom Sep 14 17:08 1
rcc Sep 14 17:08 1
qht Sep 14 17:06 1
ukqep Sep 14 16:47 1
puxwg Sep 14 16:47 1
shin Sep 14 16:47 1
uftg Sep 14 16:47 1
gfp Sep 14 16:46 1
xjz Sep 14 16:39 1
afnp Sep 14 16:38 1
jokre Sep 14 16:36 1
acsyd Sep 14 16:30 1
zkqnl Sep 14 16:29 1
qpx Sep 14 16:29 1
zwlf Sep 14 16:29 1
eiu Sep 14 16:25 1
rgvs Sep 14 16:19 1
qkcs Sep 14 16:19 1
ewoe Sep 14 16:13 1
aylru Sep 14 16:11 1
ljacu Sep 14 16:06 1
dmub Sep 14 16:06 1
vithq Sep 14 16:06 1
zfcv Sep 14 16:01 1
glwvv Sep 14 16:00 1