Re: [liberationtech] Securing Email Communications from Facebook offering PGP support

2015-06-01 Thread Matt Mackall
On Mon, 2015-06-01 at 18:26 -0400, Thomas Delrue wrote:
 On 06/01/2015 06:19 PM, z...@manian.org wrote:
  For their notification system, FB is leveraging GPG as an identity 
  provider to say only a person who has a certain private key
  should be able to reset access credentials for this account.
 
 I had not thought of this and I think that this is a good point.
 I do however question whether this is the purpose of this feature, I
 think it is more of a side-effect.

Nope, it's two distinct features:

- enter your public key so it's displayed and downloadable from your
public profile
- check a separate box to enable encrypted notifications

Further, I'll note that you don't have to trust Facebook can't be
coerced for encrypted notifications to be useful. You just have to trust
that -your enemies- can't coerce them. For many of Facebook's 1.44
billion users, this is probably true.

-- 
Mathematics is the supreme nostalgia of our time.

-- 
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] Whatsapp, a Trojan horse for seekers of easy privacy?

2015-01-15 Thread Matt Mackall
On Thu, 2015-01-15 at 11:44 -0800, Al Billings wrote:
 You’re avoiding the question. Please name a nation state in which
 software can be produced which isn’t subject to the kind of legal
 pressures or potential requirements as the USA when it comes to
 national security, spying, and the like. 
 
 Russia? Nope. The UK? Nope. Germany? Nope. I could go on.

Hell, none of these choices even get you out from under the NSA's thumb,
despite being off USA soil. If you are a communications company with a
non-trivial number of users, you will be a target of multiple national
security organizations. If you don't have the capability to do regular
CIA-level background checks on all your employees and contributors, you
can be infiltrated.

-- 
Mathematics is the supreme nostalgia of our time.


-- 
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] Facebook available as a Tor hidden service

2014-10-31 Thread Matt Mackall
On Fri, 2014-10-31 at 10:12 -0600, Robert W. Gehl wrote:
 I tried to login (with a fake account I maintain for just such a
 purpose). Your account is temporarily locked, it says. I get that; it
 appears I'm trying to login from a strange location.

I've asked some people connected to the project about this and they want
to remind everyone that the project is evolutionary and slightly
flaky. Also the goal is that we keep the service up and accessible to
people coming from Tor but not that we avoid flagging potentially odd
user behaviour.

Facebook also lets you get past this checkpoint with two-factor
authentication. Most of FB's two-factor methods involve a de-anonymizing
SMS, but in theory Google Authenticator works totally off-line so can be
safely used here. Someone with more familiarity with Authenticator can
confirm.

-- 
Mathematics is the supreme nostalgia of our time.


-- 
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] TrueCrypt Alternatives?

2014-09-30 Thread Matt Mackall
On Tue, 2014-09-30 at 14:55 -0700, Huned Botee wrote:
 Eleanor, maybe you can help shed some light on this lack of awareness.
 How do you think developers should be analyzing risk here? Do you have
 specific suggestions and/or can you point to sources where that information
 can be found?

The problem with a deniable filesystem is that not only can you deny it
exists, you also can't prove it doesn't. 

Given that the presence of software-for-deniable-encryption on a machine
is decent evidence (in the Bayesian sense) for presence of a deniable
filesystem, this is a problem: not being able to prove you don't know
something when someone thinks you do is hard, as many people in
Guantanamo might attest.

-- 
Mathematics is the supreme nostalgia of our time.


-- 
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] Hardware trojans, RNGs, and Syphermedia

2013-09-13 Thread Matt Mackall
This paper outlines simple changes that can be made to insert
vulnerabilities into silicon that are invisible to current
reverse-engineering techniques:

 http://people.umass.edu/gbecker/BeckerChes13.pdf

It uses Intel's random number generator as an example, detailing
precisely how it can be weakened such that it has predictable output yet
still appear perfectly random. This hack can be done by unobtrusive
changes to the production masks in the chip fabs.

One interesting note in the paper is that Intel has intentionally not
included the normal JTAG-style debugging interfaces on the RNG that
would allow you to spot this sort of tricker, ostensibly for security.
The trade-off here is attackers can't discreetly snoop on your RNG
internals by physically connecting to pins on your CPU (though they can
still snoop on everything else on your system including the RNG
_output_) vs no one can validate the RNG behavior. This choice seems
a little suspect.


Secondly, the company Syphermedia does this sort of silicon-level
trickery as a business:

 www.smi.tv/SMI_SypherMedia_Library_Intro.pdf‎

Their primary customers appear to be companies making set-top boxes, but
it would be interesting to investigate if they have any links to the
NSA.

-- 
Mathematics is the supreme nostalgia of our time.


-- 
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] iPhone5S Fingerprint and 5th amendment

2013-09-11 Thread Matt Mackall
On Wed, 2013-09-11 at 08:42 -0700, Peat Bakke wrote:
 Are there any reasons why fingerprint data couldn't be treated with the
 same concern as passwords? That is, subject to a one-way hash before being
 stored, transmitted in signed payloads, etc?

 I'm not sure how securing this data would be different than passwords --
 and given how much unique data can be generated from a fingerprint, it
 should be significantly better than John Doe's 8 character password.

Fingerprint matching (like just about anything analog) is not going to
be error or noise-free, and thus will have to work on something less
than a 100% perfect match. Thus, comparing cryptographic hashes of the
input with a stored hash won't work: any single bit change in the input
will completely change the hash.

Similarly, any other sort of one-way algorithm that prevents you from
reconstructing a valid input from the stored data is not going to work.

-- 
Mathematics is the supreme nostalgia of our time.


-- 
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 generator failure in Rasperri Pis?

2013-07-19 Thread Matt Mackall
On Fri, 2013-07-19 at 10:42 -0700, Andy Isaacson wrote:
 On Fri, Jul 19, 2013 at 01:17:51PM +0100, Michael Rogers wrote:
  On 19/07/13 13:03, KheOps wrote:
   Just came accross this article, apparently showing the bad quality
   of the hardware RNG in Raspberri Pi devices.
   
   http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/
  
Quite interesting since (pseudo-) random numbers are heavily used
   in crypto. Interesting also to see another post on this topic,
   after the study of a random number generation procedure formerly
   used in Cryptocat and that was also problematic.
  
  Is that what the article shows? Looks to me like the Raspberry Pi's
  hardware RNG (/dev/hwrng) is being held up as an example of 'good
  randomness' in contrast to the RANDU algorithm's 'bad randomness'.
 
 Regardless of the quality of the HW RNG on RPI, it's not good to expose
 the entropy directly to userspace in /dev/hwrng.  Rather, the RPI kernel
 should mix the entropy into the kernel entropy pool and apps should use
 /dev/random to get high-quality entropy mixed from all available entropy
 sources.  That way even if an attacker has a backdoor to the HW RNG,
 the user still has a second line of defense due to the other
 unpredictable data mixed into the same pool.

And there's a daemon for this:

apt-get install rng-tools

-- 
Mathematics is the supreme nostalgia of our time.


--
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] Heml.is - The Beautiful Secure Messenger

2013-07-11 Thread Matt Mackall
On Thu, 2013-07-11 at 13:47 -0700, Andy Isaacson wrote:
  Linux now also uses a closed RdRand [2] RNG if available.
 
 There was a bunch of churn when this code went in, so I could be wrong,
 but I believe that RdRand is only used to stir the same entropy pool as
 all of the other inputs which are used to generate random data for
 /dev/random et al.  It's hard to leverage control of one input to a
 random pool into anything useful.

It's worth noting that the maintainer of record (me) for the Linux RNG
quit the project about two years ago precisely because Linus decided to
include a patch from Intel to allow their unauditable RdRand to bypass
the entropy pool over my strenuous objections.

From a quick skim of current sources, much of that has recently been
rolled back (/dev/random, notably) but kernel-internal entropy users
like sequence numbers and address-space randomization appear to still be
exposed to raw RdRand output.

(And in the meantime, my distrust of Intel's crypto has moved from
standard professional paranoia to actual legitimate concern.)

-- 
Mathematics is the supreme nostalgia of our time.


--
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] How to defend against attacks on chips?

2013-06-16 Thread Matt Mackall
On Sun, 2013-06-16 at 11:54 +0200, Guido Witmond wrote:
 On 16-06-13 04:12, Waitman Gobble wrote:
  On Sat, 15 Jun 2013 17:19:14 -0500, Anthony Papillion
  anth...@cajuntechie.org  wrote:
 
  But how do we handle hardware attacks? For example, what happens when a
  chip maker, say Intel, collaborates with the government to allow access
  to users systems from the chip level? How can we defend against this?
 
 
 Unless it's tamper resistant hardware, there is always the electron 
 microscope to verify the chips itself. It's a big job but could be an 
 ongoing graduation project at a few universities in 
 China/Russia/Iran/Iraq. I bet they love to present the evidence of 
 tampering in an Intel processor.

Let's say we could fully automate the process of converting an an
electron microscope image of the 1B transistors on a recent Intel CPU
to about a billion lines of Verilog source code. Let's divide that by
a generous factor of 50 to account for a lot of this being highly
repetitive patterns like cache.

Now we simply have to audit 20 million lines of source code. Given that
we're hopelessly bad at auditing the millions of lines of source code we
already have, this seems like a doomed process. That's before we even
start to consider any of the ways that Intel could obfuscate the
process.

Bear in mind that Intel can't even fully verify their own designs,
despite having complete access to the design. This is how we get things
like the Pentium FDIV bug, which is only the most famous of the
thousands of bugs discovered in their CPUs. And yes, a bunch of those
bugs have been remotely-exploitable security holes:

https://encrypted.google.com/search?q=intel+cpu+security+errata


(One could argue that the NSA doesn't need Intel to backdoor their CPUs
because Intel is already doing that by accident on a regular basis.)

-- 
Mathematics is the supreme nostalgia of our time.


--
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] list reply-all

2013-03-20 Thread Matt Mackall
On Wed, 2013-03-20 at 18:02 +0200, Maxim Kammerer wrote:
  Isn't that a valid point?
 
 No, it's a useless imaginary construct. A valid point would be an
 example (preferably, more than one) of such an email on this list,
 where it would be possible to debate whether the person actually
 deserved losing his job / life for hastily sending said email.

Am I reading this correctly? You need to personally witness someone make
a potentially fatal mistake before you'll take a risk seriously? 

If you're unwilling to employ foresight as a decision-making aide, you
may not be taking full advantage of your prefrontal cortex.

-- 
Mathematics is the supreme nostalgia of our time.


--
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] list reply-all

2013-03-19 Thread Matt Mackall
On Tue, 2013-03-19 at 19:08 -0400, Joseph Lorenzo Hall wrote:
 Has the possibility of reconfiguring libtech to not reply-all by
 default been broached?

Reply-to-list poses a significant usability risk that can escalate into
a security issue, so it's unfortunate that it's being used here of all
places.

Let me relate a personal example from several years ago:

A: operational discussion on activist group list
B: Right on! ps: how's extremely embarassing private matter going?
B: Oh SH*#$#*T, I'm SO sorry, I didn't mean to reply-all!! I feel
horrible!!

It's quite easy to imagine extremely embarassing private matter being
replaced by career-ending aside on most lists, but on this one in
particular it might be replaced by potentially life-endangering datum.

Now compare this to the typical fall-out that happens without reply-to:

A: operational discussion on activist group list
B: public reply accidentally sent privately
B: Oops, sent that privately, sorry for the duplicate.

How many such minor inconveniences equal one job lost or life
endangered? In my opinion, no list should use reply-to-list.

-- 
Mathematics is the supreme nostalgia of our time.


--
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] Man-in-the-middle attack on GitHub in China

2013-01-30 Thread Matt Mackall
On Wed, 2013-01-30 at 13:15 -0600, Matt Mackall wrote:
 On Wed, 2013-01-30 at 09:55 -0800, x z wrote:
  @Nadim, I think breaking in a CA is a rather serious crime that GFW would
  refrain from committing;
 
 Unlike, say, breaking into the Tibetan government-in-exile, Google and
 hundreds of other companies?

From today's news:

https://www.nytimes.com/2013/01/31/technology/chinese-hackers-infiltrate-new-york-times-computers.html

-- 
Mathematics is the supreme nostalgia of our time.


--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech


Re: [liberationtech] Man-in-the-middle attack on GitHub in China

2013-01-30 Thread Matt Mackall
On Wed, 2013-01-30 at 23:30 -0800, x z wrote:
 2013/1/30 Matt Mackall m...@selenic.com
 
  On Wed, 2013-01-30 at 13:15 -0600, Matt Mackall wrote:
   On Wed, 2013-01-30 at 09:55 -0800, x z wrote:
@Nadim, I think breaking in a CA is a rather serious crime that GFW
  would
refrain from committing;
  
   Unlike, say, breaking into the Tibetan government-in-exile, Google and
   hundreds of other companies?
 
  From today's news:
 
 
  https://www.nytimes.com/2013/01/31/technology/chinese-hackers-infiltrate-new-york-times-computers.html
 
  Interesting. The following from this article is alarming:
 
 Security experts found evidence that the hackers stole the corporate
 passwords for every Times employee and used those to gain access to the
 personal computers of 53 employees, most of them outside The Times’s
 newsroom.
 
 Does Times store these passwords in plain text?

Probably not, but it no longer matters. The state of the art in password
cracking has massively improved in the past few years and most hashed,
salted passwords are no longer safe.

-- 
Mathematics is the supreme nostalgia of our time.


--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Travel with notebook habit

2012-12-27 Thread Matt Mackall
On Thu, 2012-12-27 at 23:56 +0100, Radek Pilar wrote:
 Full HDD encryption (including swap space and hibernate file) and
 powered down or hibernated (s2disk) machine is the only way to go.

Expect that if you're a target of state oppression that your laptop WILL
be taken away from you for hours at border crossings. This was a routine
occurrence for me between 2001 and 2006 or so. Fortunately for me, I
didn't warrant the big guns: the customs officers involved usually
reported their techs being completely thwarted/baffled by my Linux
screensaver.

However, it would be fairly straightforward to take apart a laptop,
install a hardware keylogger inside, and reassemble it in that sort of
timeframe, then recover your key and decrypt your laptop on your return
trip. So unless you have some sort of tamper-proof seals on your laptop,
you can't trust it once it leaves your physical possession.

Also note that encryption is NOT sufficient. Canadian customs officials
have demanded that I log in to my laptop so they could peruse my photo
collection (?!) as a condition of entering the country and/or being
released from customs. It's easy to imagine much more severe coercion if
the authorities are actually interested in your data. Not having a hard
disk is excellent defense against such coercive privacy invasions but
encryption is not. Since then, I've personally started keeping a dummy,
empty account on my laptop for basic deniability: nothing to see here
but my travel itinerary, can I go now?

But if the operational security or privacy of your laptop actually
matters and you must take a laptop, I have to agree with Jacob: don't
travel with your data. Same applies for cameras and phones.

-- 
Mathematics is the supreme nostalgia of our time.


--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech


Re: [liberationtech] Large amounts of spam

2012-10-31 Thread Matt Mackall
On Wed, 2012-10-31 at 18:39 -0400, Andrew Lewis wrote:
 Maybe someone is simply scrapping the archives for the sender address?

Scraping archives is passe. Most likely scenario:

- random subscriber's Windows box got owned by botnet malware
- malware scraped their disk for address books and credit card data
- malware began sending spam to people in said addressbooks for whoever
is renting the botnet

This is completely typical cybercrime behavior in 2012. And there's very
little that can be done about it.

-- 
Mathematics is the supreme nostalgia of our time.


--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech