October 2013 - cypherpunks - lists.cpunks.org

Re: South Park NSA (update)
by brian carroll 19 Oct '13

19 Oct '13

// note: repeated pattern of infrastructure subversion... South Park Studios loses power, misses deadline for new show http://www.latimes.com/entertainment/tv/showtracker/la-et-st-south-park-stu… "South Park Studios lost power on Tuesday night, and with their computers down for hours the team could not animate, render, edit or work on sound. As a result they couldn't finish Wednesday night's scheduled episode, which is a first in "South Park" history." // power-outage follows airing of this criticism... > Original Air Date: 09.25.2013 > > Cartman infiltrates the NSA... > http://www.southparkstudios.com/full-episodes/s17e01-let-go-let-gov // in other news... (urls via Drudge) Most epic read of our time? It's not classics Beowulf or War and Peace but Google's terms and conditions, say scientists http://www.dailymail.co.uk/news/article-2467166/Googles-terms-conditions-be…

1 0

Re: [zfs] [Review] 4185 New hash algorithm support
by Tim Cook 19 Oct '13

19 Oct '13

On Sat, Oct 19, 2013 at 6:26 AM, Pawel Jakub Dawidek <pjd(a)freebsd.org>wrote: > On Mon, Oct 07, 2013 at 11:18:21PM +0100, Saso Kiselkov wrote: > > On 10/7/13 10:17 PM, Zooko Wilcox-OHearn wrote: > > > So, before I go on with my pitch for why you should consider BLAKE2, > > > first please clarify for me whether ZFS really needs a > > > collision-resistant hash function, or whether it needs only a MAC. I > > > had thought until now that ZFS doesn't need a collision-resistant hash > > > unless dedup is turned on, and that if dedup is turned on it needs a > > > collision-resistant hash. > > > > The reason is purely for dedup and pretty much nothing else. As such, we > > only need a hash with a good pseudo-random output distribution and > > collision resistance. We don't specifically need it to be super-secure. > > The salted hashing support I added was simply to silence the endless > > stream of wild hypotheticals on security. > > Just FYI, Richard Yao just proposed providing VM images with existing > ZFS pool also for production use. This is great idea, but also a nice > proof why making assumptions on how exactly a general purpose software > will be used is bad. In this case your salted hashing is pointless as > everyone knows about the salt in those images. And we are back to square > one. > > Saso, there are countless examples where so called hypothetical security > bugs turned out to be exploitable in practise. Which is especially true > for general purpose software that we have no control over how it is > being used. > > As Zooko mentioned cryptoanalysis of the Edon-R algorithm stopped at the > point where we know it is not cryptographically secure and this is > unlikely we will see any further work in the subject, which in my eyes > is even worse, as we don't know how bad is it. > > To sum up. Even if the OpenZFS community will agree to integrate Edon-R, > I'll strongly oppose having it in FreeBSD. In my opinion it is just > asking for trouble. I still like your change very much and would love to > see new, cryptographically secure hash algorithms for dedup in ZFS. > Currently there is no alternative, which is bad for security too. > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://mobter.com > > > So as I have asked previously, can you point to any working exploit of any of the commercially available deduplication stacks? None of them are cryptographically secure. All of them are used in extremely high value targets including top secret government installations. I would assume that almost a decade on there is working code out there if the exploits are anything beyond hypothetical. While I applaud your diligence, it seems beyond silly to me to hamstring people's options because you PERSONALLY wouldn't want to use that as an option. If I as a user understand and am willing to accept the risks associated in exchange for something approaching usable from a performance perspective, you're telling me I shouldn't get that option because you are worried about a theoretical exploit. That's an awfully slippery slope to start heading down. Where does that stop? Are you going to recommend BSD also stop supporting any system that boots off of PCBIOS which has been proven to be exploitable in the field? Are we going to remove md5sum from BSD because that's exploitable? If you want to recommend they not have it as the default, great. But recommending it not be included at all because you don't feel comfortable with it seems like a GREAT disservice to the community. I thought this horse had already been beaten to death but I guess not. --Tim ------------------------------------------- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3… Powered by Listbox: http://www.listbox.com

1 0

Re: bird.comms + compilers (urls)
by John Young 19 Oct '13

19 Oct '13

This is the most interesting post to appear since the list was re-energized. The weakest elements of comsec are related to matters seldom discussed on crypto fora which are heavily biased toward digital technology. As might be expected on the Internet and its crippling and perhaps fatal dependence on digi-tech isolation from reality. Manifold other means and methods of comsec get short shrift on the Internet yet are the most frequent ways that digital comsec is breached, defeated, embarassed, ridiculed, dumped for legacy methods that require deep familiarity with divers physical and electromagnetic constraints and exploits. Brian Carroll, in case you have missed his copious contributions elsewhere, is more adept than most in addressing the conceits of digi-tech masters by providing leads to these diverse legacies. Don't expect him to rollover and succumb to the usual putdowns of conceited digi-techers. Happily, this noble list is broadminded enough to host his offerings which would be banned on premier digi-tech hideaways from reality. At 12:53 AM 10/19/2013, you wrote: >// analysis, feedback, and pattern matching... > >Dude, where's my code? >http://phys.org/news/2013-10-dude-code.html > >(re: paper is titled "Towards Optimization-Safe Systems: Analyzing the >Impact of Undefined Behavior." // Stack) > >Birds on repeat: Do playbacks hurt fowl? >http://phys.org/news/2013-10-birds-playbacks-fowl.html > >(context is of birdcall networks & modem protocols, perhaps this issue >of emulation relevant to security protocols, monitoring, attack >strategy- or not) > >Cuckoos impersonate hawks by matching their 'outfits' >http://phys.org/news/2013-10-cuckoos-impersonate-hawks-outfits.html > >(crazy cuckoo birds impersonate hawks, exploit of localized >overlapping pattern matching. potential comp.security or software >systems correlation, beyond poli-sci)

1 0

Fwd: Re: please ignore: this is only a test...
by Moon Jones 19 Oct '13

19 Oct '13

On 17.10.2013 23:25, brian carroll wrote crap. Oh! How cute! Momma's boy has grown up. Now he's an IT something somewhere. He's sooo smart he can get a Gmail.com account! And it's even better! He can get a cutisie user name like electromagnetize. I'm in tears. Thank you for letting us all know that. You are certain to have a big future so to make your momma proud, not like her old man. Be sure not to become an alcoholic, as it would take some of the shine of the small town pride. Hey! You can even say you work for Google Inc. Nobody would notice, I'm sure. Way to go Brian! Hurray! Now my mail filter has an extra a**hole on the /dev/null list.

1 0

Re: [liberationtech] RiseUp
by Eugen Leitl 19 Oct '13

19 Oct '13

----- Forwarded message from Maxim Kammerer <mk(a)dee.su> ----- Date: Fri, 18 Oct 2013 23:20:58 +0300 From: Maxim Kammerer <mk(a)dee.su> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] RiseUp Message-ID: <CAHsXYDBwCfoAg5U1nLK6Gcz8EQqim9KkFkt8nmZkprRwYGJuGw(a)mail.gmail.com> Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> On Fri, Oct 18, 2013 at 8:54 PM, Yosem Companys <companys(a)stanford.edu> wrote: > On Fri, Oct 18, 2013 at 10:53 AM, Sahar Massachi <sayhar(a)gmail.com> wrote: >> As Elijah wrote, the point of riseup is to serve a specific constituency. >> The point is not to help the general public encrypt their email. > > Exactly, and they do that quite well. Those who use RiseUp's mailing > lists rave about the service. First, users raving about a service typically has very little to do with quality of the service as a security product. I believe that's why you posted the original question, after all. Second, the unusual stress of ideology in such a service is very relevant to product's security in this case. When I read RiseUp's social contract page [1] some time ago, I found the mild creepiness and passive-aggressiveness quite amusing, but immediately thought the following: these guys seem pretty radicalized in whatever hippie ideology they seem to be adepts of. This probably indicates that in their closed group, they value ideological loyalty at least as highly as technical expertise. It means that one of them could be incompetent and still have administrative access to security-critical systems, or that one of them could be recruited at some point under a suitable ideological pretense — compromising the service in either case. [1] https://www.riseup.net/en/social-contract -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [zfs] [Review] 4185 New hash algorithm support
by Eugen Leitl 19 Oct '13

19 Oct '13

----- Forwarded message from Pawel Jakub Dawidek <pjd(a)FreeBSD.org> ----- Date: Sat, 19 Oct 2013 13:26:08 +0200 From: Pawel Jakub Dawidek <pjd(a)FreeBSD.org> To: zfs(a)lists.illumos.org Subject: Re: [zfs] [Review] 4185 New hash algorithm support Message-ID: <20131019112608.GF1408(a)garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: zfs(a)lists.illumos.org On Mon, Oct 07, 2013 at 11:18:21PM +0100, Saso Kiselkov wrote: > On 10/7/13 10:17 PM, Zooko Wilcox-OHearn wrote: > > So, before I go on with my pitch for why you should consider BLAKE2, > > first please clarify for me whether ZFS really needs a > > collision-resistant hash function, or whether it needs only a MAC. I > > had thought until now that ZFS doesn't need a collision-resistant hash > > unless dedup is turned on, and that if dedup is turned on it needs a > > collision-resistant hash. > > The reason is purely for dedup and pretty much nothing else. As such, we > only need a hash with a good pseudo-random output distribution and > collision resistance. We don't specifically need it to be super-secure. > The salted hashing support I added was simply to silence the endless > stream of wild hypotheticals on security. Just FYI, Richard Yao just proposed providing VM images with existing ZFS pool also for production use. This is great idea, but also a nice proof why making assumptions on how exactly a general purpose software will be used is bad. In this case your salted hashing is pointless as everyone knows about the salt in those images. And we are back to square one. Saso, there are countless examples where so called hypothetical security bugs turned out to be exploitable in practise. Which is especially true for general purpose software that we have no control over how it is being used. As Zooko mentioned cryptoanalysis of the Edon-R algorithm stopped at the point where we know it is not cryptographically secure and this is unlikely we will see any further work in the subject, which in my eyes is even worse, as we don't know how bad is it. To sum up. Even if the OpenZFS community will agree to integrate Edon-R, I'll strongly oppose having it in FreeBSD. In my opinion it is just asking for trouble. I still like your change very much and would love to see new, cryptographically secure hash algorithms for dedup in ZFS. Currently there is no alternative, which is bad for security too. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com ------------------------------------------- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3… Powered by Listbox: http://www.listbox.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [liberationtech] RiseUp
by Eugen Leitl 19 Oct '13

19 Oct '13

----- Forwarded message from "Fabio Pietrosanti (naif)" <lists(a)infosecurity.ch> ----- Date: Fri, 18 Oct 2013 20:20:07 +0200 From: "Fabio Pietrosanti (naif)" <lists(a)infosecurity.ch> To: liberationtech <liberationtech(a)lists.stanford.edu> Subject: Re: [liberationtech] RiseUp Message-ID: <52617BD7.7010605(a)infosecurity.ch> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: liberationtech <liberationtech(a)lists.stanford.edu> Il 10/16/13 12:07 AM, Yosem Companys ha scritto: > If you have any thoughts about Riseup, whether > security/privacy-related or otherwise, I'd love to hear them. While i appreciate Riseup project goals and approach, i would not personally keep my usual email flow (inbound/outbound) going trough a communication line that's used by many other "sensible users", because it's more likely to be massively monitored. Generally is not valuable to use only 1 email provider, because email is made up of many pieces: - Inbound flow - Outbound flow - Data storage That require a user to have at least 3 different providers by: - Splitting your communication flow - Stay on countries with (strong economy & strong privacy law) I wrote about this concept/setup there https://mailman.stanford.edu/pipermail/liberationtech/2012-February/003144.… Anyone can implement their own mix of providers/countries/flows by using easy web-interfaces of hosting providers without having to deal with server's setup. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: [cryptome] Re: Thank You, Edward Snowden
by John Young 19 Oct '13

19 Oct '13

>perhaps the proceedings were better; Schneier was there after all,.. Schneier is a leader of the monetizing pack, never crosses the line, sits among the stellars of institutional control, incessantly promotes his wares, spoon-feds fans. Predictably for self-promoters, like other stellars, he is security chief for a principal telecom spy. Impolitely, a security flack, which may be redundant. Self-reportedly he is helping skim, cherry-pick, sanitize, ass-cover abetters of NSA, shoveling insider tips to outlets. Warns must not go too far in response, merely securitize! the net. Which is the scam comseckers have been running in cahoots with the officials since the birth of government networks. >... is there anyone you approve of John? Snowden and Manning, the brands and fans, let others off the hook, when more like them are needed to avoid sacralization of the crucified. Just hope there are a lot more doing truly good behind and below the media and crazed followers tampering down of dissent with adoration, gratitude, attitude and hyperbolization. Leaks should be done without fanfare, which contradicts the very term.

2 1

bird.comms + compilers (urls)
by brian carroll 19 Oct '13

19 Oct '13

// analysis, feedback, and pattern matching... Dude, where's my code? http://phys.org/news/2013-10-dude-code.html (re: paper is titled "Towards Optimization-Safe Systems: Analyzing the Impact of Undefined Behavior." // Stack) Birds on repeat: Do playbacks hurt fowl? http://phys.org/news/2013-10-birds-playbacks-fowl.html (context is of birdcall networks & modem protocols, perhaps this issue of emulation relevant to security protocols, monitoring, attack strategy- or not) Cuckoos impersonate hawks by matching their 'outfits' http://phys.org/news/2013-10-cuckoos-impersonate-hawks-outfits.html (crazy cuckoo birds impersonate hawks, exploit of localized overlapping pattern matching. potential comp.security or software systems correlation, beyond poli-sci)

1 0

Re: [cryptome] Thank You, Edward Snowden
by John Young 18 Oct '13

18 Oct '13

Pure bullshit, putting it politely. More accurately self-serving bullshit. None of these bear-hugging rhetoricians have the guts to do what Manning and Snowden have done, nor those who have been their clients, speechifying fees and funding topics, career boosters, campaign posters, cowardly woe-is-the-US industry while enjoying the beltway and coastal perks and prizes beloved of arm chair pundits and civil liberties pimps. This is vulgar behavior parading as valiant derring-do, never ever crossing the red line of genuine courage. Merely thanking Snowden and Manning, rather than crossing the line of lawfulness into their fearful terrain is as predictable national security mongering on all sides. Pity Snowden for falling into their trap. And burn that ACLU card after gazing at the 1/2 million salary of its slick director over-paid to suck the teats of excessively wealthy under cover of thousands of lesser contributors corraled into craven water-carrying for legal actions amply exploited for billable hours. Why Wyden and his ilk milk insider knowledge as if privileged journalists should be no mystery. It is the coin of kings.

3 2