PyBitmessage Security Scan on Branch v0.6

[chan] de995093c3873da70881ddf0bc1bb0f714ff361e653a1030d193497dbaba6355
May 26 07:23 [raw]

Sure, Granny. Bitmessage sucks mightily, because its code is full of security holes and vulnerabilities exploitable by attackers.

[chan] alt.anonymous.messages
May 26 07:35 [raw]

If there were a highly secure alternative to Bitmessage, with no encoding, regex, database, xss vectors, etc. with proper security auditing and proof of its security, how many people would use it?

[chan] general
May 26 10:35 [raw]

> If there were a highly secure alternative to Bitmessage An alternative to what exactly? To Bitmessage, the protocol, or to PyBitmessage, the reference open-source Python client maintained by Peter Surda?

[chan] general
May 26 18:34 [raw]

PyBM

[chan] Crypto-Anarchist Federation
May 26 22:58 [raw]

No, it does not mean that. However there are some severe security issues with Bitmessage. 1. Pickle - remove it entirely, use flat text files and pattern matching to sort the data - no external module should be used for sorting data. 2. XML - remove it entirely, use flat text files or monkeypatch - same as pickle - XSS exploits can attack through this module. 3. Eval() - thankfully was removed, should not be used at all. When coding high security software you do not rely on external libraries unless they are certified high security and someone is accountable for it and standing behind the product. You roll your own functions from scratch, tailored to the security application, to eliminate attack surface. OpenSSL is an example. It can't be trusted. Switch to LibreSSL or roll your own. TLS is an example. It can't be trusted. Switch to SSH or roll your own. The BSD crew got it right with crypto security and they stand behind it and are accountable, so it is marginally safe to use their libraries. This is not so for OpenSSL, TLS and most Python libraries.

[chan] Crypto-Anarchist Federation
May 27 05:30 [raw]

> You don't roll your own security functions EVER " . . . anyone concerned with real security probably should consider using something other than the same cipher as everyone else. . . . . . Our opponents operate in secrecy and do not reveal their successes. If they break our cipher and take some care to protect the results, we will continue to use that broken cipher, all the while assuming our data is protected. Confidence from long use is a self-delusion that springs from not specifically being told that our cipher has failed. We hope that our lack of knowledge means that our cipher has not been broken. But if hope were enough, we wouldn’t need cryptography." (Terry Ritter) [http://ciphersbyritter.com/ARTS/R8INTW1.PDF] This article is a must read. It debunks the myth that you should not roll your own crypto. What if our enemy is the open source crytpo community itself? What if they have given us ciphers to which they know the back door or quadratic equations to disassemble ciphertexts? Then they tell us, "use our crypto, NEVER roll your own." What if?

[chan] Crypto-Anarchist Federation
May 27 07:47 [raw]

Ritter is right. Herd is wrong. Somebody please read Snowden leaks. NSA spends millions and millions on dedicated HARDWARE to attack crypto. Now think about their "joy" when they discover that their ultra-speed cracking machines are totally useless, because more and more people use "custom crypto". My personal advice for people would be: use also polymorphic cryptography to keep NSA in the dark even more. I know people who replaced ciphers in source code of their in-house SSH implemetations. I know people who use block ciphers without their respective keyschedules, but with loading random bits directly to cipher state. I know people who kept "standard" ciphers and hashes in their SSH/SSL but they patched constants used in these ciphers/hashes to make hardware attacks impossible. These people are not some boy scouts. They were INSIDE TLAs. They told me that these two strategies are a must to be more secure against surveillance.

[chan] bitmessage
May 27 09:26 [raw]

"Loading random bits as round keys can significantly decrease strength of the cipher" Not really. Read Applied Cryptography, many ciphers can be strengthened using independent random subkeys. Also, how changing some "nothing in my sleeve" constants in SHA algorith with some purely random ones can make it weaker? SHA security does not depend on exact values of these constants. You can replace Pi with any otrher random data in Blowfish. You can directly load random data to Blowfish state. You can use random subkeys in IDEA. You can skip keyscheduling in TEA ciphers family. And so on. Of course in some ciphers constants and S-Boxes are explicitly predetermined by indispensable mathematical relations and can't be touched. But I am talking only about totally replaceable non-critical values. So one can easily patch his VeraCrypt copy to use non-standard constants and make NSA job a nightmare. And then we can apply such "rogue" ciphers in cascades.

[chan] general
May 27 09:57 [raw]

All of these are weak compared to the bastard nightmare I made.

[chan] sex
May 27 10:20 [raw]

Tell me more.

[chan] G3N3RAL
May 27 11:21 [raw]

> Ritter is right. Herd is wrong. +1 Unlike the open source crypto gatekeepers, Ritter actually successfully sold his crypto to businesses and made a living of it. You will not find ego in any of his papers, whereas his detractors scream their own egotism and cultism, and have cult followings. I agree with your suggestion of polymorphism - each cipher should be polymorphic, use different keys, use random padding and xoring to eliminate metadata, and wrap at least 3 algorithms around each other. In addition to polymorphism the element of unavoidable work, where large memory resources are required to encrypt and decrypt, further frustrates brute force of keys and cryptanalysis. For starters key generation from the passphrase should take at least a few seconds and consume a couple hundred megs of ram. Then enciphering or deciphering each block should be difficult to a smaller degree. This makes running a cracker in parallel geometrically more expensive. Highly efficient ciphers with neglibible memory requirements are mathematically much more susceptible to brute forcing key space.

[chan] general
May 27 17:50 [raw]

I like nightmare stories. Spin the tale, dear detective.

[chan] general
May 28 10:50 [raw]

Congrats, now did you want to catch up on the last 20 years ?

[chan] general
May 29 03:19 [raw]

In case you haven't noticed, nothing has changed in 20 years. They're still using the same old crypto. And Ritter is still in business with his private consulting, making money just selling rights, for which businesses gladly pay a hefty sum, so they don't have to use openssl and GNU products.

[chan] general
BM-2cW67GEKkHGonXKZLCzouLLxnLym3azS8r

Subject Last Count
0591487CDD96037B44FB93CC639B9456 Aug 16 19:24 1
double down -- UK Column News Aug 16 00:07 1
560C503734039BC1B748A353C4A2C94A Aug 15 15:42 1
54624370B2EAF49AC65BD7B575A20934 Aug 15 15:12 1
A641BC21CCDA3809665E8DB422C32607 Aug 15 15:12 1
UK Column News - 13th August 2018 Aug 15 07:44 2
08B3115B5AD1EBDC4A15FABEA12590C6 Aug 15 07:44 1
UK Column News - 16th August 2018 Aug 15 07:44 1
FEE42368E2751EA5A5697DBDD3462AD8 Aug 15 07:44 1
UK Column News - 15th August 2018 Aug 15 07:44 1
UK Column News - 14th August 2018 Aug 15 07:38 1
decrypted some of the crapflood spam Aug 14 14:46 1
https://www.justice.gov/file/1080281/download Aug 14 13:10 2
huowb Aug 13 21:27 1
sldy Aug 13 21:27 1
uvjrk Aug 13 21:27 1
owhdbgk Aug 13 21:27 1
bkqi Aug 13 21:27 1
yyq Aug 13 21:27 1
cvjcu Aug 13 21:27 1
mzm Aug 13 21:27 1
tbhas Aug 13 21:27 1
eanxqgm Aug 13 21:27 1
hdrtq Aug 13 21:27 1
wxe Aug 13 21:27 1
zdodp Aug 13 21:27 1
rxllbhh Aug 13 21:27 1
crcumoi Aug 13 21:27 1
ojkqa Aug 13 21:27 1
fllrcu Aug 13 21:26 1
khscyti Aug 13 21:26 1
dwejgo Aug 13 21:26 1
hhu Aug 13 21:26 1
jox Aug 13 21:26 1
reswg Aug 13 21:26 1
odzwdn Aug 13 21:26 1
ajdk Aug 13 21:26 1
rzxjgre Aug 13 21:26 1
rgp Aug 13 21:26 1
fsktumz Aug 13 21:26 1
qycybu Aug 13 21:26 1
sgthuek Aug 13 21:26 1
xgpuinq Aug 13 21:26 1
czwazg Aug 13 21:26 1
inyu Aug 13 21:26 1
fdpg Aug 13 21:26 1
uhkmxr Aug 13 21:26 1
fzo Aug 13 21:26 1
egqpdi Aug 13 21:26 1
zxpc Aug 13 21:26 1
vqnzzr Aug 13 21:26 1
pcqd Aug 13 21:26 1
nnb Aug 13 21:26 1
iiivwjs Aug 13 21:26 1
ertif Aug 13 21:26 1
ewyog Aug 13 21:26 1
phxa Aug 13 21:26 1
vhynjlh Aug 13 21:25 1
qrmz Aug 13 21:25 1
rdo Aug 13 21:25 1
qxyyle Aug 13 21:25 1
nsmo Aug 13 21:25 1
qsnewik Aug 13 21:25 1
aso Aug 13 21:25 1
ndjagg Aug 13 21:25 1
opci Aug 13 21:23 1
ckijqrm Aug 13 21:21 1
biwmvg Aug 13 21:20 1
wofmd Aug 13 21:20 1
kleigta Aug 13 21:20 1
mlnmrm Aug 13 21:20 1
fbj Aug 13 21:20 1
tkh Aug 13 21:20 1
ycikif Aug 13 21:20 1
chy Aug 13 21:20 1
mzknth Aug 13 21:20 1
onnghr Aug 13 21:20 1
hobrbm Aug 13 21:20 1
oxab Aug 13 21:20 1
fdxmjhy Aug 13 21:20 1
uxsltle Aug 13 21:20 1
taxzlpy Aug 13 21:20 1
jzdy Aug 13 21:20 1
ktgeab Aug 13 21:20 1
eganzh Aug 13 21:20 1
tbiij Aug 13 21:20 1
gsd Aug 13 21:20 1
shtt Aug 13 21:20 1
rzy Aug 13 21:20 1
mcpryvd Aug 13 21:20 1
nhitwh Aug 13 21:19 1
ikpwpka Aug 13 21:19 1
ncfrgul Aug 13 21:19 1
wzyh Aug 13 21:19 1
oouyniy Aug 13 21:19 1
vntexgy Aug 13 21:13 1
otovrni Aug 13 21:13 1
qprndcl Aug 13 21:13 1
xjrgylf Aug 13 21:13 1
prgr Aug 13 21:13 1