- cypherpunks - lists.cpunks.org

Re: HTML List Abuse (was: "please ignore: this is only a test")
by brian carroll 19 Oct '13

19 Oct '13

i somewhat understand the situation thanks to feedback... the problems here involve a broken pc and porting texts from one platform into Gmail, where formatting errors and line wrap issues exist, thus unreliable rendering of emails. since the list does not send me a copy of my own posts, the archives in plain text are what i see as to the filetype, not realizing it may be rendered as HTML email elsewhere, because data only appears in plain text anywhere i see it this whole time i never figured it was about my posts due to this, unless somehow MINE attachments were what was referenced - yet only HTML was repeatedly scolded. in approximately two months, looking at emails, i have only seen a few examples of HTML email that i recognize, mainly because of formatted or colored text, and did not connect this with the *scrubbing* of the HTML content, associated with the way the email is being processed by the list management software -- which i thought is neutralizing the HTML formatting before it goes out thus, if there is a setting to receive plain text, why not subscribe to that option, for that situation, i do not yet comprehend what is going on as these posts render in mailboxes elsewhere, if they are indeed HTML or it just involves a footer with links to the scrubbed html and associated attachments, aka multipart MIME (?) i tested plain text resend (locally) of the last file and it renders Unicode ok, so will try that approach though mystery formatting issues persist with Gmail (and, as an indication of deterioration of usability, they recently removed 'translate' from Google search, so downgrading functionality in email also seems likely, with formatting and limited reply or other control over email content)... that said, i do not know (for lack of getting a copy of emails myself) if graphics are sent out as attachments or scrubbed and archived on the list (which i assumed, given the footer attachment data). the reason for not direct linking everything is to keep a copy in archive, in case i delete drop-box, so the essays have basic content for a few ideas requiring of some diagrams. if that multipart MIME attachment is the issue, is it not possible to somehow 'not view attachments' if they are sent out, or filter such messages, versus stop visual messaging of relevance to list content, because someone somewhere does not want that, and it is a potential security threat if 'weaponized', in that it is a way of attacking through delivery, etc what is a forum without ideas, how much security to protect what, security talk about security tech yet no conceptualization beyond those boundaries, like what is crypto, what are the concepts, where are various peoples understandings and interests, and might some visual information help assist the conceptual issues, or is it text-only, no imagery. because then it is just not worth it, trying to share new views and ideas about issues of crypto today not everything fits into text or a 77 character line width. these tools suck for communicating and sharing ideas. it is self-punishing even to try to share ideas online. everything goes against viewpoints that are not already agreed upon as part of the existing perspective. it takes and requires a significant effort to build up an alternative model and this requires some additional visual data to make points or frameworks otherwise not possible in text alone, and things are beyond Lynx interfaces as an email exchange scenario, to limit exchange to those parameters is perhaps too limiting even, unless what is said here is supposed to be secure in some way that i do not comprehend, like this data is under attack maybe i just do not get it, what the issues are. are online forums not to communicate ideas and while mobile and other platforms exist, there are many examples in code of how data is ported to those interfaces, not determined by it, because it is a different set of requirements, ex: m.mobile.tld 1) will try to send plain text, if formatting is retained, this will include a few attachments for the list archive 2) MIME-footer scenario will continue. unknown if these images go out to everyone- my assumption is that they went directly to the list archive: scrubbed with HTML... 2a) if attachments go out to list members, is there is a way to choose not to receive them, via list software, 2b) if images go straight to archive is there any issue 3) is there disagreement on attachments. no images and i am gone, cannot communicate the ideas. i can Dropbox them-- never meant to impose the imagery on every mailbox, especially if a security threat. yet it seems more secure to email than Dropbox them, potentially, if somehow the file was remote altered while stored static. assumed a central list archive was holding imagery via the scrubbing process. 4) what would resolve the issues... i do not see how to avoid multipart MIME footers with image attachments, yet perhaps however many list member should have to goto an URL to retrieve attached image content than have it arrive with the email. i am a believer in the text + image approach for emails, i think it is too low a limit on communication to take out visuals in basic exchange because much more can be communicated w/ diagrams. unfortunately everything is against this, even in-line images are no longer an option in email and webmail software... thus forcing text-only, sign-based, linearity like this feedback? p.s. used to ASCII diagram extensively yet no longer have tools able to control monospace fonts this way. any pointers to online resources for creating technical diagrams using ascii for email communications and the settings needed greatly appreciated. saw this online documentation the other day and its formatting is ideal, http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00 why is it so impossible to get that kind of control over text, and how do technical diagrams get rendered in ASCII (no examples here, rare to encounter them) and where to learn how to do this. not online ASCII-image translators and instead, are there tools and settings for text editors or does Gmail limit this from happening. tried Outlook yet it is insane and unusable. cannot find the new mail button even. fake whois. sick software experimentation. Eugen Leitl wrote: > > On Thu, Oct 17, 2013 at 08:43:01PM -0500, brian carroll wrote: > > hello. as far as i know, this is not HTML, it is a unicode message. > > It was a multipart message: > > I 1 <no description> [multipa/alternativ, 7bit, 3.9K] > I 2 ├─><no description> [text/plain, 7bit, utf-8, 1.2K] > I 3 └─><no description> [text/html, quoted, utf-8, 2.5K]

6 6

Pa: da: d-a#2e !8upje. In.z :$ qu# e ta2t:_
by brian carroll 19 Oct '13

19 Oct '13

Moon Jones -- (difficult to take you seriously while you're wearing a tutu and holding a pink umbrella) YES. i worship my mother. this is your problem? > On 1L.J.B:AC W!Y, dj!eu nejj8= mrota drab. > H8! Wud ncxa! 3owme's poh ye$ 8jdmu up. Z8E da$ eu H- 2o3E#H!z6 > 56wemyaRE. 8a!2 58o zwej+ #3 uec 8a| 6 6E8!-:88 888-uTi Vhq !t+12 ^9) > 6920x25ji 8-=5 Nep oo& ^ nutS!E nz5ah gAme |!k 3|3ctj0w^7u520925. > =W !c +earZ. > Lyeu11 21 d b-7pi.ng cS 8= 1415 .ty1+ V8N #j5 8-7pi19u B y1^a 1 p!6 > jutcj5 2q 28 3#ka h0ur WoE31 bjond, wot Ly8a H3i c|d 8ec. 8a 2m-15 n+2 > 25^15135 iC 1icohoUn' se _L! v28-i0 #1115 50nu3 J 7-/7E N'n:uc- 8j +8 2m^= > -L9mm 6n'45; 8avi V8- na14 /0d 2e-w-on mrk D 68915 !cu: S060#H \N8-id > 7_8-0_L!3e' 9'E sn?\5 > 231v/ 5 68 8#|1Ui B-=nn-eV/: > "Now my ma filter has an extra #ss#### on the /dev/null list." >

1 0

[Cryptography] PRNG WYTM
by John Denker 19 Oct '13

19 Oct '13

On 10/19/2013 09:55 AM, Sandy Harris wrote: > Mixing in the clock makes a machine behave a bit > differently each time it is rebooted. Again, there > are better fixes such as mixing in a saved file, but > again this is still worth doing. > > These are reasonably cheap and done only once > at boot time. They can do no harm and are useful > in at least some cases, so worth doing. OK, the next step in any such discussion is to ask the famous question, What's Your Threat Model (WYTM). Several different reasonable answers are possible. 1) At one extreme, we have the "no threat at all" model, aka the "non-adversarial" model. Examples include *) Doing a Monte Carlo integral in the context of a molecular dynamics calculation. The molecules are not going to attack our PRNG. They are not going to cryptanalyze it. Almost any PRNG is "random enough" for this purpose. *) Cooperative situations, such as friendly computers on a LAN, doing random exponential backoff as part of the layer-1 Ethernet CSMA/CD. Everybody has a shared interest in implementing the protocol properly, so even if they could break the PRNG they wouldn't want to. *) Et cetera. There are tons of examples in this category. A PRNG in category (1) could be considered "random" but not "secure". It is usually adequate to seed this type of PRNG with things like the MAC address, serial number, and time-of-day. 2) At the opposite extreme we have high-stakes adversarial applications, including military cryptography, banking, other high-value business communications, high-stakes gaming, etc. etc. etc. A PRNG in this category needs to be *secure* against a wide range of threats. For tasks in this category, seeding the PRNG with things like the MAC address, serial number, and time-of-day is nowhere near good enough. It is a band-aid or worse. It is security theater. It gives you "randomness" in some weak sense, but it does not give you security. The typical modern PRNG in this category consists of a seed, a counter, a hash function, and a reseeding mechanism. Sometimes there is a block cipher in there somewhere, but to a sufficient approximation this is the same basic architecture, just with a fancier hash function. So let's look in more detail at the threats against such a PRNG. *) For starters we have the threat of direct cryptanalysis of the output. If the preimage can be found, all further outputs will be known to the attacker, and probably all past outputs as well, over the span bounded by the nearest past and present reseedings. The feasibility of finding a preimage depends on the number of bits output by the PRNG. Therefore there should be a limit on the number of output bits between reseedings. *) Another type of threat is more indirect. For example, suppose the PRNG was seeded at boot time from the saved random-seed file. It may be possible for the attacker to find this, perhaps by sneaking a peek at an old backup tape or whatever. Such a threat is independent of the number of bits emitted by the PRNG. It is hard to say what it /does/ depend on, but in the absence of anything better, wall-clock time is a plausible proxy. Therefore there should be a time limit on how long a seed file is allowed to remain on disk before it is regenerated, and a time limit between reseedings of the PRNG. On 10/19/2013 01:37 PM, James A. Donald wrote: > > Any system that needs crypto, communicates. Any system that > communicates, sees events whose details are difficult to predict for > anyone not in physical possession of the system. > > Solution: Block for a short period after startup. Possibly a small > number of systems will freeze up and fail to boot. This is almost > always fixable by moving the blocking process in the bootup so that > it no longer blocks other processes while it is blocked waiting for > /dev/urandom, while /dev/urandom is blocked waiting for entropy. That might be a "solution" in certain favorable cases, but it is nowhere near being a reliable, general solution. I can think of five failure modes in five minutes. Perhaps the most obvious is this: Suppose my system is sitting in a rack at some colocation provider. All the attacker needs to do is rent a box in the same rack, on the same LAN segment. Then he knows my MAC address, the time at which I booted up, and (to a good approximation) the arrival time of every network packet addressed to me. Similarly for my laptop on the corporate wifi network. The bad guy in the loft across the street has a nontrivial chance of figuring out everything he needs to know about my network traffic. If anybody has a proof that this cannot happen, please explain. Here's the only thing that has ever made sense to me: a) Any device that wants to have any security whatsoever needs to be able to store a seed, even when powered off. b) The seed needs to be provisioned on a per-device basis, much like the MAC address is provisioned. c) The seed needs to be big enough, randomly-chosen, and secret, very unlike the MAC address, RTC, and device serial number. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
by Theodore Ts'o 19 Oct '13

19 Oct '13

On Sat, Oct 19, 2013 at 09:33:32AM -0400, John Kelsey wrote: > > One other thing you can see from the duplicate RSA keys: many RNGs > (I think instances of /dev/urandom drawn on by openSSL) do not > incorporate any internal information that can work like a salt. > They should. If my device has a device serial number, ethernet > address, timestamp, etc., those should all be hashed into the > entropy pool, with 0 entropy bits assessed. At the risk of repeating myself, we made a lot of changes to the /dev/random code base when we received a preprint of the Mining your P's and Q's paper (patches went into mainline the first week in July, and got propagated to older kernels via the stable kernel trees about 2 weeks later; the paper was published at Usenix Security in August.) One of them was to do precisely this --- /dev/urandom now mixes in salting information (ethernet MAC addresses, etc, via the new interface add_device_randomness). Zero entropy is indeed assessed, and the main goal is to avoid the trivially easy case of shared primes in the case where we fail to gather enough entropy. The other change we made was to gather entropy on every single interrupt, instead of only on those device drivers where the device driver authors gave us permission to collect entropy. That was a mistake, because device driver maintainers care about performance and CPU efficiency at all costs, and they don't particularly care about entropy collection. So we made entropy collection fast, and unconditional. As I've already said, I'm open to adding code that blocks /dev/urandom until "enough" entropy has been collected. But that's an interface-visible change, and it could break things. So there is due diligence that will need to be done first, because the reality is if it breaks things, people will just comment it out, and it will be harder to propagate the change in the future. In the real world, the product manager is often as much a security engineer's adversary as Boris and Natasha. :-( - Ted _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

2 1

pǝɔɹʎdʇoɹ (nɹls)
by brian carroll 19 Oct '13

19 Oct '13

The Artist of the Unbreakable Code (via A&L Daily) Composer Edward Elgar still has cryptographers playing his tune. http://nautil.us/issue/6/secret-codes/the-artist-of-the-unbreakable-code read this article the other day and wondered if anyone evaluated the alphabet for letters that have those curved shapes (e.g. m, n, c, w, u, p, q, b, d, g, etc) at the subsign level, removing extra details for common squiggle structure, &or potentially how the cipher could be related to musical note values... Dorabella Cipher http://en.wikipedia.org/wiki/Dorabella_Cipher Letter Groupings http://www.rinkworks.com/words/lettergroups.shtml (list of alphabetic structure in terms of what letters share certain qualities, like lowercase with vertical bars, or lowercase with structure beneath the baseline. vital knowledge for such calculus... though missing rotational without reflective symmetry NSZ) Homoglyph http://en.wikipedia.org/wiki/Homoglyph "In typography, a homoglyph is one of two or more characters, or glyphs, with shapes that either appear identical or cannot be differentiated by quick visual inspection." Numeronym http://en.wikipedia.org/wiki/Numeronym "A numeronym is a number-based word." Transformation of text http://en.wikipedia.org/wiki/Transformation_of_text "Transformation of text is strategies to perform geometric transformations on text (reversals, rotations, etc.), particularly in systems that do not natively support transformation, such as HTML, seven-segment displays and plain text." ʇno ʇı ƃuıʇsǝʇ http://flip-o-matic.net/ 14.2 October 2013 http://www.mnartists.org/work.do?rid=340505

1 0

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