Re: [liberationtech] data manipulation

[coderman]

also relevant:
https://www.usenix.org/conference/enigma2016/conference-program/presentation/rozier

Data Integrity Based Attacks in Investigative Domains: How Companies
are Exploiting Data Science to Thwart Investigative Outcomes

Abstract:

The Trustworthy Data Engineering Laboratory (TRUST Lab) has been
working with the World Bank, the Federal Bureau of Investigation
(FBI), the Environmental Protection Agency (EPA), and the City of
Cincinnati to help solve a common problem faced by many organizations
involved in data driven investigations: companies and entities that
attempt to disguise malicious activities through attacks on the
integrity of available data.

In this talk we will explore the challenge of assuring data integrity
in heterogenous data systems that face the challenges of velocity,
variety, and volume that accompany the domain of Big Data. We will
examine real case studies in debarrment and corruption in
international procurement with the World Bank, investigations into
violations of the Foreign Corrupt Practices Act with the FBI, cases of
violations of the Resource Conservation and Recovery Act with the EPA,
and human rights abuses of low income citizens by corporate slum-lords
in the city of Cincinnati. In each of these cases we will show how
malicious actors manipulated the data collection and data analytics
process either through misinformation, abuse of regional corporate
legal structures, collusion with state actors, or knowledge of
underlying predictive analytics algorithms to damage the integrity of
data used by machine learning and predictive analytic processes, or
the outcomes derived from these processes, to avoid regulatory
oversite, sanctions, and investigations launched by national and
multi-national authorities.
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] data manipulation

[coderman]

On 11/10/15, carlo von lynX  wrote:
> ...
> in other words, these methods based on JTRIG and KARMA POLICE
> dismantle democracy at its foundation - the ability to form a
> political opinion and to make government act accordingly.

the combination of mass spying for mass media control (including propaganda)
 is abhorrent, and as yet unrestrained.



> for as long as we do not produce a surveillance-resistant social
> networking and communication platform, we are not in a state of
> democracy. anywhere in the world. i cannot imagine any higher
> political priority than to fix the internet and create a distributed
> social network to replace facebook and the like.

decentralization is a moral imperative for many reasons!

and a fully decentralized IT infrastructure might thwart centralized
power most effectively.



> what do you think?

fully decentralizing these types of services, along with
decentralizing the production of computing systems which support them,
some of the most challenging problems in technology. good luck! :)

best regards,


P.S. these are also my favorite problems to explore. don't get discouraged!
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] data manipulation

[coderman]

On 11/9/15, Elias Groll  wrote:
> ... I've been reporting on warnings issued by DNI Clapper and NSA Director
> Rogers on the threat posed by data manipulation and integrity attacks.
> These statements have been vague in nature and lacking specifics.

generally, manipulating data is done for any of the following reasons, and more!

- to eliminate, fabricate, or bend digital records to achieve an end,
such as espionage, blackmail, disruption, CNE, or camouflage.

- to introduce fatal flaws into processing systems, such that loss of
service or data occurs. e.g. financial systems will "halt" if internal
integrity checks fail. this loss of service is sometimes itself the
intent.

- to remove the possibility of accurate attribution or forensic
analysis. similar to first but focused on "getting away clean" after
committing a "cyber crime".

- to prevent a targeted business from remaining a going concern, if
business critical records are lost or corrupted.

others, but these are motivations foremost in mind.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The Future of Security Journalism

[coderman]

On 1/30/15, hellekin  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 01/30/2015 08:03 AM, coderman wrote:
>>
>> your threat model is:
>>  securing yourself and your sources against
>>   nation state dragnet and targeted attacks,
>>including tailored access and special collection.
>>
> *** Unfortunately the problem goes further than that.
>
> To me it seems that the threat model is a bit harder than just securing
> yourself and your sources against surveillance: corporate-states beyond
> nation-states are--have been--removing self-determination of people and
> deem it terrorism, and the freedoms, rights, and responsibilities of
> individuals and communities around the world.  This situation is far
> worse than anything we've seen before for its global scale and the
> inevitability of running into its consequences.
>
> In the light of this analysis, "security" is a bit understated and
> vague, don't you think?


if anonymity and privacy are aspects of security,
 and corporations as much a threat as nation states, in some scenarios,
  then perhaps it is not so understated or vague,
   just different shades of incredibly hard to attain "security"...
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The Future of Security Journalism

[coderman]

On 1/29/15, J.M. Porup  wrote:
> ... If we don't wish to be serfs in the new feudal, digital
> world, we need to re-disrupt the disruption, and invent new tools that
> ensure human liberty and dignity. ... that time
> is short, and the New Dark Age is nearly upon us.


as one who is always fond of the question,
 "what's your threat model?"


the implication appears to be two fold:

1. good security journalism, aka "activist journalism", begs forth
selective and retributive prosecution through open-ended legislation
(CFAA, et. al.) as cover.

2. technical sophistication pursuing these prosecutions is now, thanks
to the cyber-industrial-complex, at a point where law enforcement uses
techniques recently considered nation state intelligence caliber.


thus to pursue "activist security journalism" that is not powers that
be sanctioned "mainstream security regurgitation" journalism,

your threat model is:
 securing yourself and your sources against
  nation state dragnet and targeted attacks,
   including tailored access and special collection.


this is currently considered a "Hard Problem" (TM)(R) even with
decades dedicated to the challenge.  i do take hope in the fact that
most earth humans are not coding to hard problems, but instead to
easy, well paying ones.  perhaps different incentives will play a
bigger role for security?
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] LRAD counter-measures?

[coderman]

On 12/14/14, Jay Cassano  wrote:
> ...
> If anyone knows of attempts to build such counter-measures or has ideas
> for how one might be built, please feel free to reply to me off-list.

FU-LRAD kit:

1) Flexible Flyer: 26" Metal Saucer - Steel disc with rope handle
grips, Ages 4 and up. (use to re-direct offensive acoustics towards
offenders.)
2) Surefire EP4 Sonic Defender Ear Protection, 19dB noise reduction
rating (NRR) with stoppers in.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Any thoughts on the OPERATION CLEAVER reports?

[coderman]

On 12/7/14, Michael Rogers  wrote:
> ...
> Was this meant for another thread? The Operation Cleaver report
> doesn't mention smartphones or baseband exploits.

hi Michael,

this was indeed a mis-chan; Operation Auroragold a different
coordinated and and determined group dedicated to compromising the
worlds cellular communications infrastructure run by multiple
companies across many countries.

apologies for the confusion!  (too many operations :)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Any thoughts on the OPERATION CLEAVER reports?

[coderman]

On 12/2/14, Nariman Gharib  wrote:
> "OPERATION CLEAVER: A new global cyber power has emerged; one that has
> already compromised some of the world’s most critical infrastructure. The
> Operation Cleaver report sheds light on the efforts of a coordinated and
> determined group working to undermine the security of at least 50 companies
> across 15 industries in 16 countries. Our report unveils the tactics,
> techniques and procedures used in what it still an ongoing campaign. "

reinforces what a number of individuals have been saying for years now,

1. smart phones are the least privacy capable computing devices, with
inherent vulnerabilities in baseband and carrier configurations which
cannot be mitigated by the user, no matter what they load / change on
device.

2. encryption software on phones is good for thwarting passive
surveillance (watching plain-text) but offers no protection against an
active adversary in a privileged position.

best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] New Citizen Lab report on Hacking Team's Government Surveillance Malware

[coderman]

On 6/26/14, Rich Kulawiec  wrote:
> ...
> The most disturbing thing about it is the realization that this can't
> possibly be the only such project.  Surely there are others.  Many others.

more news on this (espionage malware) front:
  
https://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/regin-analysis.pdf
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Looking for a talented TOR/VPN developer/ops manager

[coderman]

On 10/29/14, William G. Gardella  wrote:
> Hello Rafal,
>
> Before circulating this more widely, I would urge you to reconsider your
> choice of the "white male hacker in hoodie surrounded by green Matrix
> text" art next to the posting. I find it sad that even in social justice
> and activism circles we cannot rid ourselves of such pernicious and
> exclusionary stereotypes.

seconded, and also note:

it is "Tor", not "TOR". those qualified for this position appreciate
the difference!

best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] With This Tiny Box, You Can Anonymize Everything You Do Online | WIRED

[coderman]

On 10/13/14, Travis Biehn  wrote:
> ...
> Interested in update mechanisms, interdiction resilience, trusted boot, web
> / other interfaces.
>
> These devices just change and expand your threat surface.


back in 2007/2008 we launched the Janus Privacy Adapter devices. first
on dual NIC gumstix, then on the now defunct Yoggie Gatekeeper Pro
hardware. both of these had a minimal footprint, two ethernet jacks
for transparent proxy in-line, and power via USB.

updates deployed via hidden service, or yourself via command line ssh.

the attack surface (on device) was minimal, as the control port was
not exposed to the network, etc.

client risk is another story, considering untrusted exit relays and
insecure protocols. for this reason we applied a number of band-aids
blocking known risky ports. this is not an effective approach, and
EPICFAIL shows how a single request not behind Tor proxy unmasks
perfectly.

best case you would use a Tor Browser on each of the hosts behind the
privacy appliance in transparent proxy mode. (e.g. TOR_TRANSPROXY=1
before launching) and block any other application or service from
communicating over the network.  this significantly impairs
functionality, however.

as also mentioned in the article, there have been other variations on
this theme, with more or less robust security posture on device and
for the users behind.

many of these considerations are outlined in the transparent proxy
page: https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] proof of tampering

[coderman]

On 9/16/14, Jonathan Wilkes  wrote:
> ... over a year after the initial Snowden-leak stories-- I'm curious if
> anyone has references to articles or papers that have researched and
> reproduced any of these exploits to show how they are used in practice to
> steal data, surveil, etc.

it is very difficult finding detailed, public research into this
particular type of offensive reversing. public knowledge is
constrained by:

- lack of access. see list history regarding ability to even
detect/observe the most advanced attacks.  this is changing, however.
c.f.: exposure of corporate level, middle school type contract kit:
https://wikileaks.org/spyfiles4/ and the work of Morgan Marquis-Boire.
The Stuxnet/Flame/Guass/Duqu/Skywiper/Mahdi analysis are still the
only views of TAO/NSAlike campaigns. corrections welcome ;)

- lack of skills+/-experience spanning domains required to dissect the
attack across its many pivoting boundaries of enabling and transiting
through hardware, devices, networks, and systems under attack. [a
redditor could do a shiny graph showing how nearly every technologist
with the expertise for world class malware analysis ends up under
secret contract, private contract, or does something else outside of
university, to varying proportions of each.]

- lack of interest or time; the small subset left in consideration is
only human, and a thorough reverse analysis of complex stealthy code
eats your life in quarter or full years chunks. a passion for the
subject only carriers so far...



finally, to underscore the point as is so conveniently at fingertip,
your mail immediately went to the spam trap, having violated who knows
what in googbrain to indicate forgery or malicious intent.

why aggressively stamp down a narrative when you can slowly bleed it
into silent not-existing instead?



good luck, and best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Foxacid payload

[coderman]

On Tue, Jul 22, 2014 at 1:48 AM, coderman  wrote:
> ...
> perhaps someone to help answer the question is Google, if they felt inclined.

more context, although less sophisticated than TAO tech:

"When Governments Hack Opponents: A Look at Actors and Technology"
 - http://www.icir.org/vern/papers/govhack.usesec14.pdf

'''
Computer security research devotes extensive efforts to protecting
individuals against indiscriminate, large-scale attacks such as those
used by cybercriminals. Recently, the problem of protecting
institutions against targeted attacks conducted by nation-states
(so-called “Advanced Persistent Threats”) has likewise elicited
significant research interest. Where these two problem domains
intersect, however—targeted cyber attacks by nation-states against
individuals —has received virtually no significant, methodical
research attention to date.

This new problem space poses challenges that are both technically
complex and of significant real-world importance. In this work we
undertake to characterize the emergent problem space of nation-state
Internet attacks against individuals engaged in pro-democracy or
opposition movements. While we lack the data to do so in a fully
comprehensive fashion we provide extensive detail from both technical
and operational perspectives as seen in three countries. We view such
characterizations as the fundamental first step necessary for the
rigorous, scientific pursuit of a new problem space.

For our study we draw upon several years of research we have conducted
into cases from Bahrain, Syria and the United Arab Emirates. We frame
the nature of these attacks, and the technology and infrastructure
used to conduct them, in the context of their impacts on real people.
We hope in the process to inspire additional research efforts
addressing the difficult problem of how to adequately protect
individuals with very limited resources facing powerful adversaries.
'''
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Foxacid payload

[coderman]

On Fri, Jul 18, 2014 at 12:22 PM, Denis 'GNUtoo' Carikli
 wrote:
> ...
> If the adversary looses one exploit each times he attacks someone, then...

perhaps someone to help answer the question is Google, if they felt inclined.

per "re:publica 2014 - Morgan Marquis-Boire: Fear and Loathing on the Internet"
 - https://www.youtube.com/watch?v=bOK_KAXbTe8
(better archive?)

at one point most large media organizations (21 of 25) received
targeted malware through email.  most of that is weaponized-unpatched,
not weaponized-0day[s].

Google has implemented both more prominent notifications to warn users
directly, and published research on hacking by governments with
HackingTeam, Gamma, etc. publicly.

it would be interesting for Google to report specifically 0day attack
trends, past and current, to determine if they've successfully moved
the more advanced attacks to other mediums of communication outside
their purview.

---

using a different reference,

it is difficult to get a sense of how the detection landscape has
changed for TAO and JTRIG like groups, as the leaks only indicate that
attacks are almost always successful, and presumably that also means
undetected. out of 100,000's of implants, only dozens identified and
dissected by research groups or anti-virus companies.

one trend is clear, which is away from email attachments or click bait
toward in-line attacks on downloads, updates, browser software, chat
clients, and other attack surfaces.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Snakeoil and suspicious encryption services

[coderman]

On Mon, Jul 21, 2014 at 5:52 PM, Aymeric Vitte  wrote:
> ... including your focus on elementary mitm
> issue, your arguments and judgement are so basic that I am wondering why I
> am answering it, you should do some reading, and if you can trivially defeat
> Peersm, then just show us how

problems with js crypto:
- side channels / non constant run time
- lack of access to robust entropy sources
- unless delivered over pinned HTTPS with CSP vulnerable to mitm attack
- unless an extension, vulnerable to code injection or malicious servers
- even as extension, keeps keys in address space of browser with rich
attack surface. (this is true for SSL/TLS as well)


contrast this with a configuration where key material is kept isolated
from the rich browser attack surface through low level protections,
e.g. Qubes throwaway browser app vm talking to hidden service.  A
separate Tor VM would contain keys for your client on the network and
accessing hidden sites, while the vulnerability rich browser speaks
over this transparent channel managed outside its purview.

for advanced threats, isolation and defense in depth are paramount.
peersm is inherently limited in this regard, not matter how many other
pitfalls it successfully avoids.

unfortunately strong isolation and defense in depth are even more
difficult to make easy to use, once again highlighting the
complexities of usability and security in privacy enhancing
technologies.

best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] no-disclosure / other-disclosure [was: Foxacid payload]

[coderman]

On Sun, Jul 20, 2014 at 4:55 PM, coderman  wrote:
> ...
> the problem is you assume this is easy.

ok, maybe easy after all. just write a book! ;)

http://www.theguardian.com/books/2014/feb/20/edward-snowden-files-nsa-gchq-luke-harding


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] no-disclosure / other-disclosure [was: Foxacid payload]

[coderman]

On Sun, Jul 20, 2014 at 8:00 AM, Michael Rogers
 wrote:
> ...
> Assuming the effort doesn't stop when exploits dry up, but instead
> looks for new ways to attract exploits, what's the problem?

the problem is you assume this is easy.

"look for new ways to attract exploits" is a special kind of fishing.

maybe i'm just incompetent? i've been playing the "observe attacks to
better defend against attacks" game for over a decade. it used to be
dead simple, the exploits prevalent, the environment accommodating
(run a VM, expose to attacks, trace the traffic and malcode)

now even the average crimeware is obfuscated and multi-staged, nopes
out of virtualized environments to avoid detection, and rarely if ever
uses novel attacks or 0day exploits. even the targeted spear fishing
campaigns rarely use 0day anymore.

now consider the attacks you're looking for are an order of magnitude
less prevalent, an order of magnitude more stealthy, and an order of
magnitude more difficult to capture, with the most advanced attacks
delivered over direct injection to local radios, not via upstream
network over IP. (not to mention all the tricks available if physical
access to your systems is obtained. e.g. physical implants through
blackbag or  tampering during shipment.)



>> if your concern is security for the public, do it by making the
>> software we use more difficult to exploit as a whole, rather than
>> fixating on free exploits from NSA for a particular vulnerability
>> among many.
>
> That sounds like a false dichotomy to me. Publicising a specific
> exploit may spur the development of general as well as specific
> mitigations.

let me provide a concrete example: stolen certificates used in an
active attack to inject in the middle a malicious payload as trojan
update, then feed a second stage to this loader for desired effect.

publicize the payload over presumably authentic TLS? "that's not
possible because the certificate is valid.",  provider:"this is false
as we have no evidence of malicious activity on our servers nor have
any of our systems sent malware to our customers" (see lavabit. they
won't believe you unless the private keys are leaked, or stolen keys
are used for signing malicious code directly.)

publicize the code delivered in the payload that serves as loader? "if
you allow untrusted code to execute locally, that's your problem."
(see every mobile and most desktop app that does insecure updates, for
a start.  the loaders are not really that interesting)

publicize the local priv esc. delivered to the loader for
pivot/persistence/exfil? "another day, another local escalation, you
should have better
[sandboxing|grsec|rbac|ACLs|apparmor|selinux|jails|etc]" (see how
local execution almost always leads to privilege escalation on most
consumer devices and computers)


all of these things we know are problems. not only that, but we have
multiple general and specific mitigations for them, and yet they
continue to be prevalent, the protections slow to be integrated. go
look up how many known and still un-patched vulnerabilities exist in
your mobile device.



finally, while "publishing the whole thing" is a bad idea (e.g. the
public db of verbatim attacks and payloads),

reporting some of the vulns (like the priv. esc part) is useful,
though i still argue it should be done anonymously to the vendor, so
that whoever is in position to observe these attacks may continue to
do so as long as possible.  i also argue that "report anonymously to
the vendor" is very difficult right now, given the types of systems
every vendor uses to coordinate vulnerability reporting. (plain-text
email, insecure web forms, "private" mail lists, etc.)


best regards,
-- 
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 
compa...@stanford.edu.

[liberationtech] Identifying back doors, attack points, and surveillance mechanisms in iOS devices

[coderman]

doubt this will surprise anyone; iOS intentionally designed to support
surveillance.

---

http://www.sciencedirect.com/science/article/pii/S174228761436

"Identifying back doors, attack points, and surveillance mechanisms in
iOS devices"
 by Jonathan Zdziarski

Abstract

The iOS operating system has long been a subject of interest among the
forensics and law enforcement communities. With a large base of
interest among consumers, it has become the target of many hackers and
criminals alike, with many celebrity thefts (For example, the recent
article “How did Scarlett Johansson's phone get hacked?”) of data
raising awareness to personal privacy. Recent revelations (Privacy
scandal: NSA can spy on smart phone data, 2013 and How the NSA spies
on smartphones including the BlackBerry) exposed the use (or abuse) of
operating system features in the surveillance of targeted individuals
by the National Security Agency (NSA), of whom some subjects appear to
be American citizens. This paper identifies the most probable
techniques that were used, based on the descriptions provided by the
media, and today's possible techniques that could be exploited in the
future, based on what may be back doors, bypass switches, general
weaknesses, or surveillance mechanisms intended for enterprise use in
current release versions of iOS. More importantly, I will identify
several services and mechanisms that can be abused by a government
agency or malicious party to extract intelligence on a subject,
including services that may in fact be back doors introduced by the
manufacturer...
'''
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Snakeoil and suspicious encryption services

[coderman]

On Sat, Jul 19, 2014 at 2:13 AM, carlo von lynX
 wrote:
> ...
> The slides are entirely missing out on distinguishing public-key
> routing infrastructures such as Tor, I2P, GNUnet, cjdns etc from the
> traditional encryption-on-top-of-broken-routing technologies

there were some useful projects that support or facilitate a
decentralized structure or apply to privacy enhancing technologies at
the end point:

[in order of my personal preference]

"Tahoe-LAFS is a Free and Open cloud storage system. It distributes
your data across multiple servers. Even if some of the servers fail or
are taken over by an attacker, the entire filesystem continues to
function correctly, preserving your privacy and security."
- https://tahoe-lafs.org/trac/tahoe-lafs

"Macaroons are flexible authorization credentials that support
decentralized delegation, attenuation, and verification."
- https://github.com/rescrv/libmacaroons

"libsnark: a C++ library for zkSNARK proofs"
 - https://github.com/scipr-lab/libsnark

"The Cryptosphere is an open-source P2P web application platform for
decentralized, privacy-preserving software which keeps users in
control of their own content."
- http://cryptosphere.org/



thank you for the slides Steve, i discovered Macaroons!

best regards,
-- 
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 
compa...@stanford.edu.

[liberationtech] Strong Security Processes Require Strong Privacy Protections

[coderman]

"Strong Security Processes Require Strong Privacy Protections"

A request for all security conscious organizations handling
vulnerability reports to deploy privacy enhancing technologies.

---

With the Snowden disclosures and Google's Project Zero on the minds of
security professionals everywhere, it is time to evaluate one more
aspect of this renewed focus on 0day and targeted attacks:
vulnerability submission to vendors. [0][1]

Software vulnerabilities of use to nation states and espionage
organizations are recognized as a threat to privacy and basic human
rights. Their impact no longer dismissable or discounted given
evidence of misuse. I will not discuss hardware vulnerabilities in
this treatment as they entail different considerations and
constraints. [2]

Reporting vulnerabilities of this nature in turn requires strong
privacy protections commensurate with the five and six digit monetary
values they command, and the adversaries intent on discouraging their
discovery or mitigation. [3][4]

---

Therefore, any organization handling vulnerability reports must
support strong privacy for vulnerability submission. This is mandatory
even if most or all issues received via this channel are not 0day, not
high value, and entail very little risk to users.

The characteristics of a strong private reporting method are:

- Email must not be used. In the best circumstances email leaks too
much information. In common situations it is passed around clear text,
trivially interfered with, and winds through software with huge
usability and vulnerability problems. Email for initial security
vulnerability reporting must cease immediately. [5][6]

- Public web systems for vulnerability reporting must not be used.
Like email, this leaks too much information and is vulnerable to a
wide array of attacks destroying any privacy intended. [7][8]

- Submission of reports via hidden site required. This has become
fashionable in media organizations as the "secure drop" for
whistleblowers, and it is equally apropriate for vulnerability
reporting. This significantly raises the cost of surveilling a
vulnerability reporting service, and ensures that passive interception
of reported vulnerabilities is impossible. [9]

- Encryption of submitted reports required. PGP and GPG are wonderful
tools, despite encrypted email being a dismal failure. While the
hidden drop may protect the privacy of the reporter, encryption of the
report content to specific vulnerability researchers' keys ensures
privacy to the receiver. A compromise of the hidden site must not lead
to access of reported vulnerabilities. [10]

- Submitter anonymity the default. Submissions and communication must
accomodate an anonymous identity. If a researcher wishes to claim
credit they must opt-in and provide additional information. No
psuedonymous account requirements, no key linking across submissions.

- Obfuscated disclosure should be available if desired. Capturing 0day
in the wild used for espionage or cyber effects is a rare event.
Publicly disclosing when, where, and how you obtained such captures
ensures you're likely never to see any others. Researchers in position
to observe and inspect such events should be able to report the
vulnerabilities without credit and without indicating the origin. A
vendor could provide a "cover story" for how the vulnerability was
discovered internally, to best protect sources' ability to continue to
discover these types of weaponized exploits in the wild.

Finally, it goes without saying that this privacy applies during
reporting and mitigation phases of defect resolution. Once a patch is
prepared and public the details of the vulnerability should be public
as well, via email list, public blog, or any other useful medium.

---

As participants in the security industry it behooves us all to set an
example for others and to demonstrate a committment to security and
privacy via action.

Security conscious organizations handling vulnerability reports can
support strong privacy and send a clear message deploying private
reporting methods described above.

Security researchers must demand strong privacy from organizations
they collaborate with, even in the most trivial or minor of
circumstances, so that infrequent severe vulnerabilities may also be
reported in confidence.

Privacy is a basic human right we must all support. Let's demonstrate
our support by using privacy enhancing technologies to resolve risks
to privacy!


best regards,



0. "The NSA Revelations All in One Chart"
 https://projects.propublica.org/nsa-grid/

1. "Announcing Project Zero"
 No link as the announcement is only supported over HTTP; attempt
HTTPS and you're redirected to plain-text. This is an embarassment
that should be fixed, Google Project Zero!  (the other plain-text
sites below have not unreasonable exuses ;)

2. "New technologies are radically advancing our freedoms but they are
also enabling unparalleled invasions of privacy"
 https://www.eff.org/issues/priv

Re: [liberationtech] Foxacid payload

[coderman]

On Fri, Jul 18, 2014 at 1:40 AM, Wasa Bee  wrote:
> if Google start actively looking for bugs, aren't they going to have a
> ranking per vendor every year to incentive "bad vendors" to improve?

you'll be able to read the vendor responses yourself in the Project
Zero blog. two timelines were stated:
- 60 to 90 days for Google discovered issues to be responsibly
resolved (then they publish)
- 7 days for in-the-wild exploits to be resolved (then they publish)

i approve of this timeline, and am anxious to see if NSL's are used to
trump some exploits.
(how would you know? good question :)



> What are the other means they can incentive vendors, without making too much
> of a fuss that users don't loose confidence in web security overall?

carrot:
 "we found this bug in your software this way. you should add this
type of testing to your continuous build and test infrastructure so we
don't have to keep reporting issues like this, and we can all be more
productive!"

stick:
 "when company X in your industry failed to address serious security
concerns, the public noticed, and the hit to their bottom line was
"
-- 
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 
compa...@stanford.edu.

[liberationtech] no-disclosure / other-disclosure [was: Foxacid payload]

[coderman]

On Thu, Jul 17, 2014 at 2:57 PM, Griffin Boyce  wrote:
> ...
>   Solidarity is really important here.  "Increased security for those
> who actively set honeytraps" doesn't really scale at all, and most
> people will never reap the rewards of this work. =/

it doesn't scale at all, actually.  and it doesn't provide better security.

to avoid FOXACID** risk, you are not using the Internet like normal people.
(only pond over onions from wifi hotspots using gnuradio stacks on
custom built hardware?)

to catch FOXACID** 0day you are not simply browsing to www.jihad.is,
and you likely wouldn't notice it if it did implant.
** and by this i mean
TAO/QUANTUM*/TURBULENCE/TURMOIL/TUR/DUQU/FLAME/** in general.




> Forcing the
> government and defense contractors to burn through 0day at a high rate
> is far, FAR better

absolutely! this is why i like the Google effort; they are aiming for
the vulnerabilities most useful in these campaigns.

if your intent is to cause them to burn through 0day,
 then burn their 0day en mass, entire classes or critical pivots at a time!
:)



> These backdoors need to be revealed if we're to protect
> ourselves.
>
>  Let's sunburn these motherfuckers.

the technical detail in the TAO catalog and the JTRIG docs and the
XKeyScore source code among other leaks has been exceptionally helpful
in this regard.

it shows how hardware is compromised during shipping.  it shows how
attacks are tailored to the target, out of a wide repertoire of
weaponized options (not to mention the vast trove of exploitable bugs
they've found or fuzzed and not yet weaponized into operational
capability). it shows their ability to be any host anywhere on the
public internet, negating the utility of ACLs and good practice. it
shows their affinity for in the middle attacks, where applications and
operating systems are most vulnerable. it shows their continued,
pervasive efforts to defeat crypto systems, further opening exploit
avenues. it shows their impressive budget for field gear and
up-close-and-personal exploitation direct to your radios sitting on
your bus.

and specifically, it shows how an effort to collect and distribute
captured NSA 0day will do nothing to improve security of those who
need it, but instead let NSA better target and implement their attacks
for stealth.



as thought experiment:
a hidden site is setup by presumed trustworthy experts.  exploits are
funneled there, then they all dry up.

- congratulations! NSA is out of 0day! ?
- congratulations! NSA is not using 0day over Internet! ?
- technique for catching 0day has been compromised. start over,...

explain to me how any public effort will not fall into the last trap,
repeatedly.



in summary, and back to the original point:

if your concern is because your threat model is NSA attacker, your
problem is all technology, not specific exploits.  a public registry
not changing that risk at all.

if your concern is security for the public, do it by making the
software we use more difficult to exploit as a whole, rather than
fixating on free exploits from NSA for a particular vulnerability
among many.

if your concern is discovering more about the attackers, catching the
free exploits is harder than you think and the time spent being able
to catch, catching them, and noticing when you caught one, is better
spent as tool to peer inside the veil of secrecy regarding tasking
these systems than publicly disclosing and starting all over on your
collection effort.

if your concern is to raise a signal of contempt for this behavior
alone and force a modest rolling of exploits used, then by all means
try and catch some NSA 0day and post it publicly!  i would be curious
to see the results, i must admit.



best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Foxacid payload

[coderman]

On Thu, Jul 17, 2014 at 1:11 PM, coderman  wrote:
> ...
> - if you want to thwart FOXACID type attacks there are ways to do it
> without knowing specific payloads. (architectural and broad
> techniques, not fingerprints on binaries or call graphs)


some specific examples:

A: exploit reuse to arbitrary execution, persist via pivot
D: run vulnerable app in Throw away Qubes VM, log traffic for
inspection through gateway VM.  exploit unable to persist, exploit
vector captured.

A: android intent misuse to elevate privs, then exfiltrate data.
D: "root" your device to restrict intent use and network communication
by application, preventing vulnerable app from being usefully
exploitable.

A: baseband exploit to device crypto key retrieval used
D: apply software defined radio to confirm compromise at baseband
level via suspect emissions, use SDR instead of proprietary radios to
communicate.
 (you can't mitigate against a compromised baseband, in most cases.)


"convenience is the cost of privacy" - who said this? very true in
this instance.
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Foxacid payload

[coderman]

On Thu, Jul 17, 2014 at 1:11 PM, coderman  wrote:
> ...
>> Forcing deployments to move to more interesting bugs will also give
>> insight into IAs' exploit sourcing methodologies.
>
> this is absolutely true and useful,
>  and does not require making specific exploits public.

i have high hopes for Google's Project Zero:
 http://www.wired.com/2014/07/google-project-zero/

we'll see how the effort plays out!


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Foxacid payload

[coderman]

On Thu, Jul 17, 2014 at 12:41 PM, Andy Isaacson  wrote:
> ...
>> this is exactly why some who have received these payloads are sitting
>> on them, rather than disclosing.
>
> Hmmm, that seems pretty antisocial and shortsighted.  While the pool of
> bugs is large, it is finite.

consider, having recv a payload:
- who do i trust to evaluate / dissect?
- would it be better to fix a class of bugs than a specific instance?
- what information would be lost if burned?

looking over the JTRIG and TAO catalogs you see how pervasive
vulnerabilities are in all our systems.  there is a process at work
churning out weaponized exploits.

the only exception might be a heartbleed type bug, where the
vulnerability is pervasive and the risk high. (this is also the type
of bug least likely to be used capriciously against targets. you would
need to be high value to get a high value exploit your direction.)



> Get bugs fixed and get developers to write
> fewer bugs going forward, and we'll rapidly deplete the pool of 0day and
> drive up the cost of FOXACID style deployments.

i was young once, too.  ;)

in all seriousness, we don't know how to build systems resistant to
the attacks of collaborating nation states.  you can dodge some
attacks, some of the time, at best.
research continues...



> Forcing deployments to move to more interesting bugs will also give
> insight into IAs' exploit sourcing methodologies.

this is absolutely true and useful,
 and does not require making specific exploits public.



> Hasn't someone already created an open "FOXACID observatory" tracking
> potential deployments of this and similar APT exploit deployments?

various security companies or research groups drop docs for publicity
or other self interest.  the work some NGOs are doing to protect human
rights workers in foreign lands may touch on it now and then. (burning
HackingTeam's tech, for example)



>> it is more useful to mitigate privately, and observe how/when an
>> exploit is used, than burn it publicly for zero effective security
>> improvement.
>
> That seems unlikely to be correct even in the medium term.

let's have a chat at a conference over strong drinks and plausible
deniability...



to recap:

- if you want to thwart FOXACID type attacks there are ways to do it
without knowing specific payloads. (architectural and broad
techniques, not fingerprints on binaries or call graphs)

- burning specific payloads does nothing to protect against the
threat, as they are trivially replaced. (this is a continuous process
with envious resources)

- all options for disseminating caught exploits involve trust in third
parties which you may not give. (sorry, i'm a skeptic by nature and
nurture :)

- private use for signalling/discovery (see honey tokens, etc.) is
useful as a testing / integrity check in some ways, given no other
more useful options.
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Foxacid payload

[coderman]

On Thu, Jul 17, 2014 at 12:19 PM, Andy Isaacson  wrote:
> ...
> And once you've patched this bug, FOXACID will update to issue another
> 0day.
>
> It's worth doing, for sure!  Patching bugs makes us all incrementally
> safer.
>
> But don't pretend that patching the specific attack your adversary is
> currently using will disable or even seriously inconvenience the
> adversary.


this is exactly why some who have received these payloads are sitting
on them, rather than disclosing.

it is more useful to mitigate privately, and observe how/when an
exploit is used,
 than burn it publicly for zero effective security improvement.

(the less scrupulous would sell to highest bidder for other clandestine hacks)


better ideas welcome!


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] data mine the snowden files [was: open the snowden files]

[coderman]

added example privoxy config as http_proxy to Tor, add sig note for Update 13.
 no further updates on list; contact direct if issues encountered.

best regards,

 Cryptome Donation Required
  - http://cryptome.org/donations.htm

 Donation also provides current archive as this selection is not current,
  and increasingly out of date by the day.

 -

 "This is a trap, witting and unwitting.
  Do not use it or use at own risk.
  Source and this host is out to pwon and phuck you in complicity
   with global Internet authorities.

  Signed Batshit Cryptome and Host,
  9 July 2014, 12:16ET."
   - https://cpunks.org//pipermail/cypherpunks/2014-July/005020.html

 -

 Index: 
  0eb8551d977dde4f4193b3a16dedcd18f01e854e371e96623d33dd5b9519e413 *USB-1.rar
  9653d105293b9f77d5b0067d51a35ed286a7f50a0b37b3ea2bd78c092caab584 *USB-2.rar
  7e798bb2b09cac49181aa7c12170e03fc3d3cf69a73d9e1b04171c80910e7525 
*Update-13-1231.rar
  b63e185c21232724f9c90238496b9122a46d492752d56f690200fab6fe9fb6ed  
Update-14-0206-0602.tar.rar
  6e5146b4c53f61b555822eda90e70a20a8050fe3dbf0bd3a084a042a36bdd3b1  
Cryptome-Update-13-0701-to-13-1202.tgz
  80652978f46ef6e6f26bd2bec406349ef766ad1722fc81d9f7575148edc6324f  
wikileaks-bank-julius-baer.zip
  c56f0fd30924f7398ca9e20c098acced50766d3325754f29014dd33029ebf351  
wikileaks-safekeep-to-08-0210.zip
  9d2aa03048c60eec2c94d45293d4e95977a94f3477a4701f6ee2ef7ec888a7c9  
WikiLeaks-State-Dept-Cables-xyz.zip
 *- these files have a detached signature by presumed key
0xB650572B8B3BF75C "Cryptome "
append '.sig' for signature files.
 
 -

 Recommended usage:
  # apt-get install privoxy tor
  nano /etc/privoxy/config
--- begin-cut /etc/privoxy/config ---
# Tor Privoxy configuration
# NOTE: toggle=0 disables all privacy rewrite protections
toggle  0
confdir /etc/privoxy
logdir /var/log/privoxy
logfile logfile
hostname hostname.example.org
listen-address  127.0.0.1:8118
enable-remote-toggle  0
enable-remote-http-toggle  0
enable-edit-actions 0
enforce-blocks 0
forwarded-connect-retries  0
accept-intercepted-requests 0
allow-cgi-request-crunching 0
split-large-forms 0
keep-alive-timeout 5
socket-timeout 300
max-client-connections 256
#
# for Tor browser bundle 
#forward-socks5   /   127.0.0.1:9150 .
# for Tor upstream
forward-socks5   /   127.0.0.1:9050 .
--- end-cut --- 

 Aria2 download:
  # Requires Tor running and http proxy to Tor at 127.0.0.1:8118
  export onions="sek42kxkbjuivxws.onion ajzxwgtrtws7zwyg.onion 
wpv2bxujoctsmzcn.onion aiyu6uyckomxt2ld.onion kvrvzxgdutjcjxqw.onion 
hz5sj76rh3avsmfc.onion jt7klzczup6hrtes.onion 3qcs4cqbsrfdz7xa.onion"
  export files="Update-13-1231.rar Update-14-0206-0602.tar.rar USB-1.rar 
USB-2.rar wikileaks-bank-julius-baer.zip wikileaks-safekeep-to-08-0210.zip 
WikiLeaks-State-Dept-Cables-xyz.zip Cryptome-Update-13-0701-to-13-1202.tgz"
  for cfile in `echo $files`; do
export olist=""
for chost in `echo $onions`; do
  export olist="${olist} http://${chost}/cryptome-july2014/${cfile}";
done
echo "Retrieving $cfile ..."
aria2c \
 --all-proxy=127.0.0.1:8118 \
 --continue=true --always-resume=true \
 --retry-wait=30 --timeout=120 \
 --summary-interval=3 \
 --max-connection-per-server=2 --max-concurrent-downloads=8 \
 -o "$cfile" `echo $olist`
  done

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iL4EABEKAGYFAlPAxEBfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDQxQzEyQjhDMzA3RDdFMjE5OEFBNTc4MTY1
QTg0N0U3QzJCOTM4MEMACgkQZahH58K5OAxNnwD/QgupHQOtNx6RNsF1nJR2n9FB
qXRhdIYxwbTbTzAji8MA/0XAy3vpsS/V7TR2MmS1Lrhvyg7UHrcBZVZlu36hYWaU
=fdiR
-END PGP SIGNATURE-
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] data mine the snowden files [was: open the snowden files]

[coderman]

 Cryptome Donation Required
  - http://cryptome.org/donations.htm

 Donation also provides current archive as this selection is not current,
  and increasingly out of date by the day.

 -

 "This is a trap, witting and unwitting.
  Do not use it or use at own risk.
  Source and this host is out to pwon and phuck you in complicity
   with global Internet authorities.

  Signed Batshit Cryptome and Host,
  9 July 2014, 12:16ET."

 -

 Index: 
  0eb8551d977dde4f4193b3a16dedcd18f01e854e371e96623d33dd5b9519e413 *USB-1.rar
  9653d105293b9f77d5b0067d51a35ed286a7f50a0b37b3ea2bd78c092caab584 *USB-2.rar
  7e798bb2b09cac49181aa7c12170e03fc3d3cf69a73d9e1b04171c80910e7525  
Update-13-1231.rar
  b63e185c21232724f9c90238496b9122a46d492752d56f690200fab6fe9fb6ed  
Update-14-0206-0602.tar.rar
  6e5146b4c53f61b555822eda90e70a20a8050fe3dbf0bd3a084a042a36bdd3b1  
Cryptome-Update-13-0701-to-13-1202.tgz
  80652978f46ef6e6f26bd2bec406349ef766ad1722fc81d9f7575148edc6324f  
wikileaks-bank-julius-baer.zip
  c56f0fd30924f7398ca9e20c098acced50766d3325754f29014dd33029ebf351  
wikileaks-safekeep-to-08-0210.zip
  9d2aa03048c60eec2c94d45293d4e95977a94f3477a4701f6ee2ef7ec888a7c9  
WikiLeaks-State-Dept-Cables-xyz.zip
 *- these files have a detached signature by presumed key
0xB650572B8B3BF75C "Cryptome "
 
 -

 Recommended Usage:
  # Requires Tor running and http proxy to Tor at 127.0.0.1:
  export onions="sek42kxkbjuivxws.onion ajzxwgtrtws7zwyg.onion 
wpv2bxujoctsmzcn.onion aiyu6uyckomxt2ld.onion kvrvzxgdutjcjxqw.onion 
hz5sj76rh3avsmfc.onion jt7klzczup6hrtes.onion 3qcs4cqbsrfdz7xa.onion"
  export files="Update-13-1231.rar Update-14-0206-0602.tar.rar USB-1.rar 
USB-2.rar wikileaks-bank-julius-baer.zip wikileaks-safekeep-to-08-0210.zip 
WikiLeaks-State-Dept-Cables-xyz.zip Cryptome-Update-13-0701-to-13-1202.tgz"
  for cfile in `echo $files`; do
export olist=""
for chost in `echo $onions`; do
  export olist="${olist} http://${chost}/cryptome-july2014/${cfile}";
done
echo "Retrieving $cfile ..."
aria2c \
 --all-proxy=127.0.0.1:8123 \
 --continue=true --always-resume=true \
 --retry-wait=30 --timeout=120 \
 --summary-interval=3 \
 --max-connection-per-server=2 --max-concurrent-downloads=8 \
 -o "$cfile" `echo $olist`
  done

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iL4EABEKAGYFAlO/L2BfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDQxQzEyQjhDMzA3RDdFMjE5OEFBNTc4MTY1
QTg0N0U3QzJCOTM4MEMACgkQZahH58K5OAyvjgEAjX5aggjFGl2sIHqzBZanMYiV
pQ6Wm9EaH1UvPHkt4CgBAKTqhhj77W4aNfkafuqxXM9pgUaBBhT3pnKe64I0vaGs
=jqsm
-END PGP SIGNATURE-
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] data mine the snowden files [was: open the snowden files]

[coderman]

On Wed, Jul 9, 2014 at 9:17 AM, John Young  wrote:
> Tag the Cryptome Archive: "This is a trap, witting and unwitting. Do not use
> it or use at own risk. Source and this host is out to pwon and phuck you in
> complicity with global Internet authorities. Signed Batshit Cryptome and
> Host, 9 July 2014, 12:16ET."


see attached. onion before torrent; rest TBD.
 also: http://cryptome.org/donations.htm


best regards,

 Cryptome Donation Required
  - http://cryptome.org/donations.htm

 "This is a trap, witting and unwitting.
  Do not use it or use at own risk.
  Source and this host is out to pwon and phuck you in complicity
   with global Internet authorities.

  Signed Batshit Cryptome and Host,
  9 July 2014, 12:16ET."

 Index: 
  0eb8551d977dde4f4193b3a16dedcd18f01e854e371e96623d33dd5b9519e413 *USB-1.rar
  9653d105293b9f77d5b0067d51a35ed286a7f50a0b37b3ea2bd78c092caab584 *USB-2.rar
  7e798bb2b09cac49181aa7c12170e03fc3d3cf69a73d9e1b04171c80910e7525  
Update-13-1231.rar
  80652978f46ef6e6f26bd2bec406349ef766ad1722fc81d9f7575148edc6324f  
wikileaks-bank-julius-baer.zip
  c56f0fd30924f7398ca9e20c098acced50766d3325754f29014dd33029ebf351  
wikileaks-safekeep-to-08-0210.zip
  9d2aa03048c60eec2c94d45293d4e95977a94f3477a4701f6ee2ef7ec888a7c9  
WikiLeaks-State-Dept-Cables-xyz.zip
 *- these files have a detached signature from key
0xB650572B8B3BF75C "Cryptome "
  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iL4EABEKAGYFAlO97OxfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDQxQzEyQjhDMzA3RDdFMjE5OEFBNTc4MTY1
QTg0N0U3QzJCOTM4MEMACgkQZahH58K5OAxW4AEAgBKvsQz16zQyBsXbAl+qluiL
5/p3BtEPTLWSW6V5gTsA/1i8gatIPCAA3TXwTHRabvScVJ16CuIMkWm7Pb6QPIhJ
=XcIm
-END PGP SIGNATURE-
-- 
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 
compa...@stanford.edu.

[liberationtech] distributing Cryptome June 2014 [was: data mine the snowden files]

[coderman]

On Wed, Jul 9, 2014 at 7:04 AM, coderman  wrote:
> ...
> anyone who would like to host mirrors is welcome to tell me how they
> anticipate mirroring ~30G of data as quickly as possible. :)

based on feedback, here is what i intend:

1. A torrent of:
USB-1.rar
USB-2.rar
Update-13-1231.rar
each of these have an accompanying signature from John.  i will
include a magnet URI.

2. The same files on a hidden service with nginx and HTTP/1.1 range
request capable (resume-able)

3. An extracted collection of all relevant files, which can be
rsync'ed from hidden service or browsed directly.

note that this is a point in time archive from June 2014.


please donate to John as i hate to think i would be taking revenue
from his pocket with this setup!



best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] data mine the snowden files [was: open the snowden files]

[coderman]

On Tue, Jul 8, 2014 at 3:27 PM, grarpamp  wrote:
> ...
> To do any of this you will need to collect all the releases of docs
> and images to date, in their original format (not AP newsspeak),
> in one place. Then dedicate much time to normalizing, convert to
> one format and import into tagged document store, etc. Yes, this
> could be hosted on the darknet.

indeed. i will also be hosting the complete cryptome archive on hidden
site, as it too is part of this corpus to feed into a normalization
and extraction engine of great justice.  i am using the various python
image processing libraries to accomplish this but any language or tool
could be useful.

i had hoped to distribute the cryptome archives further during the
Paris hackfest, alas, unexpected events conspired otherwise.

anyone who would like to host mirrors is welcome to tell me how they
anticipate mirroring ~30G of data as quickly as possible. :)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] data mine the snowden files [was: open the snowden files]

[coderman]

On Tue, Jul 8, 2014 at 1:05 PM, Griffin Boyce  wrote:
> One approach is to take the existing public data, make some assumptions
> (educated guesses) and do additional research on top of that. It's what I'm
> doing right now. It's also what led to the original cointelpro revelations.
> Before the follow-up research, it was a meaningless acronym.
>
> Find, extrapolate, expand.

hi Griffin!

this is the type of effort i was hoping to see undertaken.

when you say "additional research", is this organic or structured?
tool assisted or old skewl?

i too have been building up some terms and technologies, but yet to
put it into any structured format with context, as part of my post is
to see how others are handling the vast complexity and extensive
compartmentalization embodied in the leaks to date.

i also would like to pursue this research anonymously, on hidden
services rather than public sites or email.


best regards,
-- 
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 
compa...@stanford.edu.

[liberationtech] data mine the snowden files [was: open the snowden files]

[coderman]

On Sat, Jul 5, 2014 at 11:29 AM, Geert Lovink  wrote:
> ...
> the snowden files are of public interest. but only a small circle of
> people is able to access, read, analyze, interpret and publish them. and
> only a very small percentage of those files has been made available to
> the public...
>
> what can be done about this situation? are we able to find a way to
> "open" this data? and in the course of this create a modell for future
> leaks?
> ..
> prior to my intervention harding had already hinted at some very obvious
> limitations of the ongoing investigation, alluding to various reasons
> why those "few lucky ones" are incapable to deal with the investigation
> challenge in an approriate manner: "we are not technical experts" or
> "after two hours your eyes pop out". inspite of this, harding seemed
> unprepared to refelect the possibility to open the small circle of
> analysts dealing with the snowden files.

an impasse of extremes, a full or limited dump off the table.

let's find a middle ground. how best to proceed?



> * last but not least: one should work out a concept/model for
> transferring those files into the public domain -- taking also into
> account the obvious problems of "security" and "government pressure".
>
> it would be great of we could start a debate about in order to build a
> case for the future of handling big data leaks in a more democratic and
> sustainable manner.

very great indeed.  what kind of tools would make the journalists
involved more effective and productive?

1. using the leaks currently published, devise a framework for "data
mining" the leak documents, aka, generating metadata from the data and
operating various matches and relevance across the metadata to narrow
the search and aggregate related efforts or technologies across their
compartmentalized worlds.

2. #1 requires that there is an index of special terms, techniques,
suppliers, code names, algorithms, etc. that used to generate the
metadata for deeper search and tie to general themes of surveillance.

3. extrapolating from current leaks, also look toward recent
advancements and specific technical tell tales of interest.  doping
silicon as tailored access technique? this could refer to compromised
runs of security processors for desired targets. etc.

4. justifying technical detail specifically.  we have seen so little
technical detail of the source code / hardware design level.  how best
to justify source code - explaining that the language choice, the
nature of the algorithms, the structure of the distributed computing
upon which it runs all conveys critical technical details important to
understand what part of our technologies are compromised, and guiding
the fixes required to protect against such compromises?



in short, it would behoove us to build tools to make the journalists
more effective, rather than bitch about not being included in the
inner circle.  (sadly, many good knowledge discovery tools are
proprietary and applied to open source intelligence)


what types of features would you want such a leak-assistant software
to have?  what types of existing tools, if any, would provide these
capabilities?


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] XKeyScore code authenticity - genuine [was: messing with XKeyScore]

[coderman]

On Sun, Jul 6, 2014 at 7:51 PM, Nathan Andrew Fain  wrote:
> ... the half hazard rules protecting five eyes users. Apparently
> as someone (terrorist or not) accessing Tor from the five eyes nations
> you are filtered out. If you also happen to have looked at the linux
> journal there is no filtering for five eyes so you would have been
> tagged. This inconsistency shows how foot loose things were/are at the
> NSA.
>
> This would fit with what Diane Roark said in her interview with
> Frontline [1]. She protested the removal of strict filtering for US
> Citizens and was buffed by every side. In that light it is clear the
> US made the entire cache free game for one or many engineers without
> anyone looking over their shoulder. A ship early fix later policy many
> engineers love so much.

well said.  any protections of the nature ThinThread would have made
systemic and pervasive are instead left as ad-hoc, opt-in type filters
upon what is so clearly full take (at the deep inspection point at
least.  i agree with Graham that it is far to expensive to mirror all
traffic everywhere back to NSA)

i also completely disagree with the legal interpretation of "a search"
occurring only when a human analyst sees the intelligence gathered,
and not when the intelligence gear gathers it.



> In the end, with their budget, a 50% reduction in efficiency from a
> regex would just justify a few hundred more distributed computing
> nodes. The only person in the chain that may question this would be a
> pro-surveillance tax payer that knows regular expressions. So it may
> not indicate the age of the filters at all.

i never considered the "hire more mediocre analysts for budget
justification" angle, which is impressive, as i'm usually a pretty
jaded individual ;)



> http://www.pbs.org/wgbh/pages/frontline/government-elections-politics/united-states-of-secrets/the-frontline-interview-diane-roark/

you might the mix a friend made for the Tor hackfest a fun listen:

two versions (which has better voice over?)

https://peertech.org/files/Prodigy_-_Their_Law_-_Toggs_Diane_Roark_Remix.mp3
https://peertech.org/files/Prodigy_-_Their_Law_-_Toggs_Diane_Roark_Remix2.mp3

 [ cache friendly plaintext
http://207.198.103.187:8081/Prodigy_-_Their_Law_-_Toggs_Diane_Roark_Remix.mp3
http://207.198.103.187:8081/Prodigy_-_Their_Law_-_Toggs_Diane_Roark_Remix2.mp3
]


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] XKeyScore code authenticity - genuine [was: messing with XKeyScore]

[coderman]

On Sun, Jul 6, 2014 at 7:30 PM, coderman  wrote:
> ...
> the code do not point toward this being a non-fictitious example,

i meant "non-functional, fictitious example" of course.  and with
that, i will leave my further comments to a later, more sober date...
 airport security, here i come!

:P



best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] XKeyScore code authenticity - genuine [was: messing with XKeyScore]

[coderman]

On Sun, Jul 6, 2014 at 7:11 PM, coderman  wrote:
> ...
> a regexp rule like:
> '''
> extractors: {{
> bridges[] =
> /bridge\s([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}):?([0-9]{2,4}?[^0-9])/;
>   }}
> '''
> is both written by a novice regexp'er, and also took them a bit of
> time. more than they'd spend on an example.


i should have clarified this statement.  this is code someone wrote to
get a job done.  they are pulling bridge addresses out of text (email
bodies?) and getting a job done.

this is fine code and similar to what you'd see in any production environment.

this is not what a regexp guru would use to show their ability to
tightly match with sparse efficiency.

it is also not so simple that a non-PCRE fluent person would use it as
a fictitious example.


to be clear: all signs point to this being real code a person wrote to
get a job done - parse out bridge addresses from text.  the signs
point toward this code being legitimate depricated code, even if not
currently useful.

the code do not point toward this being a non-fictitious example, and
it seems Robert even alludes to as much with.
 "One interesting thing to note about the port number is that it
captures the first non-digit character after the number as well. This
is obvious[sic] a bug, but since it's usually whitespace, one that
doesn't impact the system."
 - implying he believes this is a legitimate rule, and also not
written by an expert.


best regards,
-- 
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 
compa...@stanford.edu.

[liberationtech] XKeyScore code authenticity - genuine [was: messing with XKeyScore]

[coderman]

the theme of messing with XKeyScore is amusing[0], but more to the
point i was asked to respond to some concerns of authenticity made in
a different post:

"Validating XKeyScore code"
http://blog.erratasec.com/2014/07/validating-xkeyscore-code.html

i'm trying to keep this feedback technical, as i don't like much of
Graham's reasoning. (i do however approve of his use of "Great Man" in
the Voldemort sense, in reference to Cowboy Alexander[1])

his claim that "we believe the code partly fake and that it came from
the Snowden treasure trove." should be ammended:

"we believe the code deprecated, and that it came from the Snowden archives"

onward!

---

first segment of summary, by point:


# Point 1)
"The signatures are old (2011 to 2012), so it fits within the Snowden
timeframe, and is unlikely to be a recent leak."
 - agreed.


# Point 2)
"The code is weird, as if they are snippets combined from training
manuals rather than operational code. That would mean it is “fake”."
 - false; the code is valid and deprecated (can be used as example)
rather than false. the technical detail. as a programmer, i know that
a regexp rule like:
'''
extractors: {{
bridges[] =
/bridge\s([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}):?([0-9]{2,4}?[^0-9])/;
  }}
'''
is both written by a novice regexp'er, and also took them a bit of
time. more than they'd spend on an example.

for another example,
'''
for (size_t i=0; i < bridges.size(); ++i) {
std::string address = bridges[i][0] + ":" + bridges[i][1];
DB[SCHEMA_OLD]["tor_bridge"] = address;
DB.apply();
DB[SCHEMA_NEW]["tor_ip"] = bridges[i][0];
DB[SCHEMA_NEW]["tor_port_or"] = bridges[i][1];
DB[SCHEMA_NEW]["tor_flags"] = FLAGS;
DB.apply();
  }
'''

why two commits here to backend changes? as a programmer i understand
why this is done, but as a purely fictitious example the double commit
is pointless noise.


# Point 3)
"The story makes claims about the source that are verifiably false,
leading us to believe that they may have falsified the origin of this
source code."
 - false

how does limited misunderstanding arcane technicalities invalidate the entirety?
 if this were true, Robert Graham would be a complete imbecile, rather
than  technically competent and occasionally wrong.



# Point 4)
"The code is so domain specific that it probably is, in some fashion,
related to real XKeyScore code – if fake, it's not completely so."
 - false. as stated above, these rules are deprecated rather than
fictitiously constructed. (and perhaps referenced in training
materials for utilizing the particular language engines demonstrated)

as explained above, and i will go into more detail later (i wager i
have more big data experience and DPI experience than Mr. Graham the
DPI expert does in this domain alone[2] ;)



last but not least, this speaks to the need for greater technical
expertise to be applied to the leaked archives.  if anything, the
nature of domain specific details discussed here show that not just
generalists, but an army of specialists, will ultimately be needed to
properly parse and protect based upon the archives as yet revealed.


best regards,



---

0.  "" for those with "Jam Eschelon Day" nostalgia ;)
  ^- see whole thread from "messing with XKeyScore"

1. "The character assassination of Keith Alexander"
 '... People have criticized calling him a "great man". I'm quoting
the Harry Potter movie here people, where the guy who sells
Harry's[sic] wand points out that Voldermort was a great wizard,[sic]
a great and terrible wizard'
   http://blog.erratasec.com/2014/06/the-character-assassination-of-keith.html

2. "XKeyScore: it's not attacking Tor"
 '... I am an expert in deep packet inspection (DPI). I've written a
system vaguely similar to this XKeyScore system here: (ferret). I find
the conclusions in this story completely unwarranted, though the
technical information cited by this story is pretty good. I suggest
future stories about the NSA's deep packet inspection actually consult
with engineers who've written DPI code before making wild claims.'
  http://blog.erratasec.com/2014/07/xkeyscore-its-not-attacking-tor.html
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Mapping out physical surveillance across a city

[coderman]

On Tue, Jun 24, 2014 at 11:19 AM, Patrick  wrote:
> How would one map an entire city's surveillance anyway? Are the location of
> police cameras available? And even if they are, how does one map out all the
> private cameras watching?

you compromise all of a city's network communications. hardlines (coax
and fibre), wireless (open spectrum 802.x or closed spectrum cell).

the video feeds stick out nicely from other traffic behavior...

;)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] [GNU/consensus] Why support "Reset the Net" ? I don't get it

[coderman]

On Thu, Jun 5, 2014 at 11:23 AM, carlo von lynX
 wrote:
> ...
> the change of attitude needs to happen in the browsers and in the W3C,
> not in the gazillions of websites that should all invest serious
> amounts of money. browsers should ship with a public-key routing
> technology like tor's .onion, i2p's .i2p or gnunet's .gnu.

even better, map public key routed identifiers into IPv6 via ORCHID
addressing in overlay networks!

(i have a favorite rant on low latency traffic analysis resistant
designs, too, but i'll try to keep this on topic ;)



> i have about a hundred websites. i can't get certificates for each of
> them. but what i will do soon is relaunch them as website.X.onion
> since all it takes is apt-get install tor and a torrc.

onions in the namecoin tree also useful (i use this to map a friendly
name to multiple onions. there is a good thread on improving hidden
service availability and scalability on the tor-dev lists as well, but
for now redundancy is my favored approach.)



> it launched a month and a half later, but that's because it isn't a
> simple campaign like resetthenet. YBTI is about developing the
> necessary technology to enable usable end-to-end encryption and
> social graph (aka metadata) protection (and a few things more).
> so it is a site that aims for a *real* solution.

i think resetthenet is more complicated on the social/organization
level than you give credit.  this makes sense, as the wonderful YBTI
is very technical and awesome.  technical people tend to think of
organization and communication and collaboration aspects as "easy" or
"afterthoughts" but i've come to see them as anything but.  (often,
the easier an effective campaign appears, the more inspired and
labored it's creation.)



>> i also think all of the technologies you listed above are insufficient
>> for a truly decentralized, robust, privacy enhancing infrastructure.
>
> you mean you agree with me? of course HTTPS etc are all broken and
> inadequate. or what are you referring to?

i absolutely agree with you that HTTPS and etc are all broken under
some reasonable threat models.  and i believe all of the technologies
you've listed in YBTI are also broken under reasonable threat models.

we have a lot of work to do!



> no, it is wasted energy. 99% of engineers insisting on working on
> horse carriages after 1% told the world they invented a car and
> need help improving it.

all horse carriages immediately deprecated?  transitions take time!



> in a couple of years 99% of engineers will find out they have
> invested sooo muuuch tiime in a technology which slowly but
> steadily turns obsolete

do nothing in the interim?  instead, i am doing many things. holding
my nose paying tithe to the CA cartel. working on better solutions.
thinking about how remaining flaws in better options can be further
mitigated...

please keep up the good work on YBTI!

best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] [GNU/consensus] Why support "Reset the Net" ? I don't get it

[coderman]

On Thu, Jun 5, 2014 at 3:28 AM, carlo von lynX
 wrote:
> Heya.. I saw ... https://www.resetthenet.org
>
> Yet the things the page recommends are band-aids.

in terms of first steps, the https push is the most approachable.
passive, blanket surveillance resistance maybe a band-aid, yet still
useful.

as a symbol of the value of privacy online resetthenet is more effective.

(only other practical impact i have observed is users updating their
browsers. having tried some https sites with good cipher suite hygiene
and getting errors, they take the hint and grab the latest copies of
Firefox or Chrome...)



> If it was that simple we could have done such a
> campaign the same day the revelations came out.

how long did youbroketheinternet.org take? ;)



> So I don't see the point in a superficial campaign that
> doesn't actually fix anything about the status quo, instead
> it is likely to foster further damage by not offering long-term
> solutions.

i disagree that it is entirely superficial.

i also think all of the technologies you listed above are insufficient
for a truly decentralized, robust, privacy enhancing infrastructure.

and finally, i think we should all be working on these types of
efforts, and others, per our interests even if they have flaws.
(improvements that are not long-term solutions are not causing
"damage")

learning from our fails faster is a question for another thread... *grin*



best regards,
-- 
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 
compa...@stanford.edu.

[liberationtech] PBS Frontline and "The Program"'s "innovative" legal interpretations [was: stinky shit in fedland - lawful^H^H^Hless mobile fuckery cover-ups in progress...]

[coderman]

regarding the parallel construction and warantless / indiscriminate techniques,

the PBS Frontline program "United States of Secrets" provides an
exceptional analysis of how these invasive and un-constitutional
programs and arguments came into being and expanded across
administrations.

http://www.pbs.org/wgbh/pages/frontline/united-states-of-secrets/ or
http://www.pbs.org/wgbh/pages/frontline/government-elections-politics/united-states-of-secrets/transcript-61/

# convenient links, for those who can't torrent / stream
https://peertech.org/files/PBS.Frontline.2014.United.States.of.Secrets.1.mp4
https://peertech.org/files/PBS.Frontline.2014.United.States.of.Secrets.2.mp4

# plaintext for those with poor clients who can't speak strong SSL/TLS
http://207.198.103.187:8081/PBS.Frontline.2014.United.States.of.Secrets.1.mp4
http://207.198.103.187:8081/PBS.Frontline.2014.United.States.of.Secrets.2.mp4


best regards,


On Tue, Jun 3, 2014 at 8:12 PM, coderman  wrote:
> ...
> - Truly In-discriminant and Whole-sale Invasions of Constitutionally
> Protected Communications Are Routine Fed Behaviors
> and not just routine but the expected side effects of military
> blunt-force intelligence gathering systems aimed at domestic targets
> illegally. these military systems covertly re-purposed for domestic
> surveillance at the federal level enjoy FBI DITU running front-man and
> cover for all the exceptional secrecy this programs entails. (and why
> such truly aggressive offensive techniques applied indiscriminately
> have yet to reach state and municipal LE need to know.)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] stinky shit in fedland - lawful^H^H^Hless mobile fuckery cover-ups in progress...

[coderman]

for those new to this game, the storyline is summarized below,


On Tue, Jun 3, 2014 at 7:53 PM, coderman  wrote:
> ...
> U.S. Marshals Seize Local Cops’ Cell Phone Tracking Files in
> Extraordinary Attempt to Keep Information From Public
>
> RED FLAG #1: The Sarasota Police initially told us that they had
> responsive records, including applications filed by and orders issued
> to a local detective under the state “trap and trace” statute that he
> had relied on for authorization to conduct stingray surveillance. That
> raised the first red flag, since trap and trace orders are typically
> used to gather limited information about the phone numbers of incoming
> calls, not to track cell phones inside private spaces or conduct
> dragnet surveillance...
>
> RED FLAG #2: The Sarasota Police set up an appointment for us to
> inspect the applications and orders, as required by Florida law. But a
> few hours before that appointment, an assistant city attorney sent an
> email cancelling the meeting on the basis that the U.S. Marshals
> Service was claiming the records as their own and instructing the
> local cops not to release them...
>
> RED FLAG #3: Realizing we weren’t going to get hold of the Sarasota
> Police Department’s copies of the applications and orders anytime
> soon, we asked the county court if we could obtain copies from its
> files. Incredibly, the court said it had no copies. The court doesn’t
> even have docket entries indicating that applications were filed or
> orders issued. Apparently, the local detective came to court with a
> single paper copy of the application and proposed order, and then
> walked out with the same papers once signed by a judge.



discoveries we'll get to enjoy, with the appropriate shocked, shocked!
theatrics:

- The Known Tools Have Few Controls and Intentional Secrecy
not only are the Stingray/IMSI catcher devices not properly
controlled, but they are actively shielded from oversight through
non-disclosure / trade-secret / and national security trump card
arguments that don't hold water.

- The Known Tools Hint at Deeper Invasive Techniques, Also Lacking Oversight
not only is location / metadata (penregister) information obtained,
but similar programs with private industry selling advanced tools to
law enforcement will uncover even more egregious violations of law
extending to full content (wiretap) collection without sufficient
authority or oversight.

- The Lawless Intercepts and Unlawful Invasions Of Privacy Shielded by
Prosecutors and Judiciary using Reverse Forensics
 the synergy of "parallel construction meets illegal intercepts" will
uncover the ways in which initial aggressive legal interpretations are
further distorted, and secrecy further applied paramount, to serve the
interests of prosecutor careers and public face over actual justice
and respect for law.

- Truly In-discriminant and Whole-sale Invasions of Constitutionally
Protected Communications Are Routine Fed Behaviors
and not just routine but the expected side effects of military
blunt-force intelligence gathering systems aimed at domestic targets
illegally. these military systems covertly re-purposed for domestic
surveillance at the federal level enjoy FBI DITU running front-man and
cover for all the exceptional secrecy this programs entails. (and why
such truly aggressive offensive techniques applied indiscriminately
have yet to reach state and municipal LE need to know.)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] PBS Frontline: United States of Secrets ( 2 part series )

[coderman]

On Fri, May 23, 2014 at 9:04 PM, Gregory Foster
 wrote:
>> http://www.pbs.org/wgbh/pages/frontline/united-states-of-secrets/
>> http://video.pbs.org/video/2365245528/
> ... Also available at ThoughtMaybe:
> http://thoughtmaybe.com/the-united-states-of-secrets/


anyone know where to obtain a stand-alone video file for DL?
(any encodings OK...)

best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Auditing of Auto-Update of software commonly used by Human Rights Defenders

[coderman]

On Thu, May 15, 2014 at 2:47 PM, Tom Ritter  wrote:
> On 14 May 2014 23:36, Fabio Pietrosanti (naif)  wrote:
>> i think that would be very important to organize a project to Audit the
>> functionalities of Auto-Update of software commonly used by human rights
>> defenders.
>
> Sounds interesting. What software did you have in mind?

start with evilgrade; there's a reason it had hundreds and hundreds of
vectors.  MitM position is absolute failure more often than not...

best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Programming language for anonymity network

[coderman]

On Fri, Apr 18, 2014 at 8:25 PM, coderman  wrote:
> ... the criteria:...
>> 1) Familiarity: ...
>> 2) Maturity: ...
>> 3) Language security: ...
>> 4) Security of runtime / tool chain:..
>
>
> use modern C++ with testing discipline.


also relevant:
  https://chriskohlhepp.wordpress.com/convergence-of-modern-cplusplus-and-lisp/
 which gets kudos for also mentioning the benefits of modern C++ in
respect to unit tests.


to summarize the goals for your C++ implementation:
 - reads with clarity like a high level language
 - performs with efficiency like a low level language
 - tests with coverage across whole codebase regardless of language.


full disclosure: i am a completely not biased party in this
declaration of absolute truth.
 *cough*



best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Programming language for anonymity network

[coderman]

On Fri, Apr 18, 2014 at 1:26 AM, Stevens Le Blond  wrote:
>...
> We are a team of researchers working on the design and implementation of
> a traffic-analysis resistant anonymity network...

is this an implementation of existing research, or experimentation
with novel architectures?  tell us more :)



> ... and we would like to
> request your opinion regarding the choice of a programming language /
> environment. Here are the criteria:...
> 1) Familiarity: ...
> 2) Maturity: ...
> 3) Language security: ...
> 4) Security of runtime / tool chain:..


use modern C++ with testing discipline.

 , but what about this traffic analysis resistant anonymity network,
low latency too?
  *grin*


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH]

[coderman]

the early research on passive backbone network measurement:
  
http://www.ece.ucdavis.edu/~chuah/classes/eec274/eec274-w09/refs/FML03-ipmon.pdf

[ED: at the time, the working storage of 330GB could potentially keep
~1,300 continuous days of compressed voice capture.
 (or mere hours of a lightly utilized OC12 if capturing it all like MYSTIC) ]

"""
The IPMON monitoring infrastructure ... consists of three elements: a
set of passive monitoring entities which collect the packet traces; a
data repository that stores the traces once they have been collected;
and an analysis platform which performs off-line analysis. Analysis is
performed off-line for two reasons. The primary reason is that the
data is used in many different research projects, each of which has
its own set of custom analysis tools. It is more efficient to perform
the multiple types of analysis on a computing cluster in the lab where
many systems can access the data simultaneously. The second reason is
we archive the traces for use in future projects.

1) Monitoring entities ... are responsible for collecting the packet
traces. Each trace is a sequence of packet records that contain the
first 40 bytes of each packet, which are just the IP and UDP/TCP
headers, as well as a sub-microsecond timestamp which indicates the
time at which the packet was observed. The source and destination IP
addresses are not anonymized, since they are needed in routing-related
analysis. Each monitoring entity is a dual-processor Linux server
(Dell PowerEdge 6000 series) with 1 GB main memory, a large disk array
(100 to 330 GB), and a POS network interface card, known as the DAG
card. Existing DAG cards are capable of monitoring links ranging in
speed from OC-3 to OC-48... The DAG card captures, timestamps, and
transfers the POS HDLC framing information and the IP packet headers
to the main memory of the Linux server where a driver software then
transfers the data to the disk array. An optical splitter is installed
on the monitored link, and one output of the splitter is connected to
the DAG card in the server... Each monitoring entity has a removable
disk array of up to 330 GB. This amount of disk space allows us to
capture a minimum of several hours of trace data at full link
utilization. We can either schedule trace collection for a pre-defined
interval or allow it to run until space on the hard disks is
exhausted. By Sprint engineering design, the network links are not
fully loaded (except in extreme failure scenarios) and we are
typically able to collect several days of measurement data... A total
of 60 monitoring entities are installed at 4 different POPs, chosen on
the basis of geographic diversity and connectivity. They monitor the
traffic on OC-3, OC-12, and OC-48 links which connect access routers,
backbone routers
and several of the private peering links.

2) Data Repository... involves two levels of storage, consisting of a
12 TB removable tape library and a 10 TB disk storage array. It is
located at the Sprint Advanced Technology Laboratory (ATL). For short
traces, a dedicated OC-3 link is available for transferring the data
from the monitoring entities back to the ATL. Given that a full
multi-POP trace set consists of approximately 10TB when trace
collection is allowed to run until the disks fill up, the best method
for transferring full traces back to the data repository is by
physically shipping the removable hard disks. As a result of these
constraints on transferring trace data, we do not schedule new traces
until the previous trace data is either transferred or deleted.

3) Data Analysis Platform: Data analysis is performed on a cluster of
17 high-end servers connected to a Storage Area
Network (SAN) with a capacity of 10 TB.
"""



On Tue, Mar 18, 2014 at 7:54 PM, coderman  wrote:
> ... [ lots of tapping, everywhere! ]
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH]

[coderman]

On Tue, Mar 18, 2014 at 4:28 PM, coderman  wrote:
> regarding the latest discussion of full take voice and cache for weeks...

i linked to WCI as one of many;  the Northstar upgrade complete with
"wetland beautification" as example of infrastructure at a landing
site consistent with terminating lambdas, yet the established and
operating landing facility is located off shore (like usual) in
Hillsboro.

JYA @ cryptome teaches a great course on reversing infrastructure to
identify intent.  together many clues present a picture. ;)


consider 641A rooms lurking on your landing sites:
"""
Room 641A is located in the SBC Communications building at 611 Folsom
Street, San Francisco, three floors of which were occupied by AT&T
before SBC purchased AT&T. The room was referred to in internal AT&T
documents as the SG3 [Study Group 3] Secure Room. It is fed by fiber
optic lines from beam splitters installed in fiber optic trunks
carrying Internet backbone traffic and, as analyzed by J. Scott
Marcus, a former CTO for GTE and a former adviser to the FCC, has
access to all Internet traffic that passes through the building, and
therefore "the capability to enable surveillance and analysis of
internet content on a massive scale, including both overseas and
purely domestic traffic." Former director of the NSA's World
Geopolitical and Military Analysis Reporting Group, William Binney,
has estimated that 10 to 20 such facilities have been installed
throughout the United States.
"""

prioritize by foreign landing site rather than domestic exchanges
you've got your half dozen favorites from the current focus.


and again, these are just the "confidential special partner agreement"
facilities.

 not the "legally compelled and gagged" orders,
   nor the black bag "non-compliant" taps...
(like the USS Jimmy Carter ocean taps, my favorites :)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Are undersea cables tapped before they get to ISP's? [was Re: Security over SONET/SDH]

[coderman]

regarding the latest discussion of full take voice and cache for weeks[0]:

updated image of the landing station now at:
  https://peertech.org/files/wci.jpg

the lower left images are the landing station,
  the upper remainder the cable operator facilities.


these landing station infrastructure upgrades were performed as part
of "some intelligence programs".


voice compresses exceptionally well, particularly some non-free codecs
or tightly tuned opus :)


[ see also: the Google Voice Search hack against Android devices
performed by DITU at DEF CON 19 with DRT boxes amped to max - this
also made great use of highly compressed Speex aspect; so many phones
in "Open MIC Night" without undue congestion or noticeable impact on
data channel even if in use. ]


last but not least, regarding cover stories for such infrastructure:
at Sprint in the late 90's there was a pioneering effort at full-take
DPI on backbone OC-12 and OC-48 links.  the cover story was
"collecting only header information, and only to optimize internet
routing across the internet."

the reality was: a slight adjustment, heavily compartmentalized, to
full take and DPI for intelligence work.  (see also the origins of the
DPI vendors :)  in all likelihood, many technicians have seen
something funny, but the plausible story was plausible, and so...

[ note however that this system could not store full take for any
period, like the pioneering GCHQ efforts for full spectrum capture and
cache across data in addition to voice.  thus the focus was on custom
ASIC and hardware chasis mounted to storage where matching "streams"
could be "selected" and then processed UPSTREAM. ]


perhaps more later!


---

link salad:

long phat cables:
  http://cryptome.org/eyeball/cablew/cablew-eyeball.htm
  http://cryptome.org/eyeball/cable/cable-eyeball.htm
  http://cryptome.org/nsa-seatap.htm


and telegeography's submarine cable map:
  http://www.submarinecablemap.com/


also relevant:
  http://cryptome.org/telecomm-weak.htm
  http://cryptome.org/nsa-fibertap.htm
  http://cryptome.org/nsa-lynn.htm



0. "NSA surveillance program reaches 'into the past' to retrieve,
replay phone calls"
   
http://www.washingtonpost.com/world/national-security/nsa-surveillance-program-reaches-into-the-past-to-retrieve-replay-phone-calls/2014/03/18/226d2646-ade9-11e3-a49e-76adc9210f19_story.html
"The voice interception program, called MYSTIC, began in 2009. Its
RETRO tool, short for "retrospective retrieval," and related projects
reached full capacity against the first target nation in 2011."


--- end top post of great negligence ---


On Tue, Jun 25, 2013 at 10:09 AM, coderman  wrote:
> On Tue, Jun 25, 2013 at 6:26 AM, Eugen Leitl  wrote:
>> ...
>> Very few ISP's ever go to the landing stations, typically the cable 
>> operators provide cross connects to a small number of backhaul providers.  
>> That makes a much smaller number of people who might ever notice the 
>> splitters and taps, and makes it totally transparent to the ISP.  But the 
>> big question is, does this happen?  I'm sure some people on this list have 
>> been to cable landing stations and looked around.  I'm not sure if any of 
>> them will comment.
>
> yes it happens.  c.f.:
>   http://207.198.103.187:8081/wci.jpg
>
> the lower images are the facilities at the landing site, the upper
> images the termination / peering point a few score miles down fiber.
> pre-911 the landing site was more shack and less fortress (i may have
> a before picture somewhere.)
>
> cryptome has some great info on cable routes and facilities:
>   http://cryptome.org/eyeball/cable/cable-eyeball.htm
>   http://cryptome.org/nsa-seatap.htm
>   http://cryptome.org/telecomm-weak.htm
>   http://cryptome.org/nsa-fibertap.htm
>   http://cryptome.org/nsa-lynn.htm
>
> note that this line of inquiry is frowned upon.  after Sean Gorman's
> dissertation on critical infrastructure vulnerabilities the prevailing
> approach has been security through obscurity.  we all know how well
> that works...  ;)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] A modest proposal for protecting the work (and freedom) of activists.

[coderman]

On Sat, Jan 25, 2014 at 3:23 PM, Ben Laurie  wrote:
> [low latency vs. anonymity]
>
> Actually, it seems it is a natural law.
>
> Hope is not a strategy.


natural in that they interfere with each other? (like multi-path fade,
apply science for great justice! (e.g. more radios, better encoding
turns multi-path from detriment to signal positive))

if high bandwidth[0] is half way there, and so many techniques[1] yet
unexplored, why the pessimism?

it is certainly taking too long to get here, of course.  *grin*


best regards,



0. "Towards Efficient Traffic-analysis Resistant Anonymity Networks"
 http://research.microsoft.com/apps/pubs/?id=199302
"""
In this paper, we present the design, implementation, and evaluation
of Aqua, a high bandwidth anonymity system that resists traffic
analysis. We focus on providing strong anonymity for BitTorrent, and
evaluate the performance of Aqua using traces from hundreds of
thousands of actual Bit-Torrent users. We show that Aqua achieves
latency low enough for efficient bulk TCP flows, bandwidth sufficient
to carry BitTorrent traffic with reasonable efficiency, and resistance
to traffic analysis within anonymity sets of hundreds of clients. We
conclude that Aqua represents an interesting new point in the space of
anonymity network designs.
"""


1. various datagram based Tor-like protocols with traffic analysis
protections afforded new multi-path, out-of-order, stochastic shaped
bandwidth in non-TCP, non-stream based variants.  plenty of fertile
research ground across:
- IPsec telescopes
- DTLS transports for Tor
- userspace SCTP multi-path end-to-exit and end-to-hiddensvc over
datagram Tor, I2P, etc.
- userspace IPv6 with ORCHID based node identifier overlay as endpoint
and route addressing to existing applications.
- new variations and combinations of optimized dynamic link padding
- decentralized low bandwidth directory/path building low overhead techniques
- stochastic fair queuing and reordering with traffic source
classification into priority queues for even lower path latency, RTT.
 and many more, not on top of mind... [obligatory link to anon bib here]
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net

[coderman]

On Sun, Jan 19, 2014 at 4:23 AM, carlo von lynX
 wrote:
> ...
>> The highest level of "this feature" would be if this "Mock JS" could have
>> full WebRTC functionality ;)
>
> Dunno, WebRTC is so prone to MITM.
> I'd rather have something secure.


as mentioned before, do WebRTC over private address space, like IPv6
ORCHID identifiers based on cryptographic identities.  then you can
easily move sensitive crypto outside the browser, (outside current
user, even outside current domU).  in the case of hidden services,
you'd map to onions for TUN endpoints which bring up ORCHID
identifiers based on hidden service private key digest.

if browser is hacked sideways, you expose ephemeral context of current
browser process, history, sessions, cache, etc, but keep long lived
keys and identities protected outside the dirty cesspool that is your
browser swimming naked in sewage.
 (aka: contemporary software using data networks built without your
interests at heart)

for the Tor example:
- Qubes dom0 (ring -X): handles launching the following VMs which
together implement the system discussed:
- Disposable Chromium/FFox VM supporting WebRTC, DNS  petnames->ORCHID IPv6
- FirewallVM which forces all traffic over hidden address space to
ORCHIDvm, or drops it. (and prunes much needless IPv6 *cast chatter)
- ORCHIDvm maps incoming IPv6 connections and  lookups to Tor
hidden services, and forces all upstream traffic over Tor or drops it.
 this is where the ORCHID tun device lives and is bound.
- TorVM runs the Tor client/relay and hidden services; any control
port access via domU console, not remote.
- NetworkVM finally delivers the intended data to and from the
selected network device preferably using VT-d/IOMMU extensions to
isolate this network device from other devices or domUs.


^- this is how i would prefer to use a browser :)


pointing the browser at localhost is a similar intent and separation,
as demonstrated and discussed by Tony Arcieri in cryptosphere.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] 15 years later, why can't Johnny still not encrypt?

[coderman]

On Thu, Jan 16, 2014 at 6:20 AM, Mrs. Y.
 wrote:
> ...
> http://www.edge.org/conversation/smart-heuristics-gerd-gigerenzer


your caloric heuristic optimization,
 is my bug.
  (now if only we could patch wetware! ;)


Tempest: perhaps we should clarify incentives.  Johnny has zero
incentive in the modern social world to use crypto, and high barriers
to any interest that does occur.

journalists and human rights workers are motivated like never before,
and likely more sophisticated.  however they still struggle with
technical tools for strong privacy.

my challenge was to the cypherpunks list for digital monies; favorable
selection if there ever was!  yet still not 100% and some contexts
place severe penalties on even a single, innocent failure.



as for the title and research, it does not imply encryption is useless
and should be abandoned.  it does imply that casual, less technical
users (Johnny) need a system which is intuitive, fails safe, and
unambiguously expressive about failures.

any improvement to usability is useful.  we certainly need much
improvement for pervasively employed end-to-end privacy.



best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] 15 years later, why can't Johnny still not encrypt?

[coderman]

On Thu, Jan 16, 2014 at 4:36 AM, Mick Fuzz  wrote:
> ... try this out, it's as close as I could replicate the
> experience of talking someone through it.
>
> https://p2pu.org/en/groups/encrypt-and-sign-your-email/
>
> other version as 'work book on http://flossmanuals.net/thunderbird-workbook/

this looks useful and interesting; i'll continue to review as time permits!



> The key is that you get a chance to download and send an email to a real
> human (me) and get a reply saying it worked.

this helped in some but not all (specifically not two) experience i've
had performing same over a voice, screencast, or video conference
system.


as an experiment in the other direction, i attempted to make sending
an encrypted mail as difficult and confusing as possible.

i made a key:
- with a creation date that was clearly invalid
- with an identifier not tied to any email address or stored in any keyserver
- with a cipher suite known to cause compatibility issues (3k DSA)
- with a comment that would do nothing except leave you head scratching...
 , and requested an encrypted email to it for chance at bitcoins.

results:
- 63 successful players
- 3 failed attempts
- 1 anon recipient! (extra credit :)

however, zero successes from few who attempted to reply to a reply.
almost every email client tested will reply to a previously encrypted
message in plain-text without any obvious indicators if the recipient
key does not match one previously stored. see above-^


best regards, and thank you for your efforts improving privacy! you
should create a coin tipjar or donation address :)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] 15 years later, why can't Johnny still not encrypt?

[coderman]

On Thu, Jan 16, 2014 at 4:25 AM, coderman  wrote:
> ...
> usability with respect to security and privacy technology a great
> challenge worthy in many facets.


also required reading,

Peter's BlueHat talk on congitively flawed humans:
  http://www.cs.auckland.ac.nz/~pgut001/pubs/psychology.pdf
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] 15 years later, why can't Johnny still not encrypt?

[coderman]

On Thu, Jan 16, 2014 at 3:36 AM, Tempest  wrote:
> ... the fact that i have walked novice computer
> users through installing and using gpg shows that the level of
> difficulty is debatable...


a direct, demonstration / walk through is a very different learning
experience compared to manuals and command lines staring back at you
from the abyss.

you'll note that the MIT experiment described the nature of this
knowledge transfer: "as the first reading"

for example, http://opensecuritytraining.info/Why.html explicitly
tailors instruction around an instructor led multi-session/multi-day
explorations of the subject matter.


back to the original point, our instruction right now appears
similarly flawed with respect to technology tools.  Edward Snowden
attempted to guide G.G. through PGP encrypted email via manual, via
on-line video instruction, and other resources.  all of which left
G.G. incapable of securely communicated via email and frustrated with
the tools and their interfaces.


usability with respect to security and privacy technology a great
challenge worthy in many facets.  you speak from experience teaching
others - your input on specifics of successfully teaching others,
rather than dismissal of anecdotes, is certainly needed!
(as are others reading this list who otherwise lurk compulsively ;)


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net

[coderman]

On Tue, Jan 14, 2014 at 6:53 PM, Tony Arcieri  wrote:
> ...
> http://cryptosphere.org
>
> I also detail the present unsuitability of the browser for cryptographic
> applications in this blog post:
>
> http://tonyarcieri.com/whats-wrong-with-webcrypto


i see what you did there.  browser based crypto... pointed to localhost!
  touché!  ;)


agree with your premises:
- failure to provide cryptographic lower bounds
- failure to do crypto outside insecure browser
- failure in trusting https

however i would go further in that cryptosphere demands defense in
depth; put your trusted localhost in an environment isolated from the
browser entirely; Qubes style.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Encrypted Pastebins: Attack Vectors against ezcrypt.it and 0bin.net

[coderman]

On Tue, Jan 14, 2014 at 6:44 PM, Uncle Zzzen  wrote:
>
>> 3. "Passive" global adversary attack:
>>
> As long as the JS is what the owner claims it is (assuming it's code that
> has been peer reviewed enough according to your standards), it doesn't
> matter whether they confiscate the hard drive or just listen.

i hate the term "passive global adversary".  the adversary active
across the global theater is able and active.


also, you're wrong three ways:

1) if entropy is compromised (see history of RNG tampering) this
assumption is actionable-ly false.  don't get me started on the
OpenSSL/* RDRAND fiasco...

2) "JS is what the owner claims it is" is suspect in BULLRUN situation
where private keys pilfered. (not to mention all the other subversive
techniques applied)

3) the attack surface of the browser.  nuff said!   (or said again,
"just listen" is only harmless if no prior active intervention has
occurred)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Recent Der Spiegel coverage about the NSA and GCHQ

[coderman]

On Thu, Jan 2, 2014 at 4:37 PM, Jacob Appelbaum  wrote:
> ...
> I wanted to write to highlight some important documents that have
> recently been released by Der Spiegel about the NSA and GCHQ. We worked
> very hard and for quite some time on these stories - I hope that you'll
> enjoy them.

second only to BULLRUN drop; thank you!



> ...
> OLYMPUSFIRE:
>
> http://www.spiegel.de/fotostrecke/nsa-dokumente-so-knackt-der-geheimdienst-internetkonten-fotostrecke-105326-13.html

off by one error; this is "VALIDATOR"


the OLYMPUSFIRE doc is at:
 
http://www.spiegel.de/fotostrecke/nsa-dokumente-so-knackt-der-geheimdienst-internetkonten-fotostrecke-105326-14.html




> ...
> There are quite a few news articles and most of them have focused on the
> iPhone backdoor known as DROPOUTJEEP - they largely miss the big picture
> asserting that the NSA needs physical access. This is a
> misunderstanding. The way that the NSA and GCHQ compromise devices with
> QUANTUMNATION does not require physical access - that is merely one way
> to compromise an iPhone. Generally the NSA and GCHQ compromise the phone
> through the network using QUANTUM/QUANTUMNATION/QUANTUMTHEORY related
> attack capabilities.

thank you as well for this clarification.  keep it up :)



best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The Intimidation Factor: How a Surveillance State Can Affect What You Read in Professional Publications

[coderman]

On Wed, Jan 1, 2014 at 9:11 PM, coderman  wrote:
> attempting to obtain a copy of:
> "The Intimidation Factor: How a Surveillance State Can Affect What You
> Read in Professional Publications"
> https://www.computer.org/csdl/mags/co/2013/12/mco2013120091-abs.html


see also: http://www.berghel.net/col-edit/out-of-band/nov-13/oob_11-13.php


this is disturbing in that those professionals most experienced and
capable of critical discussion on these topics are also most likely to
be directly or indirectly pressured into self-censorship or silence.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The Intimidation Factor: How a Surveillance State Can Affect What You Read in Professional Publications

[coderman]

On Wed, Jan 1, 2014 at 9:11 PM, coderman  wrote:
> ...
> does anyone have details on the nature of the pressure to censor in this case?


only other information from RISKS digest:
"""
Surveillance leads to censorship? [PGN retitling]

Robert Schaefer Mon, 30 Dec 2013 15:40:28 -0500

In this December's IEEE *Computer* magazine, in the column titled "The
Intimidation Factor: How a Surveillance State Can Affect What You Read in
Professional Publications", Hal Berghel says that he was forced to pull a
screenshot of a powerpoint slide Edward Snowden leaked to The Washington
Post.

The screenshot appeared in the his July column printed version but was
removed from the IEEE digital library version.  Berghel writes: "Pull up a
chair and let me tell you a story..."
"""
-- 
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 
compa...@stanford.edu.

[liberationtech] The Intimidation Factor: How a Surveillance State Can Affect What You Read in Professional Publications

[coderman]

attempting to obtain a copy of:
"The Intimidation Factor: How a Surveillance State Can Affect What You
Read in Professional Publications"
https://www.computer.org/csdl/mags/co/2013/12/mco2013120091-abs.html

i appear unable to download successful purchase, "There is no
down-loadable article.".



does anyone have details on the nature of the pressure to censor in this case?



best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] "To Protect and Infect" - the edges of privacy-invading technology

[coderman]

On Tue, Dec 31, 2013 at 8:02 PM, Hannes Frederic Sowa
 wrote:
>...
> Most of the implants are installed without we surely know if the vendors
> did know about that or am I missing something?

are you only considering this 30C3/catalog set of docs?

venally complicit to conveniently compromised to blissfully ignorant
compromise of hardware vendors goes back to CryptoAG and as recently
as the BULLRUN leaks.  a bit too long and complicated a thread for
this list, i think...




> I also don't count RSA as a hardware vendor in this case, as the
> backdoored RNG was included in their bSafe suite, which is purely
> software.

sure, just another example of in scope target for a "compromise all
the things" approach.

my point was to highlight their response as particularly deceptive and
inexcusable when observing how the various parties not only respond,
but act, in response to these leaks. (e.g. Google deploying crypto
over their internal fibers is positive action.  sitting silent or
deflecting criticism not confidence inspiring...)


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] "To Protect and Infect" - the edges of privacy-invading technology

[coderman]

On Tue, Dec 31, 2013 at 10:04 AM, Hannes Frederic Sowa
 wrote:
> ...
> There is a very big difference e.g. I (and a lot of other people too, I
> guess) will react to vendors whose debug interfaces where just hijacked
> by the NSA to install backdoors and where the vendors worked hand in
> hand with the NSA to do so deliberately.

agreed.  we've got some years to wait for a definitive full picture.
 http://cryptome.org/2013/11/snowden-tally.htm - 932 pages (~1.6%) of
reported 58,000. NSA head claims 200,000 (~.40% of that released)


> If such FUD is spread against vendors, which in my opinion, do actually have a
> valid interest in trying to stop those back doors, what do you think will a
> lot of members of this community do?

vendor responses are fairly self evident.

bad: RSA
less-bad: Cisco
good/proactive: SilentCircle
etc,...   we could get into details of what makes a good vendor
response vs. one that is clearly weasel worded accountability
deflection, don't think this list is the place however.



> Until now I saw no facts that I distrust the major hardware vendors.

then you're not paying attention :)




> I don't want to see what the PR persons on those accused companies' twitter
> feeds will have to go through now. I guess lots of overreaction is happening
> now, which is not helpful at all.

corporate media sucks to more or less degree; i feel bad for anyone
who touches it.

glad it's not my problem!



best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] "To Protect and Infect" - the edges of privacy-invading technology

[coderman]

On Mon, Dec 30, 2013 at 9:14 PM, Hannes Frederic Sowa
 wrote:
> ...
> Actually, somehow, I have a feeling of relief to see that major hardware
> vendors don't seem to specifically work hand in hand with the NSA to
> implement backdoors.

you're assuming this dump is exhaustive.  this is a very specifically
themed/focused release of top end tactics and exploits (essentially
weaponized platforms for targeted attacks). Jake says as much about
what they're dropping, which while impressive, has still gone through
the "best interest of public safety scrutinizing and censorship"
rigmarole.

the indiscriminate, wholesale compromises are just getting started...
these disclosures will have more impact: financially to the impacted
vendors, effectively to IC as known vulnerable hardware and software
is replaced, and to the public at large now exposed to even more
essentially incomprehensible disclosures of vulnerability and
compromise.



> I don't see that having a JTAG connector publicaly
> accessible on a RAID controller as a hint for that. The other disclosures
> also point to my conclusion that the NSA is mostly working on their
> own. Of course, not all of Snowden's documents are released yet and
> hence my feeling could be deceiving.

this is just an example of how, when the NSA pursues "all means and
methods in parallel, without restraint" seemingly innocuous oversights
are intentionally leveraged and discouraged from remediation for use
in tailored access (black bag / targeted) attacks.



> I thought it could be worse.

it is worse.


best regards,


p.s. cryptome has lots of great docs on this and other 30C3 awesomeness:
  http://cryptome.org/ , http://cryptome.org/2013/12/nsa-catalog.zip
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The quest to make encryption accessible to the masses (Wired UK)

[coderman]

On Sun, Dec 15, 2013 at 5:40 PM, coderman  wrote:
> ...
>   where do i donate for Cryptocat scrutiny?


kudos to Kobeissi for accepting bitcoin donations.
... now create an addr specific to audits  :)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The quest to make encryption accessible to the masses (Wired UK)

[coderman]

On Sat, Dec 14, 2013 at 11:40 PM, Maxim Kammerer  wrote:
>> "That was really bad,"
>> admits Kobeissi, but he assures Wired.co.uk that subsequent audits of
>> the program have affirmed its integrity.
>
> ... as did prior audits.


all non-trivial code has bugs and oversights.  audit is not a finite
thing, one and done.

code integrity a continuous and open process;
  where do i donate for Cryptocat scrutiny?


crowd sourced audits, like TrueCrypt, are wonderful collaborations.
bounties also good for signalling false assumptions.
-- 
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 
compa...@stanford.edu.

[liberationtech] Stratfor efforts against activist groups

[coderman]

so, do the ends justify the means?
 ... that's really what any justification for this kind of un-ethical
behavior boils down to.


http://cryptome.org/2013/12/wl-stratfor-popovic-ows.htm
"""
... Below are a series of articles this past week about
internationally acclaimed activist, Srdja Popovic, and his involvement
with the private intelligence firm Stratfor.

... If anyone has information about CANVAS or Srdja Popovic, please
feel free to contact me at zoealif[at]gmail.com. I am currently
writing a blog post on the story.
"""
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Cryptography Leak in Enigmail / GnuPG

[coderman]

On Sun, Nov 24, 2013 at 9:26 AM, Moritz Bartl  wrote:
> ...
> Important to note here is that by default, Enigmail adds the sender to
> the recipient list -- which is useful if you want to reread sent mail,
> but it also means that any encrypted mail contains not only the
> recipient key ID (which at least some users know), but also the sender
> key ID.
>
> Adding to the pain, if you receive a PGP message without keyID and have
> multiple private keys, GPG/Enigmail will dumbly rotate through the keys,
> without taking the actual email addresses (sender/recipient pair) from
> the mail header into account. This can only be solved on Enigmail-level,
> since only Enigmail "knows" about email headers.
>
> Thank you Fabio for filing the tickets! Maybe some good will come out of
> that.


email for private communication is folly, nevertheless,

it would be useful to use these fields for mis-information.  e.g.
"camouflage".  by inserting incorrect software in "BEGIN PGP MESSAGE",
by inserting a different version in "X-EnigMail-Version" or "Version:
and Comment: headers".

similar to the "Windows XP" mode of Tails, this camouflage would serve
to mislead potential attackers who would use this information for
targeted client side attacks.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Defunding the NSA right now

[coderman]

On Thu, Nov 7, 2013 at 11:51 AM, Griffin Boyce  wrote:
>  ...
>   If you want the NSA to be defunded,


not only de-fund the intelligence agencies,
  but also disclose to vendors all of the classified vulnerabilities
and exploits they've identified and weaponized under TAO and related
programs.
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] arkOS starts funding campaign to push forward development

[coderman]

On Tue, Nov 5, 2013 at 2:09 PM, Jacob Cook  wrote:
> ...
> I'm not sure what you mean off the top of my head by if "cables" will
> be included as a service - could you elaborate?


cables: "secure and anonymous communication using email-like
addresses, pioneered in Liberté Linux."
  http://dee.su/cables
  https://github.com/mkdesu/cables
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Obfuscation / Network Steganography Research

[coderman]

On Sun, Nov 3, 2013 at 8:29 PM, Lucas Dixon  wrote:
> ...
> I'm trying to put together a good reading and person list for what is
> currently known on network steganography


i am compelled to mention, along with the other excellent resources
listed, Elligator:
  http://elligator.cr.yp.to/
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] [guardian-dev] Randomize MAC of Android phone?

[coderman]

On Sun, Oct 27, 2013 at 7:15 AM, Timur Mehrvarz
 wrote:
> ...
> Can you name the device models you had success with? Maybe explain how
> you changed the MAC address on those? Is it always the same procedure?
> ... it would be really good to have a
> positive/negative list in regard to Wifi chipsets.

i will follow up with the half dozen i personally use; driver and
device ids.  use native or custom busybox and ifconfig hw ether in
script or via macchanger support. the interface must usually be down
to change MAC; busybox ifconfig wifi0 down; busybox ifconfig wifi0 hw
ether 00:11:22:33:44:55; ifconfig wifi0 up ...; all you need is shell
and OUI.txt list to pick a known vendor prefix, or you can get fancy
with macchanger daemons, a dozen ways to solve it.

a mobile MAC change compatibility list by kernel and hardware device /
chipset would be immensely useful! i am not aware of such a thing. if
you start or find one, i would be happy to contribute details there
directly.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] [guardian-dev] Randomize MAC of Android phone?

[coderman]

On Thu, Oct 24, 2013 at 5:23 AM, Timur Mehrvarz
 wrote:
> ...
> The Android Wifi kernel drivers seem to not implement the functionality
> behind 'ifconfig wlan0 hw ether' (what is behind the ioctl call being
> used by ifconfig).


i've had success with HTC, LG, and Samsung devices. less so with
Motorola or newer hardware.

this is not really the kernel itself, but rather the wifi chipset - a
new kernel on the devices you're having trouble with won't fix this
ioctl.

unfortunately this problem is getting worse, not better.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Google Unveils Tools to Access Web From Repressive Countries | TIME.com

[coderman]

On Wed, Oct 23, 2013 at 12:13 PM, Adam Fisk  wrote:
> ... we really would love to hear any criticisms of Lantern people may
> have, including anything technical or ...

make Latern function as a pluggable transport for Tor!
  https://www.torproject.org/docs/pluggable-transports.html.en

thus expressing by action the fondness you describe in words ;)

best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Google Unveils Tools to Access Web From Repressive Countries | TIME.com

[coderman]

On Mon, Oct 21, 2013 at 8:27 PM, Shava Nerad  wrote:
> So, I've had this post in draft since 10/15, and I added some links and a
> couple paragraphs,...

real names as "a move based on online civility" is just as much
bullshit today as it was then. only more evidently so!

while this service (uProxy, et. al) may be worthless, Google still
pays AGL's salary, and thus isn't all bad ;)


keep it up Shava; there's nothing but appropriate context and
reasonable inference in this post...

best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Randomize MAC of Android phone?

[coderman]

On Sat, Oct 19, 2013 at 2:32 AM, Jerzy Łogiewa  wrote:
> ...
> Is it possible to randomize wifi MAC of Andorid phone on power up?

this works for most wifi devices if you have root; just modify init
scripts to ifconfig hw ether a random mac (you can do this in shell).
don't delegate something critical like this to an arbitrary app, which
is invoked much later in the start up sequence.

any of the apps which mask the MAC via intercepted calls to
Java/Android APIs will do nothing to hide your MAC on the network,
like you desire.
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Snowden sets OPSEC record straight

[coderman]

On Fri, Oct 18, 2013 at 1:38 PM, Tom O  wrote:
> Greenwald has stated on twitter that Snowden has access to docs.


do you have links to the tweets in question?  there was interesting
discussion on the reddit AMA[0] as well, however, i do not recall
seeing this ongoing access stated.

best regards,



0.  http://cryptome.org/2013/10/greenwald-gibson-reddit.pdf
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Snowden sets OPSEC record straight

[coderman]

On Fri, Oct 18, 2013 at 5:43 AM, Tom O  wrote:
> ...
> 1. NSA won't say what damage has been caused. They still operate in the
> dark. They'd be stupid to say anything either way. Silence doesn't equate to
> no damage.

desperate times and desperate measures; while this is generally true,
in this situation Snowden has been discredited along personal attacks
which serve no other purpose than to malign the source.

there is truth to this assessment, though it is not so simple as stated...



> 2. From GG has said, Snowden has access to files.

there have only been statements regarding his continued contact and
collaboration with those reporting on the leaks; there has never been
a claim that he retains access to the actual files, and in fact plenty
of statements indicating the opposite.

this is all entirely consistent.


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The missing component: Mobile to Web interoperability (in Internet Freedom Technologies)

[coderman]

On Wed, Sep 25, 2013 at 9:32 PM, coderman  wrote:
>   [... re: NSA has found a way to break Tor... ]
> i suspect it is the latter that is more concerning. of course NSA has
> the ability; but do they share it?


the recent releases[0] have shown this to be more complicated than expected.

in terms of sharing: other domestic agencies and some of the FVEY
partners appear to be partially looped in? likely to find out more
over the years,...


in terms of breaking Tor:

the core Tor protocol and network is described repeatedly as difficult
to compromise. attacking the client, opportunistic de-anonymization,
selective denial of service, and mallory-in-the-middle attacks, all
appear extremely effective when they are pointed at Tor users of
interest. Tor's dependencies are failing in practice, rather than the
network or protocol itself.


Roger says the limited number of users targeted is reassuring, “If
those documents actually represent what they can do, they are not as
big an adversary as I thought,”[1]


the lack of widespread de-anonymization of Tor users is an interesting
situation.  i do not agree that they don't have the ability. other
sources clearly show their privileged positioning in the IP core for
active attacks as well as the global passive DPI tapping
infrastructure technically capable of linking large numbers of Tor
users.[2]

instead this implies that the other routes to identifying users,
particularly taking advantage of the endpoint and operational risks
above, are cheaper and more effective.
for less effort and resources locate them via side channel tricks,
infect them with spyware, and observe what they do
pre-encryption-and-pre-proxy directly.  it's clear to see why they've
been using this approach. [here is where i plug Qubes Tor VM, Tails,
Whonix]


so after addressing the client side weaknesses, perhaps the elligator
datagram based effort[3] will be making progress in time to thwart
this new adversary model as the low hanging fruit of Tor client
cracking dries up...
  ;)


best regards,



0. NSA Tor dox:
http://www.washingtonpost.com/world/national-security/secret-nsa-documents-show-campaign-against-tor-encrypted-network/2013/10/04/610f08b6-2d05-11e3-8ade-a1f23cda135e_print.html
http://cryptome.org/2013/10/nsa-iat-tor.pdf
http://cryptome.org/2013/10/nsa-tor.pdf
http://cryptome.org/2013/10/gchq-mullenize.pdf
http://cryptome.org/2013/10/nsa-egotisticalgiraffe.pdf
http://cryptome.org/2013/10/nsa-tor-stinks.pdf
http://cryptome.org/2013/10/packet-stain/packet-staining.htm

1. "Secret NSA documents show campaign against Tor encrypted network"
  
http://www.washingtonpost.com/world/national-security/secret-nsa-documents-show-campaign-against-tor-encrypted-network/2013/10/04/610f08b6-2d05-11e3-8ade-a1f23cda135e_print.html

2. passing the buck on the math; the details you need:
 https://metrics.torproject.org/index.html /
https://trac.torproject.org/projects/tor/ticket/6443 ,
answer for the question: what is the probability of picking a guard
and exit relay using any of five-eyes-and-their-friendlies AS'es, or
that travels transoceanic cables at these points, or uses guard and
exit relays hosted at an IX under legally compelled (FVEY) or unaware
collaboration (e.g. Belgacom)?

3. sorry, no; there is no Tor datagram protocol in the works yet,
however initial considerations are in progress:
"Implement and experiment with one or more datagram-based designs"
  https://trac.torproject.org/projects/tor/ticket/4684
  http://www.cl.cam.ac.uk/~sjm217/papers/tor11datagramcomparison.pdf
this is summarized as picking from multiple hard to very hard options.
i'm fond of even more difficulty, and combining these techniques and
others (multi-path SCTP in userspace, client-side traffic
shaping/prioritization, stochastic fair queuing and packet reordering,
etc) for better protection against traffic analysis and active
attacks might take a while to code up *grin*
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] USB Block Erupters as RNG sources?

[coderman]

On Thu, Oct 3, 2013 at 2:43 AM, d.nix  wrote:
> ...
> Curious; anyone know much about what these inexpensive (comparatively,
> price seems steadily falling) ASIC Block Erupter USB Bitcoin miners
> can be adapted to doing? Could they be repurposed as RNG sources?

at best you *might* be able twist it into a DRBG that would still need
to be seeded (and regularly reseeded) with robust entropy.

these ASICs really are single purpose; they're useless for anything else.
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The missing component: Mobile to Web interoperability (in Internet Freedom Technologies)

[coderman]

On Wed, Sep 25, 2013 at 1:34 PM, Jonathan Wilkes  wrote:
> ...
> Roger Dingledine has said that his biggest fear is that the
> NSA has found a way to break Tor,

citation?  ;)


> ... and they whisper what
> they know to other agencies only in those cases where
> doing so wouldn't risk letting the cat out of the bag.

the TLAs are already adept at this "source laundering"!


i suspect it is the latter that is more concerning. of course NSA has
the ability; but do they share it?
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] settings?

[coderman]

On Wed, Sep 25, 2013 at 10:51 AM, Lina Srivastava
 wrote:
> Never happened to me before on this particular list and I've been on it for
> a few years.

i think you've been unusually lucky ;)

it would be interesting to know if specific senders are getting spam
filtered, or specific message threads. (if senders, it could be DNSRBL
or other criteria, if messages, perhaps something has changed in your
spam heuristics)
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] settings?

[coderman]

On Wed, Sep 25, 2013 at 10:47 AM, Lina Srivastava
 wrote:
> ...
> I don't know about others, but my libtech emails are starting to end up in
> my spam filter, saying that others have been marking them as spam -- I
> didn't mark them as such. Just fyi that some subscribers might be missing
> conversations.


this is par for the mailing list course.  it happens with some
infrequency on nearly all lists with decent traffic.

if you're not checking your spam trap occasionally, you're doing it wrong!
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Why can’t email be secure? - Silent Circle Blog

[coderman]

On Wed, Sep 18, 2013 at 8:27 AM, Eric Mill  wrote:
> I highly doubt Google is filtering stuff out for the NSA...
> The simpler explanation is that Google Alerts is 100% broken because it
> makes Google no money and doesn't do much for their core business interests.

i suppose Hanlon's razor is apropos...
 (this is a convenient flaw, in any case ;)


> I've switched to using Talkwalker instead.

thanks for the tip; i like it better already!
https://www.talkwalker.com/alerts


best regards,
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Why can’t email be secure? - Silent Circle Blog

[coderman]

On Sun, Aug 25, 2013 at 1:21 PM, coderman  wrote:
> ... 10,000 news alerts from scores of
> filters (everything from "TS//SI//NF" to "Flame OR Gauss OR Duqu OR
> Stuxnet" to Goldreich–Goldwasser–Halevi),..


sometime over the past few weeks google alerts has started filtering
(certain?) NSA codewords from alert matches.

ah well, nice while it lasted...
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] The missing component: Mobile to Web interoperability (in Internet Freedom Technologies)

[coderman]

On Sat, Sep 14, 2013 at 8:12 AM, Lee Azzarello  
wrote:
> We have a federated telephony system...

On Sat, Sep 14, 2013 at 10:27 AM, Nathan of Guardian
 wrote:
> ...
> A truly free internet = a federated internet in my mind... Why do you 
> consider it a sign that something is broken?


back in the p2p fad days, the distinction between federated and
decentralized became important, and was characterized as
(paraphrasing):

- federated is distributed hierarchy with a single or few points of
ownership and control. federated is focused more around
inter-operability, resilience, availability, and robustness of managed
services.

- decentralization has no single point of ownership or control nor
does it imply hierarchy of any sort, instead relying on the
cooperation of independent peers. decentralized is focused more around
peer trust boundaries, scale free growth, end-to-end anonymity and
privacy.


federated systems are working great! CALEA compliant, one stop shops
for BULLRUN.

what we need are fully decentralized systems that are even more
usable, even more scalable, and even more end-to-end protected with
hardware and software we can actually trust.
-- 
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 
compa...@stanford.edu.

Re: [liberationtech] Naive Question

[coderman]

On Wed, Sep 11, 2013 at 2:52 PM, R. Jason Cronk  
wrote:
> Anything which potentially signaled your receipt of an NSL would be grounds
> for prosecution under the gag-order. This is what the prosecutor was
> alluding to when he signaled that Lavabit's shut down was tantamount to a
> violation because his shut down essentially communicated the fact that he
> was under a court order to do something which he couldn't talk about.


if this is prosecuted, and upheld, it would signal the death of for
profit or non-profit (e.g. incorporated) services for any private
communication.

this assumes the NSL provisions do not hold against individuals in a
private capacity...
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] Random number generation being influenced - rumors

[coderman]

On Sat, Sep 7, 2013 at 10:26 AM, Eugen Leitl  wrote:
> ...
> There is a hardware RNG in the AMD Geode LX. I tried very hard to
> find any documentation, but found effectively nothing.
>
> Am I that bad at searching, or this really a black box?

the only decent on-die RNG i have used was XSTORE[0] from VIA Padlock
which allowed you very high speed access to the raw, unwhitened output
of the hardware RNG sourece(s). you could read from both at twice the
rate for maximum throughput.

it was then up to a user-space daemon to read this raw source and
perform cursory and long-lived checks, even benchmarks against large
volumes of TBytes of output for extended confirmation (looking at you
DIEHARDER).

the user-space daemon, having then verified the hardware entropy
sources, performs computation blinding and compression (e.g. hashing
or bocl ciphering) and mixes this obfuscated entropy with the kernel
entropy pool via write to /dev/random.

RDRAND/RDSEED can not be used a trusted manner with access to the
unwhitened, raw output.

the AMD768 RNG has not produced a detailed design like XSTORE and
cryopgraphy research, nor does it support the raw mode like needed,
always reading some "4 bytes:" of randomness (IIRC).

there are USB and other external sources for entropy if your CPU does
not support it, of course. these are useful to augment any userspace
entropy daemons like Havegd.


0. "Evaluation of C3 Nehemiah Random Number Generator"
  http://www.cryptography.com/public/pdf/VIA_rng.pdf
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] WaPo releases details on US offensive cyber-ops

[coderman]

On Mon, Sep 2, 2013 at 10:44 AM, Gregory Foster
 wrote:
> ...
> The NSA designs most of its own implants, but it devoted $25.1
> million this year to “additional covert purchases of software
> vulnerabilities” from private malware vendors, a growing
> gray-market industry based largely in Europe.


i would love to know how much of the overall market for exploits this
$25.1mm figure represents, and how much was exclusive vs. shared
access...
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] FW: NSA Admits: Okay, Okay, There Have Been A Bunch Of Intentional Abuses, Including Spying On Love Interests | Techdirt

[coderman]

On Sat, Aug 31, 2013 at 4:10 PM, Matt Johnson  wrote:
> Tomasz, you seem to have a dark view of human nature.

some may argue willingly participating in and furthering an illegal,
global surveillance infrastructure is a character flaw consistent with
other morally objectionable behavior ;)



> ... On the other
> hand, if this were happening, would we ever find out?


in the case of MI5 agent Geoffrey Prime it was the local police:
"""
The case that really shocked Mrs Thatcher was the traitor Geoffrey
Prime. In the 1970s he had worked at the top secret listening centre
GCHQ and had been selling all it's secrets to the Russians.

And yet again it wasn't MI5 who uncovered his treachery - it was the
local police in Cheltenham.

In 1982 a policeman came to his house enquiring about his car - a
rather distinct two-tone brown and white Mk IV Cortina - a which had
been seen in the vicinity of an assault on a young girl.

Prime told the policeman that he had been at home all day. But that
evening he and his wife Rhona went for a drive to the top of Cleeve
Hill. As they sat in the twilight Prime told Rhona that he was the man
the police were looking for. And not only that, he was also a Russian
spy.

Here is part of a very powerful interview Rhona Prime gave to the BBC
where she describes that day - and what she then did.

Prime was a paedophile - and had used spying techniques to monitor the
activities of thousands of young girls around Cheltenham. He had
created a vast set of index cards which showed when the girls were
most likely to be alone at home. He then went round to their houses in
his two tone Cortina and sexually assaulted them.
"""
  http://www.bbc.co.uk/blogs/adamcurtis/posts/BUGGER
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] Why_can't_email_be_secure

[coderman]

On Sun, Aug 25, 2013 at 12:26 PM, Ali-Reza Anghaie  wrote:
> ...
> And herein lies the problem - Silent Circle isn't talking to "us" -
> they are talking to the other 99.99% of email users in the world.


and to StealthMonger's point about latest generation mix networks for
best privacy, why not instead focus on building low latency protocols
that are resistant to traffic analysis and confirmation?

make them datagram based; utilize user space stacks and latest
research.  solving the low latency datagram anonymity problem enables
existing usable private communication with the additional benefit of
endpoint and peer anonymity.

i believe this possible to make useful, even if never infallible.
certainly more possible than the odds of making truly scalable,
available, and _usable_ mix mailer networks and clients for the
masses.


most important: make this low latency infrastructure usable and cross
platform, so the implementations are easily adopted... like Napster
and BitTorrent back in the day. ;)
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] Why can’t email be secure? - Silent Circle Blog

[coderman]

On Sun, Aug 25, 2013 at 11:59 AM, katana  wrote:
> ... as Ladar replied in
> 
> to Amy's question 'Do you think people should use email?': 'Yeah, I
> think it’s a great way to communicate ... And I think email still has a
> very important role to play in communication between people.' ACK.


it is a question of private vs. public communication.


email is and will continue to be useful for public communication. this
gmail account indexes 190+ lists, 10,000 news alerts from scores of
filters (everything from "TS//SI//NF" to "Flame OR Gauss OR Duqu OR
Stuxnet" to Goldreich–Goldwasser–Halevi), a total of 643,132 pieces of
communication. i can search through all of it in seconds and apply new
filters to existing content just as easily as new, and keep an offline
backup just in case.

but there is zero i would consider private; for that use a medium of
communication that is not a usability failure, that is not a metadata
leakage nightmare, that is not an operational security mine field.


let email _for private communication_ die already, please!
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] FW: NSA Admits: Okay, Okay, There Have Been A Bunch Of Intentional Abuses, Including Spying On Love Interests | Techdirt

[coderman]

On Sat, Aug 24, 2013 at 5:21 AM, michael gurstein  wrote:
> Okay, so we have a few joke "abuses" to divert attention but what about the
> intentional non-abuses and the non-joke ones...


what this demonstrates is two fold:

first, that any motive which may arise, no matter how petty, has
resulted in abuses of these systems for personal ends.

second, that any procedural or technical controls around preventing
these abuses are insufficient or even lacking entirely.


LOVEINT, as excellent in the mind's eye it may be as focal point for outrage,
 is clearly just the tip of the ice berg.
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] NSA Admits: Okay, Okay, There Have Been A Bunch Of Intentional Abuses, Including Spying On Love Interests | Techdirt

[coderman]

On Fri, Aug 23, 2013 at 10:25 PM, James S. Tyre  wrote:
> Best summary: https://twitter.com/slworona/status/370946271646711809


indeed; this codename gives the lie to all the congressional
testimony, to all the claims of controls and judiciary oversight, to
all the attestations of full compliance.

it's beautiful in laying bare the capriciousness to which the entire
intelligence juggernaut can be brought to bear against arbitrary
individuals; personal pettiness more than sufficient.
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] NSA Admits: Okay, Okay, There Have Been A Bunch Of Intentional Abuses, Including Spying On Love Interests | Techdirt

[coderman]

LOVEINT!!!

oh god this alone makes it all worth it,,, thank you Snowden!

P.S. setup a bitcoin donation address.

best regards,




On Fri, Aug 23, 2013 at 9:21 PM, Yosem Companys  wrote:
> http://www.techdirt.com/articles/20130823/18432024301/nsa-admits-okay-okay-there-have-been-bunch-intentional-abuses-including-spying-loved-ones.shtml
>
> NSA Admits: Okay, Okay, There Have Been A Bunch Of Intentional Abuses,
> Including Spying On Love Interests
>
> from the and-we're-just-now-telling-congress dept
>
> So, this week, we wrote about the NSA quietly admitting that there had been
> intentional abusesof its surveillance infrastructure, despite earlier claims
> by NSA boss Keith Alexander and various folks in Congress that there had
> been absolutely no "intentional" abuses. Late on Friday (of course) the NSA
> finally put out an official statement admitting to an average of one
> intentional abuser per year over the past ten years. The AP is reporting
> that at least one of the abuses involved an NSA employee spying on a former
> spouse. Meanwhile, the Wall Street Journal suggests that spying on love
> interests happens somewhat more often:
>
> The practice isn’t frequent — one official estimated a handful of cases in
> the last decade — but it’s common enough to garner its own spycraft label:
> LOVEINT.
>
> A handful is still significantly more than once. And it's a lot more than
> the "zero" times we'd been told about repeatedly by defenders of the
> program.
>
> While the NSA says it takes these abuses seriously, there's no indication
> that the analyst was fired.
>
> Much more troubling is that it appears that the NSA only told its oversight
> committee in the Senate about all of this a few days ago:
>
> The Senate Intelligence Committee was briefed this week on the willful
> violations by the NSA's inspector general's office, as first reported by
> Bloomberg.
>
> "The committee has learned that in isolated cases over the past decade, a
> very small number of NSA personnel have violated NSA procedures — in roughly
> one case per year," Sen. Dianne Feinstein, the California Democrat who
> chairs the committee, said in a statement Friday.
>
> Of course, this is the same Dianne Feinstein who, exactly a week ago, said
> the following:
>
> As I have said previously, the committee has never identified an instance in
> which the NSA has intentionally abused its authority to conduct surveillance
> for inappropriate purposes.
>
> Yeah. Because apparently the NSA chose not to tell the committee until a few
> days later, despite it happening for years.
>
> And, of course, they release this all on a Friday night, hoping that it'll
> avoid the news cycle...
>
> In the meantime, the NSA just made Senator Feinstein look like a complete
> fool. She's been its strongest defender in Congress for years, and has stood
> up for it time and time again, despite all of this questionable activity.
> Then, last week, it lets her tell lies about it without telling her
> beforehand that there had been such abuses. At this point, it's abundantly
> clear that Feinstein's "oversight" of the NSA is a joke. She's either
> incompetent or lying. Either way, it appears that the NSA is running circles
> around her, and isn't subject to any real Congressional oversight. At some
> point, you'd think that maybe she'd stop defending it and actually start
> doing her job when it comes to oversight. You'd think the fact that it let
> her make a complete fool of herself by claiming there had been no
> intentional abuses should make Feinstein realize that the NSA situation is
> out of control. But, tragically, this seems unlikely. Even her statement
> seems to want to minimize the seriousness of the fact that she -- the person
> in charge of oversight -- was completely kept in the dark about very serious
> intentional abuses. Senator Feinstein just got hung out to dry by the NSA.
> You'd think she'd stop going to bat for it and its lies.
>
> Either way, we've now gone from General Keith Alexander and Feinstein
> claiming "no abuses," to them saying no "intentional" abuses, to this latest
> admission of plenty of intentional abuses, including spying on lovers.
> Perhaps, instead of lying, it's time for the NSA to come clean and to get
> some real oversight.
>
>
> --
> Liberationtech is a public list whose 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
> compa...@stanford.edu.
-- 
Liberationtech is a public list whose 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 
compa...@stanford.edu.

Re: [liberationtech] And now for some completely different flame... Chrome + password management

[coderman]

On Wed, Aug 7, 2013 at 9:09 PM, Patrick Mylund Nielsen
 wrote:
> Encrypting the passwords with a master passphrase wouldn't be useless...

even if this is useful, it is a policy that should be implemented in
the key manager and not the browser (or any other app, each on an
ad-hoc basis, each with their own controls and configuration and
assurances, each with their own flaws and shortcomings).

consider KeyChain on Android with keystore and hardware backed secret
storage - if you use the standard interfaces instead of rolling your
own you get hardware protections where available without any
additional effort. the same applies to desktop key manager policies;
apps should rely on existing infrastructure rather than implement
their own solutions poorly.


again, policies and configuration like master passwords, session
timeouts, explicit authorization, etc. are all the domain of a key
manager and not the browser or any other app.


the only thing Google could have done better is provide a more visible
and useful description of how Chrome uses existing key management
facilities on the desktop to save passwords and where the user can
find out more about how this service functions.
--
Liberationtech list is public and archives are searchable on Google. Too many 
emails? Unsubscribe, change to digest, or change password by emailing moderator 
at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] And now for some completely different flame... Chrome + password management

[coderman]

On Wed, Aug 7, 2013 at 7:04 PM, Brian Conley  wrote:
> Are they being irresponsible or aren't they?
>
> http://mashable.com/2013/08/07/chrome-password-security/?utm_cid=mash-com-fb-main-link
>
> That is a serous question in interested to hear a variety of opinions


this is how desktop environments manage passwords. you could copy
paste some python into a terminal to do the same thing for any logged
in user, not just browser passwords. (wifi, disk crypto, services,
etc.)

you manage this key ring with a password. if it is unlocked, assume
your passwords are available in the clear!  set your desktop to
auto-lock on idle.  require a password to unlock.

if you need stronger separation of identities, authorizations, or
risk, try a more constrained and isolated environment like Qubes [0].

if you want better control over the access and availability to
credentials provided by a key ring / key manager, then install one
that meets your needs and can be configured to the policy you desire.


0.  "Qubes implements Security by Isolation"
  http://qubes-os.org/trac/wiki/QubesArchitecture
--
Liberationtech list is public and archives are searchable on Google. Too many 
emails? Unsubscribe, change to digest, or change password by emailing moderator 
at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Anonymity Smackdown: NSA vs. Tor

[coderman]

On Tue, Aug 6, 2013 at 8:43 PM, Kyle Maxwell  wrote:
> ...
> The key, obviously, is the primary assertion that the NSA runs "lots"
> of Tor nodes.

it is incorrect to assume this is for attacking anonymity of Tor users.

more likely these nodes are used as trusted guards and exits in
circuits the $TLAs use for their espionage and offensive operations.

a good anonymity network encompasses all users :)



> I've seen this assertion before, and while it's
> certainly a reasonable assumption, I don't know if anybody outside the
> NSA actually has hard evidence for that.

if you were to 0wn the Tor network and clients you would know.



> Runa Sandvik's excellent
> talk[1] at DEF CON 21 started to address this, but clearly more work
> remains to be done here.

is there a transcript of this talk? for all the mention of
inaccuracies in this errata post there were reports of inaccuracies
and invalid assumptions in the DEF CON 21 talk as well.



> Other criticisms are
> really about operational security: sending non-encrypted traffic (e.g.
> HTTP) over Tor ...

these operational issues have been and will continue to be the largest
risk to Tor users by far. this is evidenced by history of past
vulnerabilities and the focus on active, offensive capabilities by
these organizations.

in short: errata post misguided and incorrect.
  but still useful for the issues it brings to light and the
improvements made to Tor that many seem unaware of.
--
Liberationtech list is public and archives are searchable on Google. Too many 
emails? Unsubscribe, change to digest, or change password by emailing moderator 
at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Freedom Hosting, Tormail Compromised // OnionCloud

[coderman]

On Tue, Aug 6, 2013 at 12:28 PM, R. Jason Cronk  
wrote:
> ... Anybody know what ever happened to Publius[1]? Did that concept
> ever go anywhere?
>
> 1 http://www.cs.nyu.edu/waldman/publius/


wow, that takes me back. i remember running publius when it launched
back in the DeCSS days.

from what i recall there was a subsequent "tangler" censorship
resistance project, then nothing.

curious if anyone else know more...
--
Liberationtech list is public and archives are searchable on Google. Too many 
emails? Unsubscribe, change to digest, or change password by emailing moderator 
at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] EFF's new lawsuit against the NSA

[coderman]

On Tue, Jul 16, 2013 at 4:45 PM, James S. Tyre  wrote:
> For those interested, we filed a new lawsuit against the NSA today.  We have 
> another still
> in litigation, but this one focuses on a specific aspect of the new 
> revelations.
>
> Intro, FAQ and a link to the Complaint at
> https://www.eff.org/cases/first-unitarian-church-los-angeles-v-nsa


"Our goal is to highlight one of the most important ways that the
government collection of telephone records is unconstitutional: it
violates the First Amendment right of association. When the government
gets access to the phone records of political and activist
organizations and their members, it knows who is talking to whom,
when, and for how long. This so-called “metadata,” especially when
collected in bulk and aggregated, tracks the associations of these
organizations.
...
The new case will also argue the basic First and Fourth Amendment
arguments that we’re also raising on behalf of individual AT&T
customers in Jewel v. NSA. It will also raise a claim under section
215 of the PATRIOT Act since we believe the government is
misinterpreting the statute—it does not allow bulk collection and
searching without individual judicial approval. We also raise a Fifth
Amendment claim for informational privacy and for vagueness, since the
secret court rulings by the court overseeing the spying, the Foreign
Intelligence Surveillance Court, give neither the public nor law
enforcement clear rules and limits on their ability to surveil
Americans."


EFF++
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator at compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech