Re: [cryptography] HTML List Abuse (was: "please ignore: this is only a test")
Wait, numbbutt whiners, there is gold in those duplicates, triplicates. Eugen's multiple posts are not identical. Best save them all for the quite valuable and revealing metadata which differs for each. That metadata's value usually exceeds the stupid bitchings rancid and senseless as oh so witty tweets. And responses from the various fora also differ and provide information and metadata which may be senselessly filtered, typical comsec arrogantly foot shooting and blinding to score points of utter insignificance except to metadata profiling of the gullbile whiners and tut-tutters and tutors. Peer closely: you will see that Eugen is working his ass off on behalf of metadata planters, siphoners and exploiters who designed and run all levels and permutations of open and secret Internet, doing damn fine pinging and backstabbing as high-level trained to do, to work in wolf packs against sheeps gamboling as if their herder was the absolutely incorruptible RISKS operator, planter, siphoner, exploiter, redesigner of an even more pernicious Internet gobbler. At 10:22 AM 10/19/2013, you wrote: On Fri, Oct 18, 2013 at 11:40:19PM +0200, Mob wrote: > Also, if you don't want to miss anything, you are probably > subscribing to the cypherpunks, cryptography@randombits, > cryptography@metzdowd and cryptopolitics (low volume at the moment) > lists, often receiving a hundred postings every day, or more. > Including doubles and triples reposted by Eugene Leitl. To scan I'm highly sympathetic to your plight, and suggest the following solution: install a procmail recipe to filter out dupes with the same message ID (e.g. <5261aac3.6050...@mbox301.swipnet.se> in case of the mail I'm replying to) and/or matching Resent-Message-ID: with leitl.org behind it. http://help.cs.umn.edu/email/procmail > these postings with the quick-browse/delete-method (3-4 posts a > second) is significantly, irritatingly slower if you have to wait > for the fractions of a second that the HTML needs to load. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] bird.comms + compilers (urls)
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) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Snowden Comsec Is Stupefying
It is not either dribble / or "dump" as favored outlets are pontificating, seemingly by ostentatious agreement to limit harm to governments by harming the public. Both: provide the documents in a publicly accessible depository as well as narrate their significance for those who prefer readers digest and authoritative guidance. Right now, DocumntCloud provides this depository, holds over 400,000 documents provided by "authenticated" journalists to substantiate their reports and to share with others. Nearly all of the Snowden documents are on file there. http://www.documentcloud.org/public/search/ Researchers and other journalists want to see original material for their own edification, interpretations and uses. And to balance the inevitable bias and lack of understanding common to all of us. Bear in mind that readers digests, narratives and editorials are entertaining fiction like "news." Similarly, WikiLeaks initially provided copious documents as back-up to its commentary. And still does despite an uptick in exhortatory narratives. So does Federation of American Scientists, National Security Archive, Public Intelligence, Crytpocomb, and dozens more, some very old, other new: http://cryptome.org/0002/siss.htm This dribbling of documents is a moneymaking scam which may increase in harm by concealing information that puts people in harm's way, not the spies and their agents. Or worse, choking the flow is required by a confidential negotiated agreement or policy to test the market, test the USG response, vet with governments as most major newpapers do "to limit harm" a code word of complicity. At one point early on Greenwald says he considered setting a web site for the documents to be called NSADocuments. It is not clear what led him to go a conventional monetized route with the Guardian. Nor the conditions under which WaPo, O Globo, Der Spiegel, New York Times and ProPublica were brought into the stream. What is annoying for the special purpose of this honorable list of understatement is the braying about encryption as if that is now mandatory PR to show comsec responsibility. Nothing about the well-known weaknesses of encryption, its frequent failures, its backdoors, its extremely misleading marketing, its long history of many failures and few successes, its use for entrapment and tracking, its customary snake oil claims, its recantment by original authors, its cover-up by original authors, its hopelessly fuck-up state at the present time and crazed efforts to patchwork temporary solutions to prop up damaged markets and tattered reputations amply demonstrated here and other crypto fora, especially the chickenshit one which bans political and embarassing topics, therefore most likely populated with those deeply and long complicit in commercial and governmental exploitation of the public. No need to beat the dead horses of Tor, anonymizers, OTR, OTP, sekret chats, sneaker nets, black nets, key signing parties, key revocations, forgeries, impersonations, giant corps and NGOs, use of trusted cryptoids to front dubious surefire protection, use of bold names to mislead corrective efforts for damage they themselves caused, in particular misleading Manning, Snowden, Anonymous, LulzSec and many others about comsec. At 11:43 PM 10/18/2013, you wrote: You've shot down the approaches of Snowden and Assange before. I feel like I mostly understand your argument, but I'm not sure I know what you would have them do differently. Is there anything in particular you think they should have done differently to accomplish their goals? Or do you think their goals were misguided? If so, what should their goal been, and what should they have done to accomplish it? I know this seems I'm just trying to encourage counter factual arguments against history. But there will be more leaks, and more folks who are in a position to distribute them. What should they do? -- http://josephholsten.com > On Oct 18, 2013, at 13:37, John Young wrote: > > We still don't know, and likely will never know, what is in the > Snowden collection. Admirable as his courage may be, he > erred in handing it over to media incapable of assessing the > whole wad, which has led to the teasing and hyperbolized > accounts valorizing crypto to armor info-warriors. > > Perhaps more capable assessment is being done and will > be made public in a credible fashion instead of the goofy > call for debate before much is known beyond rhetoric and > hype. The heavy-handed redactions suggest official advice > threats and culling, and do not augur well for seeing the rest. > > Stupid claims of hiding the collection, insurance as stupid as > that of WikiLeaks, stupidly sending some or all of it to other > parties, come across as patent dissimulation of the comsec > advertising type. > > Comsec is now a fat mark-up of junk, espoused by stupid > comsec advisers to journalists as if a saintly medallion to > stop a bullet. > > _
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
- Forwarded message from Pawel Jakub Dawidek - Date: Sat, 19 Oct 2013 13:26:08 +0200 From: Pawel Jakub Dawidek To: z...@lists.illumos.org Subject: Re: [zfs] [Review] 4185 New hash algorithm support Message-ID: <20131019112608.gf1...@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Reply-To: z...@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-a25d3366 Powered by Listbox: http://www.listbox.com - End forwarded message - -- Eugen* Leitl http://leitl.org";>leitl 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 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
