- cypherpunks@lists.ogf.org

SilentCircle fail
by rysiek 28 Jan '15

28 Jan '15

So, this: http://blog.azimuthsecurity.com/2015/01/blackpwn-blackphone-silenttext-type… ------------------------ While exploring my recently purchased BlackPhone, I discovered that the messaging application contains a serious memory corruption vulnerability that can be triggered remotely by an attacker. If exploited successfully, this flaw could be used to gain remote arbitrary code execution on the target's handset. The code run by the attacker will have the privileges of the messaging application, which is a standard Android application with some additional privileges. Specifically, it is possible to: decrypt messages / commandeer SilentCircle account gather location information read contacts write to external storage run additional code of the attacker's choosing (such as a privilege escalation exploit aimed at gaining root or kernel-mode access, thus taking complete control of the phone) The only knowledge required by the attacker is the target's Silent Circle ID or phone number - the target does not need to be lured in to contacting the attacker (although the flaw is exploitable in this scenario as well). (...) By resetting the jctx->msg->msgType field with the "dh2" attribute at the end of the message, a type confusion vulnerability will occur where the seq fields supplied in the "data" message will be incorrectly interpreted as the pk field - a raw memory pointer. (In this case, the low two bytes have been set to 0x8080.) Note that by utilizing messages other than "data", we could arbitrarily modify the entire pointer (and the pkLen field, indicating how much data pk points to). Assuming that we are at the correct phase of protocol negotiation, sending this message results in the following crash: ]Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 17201 (com.silentcircl) I/DEBUG ( 9735): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 9735): Revision: '0' I/DEBUG ( 9735): pid: 15611, tid: 17201, name: com.silentcircl >>> com.silentcircle.silenttext <<< I/DEBUG ( 9735): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad I/DEBUG ( 9735): Abort message: 'invalid address or address of corrupt block 0x601b8078 passed to dlfree' (...) ....a raw memory pointer.... ....a raw memory pointer.... ....a raw memory pointer.... ....a raw memory pointer.... -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147

1 0

Re: [Cryptography] traffic analysis -> let's write an RFC?
by Eugen Leitl 28 Jan '15

28 Jan '15

----- Forwarded message from joe <joe(a)stsauver.com> ----- Date: Tue, 27 Jan 2015 22:37:18 -0500 (EST) From: joe <joe(a)stsauver.com> To: Stephen Farrell <stephen.farrell(a)cs.tcd.ie> Cc: Jerry Leichter <leichter(a)lrw.com>, Cryptography <cryptography(a)metzdowd.com>, Ben Laurie <benl(a)google.com>, John Gilmore <gnu(a)toad.com>, grarpamp <grarpamp(a)gmail.com> Subject: Re: [Cryptography] traffic analysis -> let's write an RFC? Message-ID: <alpine.BSO.2.11.1501272155210.19906(a)stsauver.com> User-Agent: Alpine 2.11 (BSO 23 2013-08-11) Hi, Stephen Farrell commented: > I think that traffic analysis mitigation is the next big area > we need to start trying hard to work. So far, we've (IETF) > gotten general padding capabilities added to protocols (HTTP/2.0 > for example, still in discussion for TLS1.3) on a case by > case basis, but we've not yet done anything systematic. I'd > love to see a WG chartered to try figure out how to most > effectively counter traffic analysis and then go write > protocol and/or BCPs as needed. While it's possible to talk about some fairly sophisticated anti-traffic analysis strategies, I believe the low hanging fruit for traffic analysis-resistance at the ISP level will likely involve a fairly simple (if ugly) recipe: -- Use crypto at L1 (e.g., optical transport crypto) and/or L2 (e.g., MACsec) to get what opacity you can there -- Use IPv4 with NAT/PAT (with many customer identiies comingled on each public IP; yes, I know that this is awful from an end-to-end transparency POV) -- Combine that with "short" IPv4 DHCP lease times -- Strive for minimal log retention (in reality, given the potential impact of preservation requests, there may need to be NO logging, and yes, that will be pretty bad when considered from an anti-abuse POV) Note: this assumes that non-logging is permitted by law where employed. To the best of my knowledge, there is no required log retention in the United States, and the European Data Retention Directive also got the chop from the European Court of Justice, see for example http://curia.europa.eu/jcms/upload/docs/application/pdf/2014-04/cp140054en.… (however, as always, this is not legal advice and anyone contemplating this approach should consult their own counsel in picking a strategy) That's my bet for the Internet side, sort of a lightweight/first step for anti-traffic analysis, kin to the lightweight/first step protection that opportunistic encryption provides for SMTP traffic. Obviously this isn't a total solution, but it's a start. [Shame that bulk domestic collection of metadata makes it necessary to even talk about this sort of thing...] Oh yes: what about the cellular side? Let's not forget it, too. The best you may be able to get as an anti-traffic analysis strategy on the phone side may be to use frequently-replaced and infrequently- used simple prepaid cell phones purchased for cash (but note that an increasing number of countries do not even allow purchase and use of unregistered cell phones). Naturally, batteries must be out of cellular devices when the devices aren't actively in use. Yes, this is all a big pain. (But the whole metadata/traffic analysis issue is very difficult to definitively handle without at least some inconvenience, I think.) Regards, Joe St Sauver (joe(a)stsauver.com) https://www.stsauver.com/joe/ Disclaimer: all opinions strictly my own _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message -----

1 0

Barrett Brown
by Cari Machet 28 Jan '15

28 Jan '15

Has this fucking list ever heard of barrett or like you're way too fucking parasiticly capitalistic and more interested in using your profound talents to dox workers on this list and press meaningless repetative buttons on a dirty keyboard and stare than actually functioning as a life form?

5 5

AWO text available
by brian carroll 28 Jan '15

28 Jan '15

Apple Watch Observations. 123pp, btc ---------------------------------------------------------------------- no copyright. redistribution & mirroring ok (see disclaimer) web-version: https://appleobservations.wordpress.com pdf-version: http://tinyurl.com/AWO-final-01-25-15 Critique of the Apple Watch concept in a good-bad-&-ugly scenario, accounting for app mania & the "apps apps apps" mantra preceding creation of the App Watch, standing in for the watch of the future. Thus proprietary apps, OS & ecosystem approach as a conceptual and ideological limit, though also in a context of hidden politics, exploitation of technology and rapidly developing police state. In this way dual-use blackbox devices, antagonistic electronics operating with competing value systems, human and antihuman, truth absent within computer data models, no structural basis for knowledge, the bit itself becomes 'the sign of truth', where $=bit (on=money, off=no-money) in terms of evaluating data, leading to slavery dynamics, censoring data by denying access via authoritarian control over culture, on behalf of tyrannical power politics of Big Daddy as state oppressor, not Big Brother. In this way - as an optimistic view - establishing new rights to data access via wearable technology, micro-data & -payments in surrounding pervasive wireless infrastructure, beyond the detached aristocratic mindset of Silicon Valley utopianism, developing tools for humanity, to support & secure freedom. /note: the gist for cypherpunks & crypto could involve an otherwise off-the-books threat model & related security issues in a real-world non-politically-correct analysis conveyed via plainspoken viewpoint/. 0.1 unveiling, cognitive dissonance, counterpoint, time = $$$ 1.1 device name, seitiroirp, technocracy, culture & fitness profiles 1.2 watch of the future, Achilles heel, risk and reward, App Watch 1.3 timing, SoC as movement, GPS, XU, OS-determinism, sans AI 1.4 apps, middle-mgmt, ecosystem, ideology, iPhone, autonomy 2.1 aesthetics, inside/outside, gap, data-model, utility & futility 2.2 moonshot, wrist computer, security threat, proprietization 3.1 consumerism, QC and QA, revolution, ideas and processing 3.2 calligraphy v. helveticization, interface as facade, core-rot 3.3 forced perspective, junk|joke, mirroring, mundanity of evil 4.1 watches {mechanical, electronic, computer} w/A&D display 4.2 lessons unlearned, display-battery issues, value, economy 4.3 snsrs, smartwatch {digital watch}; set {subset}, subset {set} 4.4 the heart, biorhythmic movement, fitness, ID maze, dystopia 4.5 jumping spider, true innovation, seed, wristwatch data orrery 4.6 aesthetic substance, 1984, inhuman technology, Dark Ages 2.0 5.1 space-time-place device, brain|mind, consciousness, AI, QvA 5.2 time signals, delay, accuracy, GPS & atomic clocks, Project Apollo 5.3 context+sensors+datalogging+networking < user case studies 6.1 malproduction, surveillance, antagonistic electronics, crazy ones 6.2 more: dual-use, weaponization, unreality, hidden politics, errors 6.3 blackbox, eg. flashdrive, A/B, corruption, NSA, police state, trap 6.4 control. transparency, covert infrastructure, Taylorism, insecurity 6.5 flds+sgnls, diagnostics, forbidden fruit, Abuse, sexuality & power 6.6 fear, donuts, aristocracy, slavery, OS plantation, clockwork-apple 6.7 fortune telling, $=bit, wysinwyg, invisible states, watching spies 6.8 ideals, Big Daddy, neg.dev, IoT, bubble, conceptual shareholders 7.1 data infrastructure, the grid, 1950s, security, public-private.dev 7.2 lifespan, jewelry.ext, adaptive+assistive, mission, snake eyes 7.3 hybrid [touch'e, hands]. OS highway & App store, data.access 7.4 variation, design styling, extroversion, net.watch, tiers, gold 7.5 radar, wi-fi infrastructure, micro-data development, freedom 7.6 direction, cultural RD&D, calculator v. computer, human future xtre: proposal for public email list to discuss & debate ideas... It is wondered if anyone would be interested in establishing an email discussion list related to general AWO themes as a beginning point for any such artifact/infrastructure/system issues, observations or analyses as the general framework. A proposed list name, 'net.watch-list', is keyed from the text, simultaneously referencing a potential Wi-Fi based wristwatch with public access to pervasive data services, though also the reality of being watched in surveillance-based global society, as this also relates to watching the watchers, everyone an eye as observations empirically correlate, find ground or fail to unify as this increases isolation, alienation, silence, self-censoring. The main concern with an open discussion (whether public or private) is institutional and-or legal support or backing to limit internal/external subversion or interference with list operation so that people can feel safe communicating in "free society." My vote would be for a public list connected to a University, where a lot of people are discussing the same realm of ideas, not limited of course to AWO or authorial perspective, though involving dynamics mentioned, hypotheses, many viewpoints. Any feedback or ideas on this appreciated. ~cc.nettime-l electromagnetize(a)gmail.com {The Internet Emporium}: related project http://internetemporium.wordpress.com/

1 0

Cryptome banned from DocumentCloud.org and Amazon.com
by coderman 28 Jan '15

28 Jan '15

""" Bans of Cryptome by DocumentCloud.org and Amazon.com while both publish Snowden's documents reveals corruption of profitable and NGO media. Amazon says it canceled offering of Cryptome Archive due to ban on publishing government documents. Prohibited: https://sellercentral.amazon.com/gp/help/200685320 """ banned library? banned librarian?

2 1

Re: [Cryptography] traffic analysis
by grarpamp 27 Jan '15

27 Jan '15

On Tue, Jan 27, 2015 at 3:23 PM, Ben Laurie <benl(a)google.com> wrote: > Yeah, but ... who can realistically afford that bandwidth? One can afford what they wish to give to and thus expect to get from the network in return, no more, no less, as always. (Be it literally from the physical NIC network, or the logical networks created by their applications riding over and within the physical.) > To every possible recipient? Clearly you have to make a tradeoff. Full meshing of chaff addressed to all participants seems unnecessary. > grarpamp wrote: > Is there so much (possibly far less than correct) thought out there > that fill bandwidth is evil, untolerable, unmanageable, and blocking > of usability such that these networks are moot to even try coding > for general deployment? On Tue, Jan 27, 2015 at 1:35 PM, Jerry Leichter <leichter(a)lrw.com> wrote: > Google Fiber offers 1Gb/second - but how many customers running all > out will overload any possible backbone behind the single link from the > house to the concentrator? > > If everyone starts sending constant cover traffic, links will be quickly > overloaded all over the place. At which point the providers will start > charging [...] nobody will be happy That's the simple man's kneejerk response when initially contemplating chaffed networks. > There's room to do much better. For one thing, you don't need to saturate your link with cover traffic - you need to send enough cover traffic so that a listener can't tell the difference between cover and real traffic. This depends on if you're network is a low latency one, or if it uses a store and forward model. Even that is tricky due to needs to hide the size of data each endpoint exchanges from passive adversaries. It begins to approach constant higher rate the more you data wish to pass securely. > If your cover traffic rate equals your average rate over some period of time, > you're not adding more traffic - you're simply replacing some of your cover > messages with real messages. But ... what happens when you have a > peak demand way above your average? Then you must wait until you can pass your wheat. Or plan your needs according to the give and get model. > As Stealthmonger has commented concerning anonymity, if you want > security against traffic analysis, you have to accept delays: Set your > cover traffic rate somewhat higher than your average rate, and you'll > *eventually* catch up with peaks (though as with any queueing system, > the delays can grow without bound - requiring unbounded memory > *somewhere*). Delays (trading latency) are not the only way to achieve security. You may also elect to trade available throughput bandwidth in a wheat/chaff system. > I'm not aware of any open research on these kinds of questions - though > it may well be out there. What's the optimum cover traffic rate under > various assumptions about the real traffic rate and distribution? When > is it safe to use the traffic other users present as cover for your own? > Clearly if there's only one other user sending traffic, you can't use him > for cover as *he* can tell which of the packets are yours. But is there a > way to mix traffic from multiple users in a way that requires large numbers > of them to conspire to reveal anything? The mixmaster stuff looks at this > specifically from the point of view of a store-and-forward node - is there > some suitable useful analogue on a single link? Can we somehow get > the same guarantees without storage inside the network? There were some research references posted in the threads below. > we're now going to have to change our attitudes toward traffic analysis. Yes, a lot of oppurtunity exists to create new working networks in this area that utilize fill traffic and/or delay. You may want to review the recent guardian-dev and tor-dev side threads below on this exact subject of link padding, latency and analysis. Relavent papers and talk have been posted. https://lists.mayfirst.org/pipermail/guardian-dev/2014-November/004040.html https://lists.mayfirst.org/pipermail/guardian-dev/2014-November/004069.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007741.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007934.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008039.html http://www.metzdowd.com/pipermail/cryptography/2015-January/024479.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008099.html [Copied a few places simply to include these ongoing links as reference for anyone interested.]

1 0

Re: [Cryptography] Barrett Brown allocution statement in court today
by John Young 27 Jan '15

27 Jan '15

At 10:25 PM 1/24/2015, Mahlon Theobald wrote: >Well what happened? 5 years 3 months sentence. Time served of 2.5 years to be credited. Possible parole in 1 year. http://cryptome.org/2015/01/brown-145-104.pdf Defiant statement after sentencing: "Mission now to report on FU prison system after reporting on FU cyber system."

2 2

What happened to Snowden 2.0?
by Archivists 26 Jan '15

26 Jan '15

After the reported arrest there has been absolutely zero media activity. NDA in effect?

2 2

Illinois School Password Controversy, What the Mainstream News Is Getting Wrong
by Polity News 24 Jan '15

24 Jan '15

There are a lot of news stories about the law which allows Illinois schools to demand students' passwords. Many of the stories incorrectly implicate a new anti-cyberbullying law. The law which allows schools to demand student passwords is a different law that was passed in 2013. http://piratetimes.net/exclusive-illinois-law-allows-schools-to-spy-on-stud…

1 0

Barrett Brown allocution statement in court today
by John Young 22 Jan '15

22 Jan '15

Barrett Brown allocution statement in court today just released http://cryptome.org/2015/01/BB_allocution.pdf http://cryptome.org/2015/01/BB_allocution.doc

1 0