Re: [liberationtech] WeChat

[Jerzy Łogiewa]

I can say with surely that WeChat has some market here in Poland.

Unfortunately I get a few invitation each week that I must decline.

--
Jerzy Łogiewa -- jerz...@interia.eu

On Jul 16, 2013, at 12:03 AM, Paul Holden wrote:

> I think part of it is a language problem. But even when the software is
> translated, as has been done with Wechat (微信)and Weibo, it doesn't
> seem to get far outside China. The Weibo English version is a completely
> different site and doesn't seem to have been marketed much in the west.
> I don't know why they made those choices. Based on what I've sen with
> WeChat, its largest markets outside China are Thailand and Malaysia.

--
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] Bring some UX/UI help to open secure apps

[Jerzy Łogiewa]

I believe that the attention of anyone would be some great help. This is also 
great direction.

How about it, kind of "Google Summer of Code" for UX students? Amazing idea.

--
Jerzy Łogiewa -- jerz...@interia.eu

On Jul 15, 2013, at 7:14 PM, Michael Oren wrote:

> I am a UX person (more heavily on the research end than the design end, 
> although I've done both). I'm not sure I can commit to working on this, but 
> I'm also teaching an HCI course in the Fall and can present something to the 
> students as an option for their projects. It's an introductory course though 
> so their skill levels will likely be low.
> 
> -Mike

--
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] WC3 and DRM

[Jonathan Wilkes]

On 07/15/2013 11:45 PM, Catherine Roy wrote:
As a member of the HTML working group and the Restricted Media 
community group, my experience is that discussions within these groups 
surrounding the EME draft have been extremely frustrating.  The same 
scenario as with Jeff Jaffe's blog post has happened there. The whole 
thing has been rather unreal and this recent post[1] from a Restricted 
Media mailing list member sums up my feelings about how futile the 
whole exercice has been.


A group of people have decided to try to build and maintain a profile 
of HTML5[2] that is more aligned to a human rights perspective. I know 
they could use some help so if anyone wants to lend a hand, it would 
certainly be appreciated.


Best regards,


Catherine

[1] 
http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Jul/0190.html

[2] http://freedomhtml.org/



Hi Catherine,
Thanks for the link!  I didn't know about that effort until now.

It seems like there are two fronts-- one, which you address by 
jettisoning EME in freedomhtml, and another which is to keep member 
organizations from standardizing software/hardware on EME.  Is there any 
way for the current members of all the working groups to put pressure on 
the WC3?  If they all banded together and threatened to leave would that 
have any effect on the administration?  It's only anecdotal evidence but 
I see a lot of articulate arguments against EME in the archives I've 
looked over, and no principled stances in favor.


Also, has the EFF's formal objection had any effect?

It's just all mind boggling to me because this draft is the only thing 
I've ever seen from WC3 with the sole purpose of restricting people's 
access to content.


Thanks,
Jonathan
--
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] [serval-project-dev] Re: Unique Opportunity: Input to CEOs of Smartphone Manufacturers

[Paul Gardner-Stephen]

Hello all,

Date: Fri, 12 Jul 2013 11:24:27 +0200

> From: Eduardo Robles Elvira 
> To: liberationtech 
> Subject: Re: [liberationtech] Unique Opportunity: Input to CEOs of
> Smartphone Manufacturers
> Reply-To: liberationtech 
>
> Hello:
>
> I'd like to see a mesh mode in the mobile phones. There are currently
> lots of mesh software initiatives, but I haven't seen any smartphone
> manufacturers support this. In the past, they were dependant of
> telecommunication companies to sell their phones, but now some
> companies are now starting to sell phones by themselves (Google for
> example). A mesh network mode would allow users to communicate even if
> there's no other conection, it can be useful to conect with peers in a
> demonstration or to transmit stream video to them in case police
> breaks your phone.
>

This is basically what we have been working towards with the Serval Project
(servalproject.org, developer.servalproject.org/wiki, igg.me/at/speakfreely),
with built-in end-to-end encryption, and fully distributed operation.

Disaster zones and isolated communities are our primary use cases.
 However, our one trial so far was actually for the kind of use you discuss
above, and showed that people communicated more, and spent less in the
process. It was used to get footage from a protest that ended up online
(see links in the report).  Encryption wasn't baked in at that time, but
now is.  Limited range is being addressed by the Mesh Extender (
igg.me/at/speakfreely). You can read the deployment report here:

http://developer.servalproject.org/dokuwiki/doku.php?id=content:publications:internews2010



> On Fri, Jul 12, 2013 at 1:11 AM, Blibbet  wrote:
> >> (1) A unique key built into each device, which can't be read directly
> >> by software, but which can be used to derive other keys (e.g. for disk
> >> encryption) at a limited rate, slowing down brute-force attacks
> >> against such keys.
>

We do this a different way with Serval, by having a master key that is the
private key from which the public network identifier of each node is
derived (the Serval ID or SID).  Network addresses are public keys, which
greatly simplifies a pile of things.

These keys can be, and are used to encrypt arbitrary files that can also be
replicated across the network.  This is actually how text messaging is
implemented on the Serval Mesh.


> >> (2) An effaceable area of flash storage where the operating system can
> >> store encryption keys for the entire disk and/or individual files,
> >> making it possible to securely delete the corresponding data without
> >> having to smash the device into tiny little pieces.


That would be really nice.  Knowing that it isn't likely to happen, our
solution is to never write any sensitive data to flash unless it is
encrypted.  Our keyring format doesn't even store your SID (the public key)
en claire - you must know the unlock PIN(s) to access it.

Provision has been made to erase sensitive identities when unlocking a
specially created disposable identity with a dedicated self-destruct pin.

While it doesn't guarantee erasure of the encrypted keyring block from the
flash, it does make it much harder to recover the deleted identity,
especially if long PINs (really they can be pass phrases) are used.

All this provides the basis for plausible deniability.


>
>
>> (3) A pony.
>

We considered it, but came to the conclusion that it would make the APK
file too large.  Also most modern mobile phones lack a hay chute, and lack
batteries denominated in mOh (milli-oat-hours).

Anyway, we encourage everyone to take a look at what we are doing, pick
holes in it so that we can make it better, and consider helping us to
spread the word for our crowd-funding campaign at igg.me/at/speakfreely

Thanks,

Paul.

> Presuming the smartphone is ARM-based, and presuming if (1) is applied,
> > it'll probably have ARM TrustZone installed, then:
> >
> > (4) Install a modern firmware on your smartphone, with useful security
> > features.
> >
> > (4a) Linux-based Coreboot. or
> >
> > (4b) UEFI.
> >
> > Use UEFI's SecureBoot feature, to enhance your Linux/Android/B2G/etc OS,
> > something none of your competitors are doing, except MS/Win8. To do so,
> you
> > need TPM on x86 or TrustZone on ARM, and you need to get your OS vendor
> to
> > sign the firmware, and not let MS Win8 hardware logo requirements confuse
> > you.
> >
> > Beyond the default TianoCore source, leverage Linaro's ARM-centric fork
> of
> > TianoCore, and Intel's MinnowBoard's UEFI which targets Linux
> > (Angstrom/Yocto), but neither of these Linux-centric UEFI targets support
> > the SecureBoot feature.
> >
> > Extend the current UEFI SecureBoot feature, which only targets 1 OS, to
> one
> > that lets you securely boot more-than-1 OS, for systems that want to
> > securely multiboot a handful of OSes (not necessarily installed, but
> later,
> > if your device is open, your user may opt to install another distro; your
> > job is to gather certs 

Re: [liberationtech] [cfabrigade] Mapping Sea Levels

[Alan McConchie]

Here are some maps of San Francisco only, made by local cartographers Brian 
Stokle and Burrito Justice.

http://urbanlifesigns.com/2012/03/when-floods-come-to-san-francisco.html
http://urbanlifesigns.blogspot.com/2012/12/the-streets-of-flooded-san-francisco.html
http://burritojustice.com/2012/03/20/san-francisco-archipelago/

Alan

On Jul 15, 2013, at 6:46 PM, Louis Suárez-Potts wrote:

> BTW, If you haven't read Kim Stanley Robinson, who has written
> extensively on the more or less immediate effects of the our climate
> catastrophe, you might find his work interesting, especially his
> latest.
> louis
> 
> On 15 July 2013 21:41, Louis Suárez-Potts  wrote:
>> And http://geology.com/sea-level-rise/san-francisco.shtml
>> 
>> On 15 July 2013 19:58, Rebekah Monson  wrote:
>>> Check out http://csc.noaa.gov/digitalcoast/tools/slrviewer
>>> 
>>> -r
>>> rebekahmonson.com
>>> 
>>> Q: Why is this email five sentences or less?
>>> A: http://five.sentenc.es
>>> 
>>> 
>>> On Mon, Jul 15, 2013 at 7:03 PM, Yosem Companys  wrote:
 
 Does anyone know of any maps that have been drawn up showing what the
 SF bay area coastline will look like as a result of global warming?
 Or do you know of anyone who might know the answer to this question?
 
 I'm looking for a map that changes contingent on the selected number
 of feet of higher sea level anticipated.
 
 Thanks,
 
 Yosem
 
 --
 
 You received this message because you are subscribed to the Google Groups
 "Brigade" group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to brigade+unsubscr...@codeforamerica.org.
 To post to this group, send email to brig...@codeforamerica.org.
 Visit this group at
 http://groups.google.com/a/codeforamerica.org/group/brigade/.
 For more options, visit
 https://groups.google.com/a/codeforamerica.org/groups/opt_out.
 
 
>>> 
>>> 
>>> --
>>> 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
>> 
>> 
>> 
>> --
>> 
>> Louis Suárez-Potts
>> Skype: louisiam
>> @luispo
>> GStuff: luispo[at]gmail.com
> 
> 
> 
> -- 
> 
> Louis Suárez-Potts
> Skype: louisiam
> @luispo
> GStuff: luispo[at]gmail.com
> --
> 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

--
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] WC3 and DRM

[Catherine Roy]

As a member of the HTML working group and the Restricted Media community 
group, my experience is that discussions within these groups surrounding 
the EME draft have been extremely frustrating.  The same scenario as 
with Jeff Jaffe's blog post has happened there. The whole thing has been 
rather unreal and this recent post[1] from a Restricted Media mailing 
list member sums up my feelings about how futile the whole exercice has 
been.


A group of people have decided to try to build and maintain a profile of 
HTML5[2] that is more aligned to a human rights perspective. I know they 
could use some help so if anyone wants to lend a hand, it would 
certainly be appreciated.


Best regards,


Catherine

[1] 
http://lists.w3.org/Archives/Public/public-restrictedmedia/2013Jul/0190.html

[2] http://freedomhtml.org/

--
Catherine Roy
http://www.catherine-roy.net




On 2013-07-13 23:13, Jonathan Wilkes wrote:

Hi List,
 Looking at the enormous list of members in the WC3 along with the 
fact that application membership is subject to final arbitrary 
approval by the current WC3, I'm concerned about the lack of 
democratic checks on their decision making.


Example with Encrypted Media Extensions draft:

Here's a Free Software Foundation page briefly describing the problem 
and stating that 28,000 people signed on that they want to reject 
Encrypted Media Extensions as a web standard:

http://www.defectivebydesign.org/no-drm-in-html5

Here's the Electronic Frontier Foundation's formal objection to the 
HTML Working Group Charter that explains the problem in detail:

https://www.eff.org/pages/drm/w3c-formal-objection-html-wg

And, perhaps most revealingly, here's a blog entry about 
"perspectives" on the issue from Jeffrey Jaffe, former CTO of Novell 
and current CEO of the WC3:

http://www.w3.org/QA/2013/05/perspectives_on_encrypted_medi.html

The comments to that blog are instructive, not just because they 
overwhelmingly make articulate arguments against the inclusion of EME 
into WC3 standards, but because every single reply by Jaffe is 
predicated upon the premise that the Working Group Charter refered to 
by the EFF has already been decided and is clearly not part of the 
debate.  (Notice for example how many of his responses simply turn the 
question back to the commenter asking them what their proposal is to 
support playback of "protected content" over the web.)


Whether you agree with me (and 28,000 who signed the FSF's petition) 
or not, there is clearly a problem of public accountability with a 
public standards body here.  Unlike the anti-SOPA/PIPA campaign, there 
are no politicians worried about reelection who can be called and 
emailed.  It's a small staff supported by member companies who 
obviously want to see DRM standardized into the browser-- otherwise 
that wording wouldn't have found its way into the charter.


Are there actions planned further than what the EFF and FSF have 
already taken?  I know this is a "tech" list, but the problem of how 
standards get formed isn't going to go away any time soon, and there 
should be a sustainable way to ensure that the WC3 is responsive to 
the users and not just its funders.


-Jonathan
--
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



--
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] [cfabrigade] Mapping Sea Levels

[Louis Suárez-Potts]

BTW, If you haven't read Kim Stanley Robinson, who has written
extensively on the more or less immediate effects of the our climate
catastrophe, you might find his work interesting, especially his
latest.
louis

On 15 July 2013 21:41, Louis Suárez-Potts  wrote:
> And http://geology.com/sea-level-rise/san-francisco.shtml
>
> On 15 July 2013 19:58, Rebekah Monson  wrote:
>> Check out http://csc.noaa.gov/digitalcoast/tools/slrviewer
>>
>> -r
>> rebekahmonson.com
>> 
>> Q: Why is this email five sentences or less?
>> A: http://five.sentenc.es
>>
>>
>> On Mon, Jul 15, 2013 at 7:03 PM, Yosem Companys  wrote:
>>>
>>> Does anyone know of any maps that have been drawn up showing what the
>>> SF bay area coastline will look like as a result of global warming?
>>> Or do you know of anyone who might know the answer to this question?
>>>
>>> I'm looking for a map that changes contingent on the selected number
>>> of feet of higher sea level anticipated.
>>>
>>> Thanks,
>>>
>>> Yosem
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "Brigade" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to brigade+unsubscr...@codeforamerica.org.
>>> To post to this group, send email to brig...@codeforamerica.org.
>>> Visit this group at
>>> http://groups.google.com/a/codeforamerica.org/group/brigade/.
>>> For more options, visit
>>> https://groups.google.com/a/codeforamerica.org/groups/opt_out.
>>>
>>>
>>
>>
>> --
>> 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
>
>
>
> --
>
> Louis Suárez-Potts
> Skype: louisiam
> @luispo
> GStuff: luispo[at]gmail.com



-- 

Louis Suárez-Potts
Skype: louisiam
@luispo
GStuff: luispo[at]gmail.com
--
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] [cfabrigade] Mapping Sea Levels

[Louis Suárez-Potts]

And http://geology.com/sea-level-rise/san-francisco.shtml

On 15 July 2013 19:58, Rebekah Monson  wrote:
> Check out http://csc.noaa.gov/digitalcoast/tools/slrviewer
>
> -r
> rebekahmonson.com
> 
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
>
> On Mon, Jul 15, 2013 at 7:03 PM, Yosem Companys  wrote:
>>
>> Does anyone know of any maps that have been drawn up showing what the
>> SF bay area coastline will look like as a result of global warming?
>> Or do you know of anyone who might know the answer to this question?
>>
>> I'm looking for a map that changes contingent on the selected number
>> of feet of higher sea level anticipated.
>>
>> Thanks,
>>
>> Yosem
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Brigade" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to brigade+unsubscr...@codeforamerica.org.
>> To post to this group, send email to brig...@codeforamerica.org.
>> Visit this group at
>> http://groups.google.com/a/codeforamerica.org/group/brigade/.
>> For more options, visit
>> https://groups.google.com/a/codeforamerica.org/groups/opt_out.
>>
>>
>
>
> --
> 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



-- 

Louis Suárez-Potts
Skype: louisiam
@luispo
GStuff: luispo[at]gmail.com
--
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] [cfabrigade] Mapping Sea Levels

[Rebekah Monson]

Check out http://csc.noaa.gov/digitalcoast/tools/slrviewer

-r
rebekahmonson.com

Q: Why is this email five sentences or less?
A: http://five.sentenc.es


On Mon, Jul 15, 2013 at 7:03 PM, Yosem Companys  wrote:

> Does anyone know of any maps that have been drawn up showing what the
> SF bay area coastline will look like as a result of global warming?
> Or do you know of anyone who might know the answer to this question?
>
> I'm looking for a map that changes contingent on the selected number
> of feet of higher sea level anticipated.
>
> Thanks,
>
> Yosem
>
> --
> You received this message because you are subscribed to the Google Groups
> "Brigade" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to brigade+unsubscr...@codeforamerica.org.
> To post to this group, send email to brig...@codeforamerica.org.
> Visit this group at
> http://groups.google.com/a/codeforamerica.org/group/brigade/.
> For more options, visit
> https://groups.google.com/a/codeforamerica.org/groups/opt_out.
>
>
>
--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Nathan of Guardian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/15/2013 05:55 PM, Pavol Luptak wrote:
> Any idea how to have offline secure messaging (when Jabber+OTR is
> not possible to use)?

Gibberbot already partially implements this, and we are working with
ChatSecure and others to move forward with a standards-based solution
to this. While we already have OpenPGP support on Android, we don't
think PGP is the way to go for efficient mobile chat, and also are not
ready to abandon forward secrecy as a feature.

And so, our OTR offline solution is comprised of the following pieces:

1) Client/App supports XMPP extension for message delivery receipts
and auto-retry:
http://xmpp.org/extensions/xep-0184.html

While the person you are trying to send a message to may be offline at
the very moment you want to message them, it is very likely that they
will be online at some point in the near future. If your chat client
is always running in the background on your device, it can sense when
they come online, and deliver the message you wrote earlier. By
supporting delivery receipts, you can confirm it did indeed get
through to them, and if not, continue auto-retrying until it does.

2) XMPP server that supports offline messages storage and delivery:
http://xmpp.org/extensions/xep-0160.html
http://xmpp.org/extensions/xep-0091.html
ejabberd support: http://www.process-one.net/en/ejabberd/protocols/
http://prosody.im/doc/modules/mod_offline

XMPP already has a well-established mechanism for this, and many
open-source servers like ejabberd and prosody support it well.

3) Client that supports long-lived OTR sessions. If a chat
conversation is held open, then the same OTR session key should be
used as long as possible, i.e. until one of the participants request a
session restart.

4) Optionally: use the OTR v3 shared "extra" symmetric key generation
feature to encrypt offline messages and send those via a mobile push
service.

Would love comments on this. Anything else we might have missed?

+n


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5I2eAAoJEKgBGD5ps3qpXSsP/2Bd1R7fw4C2LeGM3RAZuFup
Jhd/YIBt4I7Yh4tIGGs2Bn7B3gCGmDXRTnqWPtj8IpE/XINB0Pr4gME0kC/xV0Kf
dFotFwps3WkihJXaR2IeK4FmDoLX4xVETqiFFwZSE4FM2zNJiVPsXIDzeIXKp//9
HSU/Rhv4y/ycSPONqC0Wy6x+0TOM6arcTGmg9noDbnBWIGxbOEU9jKSpJhzDHSz7
79rMorer7KS1p88zJ+tMoprdwGqtf0wEZacwgIOKcZRUPxWveqUPcANOyGfi40u4
11vvbwVBj0hETTCWDtxFOO61JTLGWiqlVNd6bsPICr08cfe42s6hJEMnay00tWaJ
ovcw4MCAHP/c9sWqy5KSufa04NIMlON5g83cQRGevqnEMJYDHHlrLyFTHO8M+ZY+
CF6wmiGJIHQyet6xxjPZH97vk+tPC6eTnoLFiNxS2SlAJYmQxmcAtqvFO+HLDBNM
wOosJ0TjA3gmDwU6udhpPbe/BBigemnFedRahta1PbRVgl/1oDwH8ecwoj9xTWtq
O/LmJbiAkqCf4YnFq+1sbyTXvRw9MBdXXJUc3vClbxmGQ6xZjMAZKnOVpbKeSmSd
v73UVvtNXsV4XfVOICbRS84dakxA3YG9P+T37un82r0tyDJUB7DXe2HZwiGHQ58T
YJUO0epUFqDfidtrWyJf
=7SnB
-END PGP SIGNATURE-
--
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] [geoweb-r] Mapping Sea Levels

[Eric Wolf]

http://cegis.usgs.gov/sea_level_rise.html
-=--=---===---=--=-=--=---==---=--=-=-
Eric B. Wolf   720-334-7734




On Mon, Jul 15, 2013 at 5:03 PM, Yosem Companys  wrote:

> Does anyone know of any maps that have been drawn up showing what the
> SF bay area coastline will look like as a result of global warming?
> Or do you know of anyone who might know the answer to this question?
>
> I'm looking for a map that changes contingent on the selected number
> of feet of higher sea level anticipated.
>
> Thanks,
>
> Yosem
>
> --
> You received this message because you are subscribed to the Google Groups
> "geoweb-r" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to geoweb-r+unsubscr...@googlegroups.com.
> To post to this group, send email to geowe...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/geoweb-r/CANhci9F9it8GFq7DFzpmXGZBdqY9DQw2mc3T0jFr0KMDivdtNw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
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] [cfabrigade] Mapping Sea Levels

[David Riordan]

I can think of a few examples, notably Surging Seas (
http://sealevel.climatecentral.org) and this sweet NYT interactive (
http://www.nytimes.com/interactive/2012/11/24/opinion/sunday/what-could-disappear.html
)


On Mon, Jul 15, 2013 at 7:03 PM, Yosem Companys  wrote:

> Does anyone know of any maps that have been drawn up showing what the
> SF bay area coastline will look like as a result of global warming?
> Or do you know of anyone who might know the answer to this question?
>
> I'm looking for a map that changes contingent on the selected number
> of feet of higher sea level anticipated.
>
> Thanks,
>
> Yosem
>
> --
> You received this message because you are subscribed to the Google Groups
> "Brigade" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to brigade+unsubscr...@codeforamerica.org.
> To post to this group, send email to brig...@codeforamerica.org.
> Visit this group at
> http://groups.google.com/a/codeforamerica.org/group/brigade/.
> For more options, visit
> https://groups.google.com/a/codeforamerica.org/groups/opt_out.
>
>
>


-- 
David W. Riordan
--
mobile: 203.521.1222 | im: daveriordan | email: david.rior...@gmail.com |
@riordan  | http://magicschoolb.us
--
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

[liberationtech] Mapping Sea Levels

[Yosem Companys]

Does anyone know of any maps that have been drawn up showing what the
SF bay area coastline will look like as a result of global warming?
Or do you know of anyone who might know the answer to this question?

I'm looking for a map that changes contingent on the selected number
of feet of higher sea level anticipated.

Thanks,

Yosem
--
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] WeChat

[Paul Holden]

On 13-07-14 23:29:03, Sarah Lai Stirland 
wrote:
> Thanks. This is the kind of discussion and back and forth I was looking for
> ... I kind of figured this was the case, although I don't know of any
> actual examples of any of this happening. I know a lot of Chinese people

From what I understand one of the reasons the Chinese government doesn't
allow twitter or Facebook in China is because they can't get physical
access to the servers. QQ, renren (人人网) and Weibo (微博) are social
networking services equivalent to FB and twitter, and the Chinese
government has no problem with them.

Partly based on that, as well as other factors, I think it's safe to
assume that the PSB has direct access to these companies' facilities and
does whatever it wants with the data, including complete social graph
analysis. I'd be surprised if the things Nathan suggested, are not
actually happening in China.

> use it, and I think it's interesting why it's so popular with the Chinese,
> and not so much in the US. When I say the American, I mean something made

This is interesting. There's a lot going on in the domestic software
industry in China that never gets noticed outside. Whether it's word
processors, browsers or social networking services, it's all being
produced domestically in China, but rarely seems to make it outside.

I think part of it is a language problem. But even when the software is
translated, as has been done with Wechat (微信)and Weibo, it doesn't
seem to get far outside China. The Weibo English version is a completely
different site and doesn't seem to have been marketed much in the west.
I don't know why they made those choices. Based on what I've sen with
WeChat, its largest markets outside China are Thailand and Malaysia.

WeChat is an easy jump from QQ, since you can use the same credentials
(if you want). But it's a completely separate set of contacts and so a
different social network. It's mobile only, there is no website.

In my experience with WeChat, most people use it for 1-1 communication,
including sharing photos. They also post photos and links on their
"moments" (ie, wall) and their friends either comment on or like these.
It has limited social networking capability compared to QQ or FB, but it
might be that this subset of features is just what people want on a
mobile phone app. I think the proximity search for friends and the
"shake" feature are probably quite attractive ones.

I've found that I use WeChat a lot more now than I ever used the QQ
mobile app, or the QQ website. I have several Chinese friends inside and
outside China whom I keep in touch with via WeChat. I've rarely met
anyone who's not from China who uses WeChat (or QQ for that matter) or
even knows what it is.

Paul
--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Pavol Luptak]

But there is a strong disadvantage of Jabber+OTR compared to Threema (and
probably Heml.is):

Jabber+OTR needs a running client on both sides (two-way interactive 
communication) -> offline messages are not supported by Jabber+OTR
( offline messages are supported by XMPP, but not with OTR ).

But Jabber+PGP works for offline messages (I use it in my mcabber), but 
PGP is probably not supported by these smartphone jabber clients :(

Any idea how to have offline secure messaging (when Jabber+OTR is not possible
to use)? (this is probably the reason why Heml.is would use XMPP + PGP instead
of OTR).

Pavol

On Mon, Jul 15, 2013 at 02:04:34PM -0700, Parker Higgins wrote:
> On 7/15/13 2:00 PM, Pavol Luptak wrote:
> > Of course, I can use Jabber+OTR, but I think there is even no
> > opensource alternative of Jabber+OTR client on iOS platform yet.
> 
> There is ChatSecure: http://chrisballinger.info/apps/chatsecure/
> 
> Thanks,
> Parker
> 
> > On Mon, Jul 15, 2013 at 12:41:45PM +0200, Moritz Bartl wrote:
> >> Surespot looks like an open source alternative:
> >> 
> >> https://www.surespot.me/ 
> >> https://www.surespot.me/documents/how_surespot_works.html
> >> 
> >> technical overview
> >> 
> >> User creation- When a user is created in surespot two ECC
> >> (secp521) key pairs are generated, one for key derivation, and
> >> one for signing.
> >> 
> >> The username plus keypairs create a 'surespot identity'. This
> >> identity is stored on the device symmetrically encrypted using
> >> 256 bit AES-GCM with a PKCS5S2 key derived from the user's
> >> password (plus salt and other data). The public keys are uploaded
> >> to the server where they are signed by the server using the
> >> server's private key. A user may create multiple identities and
> >> switch between them at will.
> >> 
> >> User authentication- To login the client generates a signature
> >> using the identity's private signing key against the username,
> >> password, and randomly generated data. The server validates the
> >> client provided username, password, and aforementioned signature
> >> against its stored public signing key for the identity in
> >> question. If successfully verified the client is issued a session
> >> cookie which authenticates them for future requests until the
> >> session expires or they logout.
> >> 
> >> As the exchange occurs over SSL, session cookies are thought to
> >> be a secure enough mechanism to facilitate authentication, but in
> >> the future every request could be validated against the
> >> signature. The fact that messages could not be decrypted by a
> >> session hijacker given the end to end encryption nature of the
> >> system also factors into this decision.
> >> 
> >> Identity backup/restore- As the private key stored on the device
> >> is the, uh key, to unlocking all of the data, it is of utmost
> >> importance. In the case of a lost or stolen device, if the key is
> >> lost along with it, so is all of the data. Identity
> >> backup/restore and key versioning help to mitigate this problem.
> >> A user may backup their (encrypted) identities (username and key
> >> pair history) to device storage, or the cloud and restore them
> >> upon demand. Obviously the security is only as strong as the
> >> password used to store the identity in whatever cloud service
> >> and the surespot password, so make them strong! Never shall a
> >> private key be stored on a surespot server.
> >> 
> >> Man in the middle- MITM is currently thwarted by the following: 
> >> standard SSL implementation. When a user is created and its
> >> public keys uploaded to the server, the server signs the public
> >> keys. Clients that download the public key then validate the
> >> signature of the key against the hardcoded server public key in
> >> the client. This ensures a MITM attack trying to use a rogue key 
> >> pair to impersonate a user will be prevented.
> >> 
> >> Key versioning/revoking- A user may generate a new pair of key
> >> pairs at any time. This process is as follows: the user requests
> >> a ?key token? from the server the user generates a new pair of
> >> key pairs and uploads them to the server along with an
> >> authentication signature (username, password, random) and a token
> >> signature (the received key token, password) generated by the
> >> identity's existing signing private key. the server validates the
> >> password and both signatures and if valid increments the ?key
> >> version? and signs and stores the public keys in the database. 
> >> the server notifies other users involved in conversations with
> >> the revoker that the key has been revoked. clients will receive
> >> this revoke notification and act accordingly. the old keys are
> >> now considered revoked and any message sent using them will be
> >> rejected by the server.
> >> 
> >> Use case: lost/stolen phone- adam lost his phone, luckily he has
> >> his identities backed up on Google drive adam buys a new phone
> >> and installs surespot adam 

Re: [liberationtech] Conference proceedings: E-Voting and Identify

[Ben Laurie]

Why would I want to give Springer money for their old rope?

On 15 July 2013 17:34, Yosem Companys  wrote:
> E-Voting and Identify
> 4th International Conference, Vote-ID 2013, Guildford, UK, July 17-19,
> 2013. Proceedings
> http://link.springer.com/book/10.1007/978-3-642-39185-9/page/1
> --
> 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
--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Karl Fogel]

Moritz Bartl  writes:
>Surespot looks like an open source alternative:
>
>https://www.surespot.me/
>https://www.surespot.me/documents/how_surespot_works.html

surespot's code may be excellent (I haven't looked at it), but their
front page at https://surespot.me/ makes a promise it shouldn't make:

  | You can delete your message from the receivers phone.
  | 
  | Be confident sending private information and pictures.  You have
  | control over your messages, when you delete a sent message it will
  | be removed from the receivers phone and images are not sharable
  | unless you make them so.

Software can't be simultaneously open source on the client side and make
promises about how the client side will behave.  Actually, one can't
really make that commitment even when the client side is closed-source
(for example, if a closed-source app runs on an open source OS, then
when the app tries to delete the message, the OS can retain a copy).
But anyway, the loophole is even easier to exploit when the application
code itself is open source.

Surespot is just one of several apps making such claims.  I wrote a bit
of a rant about this trend here:

  http://www.rants.org/2013/06/09/privacy-promises-and-client-side-betrayal/

Again, this is not about their code, which may be fantastic.  It's just
about their marketing language around the code.

Best,
-Karl

>technical overview
>
>User creation- When a user is created in surespot two ECC (secp521) key
>pairs are generated, one for key derivation, and one for signing.
>
>The username plus keypairs create a 'surespot identity'. This identity
>is stored on the device symmetrically encrypted using 256 bit AES-GCM
>with a PKCS5S2 key derived from the user's password (plus salt and other
>data). The public keys are uploaded to the server where they are signed
>by the server using the server's private key. A user may create multiple
>identities and switch between them at will.
>
>User authentication- To login the client generates a signature using the
>identity's private signing key against the username, password, and
>randomly generated data. The server validates the client provided
>username, password, and aforementioned signature against its stored
>public signing key for the identity in question. If successfully
>verified the client is issued a session cookie which authenticates them
>for future requests until the session expires or they logout.
>
>As the exchange occurs over SSL, session cookies are thought to be a
>secure enough mechanism to facilitate authentication, but in the future
>every request could be validated against the signature. The fact that
>messages could not be decrypted by a session hijacker given the end to
>end encryption nature of the system also factors into this decision.
>
>Identity backup/restore- As the private key stored on the device is the,
>uh key, to unlocking all of the data, it is of utmost importance. In the
>case of a lost or stolen device, if the key is lost along with it, so is
>all of the data. Identity backup/restore and key versioning help to
>mitigate this problem. A user may backup their (encrypted) identities
>(username and key pair history) to device storage, or the cloud and
>restore them upon demand. Obviously the security is only as strong as
>the password used to store the identity in whatever cloud service and
>the surespot password, so make them strong! Never shall a private key be
>stored on a surespot server.
>
>Man in the middle- MITM is currently thwarted by the following:
>standard SSL implementation.
>When a user is created and its public keys uploaded to the server, the
>server signs the public keys. Clients that download the public key then
>validate the signature of the key against the hardcoded server public
>key in the client. This ensures a MITM attack trying to use a rogue key
>pair to impersonate a user will be prevented.
>
>Key versioning/revoking- A user may generate a new pair of key pairs at
>any time. This process is as follows:
>the user requests a “key token” from the server
>the user generates a new pair of key pairs and uploads them to the
>server along with an authentication signature (username, password,
>random) and a token signature (the received key token, password)
>generated by the identity's existing signing private key.
>the server validates the password and both signatures and if valid
>increments the “key version” and signs and stores the public keys in the
>database.
>the server notifies other users involved in conversations with the
>revoker that the key has been revoked.
>clients will receive this revoke notification and act accordingly.
>the old keys are now considered revoked and any message sent using them
>will be rejected by the server.
>
>Use case: lost/stolen phone-
>adam lost his phone, luckily he has his identities backed up on Google drive
>adam buys a new phone and installs surespot
>adam restores his identities from the backup
>adam generates a new pair of key pairs succ

[liberationtech] Autocorrect metadata

[Mike H. Miller]

What kind of metadata is harvestable from common autocorrect functions of 
devices and applications?  Is there much literature on this?

Miller
--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Tony Arcieri]

They seem to have an... interesting philosophy about open source:

"When you have an entire planet looking at the source code you can be
assured that the implementation is highly scrutinized and proven."

Apparently all you have to do is put your source code online and it will
magically be highly scrutinized and proven

On Mon, Jul 15, 2013 at 3:41 AM, Moritz Bartl  wrote:

> Surespot looks like an open source alternative:
>
> https://www.surespot.me/
> https://www.surespot.me/documents/how_surespot_works.html
--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Pavol Luptak]

Thanks guys for info!

Pavol

On Mon, Jul 15, 2013 at 05:04:25PM -0400, Nathan of Guardian wrote:
> On 07/15/2013 05:00 PM, Pavol Luptak wrote:
> > Of course, I can use Jabber+OTR, but I think there is even no
> > opensource alternative of Jabber+OTR client on iOS platform yet.
> 
> ChatSecure!
> chatsecure.org
> https://github.com/ChatSecure
> https://github.com/chrisballinger/Off-the-Record-iOS
> 
> Fully interoperable XMPP and OTR.
> 
> It does have its limitations (i.e. iOS limits background apps
> capabilities), but it is getting better all the time.
> 
> +n
> --
> 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

-- 
__
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]
--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Nathan of Guardian]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/15/2013 05:00 PM, Pavol Luptak wrote:
> Of course, I can use Jabber+OTR, but I think there is even no
> opensource alternative of Jabber+OTR client on iOS platform yet.

ChatSecure!
chatsecure.org
https://github.com/ChatSecure
https://github.com/chrisballinger/Off-the-Record-iOS

Fully interoperable XMPP and OTR.

It does have its limitations (i.e. iOS limits background apps
capabilities), but it is getting better all the time.

+n
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5GPZAAoJEKgBGD5ps3qplzMQAIIYJnssfduB+30HtZguo2rF
9GpqCbnsuo2TQBE+Nu8Wun2IOiCgRPBZY4pWs8p9XvsBoaV/Oc/rHAGWK8hWaTmk
4H0CxVT2Ig106MlUfbjmMusjdubs5r+49CLjD/ogspL/8vZbQfuVVE3yvfW+01MO
ymHC5Q9RjZeP29KDmF9ITfjvKj93UyAfgSMSLua5dbC1/NCaLhDQNHBVMrSscFTy
pbeMz2tDyjbGmGIzqIwdYMdZAI+ja900TMXTTBZYW5ozpApgyK4NC0ibOQHX/oHD
Z7sxE2TBg7mC1xCQR7SaV+JrRjoHQeW5G725QlEPjB+KrioeVf61Hs3jm2DLRDD8
ux8NxtapMi2ZxWJsyc2hIKqOk9UMHpCfva1Dnd5WLm48RCFxaGkgXOo8vflWJSvr
JRaiIHX40twUcbAFQZGM6czQk5GokkdLrvbLZ0DR+rg3qz0SpLSrhLHxYHyCnd0x
Ps9LltYL6XbddhLkPMOlXWu+TDntE2JWKZ07bn1U0kqBGBgdI7gd4NGYWce8SjAp
bg4DgE/o1k4C/myTDCJeHQW6d6oiFVVfJQcNcQY8VPYXc+RJdQsqeuYW1vouoC9v
YOB6UguRGEa5yAXlkELA8i0kMnJ1c6oRq19jgaTWTLMBf2/SoftyAS5ywGcaR8zW
IOnZWYcJSvqD/vgN4St2
=kZWQ
-END PGP SIGNATURE-
--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Parker Higgins]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/15/13 2:00 PM, Pavol Luptak wrote:
> Of course, I can use Jabber+OTR, but I think there is even no
> opensource alternative of Jabber+OTR client on iOS platform yet.

There is ChatSecure: http://chrisballinger.info/apps/chatsecure/

Thanks,
Parker

> On Mon, Jul 15, 2013 at 12:41:45PM +0200, Moritz Bartl wrote:
>> Surespot looks like an open source alternative:
>> 
>> https://www.surespot.me/ 
>> https://www.surespot.me/documents/how_surespot_works.html
>> 
>> technical overview
>> 
>> User creation- When a user is created in surespot two ECC
>> (secp521) key pairs are generated, one for key derivation, and
>> one for signing.
>> 
>> The username plus keypairs create a 'surespot identity'. This
>> identity is stored on the device symmetrically encrypted using
>> 256 bit AES-GCM with a PKCS5S2 key derived from the user's
>> password (plus salt and other data). The public keys are uploaded
>> to the server where they are signed by the server using the
>> server's private key. A user may create multiple identities and
>> switch between them at will.
>> 
>> User authentication- To login the client generates a signature
>> using the identity's private signing key against the username,
>> password, and randomly generated data. The server validates the
>> client provided username, password, and aforementioned signature
>> against its stored public signing key for the identity in
>> question. If successfully verified the client is issued a session
>> cookie which authenticates them for future requests until the
>> session expires or they logout.
>> 
>> As the exchange occurs over SSL, session cookies are thought to
>> be a secure enough mechanism to facilitate authentication, but in
>> the future every request could be validated against the
>> signature. The fact that messages could not be decrypted by a
>> session hijacker given the end to end encryption nature of the
>> system also factors into this decision.
>> 
>> Identity backup/restore- As the private key stored on the device
>> is the, uh key, to unlocking all of the data, it is of utmost
>> importance. In the case of a lost or stolen device, if the key is
>> lost along with it, so is all of the data. Identity
>> backup/restore and key versioning help to mitigate this problem.
>> A user may backup their (encrypted) identities (username and key
>> pair history) to device storage, or the cloud and restore them
>> upon demand. Obviously the security is only as strong as the
>> password used to store the identity in whatever cloud service
>> and the surespot password, so make them strong! Never shall a
>> private key be stored on a surespot server.
>> 
>> Man in the middle- MITM is currently thwarted by the following: 
>> standard SSL implementation. When a user is created and its
>> public keys uploaded to the server, the server signs the public
>> keys. Clients that download the public key then validate the
>> signature of the key against the hardcoded server public key in
>> the client. This ensures a MITM attack trying to use a rogue key 
>> pair to impersonate a user will be prevented.
>> 
>> Key versioning/revoking- A user may generate a new pair of key
>> pairs at any time. This process is as follows: the user requests
>> a ?key token? from the server the user generates a new pair of
>> key pairs and uploads them to the server along with an
>> authentication signature (username, password, random) and a token
>> signature (the received key token, password) generated by the
>> identity's existing signing private key. the server validates the
>> password and both signatures and if valid increments the ?key
>> version? and signs and stores the public keys in the database. 
>> the server notifies other users involved in conversations with
>> the revoker that the key has been revoked. clients will receive
>> this revoke notification and act accordingly. the old keys are
>> now considered revoked and any message sent using them will be
>> rejected by the server.
>> 
>> Use case: lost/stolen phone- adam lost his phone, luckily he has
>> his identities backed up on Google drive adam buys a new phone
>> and installs surespot adam restores his identities from the
>> backup adam generates a new pair of key pairs successfully 
>> attacker with old phone receives revoke message old phone knows
>> revoke message is from the same user and promptly logs out and
>> deletes any related data any subsequent authentication attempts
>> on old phone will be rejected
>> 
>> Sending a message- After two users invite then accept each other
>> the users are now friends, the two friends can access each
>> other's public keys, which allows key derivation and message
>> exchange. The scenario plays out as follows at a high level
>> glance: adam wants to send cherie a message adam asks the server
>> for the latest version of cherie's public key adam verifies
>> cherie's public key (which is signed by the server) against the
>> hard co

Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Pavol Luptak]

I like Surespot (and also TextSecure), but it runs on Android platform only.

If I want to communicate with iPhone users in a secure way, I am forced to 
use Threema which is available on both platforms (iOS and Android).

Is there any multiplatform opensource end-to-end secure alternative? 
(instead of Threema)?

Of course, I can use Jabber+OTR, but I think there is even no opensource 
alternative of Jabber+OTR client on iOS platform yet.

I would not care about iOS (I use Android), but many my friends have iPhone.

Pavol

On Mon, Jul 15, 2013 at 12:41:45PM +0200, Moritz Bartl wrote:
> Surespot looks like an open source alternative:
> 
> https://www.surespot.me/
> https://www.surespot.me/documents/how_surespot_works.html
> 
> technical overview
> 
> User creation- When a user is created in surespot two ECC (secp521) key
> pairs are generated, one for key derivation, and one for signing.
> 
> The username plus keypairs create a 'surespot identity'. This identity
> is stored on the device symmetrically encrypted using 256 bit AES-GCM
> with a PKCS5S2 key derived from the user's password (plus salt and other
> data). The public keys are uploaded to the server where they are signed
> by the server using the server's private key. A user may create multiple
> identities and switch between them at will.
> 
> User authentication- To login the client generates a signature using the
> identity's private signing key against the username, password, and
> randomly generated data. The server validates the client provided
> username, password, and aforementioned signature against its stored
> public signing key for the identity in question. If successfully
> verified the client is issued a session cookie which authenticates them
> for future requests until the session expires or they logout.
> 
> As the exchange occurs over SSL, session cookies are thought to be a
> secure enough mechanism to facilitate authentication, but in the future
> every request could be validated against the signature. The fact that
> messages could not be decrypted by a session hijacker given the end to
> end encryption nature of the system also factors into this decision.
> 
> Identity backup/restore- As the private key stored on the device is the,
> uh key, to unlocking all of the data, it is of utmost importance. In the
> case of a lost or stolen device, if the key is lost along with it, so is
> all of the data. Identity backup/restore and key versioning help to
> mitigate this problem. A user may backup their (encrypted) identities
> (username and key pair history) to device storage, or the cloud and
> restore them upon demand. Obviously the security is only as strong as
> the password used to store the identity in whatever cloud service and
> the surespot password, so make them strong! Never shall a private key be
> stored on a surespot server.
> 
> Man in the middle- MITM is currently thwarted by the following:
> standard SSL implementation.
> When a user is created and its public keys uploaded to the server, the
> server signs the public keys. Clients that download the public key then
> validate the signature of the key against the hardcoded server public
> key in the client. This ensures a MITM attack trying to use a rogue key
> pair to impersonate a user will be prevented.
> 
> Key versioning/revoking- A user may generate a new pair of key pairs at
> any time. This process is as follows:
> the user requests a “key token” from the server
> the user generates a new pair of key pairs and uploads them to the
> server along with an authentication signature (username, password,
> random) and a token signature (the received key token, password)
> generated by the identity's existing signing private key.
> the server validates the password and both signatures and if valid
> increments the “key version” and signs and stores the public keys in the
> database.
> the server notifies other users involved in conversations with the
> revoker that the key has been revoked.
> clients will receive this revoke notification and act accordingly.
> the old keys are now considered revoked and any message sent using them
> will be rejected by the server.
> 
> Use case: lost/stolen phone-
> adam lost his phone, luckily he has his identities backed up on Google drive
> adam buys a new phone and installs surespot
> adam restores his identities from the backup
> adam generates a new pair of key pairs successfully
> attacker with old phone receives revoke message
> old phone knows revoke message is from the same user and promptly logs
> out and deletes any related data
> any subsequent authentication attempts on old phone will be rejected
> 
> Sending a message- After two users invite then accept each other the
> users are now friends, the two friends can access each other's public
> keys, which allows key derivation and message exchange. The scenario
> plays out as follows at a high level glance:
> adam wants to send cherie a message
> adam asks the server for th

Re: [liberationtech] Secure Android guide?

[Nathan of Guardian]

On 07/15/2013 03:04 PM, Cooper Quintin wrote:
> I gave a talk a while ago on pragmatic smartphone security.  The video
> can be found here:
> http://vimeo.com/46044290
> And more up to date slides can be found here:
> https://github.com/cooperq/spiders

This is a great talk - highly recommended!
--
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] Secure Android guide?

[Nathan of Guardian]

On 07/13/2013 10:30 AM, Julian Oliver wrote:
> You can install CyanogenMod - and not install the Google suite - for a 
> pleasant
> and largely Google-free experience. To be safer, don't install a nightly 
> build.

We have a guide that is a bit out of date, and I am working on an
update. In the meantime, here are a few ways to enhance Julian's
recommendation to start with CyanogenMod, all developed by an amazingly
talented volunteer of ours:

1) Guardian Project Installer - this is a firmware image you flash on
top of Cyanogen that includes a default set of open-source
security-focused apps:
https://code.google.com/p/guardian-project-installer/

2) SecDroid - a root-required app (for ANY device with root, not just
cyanogen) that disables many unnecessary and potentially risky
services/apps in the default configuration of Android:
http://forum.xda-developers.com/showthread.php?t=2086276

3) (WARNING: Currently in "unaudited" beta, but still worthwhile to
mention): Guardian ROM: a completely open-source firmware for Android,
based on Cyanogen, that includes everything that #1 and #2 above have,
and even more:
http://guardianrom.com (aka http://shadowdcatconsulting.com/)

Again, we should have some updated tutorials on this coming soon.

Also, if you just one to buy a product off the shelf, the GSMK
Cryptophone cp500 is a great product:
http://www.cryptophone.de/en/products/mobile/cp500/


+n
--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Nathan of Guardian]

On 07/15/2013 06:41 AM, Moritz Bartl wrote:
> Surespot looks like an open source alternative:
> 
> https://www.surespot.me/
> https://www.surespot.me/documents/how_surespot_works.html

Yes, I just discovered this myself. Looks interesting at first glance.
Seems much more promising than other apps who just say "We'll use PGP!"
as their answer to security.

I have reached out to them via Twitter to offer support in adding
Orbot/proxy support into their app.

+n
--
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] CJDNS hype

[Caleb James DeLisle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 07/15/2013 04:52 PM, Michael Rogers wrote:
> On 15/07/13 01:49, Mitar wrote:
>>> BTW, how do you propose to make Sybil nodes "impossible"?
> 
>> I don't. I am just making an argument, that maybe there is some way we (or 
>> I) don't yet know which would allow us to don't have to trust other nodes 
>> with anything else that they forward the packet. And if they don't, we can 
>> maybe detect that and remove them from the routing path. So at the end maybe 
>> it is not even important if Sybil nodes are possible or impossible. You just 
>> care if they forward the packet. If they do, this is it. If they don't (from 
>> whatever reason, being malicious or
>> just malperforming), you route along that, no? But to be able to route 
>> around, you have to be able to have multiple paths.
> 
> Hi Mitar,
> 
> If there's no protection against Sybil attacks then in general it's 
> impossible to route around faulty nodes or links. The problem is that in 
> order to detect faults, we have to associate some kind of reliability 
> measurement with some kind of node or link identifier (for example, "x 
> percent of packets sent via link y were delivered"). If there's no Sybil 
> protection then whenever we detect a node or link as being faulty, the 
> adversary can simply create a new identifier for that node or link.

At the switch layer, the path is a binary encoded list of interface
indexes of the interfaces through which the packet should pass, think
of it like driving directions.
Each node along the path modifies the packet, removing the forward
index and tagging it with the index of the interface from which it
came. This means you can send someone a switch frame with *anything*
in the label and when it gets to them, the beginning of the label
will contain a nicely formatted route leading back to you.

You can spoof a switch frame source but the path will always appear
to go through your node.

> The adversary can create imaginary networks of arbitrary size and structure, 
> composed entirely of Sybil identities, to absorb our measurement resources. 
> It's like playing whack-a-mole with an infinite number of moles. ;-)

Which will all have a common route prefix. Lazy cjdns will not route
to your absurdly long path if it has short paths to the destinations
it wants to reach. It will also not care much about your zillion nodes
because it has fast nodes already in it's routing table and they're
working just fine.

> 
> If we consider the most limited form of Sybil protection, where we know that 
> our immediate neighbours in the network aren't Sybils (for example, maybe 
> they're people we know in real life) but we don't know anything about the 
> rest of the network, then we can do a very limited form of fault detection: 
> we can measure the reliability of each neighbour, without speculating about 
> what the network beyond that neighbour looks like, and route around 
> unreliable neighbours.

You can feign existence of as many nodes as you want but you can't feign
low latency and short labels, in fact the more nodes you generate, the
longer your labels will become to accommodate them all, your
(comparatively) high latency links with long switch labels look just
like a terrible route which cjdns finds and rejects all of the time.

> 
> But that's not as easy as it sounds: if the adversary can distinguish between 
> different types of packet then she can treat them differently. For example, 
> if the network uses separate measurement packets and data packets,

It doesn't (of course you can guess based on size and flow information)

> the adversary can deliver measurement packets but drop data packets. If the 
> packets carry source or destination addresses,

They don't, only route labels which route to the next hop in the recursive
routing which is usually but not necessarily the destination.

> the adversary can drop packets with certain sources or destinations while 
> keeping her overall reliability high. The adversary may be able to manipulate 
> the reliability measurements without dropping packets, for example by 
> spoofing addresses or forging measurement packets.

Can't spoof a packet because the IPv6 address is the public key hash.
Can't spoof a switch frame source except to extend the length of the
path beyond your node.

> 
> This problem is known as Byzantine robust routing. It was first framed by 
> Radia Perlman in 1988, and so far nobody's come up with a solution that 
> doesn't require some kind of limit on the creation of identities. Many have 
> tried and failed. I was one of them. :-) I don't know enough about CJDNS to 
> know whether it's solved this problem, but I'll be pleasantly surprised if it 
> has.

If you want to cause trouble for cjdns, just exploit
https://github.com/cjdelisle/cjdns/issues/204 before I get off of my lazy
ass and fix it :)

Thanks,
Caleb


> 
> Cheers, Michael
> 
> -- Too many emails? Unsubscribe, change to digest, or cha

Re: [liberationtech] Secure Android guide?

[Cooper Quintin]

Jerzy,
I gave a talk a while ago on pragmatic smartphone security.  The video
can be found here:
http://vimeo.com/46044290
And more up to date slides can be found here:
https://github.com/cooperq/spiders

Enjoy! Please feel free to contact me directly if you have other questions.

Cooper Quintin
Technology Director - radicalDESIGNS
PGP Key ID: 75FB 9347 FA4B 22A0 5068 080B D0EA 7B6F F0AF E2CA

On 07/13/2013 11:45 AM, Jerzy Łogiewa wrote:
> Thank you Julian!
> 
> Can you tell me about this "largely" Google-free experience? Is it about the 
> OS being Google, or are some more components still there?
> 
> --
> Jerzy Łogiewa -- jerz...@interia.eu
> 
> On Jul 13, 2013, at 4:30 PM, Julian Oliver wrote:
> 
>> You can install CyanogenMod - and not install the Google suite - for a 
>> pleasant
>> and largely Google-free experience. To be safer, don't install a nightly 
>> build.
>> Take out the SIM card. Flash CyanogenMod using the simple instructions for 
>> your
>> device on their website. Encrypt the file-system once the device is 
>> installed.
>> Set up a 6-or-more line swipe pattern without visual feedback (and keep your
>> screen clean!). Disable developer mode and MTP browsing, until you need it.
>> Connect the device to a wireless network you control. Install DroidWall (or
>> similar open source firewall) and lock down any unknown and/or promiscuous
>> processes (vastly less with CyanogenMod than Android). Don't use Google Play.
>> Download and install OopenVPN client and tunnel to your favourite trusted
>> OpenVPN server. Put on OrBot and run the OrWeb Tor browser.  Edit your exit
>> nodes to those that suit.  Install Firefox and requisite extensions that 
>> protect
>> against cookie tracking etc. Use StartPage instead of Google as your default
>> search engine.  Don't install any random games or other software. If you need
>> something like a PDF reader, be sure it's open source and the APK you 
>> download
>> checksums out (SHA256).
>>
>> I've done the above, more or less, with my last two Android phones. My SIII 
>> is
>> especially good to work with. I've audited it on the wire and I trust working
>> with it so far. How you use it is another thing. If you rarely need to make
>> calls over the cellular network then use Airplane Mode until you need to 
>> call -
>> that'll get you off the grid where cell provider location tracking/logging is
>> concerned. Better still, don't use a SIM card at all and tunnel/ZRTP VoIP 
>> with
>> something like RedPhone.
> 
> --
> 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
> 
--
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"

[Axel Simon]

In TextSecure, the password unlocks the local db of encrypted SMS messages.
Lose the password, lose the messages.

Also, the point of TextSecure is that it uses text (SMS) messages as a 
transport, which often work when Internet access (or even plain phone calls) 
do(es)n't.

axel

Wasabee  wrote:

>hi
>
>thank for your answer. what is the role of the password? is it used to 
>access the TextSecure app? is it a shared password with the recipient?
>
>
>On 10/07/2013 15:29, Albert López wrote:
>>
>> Hello Wasabee,
>>
>> I've used TextSecure but I found that it's like sending encrypted
>SMS, 
>> therefore you have the consequent cost associated to it. I don't know
>
>> if Heml.is will be a kind of secure whatsapp or if it will have the 
>> same approach of TextSecure.
>>
>> Correct me if I'm wrong with the SMS stuff. It was what I thought
>once 
>> I received my bill.
>>
>>
>>
>>
>
>>
>> gpg --keyserver pgp.mit.edu --search-keys EEE5A447
>> http://pgp.mit.edu:11371/pks/lookup?search=0xEEE5A447&op=vindex
>>
>>
>>
>>
>
>> Date: Wed, 10 Jul 2013 14:31:53 +0100
>> From: wasabe...@gmail.com
>> To: liberationtech@lists.stanford.edu
>> Subject: Re: [liberationtech] Heml.is - "The Beautiful & Secure
>Messenger"
>>
>> https://whispersystems.org/ already has an open-source secure 
>> messaging, voice and more.
>> Has anyone reviewed their code?
>> Does anyone use it?
>> Why not build on top of it?
>>
>>
>> On 10/07/13 14:07, Nick wrote:
>>
>> noone said it would be closed source. That's peoples
>guess. Like, your guess, I guess.
>>
>> According to their twitter account, the answer is "maybe":
>> https://twitter.com/HemlisMessenger/statuses/354927721337470976
>>
>> Peter Sunde (one of the people behind it) said "eventually", but
>> in my experience promises like that tend to be broken:
>> https://twitter.com/brokep/status/354608029242626048
>>
>> and the feature 'unlocking' aspect of the project - to be
>indication of a
>> proprietary code base.
>>
>> Frankly I can't see how they could get the "feature unlock"
>funding
>> stuff to work well if it's proper open source. As I'd expect
>people
>> to fork it to remove such antifeatures. It's a pity, as several
>new
>> funding models have been successful recently which are compatible
>with
>> free software, but this doesn't look to be one of them.
>> --
>> Too many emails? Unsubscribe, change to digest, or change
>password by emailing moderator atcompa...@stanford.edu 
>  or changing your settings
>athttps://mailman.stanford.edu/mailman/listinfo/liberationtech
>>
>>
>>
>> -- 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
>>
>>
>> --
>> 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
>
>
>
>
>
>--
>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

-- 
Axel Simon
mail / jabber / gtalk: axelsimon@ axelsimon.net
twitter / identi.ca: @axelsimon--
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] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Michael Carbone]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

GitHub here: https://github.com/surespot, includes client and server
software. Would be interested in hearing folks' thoughts on it.

Dev is @adam2fours, we ought to invite him to the conversation if he
isn't on libtech.

On 07/15/2013 06:41 AM, Moritz Bartl wrote:
> Surespot looks like an open source alternative:
> 
> https://www.surespot.me/ 
> https://www.surespot.me/documents/how_surespot_works.html
> 
> technical overview
> 
> User creation- When a user is created in surespot two ECC (secp521)
> key pairs are generated, one for key derivation, and one for
> signing.
> 
> The username plus keypairs create a 'surespot identity'. This
> identity is stored on the device symmetrically encrypted using 256
> bit AES-GCM with a PKCS5S2 key derived from the user's password
> (plus salt and other data). The public keys are uploaded to the
> server where they are signed by the server using the server's
> private key. A user may create multiple identities and switch
> between them at will.
> 
> User authentication- To login the client generates a signature
> using the identity's private signing key against the username,
> password, and randomly generated data. The server validates the
> client provided username, password, and aforementioned signature
> against its stored public signing key for the identity in question.
> If successfully verified the client is issued a session cookie
> which authenticates them for future requests until the session
> expires or they logout.
> 
> As the exchange occurs over SSL, session cookies are thought to be
> a secure enough mechanism to faciligroup chattate authentication,
> but in the future every request could be validated against the
> signature. The fact that messages could not be decrypted by a
> session hijacker given the end to end encryption nature of the
> system also factors into this decision.
> 
> Identity backup/restore- As the private key stored on the device is
> the, uh key, to unlocking all of the data, it is of utmost
> importance. In the case of a lost or stolen device, if the key is
> lost along with it, so is all of the data. Identity backup/restore
> and key versioning help to mitigate this problem. A user may backup
> their (encrypted) identities (username and key pair history) to
> device storage, or the cloud and restore them upon demand.
> Obviously the security is only as strong as the password used to
> store the identity in whatever cloud service and the surespot
> password, so make them strong! Never shall a private key be stored
> on a surespot server.
> 
> Man in the middle- MITM is currently thwarted by the following: 
> standard SSL implementation. When a user is created and its public
> keys uploaded to the server, the server signs the public keys.
> Clients that download the public key then validate the signature of
> the key against the hardcoded server public key in the client. This
> ensures a MITM attack trying to use a rogue key pair to impersonate
> a user will be prevented.
> 
> Key versioning/revoking- A user may generate a new pair of key
> pairs at any time. This process is as follows: the user requests a
> “key token” from the server the user generates a new pair of key
> pairs and uploads them to the server along with an authentication
> signature (username, password, random) and a token signature (the
> received key token, password) generated by the identity's existing
> signing private key. the server validates the password and both
> signatures and if valid increments the “key version” and signs and
> stores the public keys in the database. the server notifies other
> users involved in conversations with the revoker that the key has
> been revoked. clients will receive this revoke notification and act
> accordingly. the old keys are now considered revoked and any
> message sent using them will be rejected by the server.
> 
> Use case: lost/stolen phone- adam lost his phone, luckily he has
> his identities backed up on Google drive adam buys a new phone and
> installs surespot adam restores his identities from the backup adam
> generates a new pair of key pairs successfully attacker with old
> phone receives revoke message old phone knows revoke message is
> from the same user and promptly logs out and deletes any related
> data any subsequent authentication attempts on old phone will be
> rejected
> 
> Sending a message- After two users invite then accept each other
> the users are now friends, the two friends can access each other's
> public keys, which allows key derivation and message exchange. The
> scenario plays out as follows at a high level glance: adam wants to
> send cherie a message adam asks the server for the latest version
> of cherie's public key adam verifies cherie's public key (which is
> signed by the server) against the hard coded server public key in
> the app and proceeds if valid adam derives the shared secret adam
> encrypts the message using AES 256bit GCM

[liberationtech] US law actually protects companies that want to offer products w/ end-to-end encryption & no backdoors

[Moritz Bartl]

http://paranoia.dubfire.net/2010/09/calea-and-encryption.html
Christopher Soghoian

CALEA and encryption

Reading through Charlie Savage's New York Times piece yesterday, which
arguably marks the beginning of the 2nd crypto wars, one might get the
impression that law enforcement officials are merely seeking to tweak
the law, in order to maintain the existing status quo:

"We're talking about lawfully authorized intercepts," said Valerie E.
Caproni, general counsel for the Federal Bureau of Investigation. "We're
not talking expanding authority. We're talking about preserving our
ability to execute our existing authority in order to protect the public
safety and national security."

...

To counter such problems, officials are coalescing around several of the
proposal’s likely requirements:

* Communications services that encrypt messages must have a way to
unscramble them.

I think it is reasonable to assume that very few people have read the
text of the Communications Assistance for Law Enforcement Act (CALEA),
and so it is quite reasonable that the average layperson (or even
interested technologist) might assume that existing US law has nothing
to say about encryption, since, after all, Skype didn't exist when CALEA
was passed in 1994. That is incorrect -- not only does the law speak
about encryption, but it specifically protects the right of companies to
build strong encryption for which only the customer has the decryption
key into their products.

47 USC 1002(b)(3):
A telecommunications carrier shall not be responsible for decrypting, or
ensuring the government’s ability to decrypt, any communication
encrypted by a subscriber or customer, unless the encryption was
provided by the carrier and the carrier possesses the information
necessary to decrypt the communication.

Also from the CALEA legislative history:

Finally, telecommunications carriers have no responsibility to decrypt
encrypted communications that are the subject of court-ordered wiretaps,
unless the carrier provided the encryption and can decrypt it. This
obligation is consistent with the obligation to furnish all necessary
assistance under 18 U.S.C. Section 2518(4). Nothing in this paragraph
would prohibit a carrier from deploying an encryption service for which
it does not retain the ability to decrypt communications for law
enforcement access
...
Nothing in the bill is intended to limit or otherwise prevent the use of
any type of encryption within the United States. Nor does the Committee
intend this bill to be in any way a precursor to any kind of ban or
limitation on encryption technology. To the contrary, section 2602
protects the right to use encryption.”

If the FBI and other law enforcement agencies get their way, they will
not be tweaking existing law to deal with new technologies, but
fundamentally changing how the government regulates technology.

-- 
Moritz Bartl
https://www.torservers.net/
--
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"

[Wasabee]

hi

thank for your answer. what is the role of the password? is it used to 
access the TextSecure app? is it a shared password with the recipient?



On 10/07/2013 15:29, Albert López wrote:


Hello Wasabee,

I've used TextSecure but I found that it's like sending encrypted SMS, 
therefore you have the consequent cost associated to it. I don't know 
if Heml.is will be a kind of secure whatsapp or if it will have the 
same approach of TextSecure.


Correct me if I'm wrong with the SMS stuff. It was what I thought once 
I received my bill.






gpg --keyserver pgp.mit.edu --search-keys EEE5A447
http://pgp.mit.edu:11371/pks/lookup?search=0xEEE5A447&op=vindex




Date: Wed, 10 Jul 2013 14:31:53 +0100
From: wasabe...@gmail.com
To: liberationtech@lists.stanford.edu
Subject: Re: [liberationtech] Heml.is - "The Beautiful & Secure Messenger"

https://whispersystems.org/ already has an open-source secure 
messaging, voice and more.

Has anyone reviewed their code?
Does anyone use it?
Why not build on top of it?


On 10/07/13 14:07, Nick wrote:

noone said it would be closed source. That's peoples guess. Like, 
your guess, I guess.

According to their twitter account, the answer is "maybe":
https://twitter.com/HemlisMessenger/statuses/354927721337470976

Peter Sunde (one of the people behind it) said "eventually", but
in my experience promises like that tend to be broken:
https://twitter.com/brokep/status/354608029242626048

and the feature 'unlocking' aspect of the project - to be indication of 
a
proprietary code base.

Frankly I can't see how they could get the "feature unlock" funding
stuff to work well if it's proper open source. As I'd expect people
to fork it to remove such antifeatures. It's a pity, as several new
funding models have been successful recently which are compatible with
free software, but this doesn't look to be one of them.
--
Too many emails? Unsubscribe, change to digest, or change password by emailing 
moderator atcompa...@stanford.edu    or changing 
your settings athttps://mailman.stanford.edu/mailman/listinfo/liberationtech



-- 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



--
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


--
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] Bring some UX/UI help to open secure apps

[Michael Oren]

I am a UX person (more heavily on the research end than the design end,
although I've done both). I'm not sure I can commit to working on this, but
I'm also teaching an HCI course in the Fall and can present something to
the students as an option for their projects. It's an introductory course
though so their skill levels will likely be low.

-Mike

On Monday, July 15, 2013, Jerzy Łogiewa wrote:

> Okay great!
>
> So there are some in support to this, how to start?
>
> * Choose 1 project
> * Get author approval
> * Find designer
> * Get estimate
> * Research crowdfund sites
> * Build campaign
>
> Should we vote this first one? My hand goes up to the Jitsi!
>
> --
> Jerzy Łogiewa -- jerz...@interia.eu
> --
> 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
--
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] Bring some UX/UI help to open secure apps

[John Love]

I think it's important that we distinguish between User Interface and
User EXPERIENCE. The less effort it takes for the user to accomplish the
task the better, and IMHO a thoughtful UX helps more here than a "shiny"
UI , though a good UI is a vital component of good UX.

Jerzy Łogiewa wrote:
> Okay great!
> 
> So there are some in support to this, how to start?
> 
> * Choose 1 project
> * Get author approval
> * Find designer
> * Get estimate
> * Research crowdfund sites
> * Build campaign
Digging the call to action!
> 
> Should we vote this first one? My hand goes up to the Jitsi!
+1 Jitsi!
> 
> --
> Jerzy Łogiewa -- jerz...@interia.eu
> --
> 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
--
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] Bring some UX/UI help to open secure apps

[Scott Elcomb]

On Mon, Jul 15, 2013 at 2:29 AM, Jerzy Łogiewa  wrote:
> * Research crowdfund sites

Mozilla posted a related article recently that may be worth keeping in
mind.  A common element to the more successful campaigns I've seen:
before starting on Kickstarter or Indiegogo they're already running a
campaign on their own websites.

Anyway, Mozilla provides a tutorial on setting up one's own
crowdfunding site:


Technically it's not very difficult; there does appear to be a
geographic requirement with "Balanced Payments" however - accepting
payments is US only.

-- 
  Scott Elcomb
  @psema4 on Twitter / Identi.ca / Github & more

  Atomic OS: Self Contained Microsystems
  http://code.google.com/p/atomos/

  Member of the Pirate Party of Canada
  http://www.pirateparty.ca/
--
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

[liberationtech] Conference proceedings: E-Voting and Identify

[Yosem Companys]

E-Voting and Identify
4th International Conference, Vote-ID 2013, Guildford, UK, July 17-19,
2013. Proceedings
http://link.springer.com/book/10.1007/978-3-642-39185-9/page/1--
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] Secure Android guide?

[Karl Fogel]

Jon Camfield  writes:
>Julian - this is an excellent and concise quickstart guide to Android
>security -- have you considered posting it into
>https://github.com/opensafermobile/materials ?  Those materials which
>were posted on the http://safermobile.org/ site (which is now
>offline), but they're beginning to show their age.

You may be interested in the Guardian ROM project, currently under way:

  
http://shadowdcatconsulting.com/blog/2013/2/13/guardian-rom-secure-android-rom.html

I think it may be behind its originally-planned schedule, as is normal
with such things :-), but I know Kyle Davidson is actively working on
it.

-K

>On Saturday, July 13, 2013 10:30 AM, Julian Oliver wrote:
>> ..on Sat, Jul 13, 2013 at 03:13:41PM +0200, Jerzy Łogiewa wrote:
>>> Hello!
>>> 
>>> If I want Android phone and have it be most secure, how to do it?
>>> Is there some guide with steps?
>>> 
>>> Like this:
>>> 
>>> 1- Buy some handset such as X, Y 2- Re-flash to Z firmware 3-
>>> Change P settings to J ... 4- Install OrBot, RedPhone, and so on
>>> 
>>> What is recommended here by experts?
>>> 
>>> PS: I am willing to have device ONLY for secure communications.
>> 
>> Disclaimer: while some journalists/people call me an expert I've
>> never, ever named myself as such!
>> 
>> Firstly, smartphones are a huge risk if you're really concerned
>> about your security. Nonetheless, here's a start:
>> 
>> You can install CyanogenMod - and not install the Google suite -
>> for a pleasant and largely Google-free experience. To be safer,
>> don't install a nightly build. Take out the SIM card. Flash
>> CyanogenMod using the simple instructions for your device on their
>> website. Encrypt the file-system once the device is installed. Set
>> up a 6-or-more line swipe pattern without visual feedback (and keep
>> your screen clean!). Disable developer mode and MTP browsing, until
>> you need it. Connect the device to a wireless network you control.
>> Install DroidWall (or similar open source firewall) and lock down
>> any unknown and/or promiscuous processes (vastly less with
>> CyanogenMod than Android). Don't use Google Play. Download and
>> install OopenVPN client and tunnel to your favourite trusted 
>> OpenVPN server. Put on OrBot and run the OrWeb Tor browser.  Edit
>> your exit nodes to those that suit.  Install Firefox and requisite
>> extensions that protect against cookie tracking etc. Use StartPage
>> instead of Google as your default search engine.  Don't install any
>> random games or other software. If you need something like a PDF
>> reader, be sure it's open source and the APK you download checksums
>> out (SHA256).
>> 
>> I've done the above, more or less, with my last two Android phones.
>> My SIII is especially good to work with. I've audited it on the
>> wire and I trust working with it so far. How you use it is another
>> thing. If you rarely need to make calls over the cellular network
>> then use Airplane Mode until you need to call - that'll get you off
>> the grid where cell provider location tracking/logging is 
>> concerned. Better still, don't use a SIM card at all and
>> tunnel/ZRTP VoIP with something like RedPhone.
>> 
>> Cheers,
>> 
>
>--
>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
--
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] Secure Android guide?

[Jon Camfield]

Julian - this is an excellent and concise quickstart guide to Android
security -- have you considered posting it into
https://github.com/opensafermobile/materials ?  Those materials which
were posted on the http://safermobile.org/ site (which is now
offline), but they're beginning to show their age.

Jon

On Saturday, July 13, 2013 10:30 AM, Julian Oliver wrote:
> ..on Sat, Jul 13, 2013 at 03:13:41PM +0200, Jerzy Łogiewa wrote:
>> Hello!
>> 
>> If I want Android phone and have it be most secure, how to do it?
>> Is there some guide with steps?
>> 
>> Like this:
>> 
>> 1- Buy some handset such as X, Y 2- Re-flash to Z firmware 3-
>> Change P settings to J ... 4- Install OrBot, RedPhone, and so on
>> 
>> What is recommended here by experts?
>> 
>> PS: I am willing to have device ONLY for secure communications.
> 
> Disclaimer: while some journalists/people call me an expert I've
> never, ever named myself as such!
> 
> Firstly, smartphones are a huge risk if you're really concerned
> about your security. Nonetheless, here's a start:
> 
> You can install CyanogenMod - and not install the Google suite -
> for a pleasant and largely Google-free experience. To be safer,
> don't install a nightly build. Take out the SIM card. Flash
> CyanogenMod using the simple instructions for your device on their
> website. Encrypt the file-system once the device is installed. Set
> up a 6-or-more line swipe pattern without visual feedback (and keep
> your screen clean!). Disable developer mode and MTP browsing, until
> you need it. Connect the device to a wireless network you control.
> Install DroidWall (or similar open source firewall) and lock down
> any unknown and/or promiscuous processes (vastly less with
> CyanogenMod than Android). Don't use Google Play. Download and
> install OopenVPN client and tunnel to your favourite trusted 
> OpenVPN server. Put on OrBot and run the OrWeb Tor browser.  Edit
> your exit nodes to those that suit.  Install Firefox and requisite
> extensions that protect against cookie tracking etc. Use StartPage
> instead of Google as your default search engine.  Don't install any
> random games or other software. If you need something like a PDF
> reader, be sure it's open source and the APK you download checksums
> out (SHA256).
> 
> I've done the above, more or less, with my last two Android phones.
> My SIII is especially good to work with. I've audited it on the
> wire and I trust working with it so far. How you use it is another
> thing. If you rarely need to make calls over the cellular network
> then use Airplane Mode until you need to call - that'll get you off
> the grid where cell provider location tracking/logging is 
> concerned. Better still, don't use a SIM card at all and
> tunnel/ZRTP VoIP with something like RedPhone.
> 
> Cheers,
> 

--
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] CJDNS hype

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/07/13 01:49, Mitar wrote:
>> BTW, how do you propose to make Sybil nodes "impossible"?
> 
> I don't. I am just making an argument, that maybe there is some way
> we (or I) don't yet know which would allow us to don't have to
> trust other nodes with anything else that they forward the packet.
> And if they don't, we can maybe detect that and remove them from
> the routing path. So at the end maybe it is not even important if
> Sybil nodes are possible or impossible. You just care if they
> forward the packet. If they do, this is it. If they don't (from
> whatever reason, being malicious or just malperforming), you route
> along that, no? But to be able to route around, you have to be able
> to have multiple paths.

Hi Mitar,

If there's no protection against Sybil attacks then in general it's
impossible to route around faulty nodes or links. The problem is that
in order to detect faults, we have to associate some kind of
reliability measurement with some kind of node or link identifier (for
example, "x percent of packets sent via link y were delivered"). If
there's no Sybil protection then whenever we detect a node or link as
being faulty, the adversary can simply create a new identifier for
that node or link. The adversary can create imaginary networks of
arbitrary size and structure, composed entirely of Sybil identities,
to absorb our measurement resources. It's like playing whack-a-mole
with an infinite number of moles. ;-)

If we consider the most limited form of Sybil protection, where we
know that our immediate neighbours in the network aren't Sybils (for
example, maybe they're people we know in real life) but we don't know
anything about the rest of the network, then we can do a very limited
form of fault detection: we can measure the reliability of each
neighbour, without speculating about what the network beyond that
neighbour looks like, and route around unreliable neighbours.

But that's not as easy as it sounds: if the adversary can distinguish
between different types of packet then she can treat them differently.
For example, if the network uses separate measurement packets and data
packets, the adversary can deliver measurement packets but drop data
packets. If the packets carry source or destination addresses, the
adversary can drop packets with certain sources or destinations while
keeping her overall reliability high. The adversary may be able to
manipulate the reliability measurements without dropping packets, for
example by spoofing addresses or forging measurement packets.

This problem is known as Byzantine robust routing. It was first framed
by Radia Perlman in 1988, and so far nobody's come up with a solution
that doesn't require some kind of limit on the creation of identities.
Many have tried and failed. I was one of them. :-) I don't know enough
about CJDNS to know whether it's solved this problem, but I'll be
pleasantly surprised if it has.

Cheers,
Michael

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

iQEcBAEBAgAGBQJR5AyxAAoJEBEET9GfxSfM2OwIALyIROECcLGCiJlyM8DX6IKQ
aQdC4JFfcgsh1poTq1MaHjF1nCUA14OBF73bpxp0iRw8b0fcJ4AwqAlzdDbxL1k0
cfxdaytN6dZPSgQng6jot4o4GzCYdVNdWcAxsycNgohjX0MDa64pe6gJmYmZlmBw
S24FB8ismcMl3Ohyu1mg339NsBzo6is3zKa9/TVp5l5iB/FVFM8yjTewkAgdBFVD
BlOLwEr5h+gHUqTpmmswXbJIcqT9/xe14NogKOgUDUUfpZMe7g0ZWeF7z65FJwLn
C2kVc/HxB85TTmwaGoV/Os79lQALLVNmdafgqHhcRRNTTCRUKcqlgDsZt6/SsEE=
=ud7U
-END PGP SIGNATURE-
--
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

[liberationtech] Travellers' mobile phone data seized by police at border

[Eugen Leitl]

(leave your data at home in an encrypted cloud (you cannot
be asked to decrypt data not in your possession), treat 
seized devices as sacrificable due to potential backdoors 
installed during examination so use cheap disposables when 
travelling and restock from a known good source)

http://www.telegraph.co.uk/technology/10177765/Travellers-mobile-phone-data-seized-by-police-at-border.html

Travellers' mobile phone data seized by police at border

Thousands of innocent holidaymakers and travellers are having their phones
seized and personal data downloaded and stored by the police, The Telegraph
can disclose.

Tourist using mobile phone at an airport

A police officer can stop any passenger at random, scour their phone and
download and retain data, even of the individual is then immediately allowed
to proceed Photo: ALAMY

By Tom Whitehead, and David Barrett9:01PM BST 13 Jul 2013Comments206 Comments

Officers use counter-terrorism laws to remove a mobile phone from any
passenger they wish coming through UK air, sea and international rail ports
and then scour their data.

The blanket power is so broad they do not even have to show reasonable
suspicion for seizing the device and can retain the information for “as long
as is necessary”.

Data can include call history, contact books, photos and who the person is
texting or emailing, although not the contents of messages.

David Anderson QC, the independent reviewer of terrorism laws, is expected to
raise concerns over the power in his annual report this week.

He will call for proper checks and balances to ensure it is not being abused.

It echoes concerns surrounding an almost identical power police can use on
the streets of the UK, which is being reviewed by the Information
Commissioner.

However, in those circumstances police must have grounds for suspicion and
the phone can only be seized if the individual is arrested.

Mr Anderson said: “Information downloaded from mobile phones seized at ports
has been very useful in disrupting terrorists and bringing them to justice.

“But ordinary travellers need to know that their private information will not
be taken without good reason, or retained by the police for any longer than
is necessary.”

Up to 60,000 people a year are “stopped and examined” as they enter or return
to the UK under powers contained in the Terrorism Act 2000.

It is not known how many of those have their phone data taken.

Dr Gus Hosein, of the campaign group Privacy International, said: “We are
extremely concerned by these intrusive tactics that have been highlighted by
the independent terrorism reviewer.

“These practices have been taking place under the radar for far too long and
if Mr Anderson calls for reform and new safeguards we would be very
supportive of that.”

He added: “Seizing and downloading your phone data is the modern equivalent
of searching your home and office, searching through family albums and
business records alike, and identifying all your friends and family, then
keeping this information for years.

“If you were on the other side of the border, the police would rightly have
to apply for warrants and follow strict guidelines. But nowhere in Britain do
you have less rights than at the border.

“Under law, seizing a mobile phone should be only when the phone is essential
to an investigation, and then even certain rules should apply. Without these
rules, everyone should be worried.”

Under the Act, police or border staff can question and even hold someone
while they ascertain whether the individual poses a terrorism risk.

But no prior authorization is needed for the person to be stopped and there
does not have to be any suspicion.

It means a police officer can stop any passenger at random, scour their phone
and download and retain data, even of the individual is then immediately
allowed to proceed.

It has been a grey area as to whether the act specifically allowed for phone
data to be downloaded and recorded.

But last month, Damian Green, the policing minister, laid an amendment to the
anti-social behaviour, crime and policing bill, which is currently going
through Parliament.

It makes the express provision for the copying and retention of information
from a seized item.

The ability to potentially retain the data indefinitely could also spark a
fresh row over civil liberties similar to the controversy around DNA sample.

Laws had to be changed to end the retention of the DNA of innocent people
after the European Court of Human Rights ruled in 2008 that keeping them was
unlawful.

Mr Anderson is expected to stress he is not against the power and that it is
a useful tool in the fight against terrorism but that it must be used
appropriately.

In his report last year Mr Anderson said the general power to stop people
under the terror laws were “formidable” and “among the strongest of all
police powers”.

Christopher Graham, the Information Commissioner, is already investigating
whether the use of similar powers by polic

Re: [liberationtech] WeChat

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/07/13 04:29, Sarah Lai Stirland wrote:
> Thanks. This is the kind of discussion and back and forth I was
> looking for ... I kind of figured this was the case, although I
> don't know of any actual examples of any of this happening. I know
> a lot of Chinese people use it, and I think it's interesting why
> it's so popular with the Chinese, and not so much in the US.

Hi Sarah,

There was a thread about WeChat at the end of last year with some
great contributions by Nathan, Tricia Wang and others:

https://mailman.stanford.edu/pipermail/liberationtech/2012-December/006138.html

https://mailman.stanford.edu/pipermail/liberationtech/2013-January/006338.html

Cheers,
Michael

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

iQEcBAEBAgAGBQJR4/uBAAoJEBEET9GfxSfMbh0H/ApA4fPFkPK/TwjTAD7VcG4P
vLgY1IXxA4+8Ic/riwCpGa/1hY2Dc3ojGEAhfaJJMlwU4zhDfBTGOJeWn/M6weeG
qLSmV4zZZyG4hdGWfwbJc/6225Tm1hNDHpVGACse1FCJO6b6VXIHsf/SyigH0sFD
cOT5yUbDN2A0Ph6yIzVzC0xvSBEYzFHfqGAC4yMg7YCUN/V8z9r9fi6LtZL5WqxF
Ea8ZPxAGKEMfp0C6dTwT/OZ05mxYSOyWJUFhx4JSrUxeJ2GyzvpVQnz1roT4gsg2
BDkpyKtSlsahl0tE39TcbkwUX9QlCeqr1A9FOg2NbwuS/8pU5rQ7tA9VUaupS/o=
=Pp40
-END PGP SIGNATURE-
--
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] [cryptography] Heml.is - "The Beautiful & Secure Messenger"

[Eugen Leitl]

- Forwarded message from ianG  -

Date: Sat, 13 Jul 2013 13:17:22 +0300
From: ianG 
To: cryptogra...@randombit.net
Subject: Re: [cryptography] [liberationtech] Heml.is - "The Beautiful & Secure 
Messenger"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) 
Gecko/20130620 Thunderbird/17.0.7

On 13/07/13 09:43 AM, Noon Silk wrote:

>  So what should everyone do?


Risk analysis.  Which starts with your business model.

What you do is go talk to your customers and figure out what happens
to them.  Formally, you would figure out the frequency of these
events, and multiply them by the damages.  Order them that way.
Concentrate on the top one first, munch your way down the list.

If you do this, in ordinary business, you will find that the NSA isn't
even on the list, unless for some reason you targetted some space that
they also targetted [0].

 E.g, in my current business I'm dealing with savings for v.
poor women in Africa.  The threats that are hitting them are
shakedowns by police, government, scammers, banks, merchants, each
other, family, and self, not necessarily in the order we westerners
expect.  Sometimes with violence.  So those are the things I'm
building the system to protect against, which of course takes some
cryptography to preserve and lock down assets rather than hide them,
mixed with a lot of other things... your classic old 1990s CIA models
aren't going to help a lot here. 



iang



[0] jihadist websites, CAs and chat systems for Americans spring to mind.
___
cryptography mailing list
cryptogra...@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5
--
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

[liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

[Moritz Bartl]

Surespot looks like an open source alternative:

https://www.surespot.me/
https://www.surespot.me/documents/how_surespot_works.html

technical overview

User creation- When a user is created in surespot two ECC (secp521) key
pairs are generated, one for key derivation, and one for signing.

The username plus keypairs create a 'surespot identity'. This identity
is stored on the device symmetrically encrypted using 256 bit AES-GCM
with a PKCS5S2 key derived from the user's password (plus salt and other
data). The public keys are uploaded to the server where they are signed
by the server using the server's private key. A user may create multiple
identities and switch between them at will.

User authentication- To login the client generates a signature using the
identity's private signing key against the username, password, and
randomly generated data. The server validates the client provided
username, password, and aforementioned signature against its stored
public signing key for the identity in question. If successfully
verified the client is issued a session cookie which authenticates them
for future requests until the session expires or they logout.

As the exchange occurs over SSL, session cookies are thought to be a
secure enough mechanism to facilitate authentication, but in the future
every request could be validated against the signature. The fact that
messages could not be decrypted by a session hijacker given the end to
end encryption nature of the system also factors into this decision.

Identity backup/restore- As the private key stored on the device is the,
uh key, to unlocking all of the data, it is of utmost importance. In the
case of a lost or stolen device, if the key is lost along with it, so is
all of the data. Identity backup/restore and key versioning help to
mitigate this problem. A user may backup their (encrypted) identities
(username and key pair history) to device storage, or the cloud and
restore them upon demand. Obviously the security is only as strong as
the password used to store the identity in whatever cloud service and
the surespot password, so make them strong! Never shall a private key be
stored on a surespot server.

Man in the middle- MITM is currently thwarted by the following:
standard SSL implementation.
When a user is created and its public keys uploaded to the server, the
server signs the public keys. Clients that download the public key then
validate the signature of the key against the hardcoded server public
key in the client. This ensures a MITM attack trying to use a rogue key
pair to impersonate a user will be prevented.

Key versioning/revoking- A user may generate a new pair of key pairs at
any time. This process is as follows:
the user requests a “key token” from the server
the user generates a new pair of key pairs and uploads them to the
server along with an authentication signature (username, password,
random) and a token signature (the received key token, password)
generated by the identity's existing signing private key.
the server validates the password and both signatures and if valid
increments the “key version” and signs and stores the public keys in the
database.
the server notifies other users involved in conversations with the
revoker that the key has been revoked.
clients will receive this revoke notification and act accordingly.
the old keys are now considered revoked and any message sent using them
will be rejected by the server.

Use case: lost/stolen phone-
adam lost his phone, luckily he has his identities backed up on Google drive
adam buys a new phone and installs surespot
adam restores his identities from the backup
adam generates a new pair of key pairs successfully
attacker with old phone receives revoke message
old phone knows revoke message is from the same user and promptly logs
out and deletes any related data
any subsequent authentication attempts on old phone will be rejected

Sending a message- After two users invite then accept each other the
users are now friends, the two friends can access each other's public
keys, which allows key derivation and message exchange. The scenario
plays out as follows at a high level glance:
adam wants to send cherie a message
adam asks the server for the latest version of cherie's public key
adam verifies cherie's public key (which is signed by the server)
against the hard coded server public key in the app and proceeds if valid
adam derives the shared secret
adam encrypts the message using AES 256bit GCM using the derived shared
secret as the key and sends it to cherie, the to and from key version
used to generate the message are included as part of the message
cherie receives the encrypted message
cherie downloads and verifies the version of adam's public key needed to
derive the shared secret for the message
cherie derives the (same) shared secret
cherie decrypts the message using the shared secret

Data stored on device- surespot ensures that no message data or keys are
stored on the device

Re: [liberationtech] Ether Rag: Duck Duck Go: Illusion of Privacy

[Alec Muffett]

A blog was created and this is its first and only post.  Why are we so
exercised about its wrongness? Has the author some supposed credibility of
which I am unaware?
--
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] Ether Rag: Duck Duck Go: Illusion of Privacy

[micah]

Yosem Companys  writes:

> Standard Wiretaps
>
> DuckDuckGo can easily be compelled either under the Communications
> Assistance for Law Enforcement Act (CALEA), standard court orders, or

Under CALEA? No, DDG cannot be compelled under CALEA. 

I have a hard time continuing to read when the opening statement is
factually wrong.
--
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] Feedback on Threema - Seriously secure mobile messaging.

[Eduardo Robles Elvira]

Hello:

Just another non-free software messaging platform that jumps in the
"i' secure" bandwagon. I wouldn't use it.

Regards,

On Mon, Jul 15, 2013 at 6:51 AM, Thejesh GN  wrote:
> http://threema.ch/en/
>
> It looks great from their description.
>
> Whats your opinion if you are using it?
> Anybody who has done traffic analysis etc?
>
>
> Thej
> --
> Thejesh GN | ತೇಜೇಶ್ ಜಿ.ಎನ್
> http://thejeshgn.com
> GPG ID :  0xBFFC8DD3C06DD6B0
>
> --
> 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



-- 
Eduardo Robles Elvira +34 668 824 393skype: edulix2
http://www.wadobo.comit's not magic, it's wadobo!
--
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