- cypherpunks-legacy - lists.cpunks.org

Re: [liberationtech] Cryptography super-group creates unbreakable encryption
by Fabio Pietrosanti (naif) 06 Jul '18

06 Jul '18

Here some notes i collected with a quick review of the source code: https://pad.riseup.net/p/silentcircle -naif On 2/14/13 1:36 AM, Nadim Kobeissi wrote: > This is good news! Still far from a complete source code release, but > it's good that they're progressing, even if very slowly. > > Once all of the code is out I'll finally shut up about Silent Circle. > > > NK > -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] ICIJ's project - comment on cryptography & tools
by ianG 06 Jul '18

06 Jul '18

On 8/04/13 04:06 AM, Peter Gutmann wrote: > "Kevin W. Wall" <kevin.w.wall(a)gmail.com> writes: > >> I think you're giving the NSA way too much credit on why security sucks. Even >> if we were to restrict 'security' to the scope of cryptography, even there, I >> think the NSA has much less to do with dumbing down crypto security than >> other factors. > > Exactly. If the NSA didn't exist at all the only difference we'd notice is > that there'd be less of this weird obsession with ECDSA (via pressure to adopt > Suite B). Computer security as a whole wouldn't suck any less. I think we all suffer a fair amount of cognitive dissonance on this one. We all know stories. DES is now revealed as interfered with, yet for decades we told each other it was just parity bits. The same process happened to GSM -- MiBs specified the 40 bit key, but because it was a secret design, they didn't need to create a legend to hide the 16 bits of zeroes. Add in export control regs, add in the war against PRZ. If someone where to do a longitudinal study of the public knowledge of the interference, I think it would mount up. Individually, we can ignore those stories as conspiracy theory, but in aggregate, much harder. >> IMO, the biggest factor is that 95% or more of developers are completely >> ignorant of best practices in cryptography. > > At the other end of the scale, 99.9% of developers who do know security have > no idea how to create *usable* security. At the moment there are exactly two > crypto-using products I can think of that I'd feel confident a random member > of the public could walk up and use, those being Skype and iMessage. This is the good news. I think the message has finally got through that usability is more important than classical CIA, etc. > (Unfortunately to the crypto-purists they're not good enough because they're > MITM-able. You should be tunnelling SIP over OpenVPN, it's really easy, > here's a pointer to a list of links to 100-page discussion threads on web > boards for ways of doing this that may work sometimes). Yeah. This is a mystery to me, where did this crap come from? Although it aligns perfectly with the geek mentality, other specialties in CS tend to create a greater resistance to the guild mentality. I can't pin the causality on it as yet. > Incidentally, the NSA is, from all the reports I've seen, even worse than we > are at making security usable. My favourite publication on security > usability, Laura Heath's "An Analysis of the System Security Weaknesses of the > US Navy Fleet Broadcasting System, 1967-1974, as exploited by CWO John > Walker?", goes into this in more detail. A great read! An interference attack can be extremely high-leverage. Being good at it can do a lot of damage. This however doesn't mean that one is any good at defence. > Peter. > iang _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: remailers-tla.htm Compromised Remailers, December 15, 2003
by S 06 Jul '18

06 Jul '18

Thank you for posting the "Compromised Remailers" article: http://cryptome.org/remailers-tla.htm Over the past year, many remailer users have noticed that the reliability of the Mixmaster type II network has steadily degraded. Although it may well be the result of TLA interference, the remailer community's statistical methods of selecting a "reliable" remailer chain contribute significantly to the network's degradation. As a former employee of the United States Army Communications Command [USACC] Headquarters, I was amazed to stumble upon the existence of a publicly available communications medium permitting truly anonymous communication by hampering the government's ability at "traffic analysis," or tracking an email message from its source to its destination. One would have to be foolish to believe that TLAs are not hard at work trying to pierce the veil of anonymity afforded by the Mixmaster type II, and, the yet to be released, type III remailers. I ran tests in September, October & November, and provided the Mixmaster developers & remail operators with the same results I've included below. My testing was extremely simple: send a bunch of messages, and note which messages arrived. [The same procedure an accountant would use in tracking a financial transaction from its origin to its destination.] What I found was that a handful of remailers accounted for virtually all of the un-delivered email messages. Yet, these same remailers, that never delivered my email messages to the "alt.anonymous.messages" news group, where also listed as among the most reliable remailers in mixmaster stats used to select remailer chains. I've included my recommendations to improve the network's reliability in the test results below. ----------------------------------------------------------------------------- Mixmaster II Reliability Issues & Test Results ----------------------------------------------------------------------------- The major issue currently plaguing the Mixmaster remailer network is the true reliability of the LAST remailer in a chain. A considerable number of these remailers habitually act like "Black Holes" for email messages destined for "alt.anonymous.messages" and other news groups. Unfortunately, most of these "Black Hole" remailers also happen to be listed as among the most reliable remailers in mixmaster stats, with ratings ranging from the upper 90's to 100; consequently, it's highly probable that messages sent to newsgroups will frequently hit one of these demon remailers, never to reach their intended recipient. Over the past 2 months, I've sent & tracked over 5,124 email messages consisting of either 4 or 6 copies of 1,220 unique messages, each routed through 11 Mixmaster type II remailers, to the "alt.anonymous.messages" news group. --------------------------------------------------------------- Last Remailer Lost Msgs Delivered Msgs % Reliability --------------------------------------------------------------- antani 63 0 0 cripto 65 0 0 hastio 41 0 0 george 31 7 18 paranoia 41 10 20 futurew 33 9 21 edo 27 9 25 starwars 54 29 35 itys 7 9 56 italy 7 10 59 bog 3 14 82 freedom 3 45 94 tonga 5 106 95 liberty 2 51 96 panta 3 69 96 bigapple 3 104 97 metacolo 3 99 97 bogg 1 52 98 dizum 2 106 98 jmbcv 1 59 98 frell 0 34 100 randseed 0 3 100 --------------------------------------------------------------- Sub-totals 395 825 68 --------------------------------------------------------------- Total 1,220 --------------------------------------------------------------- Surprisingly - at first - I found that sending messages through chains of remailers rated, in mixmaster stats, at 98% or greater was FAR LESS reliable than sending messages through remailers rated at 50% or greater. This is because the "Black Hole" remailers were almost always rated, in mixmaster stats, at 98% or greater reliability, while the remailers that were the most successful at delivering my messages were usually rated, in mixmaster stats, at reliability ratings of 90% or lower. For those of you yelling, "it's the broken chains, dumbass!" I strongly disagree. Messages sent through broken chains were more than twice as likely to successfully reach the intended news group than were messages that failed. -------------------------------------------- Messages Sent Through Broken Chains (copies of the same message) -------------------------------------------- Copies Lost Delivered -------------------------------------------- 4 13 31 3 40 92 2 94 218 1 154 325 -------------------------------------------- Sub Total 301 666 -------------------------------------------- Total 967 -------------------------------------------- Broken chains were somewhat reliable predictors only after all the "Black Hole" remailers were removed from the remailer chains selected to send messages. Even then, the broken chain stats were marginally reliable only on the infrequent occasion that broken chains changed little from day to day. The difference I found in the actual ability of a remailer to successfully deliver email was completely at odds with the mixmaster remailer stats and broken chain data, rendering them of little value in selecting a remailer chain that insures a successful delivery. The remailer network screams for a testing methodology that stresses the success of actual messages delivered to their destination, as I've done in this test. Basically, the network needs to be auditable, and the current method of evaluating remailer reliability needs a complete re-think because it's not working well, at all. Additionally, Quality of Service standards need to be established and maintained. Remailers that consistently fail to deliver messages need to be removed from the network. I consistently achieved a 95% success ratio by removing the remailers, listed above, that failed to deliver email messages less than 94% of the time. It would also be helpful for there to be better communication between remailer operators. Example: "Italy" abruptly stopped accepting mixmaster messages on the morning of Monday, October 20, but did send an email, that morning, to the remops mailing list announcing its action to permanently leave the mixmaster network. At least two days later, italy was still listed as a working mixmaster remailer, and not even listed as a broken chain for most remailers. * When the "Black Hole" remailers were in the chain, but not the final remailers, they were as reliable as the rest of the remailers. I found this extremely puzzling. Thankfully, I'm not much of a conspiracy theorist... * Fortunately, in 5 of the tests when "bogg" was randomly selected as one of the last remailers, it posted all copies of each message to the "alt.anonymous.messages" news group instead of only sending one copy. Thank God for small favors. ;) ---------------------------------- Copies of Messages bogg posted to "alt.anonymous.messages" ---------------------------------- Copies Messages ---------------------------------- 4 5 3 8 2 10 1 1 ---------------------------------- >From the first line: for 5 separate messages, all 4 copies of the messages sent through "bogg" were posted to the "alt.anonymous.messages" news group. As you can see from the bogg data, usually more than a single copy made it through to the last remailer for the test cycles I noted. Using bogg as an example, I feel comfortable "jumping to the conclusion" that most of the "Black Hole" remailers, that failed to deliver messages to the alt.anonymous.messages" news group, usually received more than one copy of each message. I hope this helps improve the reliability of a network I've come to rely upon over the years... Keep up the good work! ----------------------------------------------------------------------------- Mixmaster II Reliability Issues & Test Results [Final Test] ----------------------------------------------------------------------------- 183 messages [4 copies] were sent through chains of 20 remailers with an overall & final remailer reliability of 30% or greater. This was truly a torture test that guaranteed every message an equal probability of crossing a broken chain. The results of this final test were in line with my earlier testing conducted in September & October. In a nutshell: choosing a low reliability for the remailers resulted in a greater number of messages reaching their intended recipient, which, in both tests, was the "alt.anonymous.messages" news group. This is because the "Black Hole" remailers were almost always rated, in mixmaster stats, at greater reliability than remailers that were the most successful at delivering my messages. The Mixmaster network had an overall improvement of 4% over my earlier testing, in which some batches of messages were sent through remailer chains with reliabilities of 98%, while other batches were sent through remailer chains with reliabilities of 50%. This time around, I used a reliability of +30%. I didn't bother tracking bad chain data this time around because I found the data inconsequential in my earlier testing. In both earlier & present testing, all messages had an equal probability of encountering a bad chain, and a chain of 20 remailers, in this test, virtually guaranteed it. Let me clarify the statement: "I found the bad chain data inconsequential in my earlier testing." It's not that the data aren't necessary in choosing a good chain. In fact, you can bet that the new Mixmaster client's ability to avoid bad chains was primarily responsible for all the 100% ratings in this testing cycle. [The developers really deserve a strong round of applause for their improvements to the Mix client & bad chain data.] The reason the bad chain data are inconsequential to the testing is that all messages have an equal probability of encountering a bad chain that may develop over the many hours, or days, it takes for the messages to navigate 20 remailers. My recommendations are the same as I previously outlined in my earlier test results, which I've included below... Thanks again to all the developers & remops! ---------------------- November test results: ---------------------- (November 19, 20 & 21) 183 messages (4 copies of each) ------------------------------------------------- Last Remailer | Sent | Arrived | % Reliability ------------------------------------------------- antani 14 0 0 cripto 8 0 0 futurew 12 0 0 george 6 0 0 hastio 4 0 0 bunker 8 3 38 paranoia 16 14 88 bigapple 14 13 93 dizum 10 10 100 edo 12 12 100 freedom 5 5 100 frell 12 12 100 itys 15 15 100 metacolo 8 8 100 panta 15 15 100 randseed 9 9 100 starwars 9 9 100 tonga 6 6 100 ------------------------------------------------- Total 183 131 72 ------------------------------------------------- -----

1 0

[vserver] Bought an entropykey - very happy
by Ed W 06 Jul '18

06 Jul '18

Apologies for the apparently random plug, but I was previously posting to gentoo-hardened about ways to try and avoid bumping along with an empty entropy pool caused largely by using a "hardened" glibc/kernel (uses a bunch of entropy putting canarys after all call stacks) and it's exasperated by Linux's choice to ignore network traffic as a source of randomness and only focus on keyboard/HD activity (near negligible on a typical headless server serving files from cache...), and the icing is of course the nice linux-verver patches which allow us to cram so many processes into a small server... Having tried the bunch of software entropy generators you will find with a quick google search and finding they simply burn CPU for very little benefit - I then bought an entropy key from the nice folks at Simtec via http://entropykey.co.uk Short version is you plug it in, install the ekeyd package and even on a hardened installation the entropy pool never deviates from full up... Now, at #30 it seems like a bargain for a fancy random number generator, but then I read that the daemon can be switched to pipe the data out in "egd" format and essentially you can have one machine supply high volumes of random numbers for a fair number of networked clients. In my case this solves the problem of how to pipe entropy to some cheap rented servers where we don't get to touch the physical hardware... Very nice I have no relationship with the entropy-key guys other than being a happy customer. They seem like a small shop and I think they deserve a plug (and really need to work on their presence via google... Searches on this stuff only turn up $400 alternatives... Sheesh) For those who have no idea what this means, simply try: "cat /proc/sys/kernel/random/entropy_avail" - if the answer is bumping along in low triple digits then perhaps do a little experimentation along the lines of the above Good luck Ed W ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[vserver] Bought an entropykey - very happy
by Ed W 06 Jul '18

06 Jul '18

Apologies for the apparently random plug, but I was previously posting to gentoo-hardened about ways to try and avoid bumping along with an empty entropy pool caused largely by using a "hardened" glibc/kernel (uses a bunch of entropy putting canarys after all call stacks) and it's exasperated by Linux's choice to ignore network traffic as a source of randomness and only focus on keyboard/HD activity (near negligible on a typical headless server serving files from cache...), and the icing is of course the nice linux-verver patches which allow us to cram so many processes into a small server... Having tried the bunch of software entropy generators you will find with a quick google search and finding they simply burn CPU for very little benefit - I then bought an entropy key from the nice folks at Simtec via http://entropykey.co.uk Short version is you plug it in, install the ekeyd package and even on a hardened installation the entropy pool never deviates from full up... Now, at #30 it seems like a bargain for a fancy random number generator, but then I read that the daemon can be switched to pipe the data out in "egd" format and essentially you can have one machine supply high volumes of random numbers for a fair number of networked clients. In my case this solves the problem of how to pipe entropy to some cheap rented servers where we don't get to touch the physical hardware... Very nice I have no relationship with the entropy-key guys other than being a happy customer. They seem like a small shop and I think they deserve a plug (and really need to work on their presence via google... Searches on this stuff only turn up $400 alternatives... Sheesh) For those who have no idea what this means, simply try: "cat /proc/sys/kernel/random/entropy_avail" - if the answer is bumping along in low triple digits then perhaps do a little experimentation along the lines of the above Good luck Ed W ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [tor-talk] End-to-end correlation for fun and profit
by Maxim Kammerer 06 Jul '18

06 Jul '18

On Tue, Aug 21, 2012 at 11:25 PM, tagnaq <tagnaq(a)gmail.com> wrote: > I think karsten's graphs from #6443 fit also well to this thread: Bingo b in the first graph in the ticket [1] you see that the probability gets to ~80% when the number of nodes gets to 40. What this graph doesn't show, however, is that many of these nodes are attached to the same switch, or even run on same machine in different VMs, or on different IPs (some even run on same IP). After accounting for that, the number of tiny networks (at least /28, from going over the list in the original message) and nodes one needs to intercept in order to get the same 80% figure gets down to ~25. And of course, if one is smarter about choosing which nodes to intercept, the probability of seeing both entry and exit traffic is also significant: ~25%. It is also possible to do something in between (choose some Guard-only and Exit-only nodes), but my laziness kicked in at that point of analysis. Here are the network again, in case anyone has the resources and is curious enough about who does what with Tor: DE 31.172.30.[1-4] GB 146.185.23.179 NL 77.247.181.{162,164} RO 109.163.233.{200-201,205} CA 198.96.155.3 US 199.48.147.[35-41] DE 212.84.206.250 FR 178.32.211.{130,140} US 204.8.156.142 US 173.254.216.[66-69] SE 78.108.63.44 US 96.44.189.102 GB 178.33.169.35 CZ 212.79.110.28 US 66.180.193.219 DE 88.198.100.{230,233} LU 212.117.180.65 SE 81.170.186.175 CH 62.220.135.129 SE 84.55.117.251 DE 85.31.187.132 CA 8.18.172.156 FR 213.251.185.74 US 69.42.212.2 FR 37.59.82.50 [1] https://trac.torproject.org/projects/tor/attachment/ticket/6443/exit-probab… -- Maxim Kammerer LibertC) Linux: http://dee.su/liberte _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [liberationtech] best practices - roundup
by Maxim Kammerer 06 Jul '18

06 Jul '18

On Tue, Oct 9, 2012 at 9:03 PM, Lindsay Beck <lbeck(a)ndi.org> wrote: > Disclosure: TAILS relies on BIOS for operability, and thus can have > challenges functioning on newer computers that utilize UEFI without legacy > support for BIOS. For anyone interested: Liberti Linux already has full UEFI support for all installation types (USB, CD, OVF), and is also the first Linux distribution to use Secure Boot as a trusted boot chain mechanism. -- Maxim Kammerer Liberti Linux: http://dee.su/liberte -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[drone-list] DC Area Drone User Group
by Timothy Reuter 06 Jul '18

06 Jul '18

For anyone in the Washington, DC area interested in using or building drones you may want to check out the DC Area Drone User Group at http://www.meetup.com/DC-Area-Drone-User-Group/ . Our organization's mission is to promote the use of flying robots for humanitarian, artistic, and recreational purposes. We have some events in January to help people who want to build their own low cost drones and we will be running a flight school in February. DC DUG is also going to have some policy events in 2013 so stay tuned if you are interested. I hope to see some of you at our future events. _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

None
by James A. Donald 06 Jul '18

06 Jul '18

> You commies always find socialists everywhere. Supposedly Lincoln and Adam > Smith were socialists. They were. Lincoln was the worst US president - Clinton is a small child compared to him - and Adam Smith was all for state education, for example. Mark

1 0

None
by James A. Donald 06 Jul '18

06 Jul '18

> You commies always find socialists everywhere. Supposedly Lincoln and Adam > Smith were socialists. They were. Lincoln was the worst US president - Clinton is a small child compared to him - and Adam Smith was all for state education, for example. Mark

1 0