Re: [liberationtech] Jacob Appelbaum's Ultrasurf Report

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/04/12 06:44, Jacob Appelbaum wrote:
> Practically, I also think that mixmaster is an example of "great on
> paper" and soon we'll see how it works out in the real world. Now
> that the FBI is taking nodes left (in New York last week) and right
> (in Austria this week) - we'll note that some of these anonymity
> properties are coming up for a serious test. For example, if you
> don't compose Tor and Mixmaster together, what happens when you're
> the only person to ever connect to Mixmaster? I think the answer is
> that you're a suspect, cryptographic evidence be damned.

While your point about the importance of non-cryptographic evidence is
well taken, the FBI's behaviour in this case is consistent with an
investigation looking for cryptographic evidence.

Mixmaster doesn't provide forward secrecy - if you've recorded the
messages entering and leaving a remailer (which seems plausible for
the FBI, especially during the investigation of a long series of bomb
threats), you can seize the remailer and use its private key to match
incoming and outgoing messages. If the message you're interested in
came from another remailer, seize it and repeat. If not, you've found
the sender.

This attack against Mixmaster has been known about for ten years. If
nothing else, I hope this case revives interest in Mixminion...

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

iQEcBAEBAgAGBQJPmYTvAAoJEBEET9GfxSfM9akH/0hK+YL20YcLAh3gNRFwliv4
Kuz6kHRzZML4G8lqzjObE/sbEPzEgwZFcgDIi33uflkd5Gzhd2JHyV41BsgRqynC
gFKUgUT52Fw4TFKdJvU5S+ww2BT7ejsveG6XKabzJpaHnVG+vj94YhMNED+CjPRt
5fKgkQfAge/NQ9UF0mkigawGGgXTNylcddBN3DJSJ/oWCXOuzMTjZpVMmeKCt/R6
zOGY8uLfaA1VV6YWkMf81suNdPy/ll3nPWF/ipLtGIqDpfefOzGPjbXXsUpW76AD
panCl+sMIT0wbbsPwhf//2KEwkRae0h7dIiwYD4kMhIQaH5oKbj3X2VuJBghbt8=
=OQTa
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] Jacob Appelbaum's Ultrasurf Report

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/04/12 09:10, Roger Dingledine wrote:
> So oversimplifying a bit, we thought we had a choice between "high 
> security, high latency" and "low security, low latency". But the
> trouble is that while Mixminion's design can provide more safety in
> theory, it needs the users before it can provide this safety in
> practice. Without enough users sending messages to mix with, high
> and variable latency by itself doesn't cut it.

Hi Roger,

Does the Mixminion protocol make it possible to send a message through
the network that (intentionally) has the sender's address intact when
it emerges from the network?

I'm wondering whether it would be possible to write a Thunderbird
extension that would route all the user's email through Mixminion to
provide cover traffic for anonymous senders.

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

iQEcBAEBAgAGBQJPrD9EAAoJEBEET9GfxSfM8IIH/RumQk7RqvLRasFRH1anZCAs
Fo8zjoBa3j/1qEq935XJe0HSiluNAx+bQ64j612agdGk2sSg5siicnPdoc9SixRR
a/7lsrXlgpv5CQOCTPgSfZty3LUKye5zoVQFUPi4aM7C4PHLrgDjdYbFPUb87wOM
HDNW+gF9lx/S/qJV1njThSJkKcWjHOGhviThaFR5SdnokOXOyythlqdTnq0V5OWh
88xtYYr+/4eU/r6hqVGZTuFN5HtqJ+074xqkl3ax82Niy6DLHpHsbk9V66/YZFL6
4RS9pGev2QjuKilHzboazUIC0hWb0inoUZC3Zx3FmHUFFjgGcAHPIqvXLEYSTmE=
=cf6G
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] Jacob Appelbaum's Ultrasurf Report

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/05/12 00:20, Michael Rogers wrote:
> I'm wondering whether it would be possible to write a Thunderbird 
> extension that would route all the user's email through Mixminion
> to provide cover traffic for anonymous senders.

Sorry, someone kindly pointed out off-list that there's already a
Thunderbird extension for Mixminion (though it doesn't seem to be
aimed at creating cover traffic). I should have googled
(duckduckgone?) first.

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

iQEcBAEBAgAGBQJPrM+uAAoJEBEET9GfxSfMgkoIAL0l2z9YbNP7TIk2ZOQD8sLa
5UsRxlzgRyGWRDLAib1jkBmH+AKZqwCMnPC8zCAvnhhyDHk04aU6NjXGgyBkAFYe
r9tKdc41PvNzvGd4cXvGZQAu5tUbLsfuHzEI+AeCvembU/OguI7Q+C35gYK/XlgT
mhAMCB39oA7BdQGLTgEg7DEOZmvYvvHaABK7ypYRnH5AKIW1UYHulQBIKNqBfLyH
9GL3lh4RT1mSbsVnj9Z19lli4yRPT8/0uBvwoCokBAAV0qNuTczrlY3fl54l7+7m
86ry8Fpdx0bOIORT0kMXWqaYIRkw03vGtzPOjuieapStAHKSFMEjOOixe27Rw20=
=jf3r
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] Berlin Biennale Hackathon feat. various P2P/social projects

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Anne,

I don't know of any written documentation of the discussion, but that
issue was definitely raised, and I think it's fair to say that it
contributed to the decision to hold the hackathon at IN-Berlin rather
than the gallery/occupation.

Cheers,
Michael

On 15/05/12 13:55, Anne Roth wrote:
> 
> Glad to hear about this, being a Moabit inhabitant myself.
> 
> Have to say though that I'm a bit sceptical about politics being 
> staged as an art project, as part of an exhibition that mostly
> takes part in Berlin's most gentrified part of town? I'm sure
> there's been extensive discussion about this, I just didn't follow
> it at all. (I'd be glad if anyone could point me to any articles
> etc. - no need to reinvent the wheel)
> 
> Anne
> 
> 
> Am 15.05.12 13:28, schrieb James Vasile:
>> Excellent to hear of this work, Carlo.  Please do let us know
>> how it goes!
>> 
>> carlo von lynX  writes:
>> 
>>> It started rather informally and even a bit rough concerning
>>> the working conditions but yesterday it turned out so
>>> professional and productive that it deserves to be comunicated
>>> better:
>>> 
>>> There is a hackathon event related to Berlin's Biennale,
>>> together with GNUnet, Briar, SecuShare, Lorea, UnlikeUs,
>>> TheGlobalSquare and a special guest from Bitcoin on the topic
>>> of Distributed Social Networks.
>>> 
>>> The plan is to sit down together and synchronize our
>>> development efforts; understand each other's architectures; to
>>> distribute tasks, share code and reduce duplication. Hereby we
>>> want to invite you to hack with us.
>>> 
>>> It is taking place at IN-Berlin, a hackerspace in Moabit at 
>>> Lehrter Straße 53, 10557 Berlin, until 17th of May, but most
>>> of us will be around for several days longer and keep meeting
>>> in town.
>>> 
>>> 
>>> -- »»» psyc://psyced.org/~lynX »»» irc://psyced.org/welcome
>>> »»» xmpp:l...@psyced.org »»» https://psyced.org/PSYC/ 
>>> ___ liberationtech 
>>> mailing list liberationtech@lists.stanford.edu
>>> 
>>> Should you need to change your subscription options, please go 
>>> to:
>>> 
>>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>> 
>>> If you would like to receive a daily digest, click "yes" (once 
>>> you click above) next to "would you like to receive list mail 
>>> batched in a daily digest?"
>>> 
>>> You will need the user name and password you receive from the 
>>> list moderator in monthly reminders. You may ask for a
>>> reminder here: 
>>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>> 
>>> Should you need immediate assistance, please contact the list 
>>> moderator.
>>> 
>>> Please don't forget to follow us on 
>>> http://twitter.com/#!/Liberationtech
>>> 
>>> 
>>> ___ liberationtech 
>>> mailing list liberationtech@lists.stanford.edu
>>> 
>>> Should you need to change your subscription options, please go 
>>> to:
>>> 
>>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>> 
>>> If you would like to receive a daily digest, click "yes" (once 
>>> you click above) next to "would you like to receive list mail 
>>> batched in a daily digest?"
>>> 
>>> You will need the user name and password you receive from the 
>>> list moderator in monthly reminders. You may ask for a
>>> reminder here: 
>>> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>>> 
>>> Should you need immediate assistance, please contact the list 
>>> moderator.
>>> 
>>> Please don't forget to follow us on 
>>> http://twitter.com/#!/Liberationtech
> 
> 

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

iQEcBAEBAgAGBQJPsoWjAAoJEBEET9GfxSfMBawIALVobkmBl/TXbmQtPvmSFBfl
CPznvWfx1wk6VL6xDkX3XGgFfZhXB3yZeUY4BX0+pzJ5b5uj48BmnU1nY4GZwJSe
PtzZ/G4lWiK4srJewz9BXwEO5onxWm3iFBImVbLGE9lJAkYblvAHkxBgbpqUpt20
suASYE+q9MRGJuIN7UYcqqjby5ScoHX5/IauM+std8qldr44zVPiKgGlr/gVx9OD
WBTh7hUCGNkmRpaORztd9FotD0lNT5Z0usg/+qK4MYotlD36Sk/FBxDIdFiYyB1s
mdpgFpzfLV6DKkMLpPHs0zhefOeE4XGAd0Fvb2B40qpq1ErwFiOFYxnyZnI5dZU=
=p0jC
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] FB-like "Twitter-connect" soon. How can we avoid all this tracking?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 25/05/12 08:33, The Dod wrote:
> How can we minimize the damage? The key (IMHO) is a webmaster (and
> user) awareness campaign to use a [yet to be developed]
> "fetch-a-button" ajax widget with buttons like (lame phrasing): "I
> want to like this" or "I want to tweet this". These would fetch the
> code (and thus - snitch) only for people planning to /publicly
> admit/ they've watched the page :-)
> 
> The widget doesn't seem too hard to write (famous last words), but
> the awareness campaign seems to be a much heavier task.
> 
> Any ideas?

Someone's already written the code, but I'm not sure what to do about
publicity - maybe translating the docs from German to English would help?

https://translate.googleusercontent.com/translate_c?hl=de&sl=de&tl=en&u=http://www.heise.de/ct/artikel/2-Klicks-fuer-mehr-Datenschutz-1333879.html

https://translate.googleusercontent.com/translate_c?hl=de&&sl=de&tl=en&u=http://www.heise.de/extras/socialshareprivacy/

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

iQEcBAEBAgAGBQJPv02QAAoJEBEET9GfxSfMC/UH/R+JvZq6lr759eCR8xE+M+zi
WDP1P0szV/UaA/x6UbtFf1J11d4u52DNl6PWkqADKJeQnRYZEntfN4YniE+NhkvO
EE+kqB/c6dR4IQsXRoQgFqsVwx5g0EObm5yCNfqtiWtsvb/LUtyBOk5W7Nim4L3o
ryMH7WzWnF2GtNa45oFIa2p2UFPoeeEHvlUPHefbX87Q4YJIyXh8CyCEE0riV8bS
1WPmBIvBB3YPNgto4vBFp9PDjheclSmD2BrIJHLc2CoxtBjUVQOy3WNWfsbzNiKj
Z1Ze7TWvENQrbxYsyoZBCz4UX1R4llDtCYF9Un3v9eBgKHA58q6hQNp49DloER0=
=ygJf
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

[liberationtech] Briar hackathon

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

If you're in London next Friday, I'll be hosting a Briar hackathon at
London Hackspace:

http://wiki.london.hackspace.org.uk/view/Workshops/Briar_hackathon

Please spread the word! The event's timed to coincide with Google's
Develop for Good challenge to develop conflict reporting tools for
blackout situations in repressive regimes:

https://sites.google.com/site/ioextended12/agenda-overview/hackathons/googleideas

Cheers,
Michael

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

iQEcBAEBAgAGBQJP4HbVAAoJEBEET9GfxSfMj1kH/jCzI+8xGLlIDfIcdpximIM0
chINFYOn/rVIUQ7kWy6brpDCqJVcaShD1kHOeWvw/txvylHp2xLOfJLSFjSI7zaF
BizKr5kDi7uIltX/PUcWmEHjNK06wd09nTvCEXiMfCI2LezLMOOIIDh8tZqmXStA
gGeCwbxX421s92qUKVZ5qpc+xATNEq4S/PFS3s58+3xq6+nftC+H1qzrFVhhXEKs
wupAPSCtqZQjco3kcrBq4+AynsQnEwD5qCzp/uGZyaIDSMsJQFJmsR/KGOiI7Dy0
eAahHALiBJNVdRLkv5sVe+spoe0XFXFSS5bKxC8kwm6o5AHpEah4NwE0+V9cSrU=
=OGzI
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] CfP: Info Tech & Homeland Security -- Special Issue IJEP

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/06/12 00:25, Yosem Companys wrote:
> The special issue explores implications and issues with a view to
> suggesting appropriate strategies to improve the system design by
> highlighting the political implications of technology.

The purpose of politics is to optimise the performance of the security
apparatus?

Extraordinary.

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

iQEcBAEBAgAGBQJP6PX4AAoJEBEET9GfxSfMIPYIAI/U0KZTiOHskVlak8uoDsRI
pewOa89JEf9JbPTuh7B9iqZ6ENh2WQ1CglzHfF0JjmL7dSLMsWWJzIIHYsIwoF9u
vQwLU29SZgZsaiwF0LZaRxhIrdlNaVJZ+tlw+yHmQ9opsA4P1+5IWYMrkjjT0Drh
ld4rDDYxKXb0RXYIvlwu3WFRb/O6uctUR7gFA6DzEJuuHx4osiqqHDSv8KgYY5Sa
c/9Q7trxFFg0mm4QfyxfbJbrVR3MypCw+iLJmhx4vklQaCYV9Si+WEnlE7ZMAcPu
j0e+emnIU3aNQ+O//f2MkltmTHSRp5IJpLa4sZM2awtsPXFb/CqSVjuVr97s8dw=
=a4qW
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] secure wipe of flash memory

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Oli,

I've heard that some Android devices use controller chips for their
internal flash storage, making the storage appear as a block device
from the kernel's point of view, while others allow the kernel to
access the flash chips directly. In the former case the storage will
contain an ordinary block-oriented filesystem like ext2, while in the
latter case it will contain a flash-specific filesystem like YAFFS.

I have no idea how common each case is, but it would be easy to find
out by checking the contents of /etc/mtab on a sample of Android
devices. Is anyone on the list in a position to do that?

Some researchers in Korea have created a modified version of YAFFS
that supports secure file deletion, which could be used to create a
custom Android ROM that would support secure deletion on devices with
directly accessible flash chips:

http://oslab.ssu.ac.kr/pdf/2008-5.pdf

If the modified version of YAFFS is used then an Android device with
directly accessible flash chips is preferable to one with a controller
chip. But if the modified version of YAFFS isn't used, an Android
device with a controller chip is preferable, because directly
accessible flash chips are also directly accessible to the adversary
without additional hardware (search for MTD forensics).

As far as I can tell, USB flash devices and SD cards include a
controller chip that presents a block device interface, so they
probably can't be used with the modified version of YAFFS.

As you pointed out, encrypting the data before storing it seems to be
the best solution. But there are a couple of snags. The first is key
storage: either the user will have to remember the key or the device
will have to store it somewhere. I don't know much about Android - is
there a small amount of securely deletable non-volatile storage that's
available on all Android devices?

The second snag is more subtle. A simple way to do encrypted storage
is to use a stream cipher that supports random access to the
keystream, such as AES in CTR mode. The i^th byte of the ciphertext is
the i^th byte of the plaintext XORed with the i^th byte of the
keystream. You can seek to any point in the storage and efficiently
calculate the keystream needed to read or write that part of the
storage. So far so good.

*But* every time you overwrite a given part of the storage, you use
the same part of the keystream. If the adversary gets two versions of
the same part of the ciphertext, the XOR of the ciphertexts equals the
XOR of the plaintexts. (In the worst case, one of the plaintexts is
all zeroes and the adversary learns the other plaintext.)

On a magnetic disk this situation is unlikely, because overwriting a
logical location usually overwrites the same physical location. But on
a flash disk the opposite is true: the controller goes out of its way
*not* to overwrite the same physical location. So the encryption
scheme needs to be chosen under the assumption that the adversary will
have access to multiple versions of the same part of the ciphertext.

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

iQEcBAEBAgAGBQJQA/YqAAoJEBEET9GfxSfMb9IH/2IO7HPv5r4q30mg2mg9No/H
tiASrWrjYn97NYC7iz5C6sAyfOmEyITrj9rQW9H3hHlutWZnGHJXlqfK5xnezlUo
sv7zUlg34aS0AN4smNrVgBXDtuytIxh+s/BQ1JNt4Xv/1BUgZrXigkaPREyxc3vd
ogBhAzVBgtupvG9eDlsxMalOy6N1Fqmam1g5enN7HEkbD0Lk0tQkMTZlb/KPB5XH
FSljvXNhsIgmfZZWnU7KaipMRlZY4Yxd6jXWRfXCq6OT3pn1lkqVqvw30HPer8kw
2RSjhJvceH5GWAX/9IHmBVb2sEv5BDrLKUMqyxCBWaD3loeg81f5Dq59bzLtCgk=
=QtrY
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] secure wipe of flash memory

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/07/12 18:34, James Vasile wrote:
> I've always assumed the flash problem implied two practices:
> 
> 1) Don't save sensitive data in unencrypted form 2) Don't use a 
> swap partition
> 
> Given the limitations of devices as they currently are, is there 
> anything else you would do?

The only other thing I can think of is to use an encryption scheme
that's secure if the adversary gets multiple versions of the ciphertext.

I'm not sure how LUKS, TrueCrypt, etc stack up in this regard.
SQLCipher looks secure as far as I can tell (but I'm *not* a
cryptographer) because it uses a fresh random IV each time it writes a
page:

http://sqlcipher.net/design/

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

iQEcBAEBAgAGBQJQBI1BAAoJEBEET9GfxSfMCXgH/2Arfr/JtqPy8dNfqQ6F3574
cphKmd4M1T8pdhAUlLllgGZUuNKXtpbEAODTvFSxK3lhRsAGZvrEVMS6q2he36bK
iFc6ofsBt4t3mAiQP6m8olvz1NXaBxP5JbzdLAa6tMJ4rVQHKs/lsk4xfB0vj1aY
vNgVLilIkpvwiqvhZUX1wtVdw3ajj23Fk0T24j61SZDlaCdMc4tA9ar+bqzfGF/N
KCcOn8jxcxs31tDqE7GYYf7eUKO4EVO0ZtoiHZq1UdptBW3qHneIWn5AdbRWfpdc
TNoqOPOyowfSSTJqdJJ/4tbguBHJi+UzxKBQHrYDYCjctQfNFKVgCAoX/Y60vkg=
=h1hL
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] secure wipe of flash memory

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi James,

To follow up on this, TrueCrypt uses XTS mode, which as far as I can
tell is designed to protect against an adversary who can read multiple
versions of the ciphertext:

https://en.wikipedia.org/wiki/Disk_encryption_theory#Problem_definition

However, if a flash storage device contains a journalling filesystem
or the controller chip uses journalling, the adversary may be able to
tell when each block of the encrypted volume was updated, which might
reveal the presence of a hidden volume:

http://www.truecrypt.org/docs/?s=journaling-file-systems

Does anyone on the list know whether flash controller chips use
journalling? I'm guessing they might because YAFFS does.

Cheers,
Michael

On 17/07/12 00:48, James Vasile wrote:
> Thanks, Michael.  That's a good thought.  I hadn't factored in the 
> notion of having multiple versions of the ciphertext.  I'll take a
> look at some disk-encryption systems with that in mind.
> 
> -J

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

iQEcBAEBAgAGBQJQCsSDAAoJEBEET9GfxSfMlCIH/1Zh64P75+Y1+aDL5OdW+xTy
XlvOQJ6RF5YUANYKfwGEli6oA+3cEkLsUlL1ZGKSMX3o4whNFP3TEKA1CHOGme7j
gw50ZIk+q2zxU9c3u4AiOsEFpmixhj01GjPOfuQFCQWdGSB+qVUtWKWkALVk8axe
AKQ0b0jaZnRmwgczA4DVqydJjh20sgC/SFKTS675xGwon27wYsS2pIl93Zajemwp
0L75e9FbzgVpGefIieGND2J4vcUlsqMcNqY8ENPtSmz+B8SH99ZjwfjgEm3mpBuG
b62p3kdeI4vNXs5Hr5x6da41sUcjKiJIR0SOPfVV3+CFIf8PARXM0NNgeFMRMw0=
=5Dj4
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] secure wipe of flash memory

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/07/12 18:02, Chris Ball wrote:
> Hi,
> 
> On Sat, Jul 21 2012, Michael Rogers wrote:
>> Does anyone on the list know whether flash controller chips use 
>> journalling? I'm guessing they might because YAFFS does.
> 
> I don't think so -- YAFFS is a filesystem, and the wear-leveling 
> algorithm on the controller only knows how to act on reads/writes 
> to individual blocks on the flash, so they're very different
> layers. The flash controller isn't a replacement for a filesystem;
> you still need to use one, and it may or may not be journaled.
> 
> (Although the independence between wear-leveling algorithm and 
> filesystem isn't total; there's evidence that the vendors teach 
> their firmware how to handle writes to the Windows FAT cleanly.)

Thanks for the information Chris. Perhaps journalling was the wrong
word for me to use - what I'm interested in is whether a forensic
investigator can (partially) reconstruct the order in which the
logical blocks of a flash device were updated. If so, TrueCrypt hidden
volumes could be exposed.

Each time YAFFS updates a logical block, it stores a numbered mapping
from the logical block to a physical block. The numbers reveal the
order of the updates. Do you know whether controller chips do
something similar?

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

iQEcBAEBAgAGBQJQFmmJAAoJEBEET9GfxSfMMi8H/RR3xRubP3+ld7E+JIwqhmfi
k1KE/lIHEKyJ7xlkGQzcCBG42TLcND+LlYQHk87QIyhnB/gFeIpEJUkLtBO3g+p8
aGCrAhYtRgTT+ULBN9EEQ2GdeSq6xL+JOd4l5xFLwtRgn/vDxvpjuN4FyPactDzK
02HFr867TO6BaVb+oVV1Q5EHjiv81O1fa6QHWY5yHIxN4sJDlxZQ+Mk/5Cnkvukd
Ik3iypqnCZODrABsgHfnQHgCGpB88zKIjuiANMpaeke0fUWt+2bpb1reeQlFG/lX
P1J2rqEs4Lsf/hDXIkOJARZmwlz7OsQgGK8VrOSiY9pkFhGp6kw9V/JLF+0fvlA=
=DrW7
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] [p2p-hackers] [Freedombox-discuss] Who's interested in project management & collaboration tools? And...

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/08/12 05:24, Miles Fidelman wrote:
> In some sense, the model sitting in the back of my mind, is: - NNTP
> (with encryption and crypto-based access controls) - easier
> management of (private) group creation - messages containing HTML &
> JavaScript that can do some embedded threading (think about sending
> a Wiki page, the initial page shows up as a news message, edits are
> automatically applied rather than showing up as separate messages)

Hi Miles,

I'm working on a project that's trying to achieve the first two of
those three goals (http://briar.sf.net). I'd be interested in
collaborating on the third goal.

A lot of thought has already gone into asynchronous collaborative
editing - Groove, Wave, Etherpad and distributed version control
systems spring to mind. Groove in particular was designed for a P2P
setting, and the protocols are well documented:

http://msdn.microsoft.com/en-us/library/cc313128%28v=office.12%29.aspx

Perhaps we could start by identifying the subset of Groove's
functionality that would be needed for an Etherpad-like use case?

Cheers,
Michael

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

iQEcBAEBAgAGBQJQHmlSAAoJEBEET9GfxSfMZKQH/2GJ9j4MUNbTwQ+FxLc78SOJ
f0HcsN7teLI2Ik5pF/ywVGvi32hqEoo9RxvdlM8PWF/3o1J4SujpaOtqy7/va5+3
oe1juzqYCiLaqr1jGDbiyzM7OHGbwfpn+JJNnG5rc0nd63EkY/uEZA7eRDkCw1hu
lQYpT7jUc6cfHhRZBwZsJN7sB/C/u5Sf7eWP9sIaVqjNidgkxhcrE+S/F5fdkpD2
gM2Og/r5VKtj9dmUfzWTrxPSZx/h/4o3oEfpDbcLY8eGZXGzZVpzuCOg38ehM2Jd
4Sx7hXUfOIgLwdJoolS2a15GQpNQHnZq9R794XUBSgwvE5GjOGiD1GnMXzjarV8=
=9tMB
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] What I've learned from Cryptocat

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/08/12 06:19, fr...@journalistsecurity.net wrote:
> How many people on this list have spent time asking
> non-technologists and other users who have tried, but have since
> given up even trying to use tools like PGP? Or have examined how
> new users interact with such tools? I have a great deal of respect
> for this community. But to be honest it seems to me that neither
> the technologists nor the donors have spent much time asking such
> questions.

Hi Frank,

I'd just like to make an anecdotal point here. A few months ago I
spent an interesting afternoon talking to some activists in the UK
about what communication tools they use for what tasks.

None of them regularly used PGP, Tor, or disk encryption software, but
the reasons they gave had nothing to do with usability. They were
aware of the tools and knew how to use them, but they didn't believe
that doing so provided any practical security benefits. They believed
that encryption software probably contained backdoors and could be
defeated by keyloggers. They'd seen evidence trails from computers and
phones produced in court, and rather than relying on technology to
solve technology's problems, some of them preferred to avoid
electronic communication altogether for secret work.

It's tempting to say they were right and leave it at that. Keep your
secrets away from your gadgets and your gadgets away from your
secrets. But that wasn't what they were actually doing. They all
carried phones, even though they knew they were being tracked and
possibly bugged. They all had email accounts, and some of them used
mailing lists and forums for planning, even though they knew that if a
keylogger could get their encryption passwords it could get everything
else they typed. Why the apparent inconsistency?

One possible interpretation is that they were assessing encryption
tools with a typical information security mindset: if there's any weak
point, the adversary will exploit it, so the strong points are
irrelevant. But they were assessing other techniques with a more
balanced mindset: weigh up the risks and potential benefits, compare
the available alternatives, and choose the best (or the least bad).

That's only speculation on my part, of course. But if it's right, it
raises a difficult question: how do we maintain rigorous standards of
critique within the information security community, without giving
potential users of our tools the counterproductive impression that
nothing works and you might as well give up?

Cheers,
Michael

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

iQEcBAEBAgAGBQJQIqBNAAoJEBEET9GfxSfMRLEH/04+ESJyNH9S6NYEwno1BvKe
J8kMLCmR6OpolJ15nu3K7GkE4wQnhTmZVIrHApjWGz+8TACGiIQg7rOBl19r4MvA
o/7tANsoUEgLRAO2hHQzA5tg+ZRtS+9oDe6LBVE3arHTCt9dYMW711ToOkgQwdoD
ekNWbC4Ba2aKm3t8JmSUF+goDiadF+nSP0HByvNhKHCjzP/2SLBxDOQqeOMF/kpK
Zej+0BZPCUGLaN6XaqoWw7DxgYfa9uUgx3E2ljwYnZZqcXr41kJp2uHQTZlExyxN
TfiI+2P4bQfJtkK7KcOZtp/QWCAz3whmqV6F5y3tjfcHiEywzByInnKFr3tT5D0=
=mHhw
-END PGP SIGNATURE-
___
liberationtech mailing list
liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) 
next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in 
monthly reminders. You may ask for a reminder here: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

Re: [liberationtech] Ideas for MSc research into HCI, security tools, and privacy.

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Bernard,

There are two areas where I'd love to see some research. The first is
the effect of provenance on perceptions of security: when deciding how
secure they believe a tool to be, how strongly are people influenced
by their knowledge of who created the tool, versus their knowledge of
how the tool works, or other factors?

The second area is how people reason about security boundaries - or to
put it another way, how people reason about the security properties of
data as it moves between devices, between locations and between
applications.

For example, if someone believes that Skype is in some sense "more
secure" than AIM, will that person treat files received over Skype
differently from files received over AIM? What concepts will they
refer to when explaining why they do or don't treat those files
differently?

Knowing more about how people reason about these issues would help
developers to design tools that actually have the properties people
think they have.

Cheers,
Michael

On 22/09/12 16:06, Bernard Tyers - ei8fdb wrote:
> Hi All,
> 
> I am currently researching ideas for my masters in human computer
> systems thesis. I am a mobile telecoms engineer by profession, but
> am interested in HCI, tools that help maintain your security,
> secure communications, and privacy concerns.
> 
> There have been some interesting threads here that have brought up
> some interesting questions for me: ∙ The thread discussing the
> usability of tools, such as cryptocat. How it was (originally) easy
> to use but may not have been as secure as possible. (NB: This is
> not a jab/poke at anybodies work, or an excuse to bring up any of
> the previous discussions about Cryptocat) ∙ The perception of tools
> which are easy to use but may not be secure, eg. Viber, whereas
> other tools are seen as secure, ∙ There are no shortcuts to being
> secure.
> 
> I am developing some ideas at the moment, which are mainly around
> mobile, privacy, security, encryption tools, people's use of these
> tools (and why some people don't use them), how to present
> information such as  possible interference with Internet users
> traffic.
> 
> I would be very interested to hear from anyone (on or off-list) who
> has any suggestions, "I'd love to know XYZ" questions, or projects
> that are currently on-going that may benefit from a MSc level
> research project into the intersecting topics mentioned above. I am
> open to discussing any ideas, so please let me know if you have an
> idea.
> 
> thanks in advance, Bernard
> 
> -- Bernard / bluboxthief /
> ei8fdb
> 
> IO91XM / www.ei8fdb.org
> 
> -- Unsubscribe, change to digest, or change password at:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
> 

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

iQEcBAEBAgAGBQJQXdw2AAoJEBEET9GfxSfM6OYIALdFW4DhU70nWb0OrqxkvqKa
WBbHtAFooKKYVwn1l7K72KyxHDvcq7bpvL8yZQuv3InF0fs0CDqf90op6eIpgFZp
ViqsP4rtSDWjFdn+S2NZvscyPCs6uEU8et0kPo3Q4gYUBD8orbsa6M+6Plu+tso8
QPI16gm6e2AHeAzXvyUZGcpdDpgOgdBbWP6SJHk21Bv6/wsqilMIRh4WXEZeo/Oh
e1Lx7SAOqqT3Dp4/V2Qwy1AntecDcKHFFUK87zNPnIvDZMQ7YNWUG0kaPSga3ux5
BVf6y4tlrweqvR7sGi9vi+tY0VNPYYEtqjRDnVNQrJ3FI6pcfm9goKPkcMBTGwU=
=xh9r
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Ideas for MSc research into HCI, security tools, and privacy.

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/09/12 16:56, Bernard Tyers - ei8fdb wrote:
> I have the feeling (backed up by observation) there is a similar
> approach by some people open source software, where the argument of
>  "the developer is good so s/he wouldn't do anything bad".

Absolutely - and it might be interesting to unpack the notion
"wouldn't do anything bad" into "wouldn't do anything malicious" and
"wouldn't make any mistakes". Do we tend to conflate one with the other?

>> Knowing more about how people reason about these issues would
>> help developers to design tools that actually have the properties
>> people think they have.
> 
> Do you have any information or resources on this?

I wish I did, but I'm really a beginner at thinking about usability.
I'd love to hear about any resources you find.

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

iQEcBAEBAgAGBQJQXeMAAAoJEBEET9GfxSfMvg8IAL9R5UzhyBeqaNnsn50AahqF
NHEua+lBdGjr9oYnVE4CURCPmOJc1UdCOzG/18GaHpRPqHl+VuX3F8/f4K1J8fD4
reuca/ufanG9IPDT8uQ/Wn0X3sA6beXaKkpOV/897hw46nAq22QbcSxmw384OuBz
2NaigzAV/VJkoiPSxnsHZLZgDSEOSCGDX5Uzcorj1Qdp+dOlNiU4TfQXZ09MD/+0
pp3kNczppaIvXRQ43tnCY1/4TePX9ma85TFrMPu9Hpd27xU3YyS2EVHamuMeemMq
cvRuzEUEvVxx0Na/xURXqjXDBcUcija487UqS/OEi+kcIVvbFl/jf2HQ9nldjc8=
=YJk0
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] hardware options for a computer phone, not a mobile phone...

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/09/12 16:24, John Case wrote:

> So the question ... what is the handset ?
> 
> If a handheld linux computer (archos ?  old compaq ipaq ?) wasn't 
> designed as a mobile phone, it won't have speaker at the ear and
> mic at the mouth as you would expect, so that's difficult.  OTOH,
> if you use a handheld computer that was designed as a phone, you
> have a problem with the tight integration of the mobile modem with
> the device, and you lose some control over the modem and its attack
> vectors (although if you are running a completely open OS, perhaps
> not ?)

Hi John,

The Samsung Galaxy Player is essentially an Android phone without GSM
hardware. It's phone sized and has a microphone and speaker suitable
for making VoIP calls.

I believe it's possible to install CyanogenMod on it to get a
completely free software stack. I don't know whether anyone's tried
connecting a USB GSM modem.

Cheers,
Michael

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

iQEcBAEBAgAGBQJQaJSYAAoJEBEET9GfxSfMCPkH/3qAPw7ZXzBGgnZRRwXAy7ar
sYribMx+vZhz/izJisDAA/+CJ2pIaDu0goiQdVoJrnRCU+/7mKB9GPv4i8cGjKP7
+2BdZEw3nD+jci/OvtNvQS4vELaGk5hXWg/bAQctRYTlP+PaWUWF7m1h+S9LpvZs
bE1nsSJVNaGqdbPQeBt7jYU+qyfrtMA2OuGixb8/2HtoQ3uQ73/svQjeAo9tLP/k
iaXPFEMbjld/Vm/xdyeW7FJl1YTDC5eyZewArY2+btU8J7nUI9gMXwKTb+Fl8FAL
CxHvAbygsxgyyNowBg3gfmY7jzQEUsXLiXEX8J9WnF225egJxy9Nrk0/XJ2EgRw=
=Fsjh
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] secure text collaboration platforms

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Sam,

On 03/10/12 10:25, Sam de Silva wrote:
> Can someone help me out - Is http://www.piratepad.net secure? I
> thought it was, but I can't seem to access it via SSL.

As far as I know, the pad software used by PiratePad and similar
services doesn't support SSL. It might be possible to combine the
software with stunnel (http://stunnel.org) to add SSL support, but I
haven't heard of anyone trying it.

> It'll also be really useful to know of 'piratepad' type platforms
> that are secure, and there's controls over deleting the
> collaborative pads/docs.

Etherpad Lite has an HTTP API that can be used to delete pads:
https://github.com/Pita/etherpad-lite/blob/master/doc/api/http_api.md

There's been some discussion about making the same functionality
available through a dashboard, but I don't think that's happened yet:
https://github.com/Pita/etherpad-lite/issues/192

There are a couple of other security issues you might want to
consider. First, the pad server (and anyone who hacks into the server)
can read and modify any pad. No server is completely secure, so it's
worth considering whether the pad server you're using contains
valuable enough information to be worth someone's while to hack into.

Second, if you create a named pad with Etherpad Lite, anyone who can
guess the pad's name can access the pad. If you create an unnamed pad,
a name is generated using Javascript's Math.random() function, which
is not a strong source of randomness, so it might be possible for an
attacker to guess the random name and access the pad.

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

iQEcBAEBAgAGBQJQbCs0AAoJEBEET9GfxSfMgKEH/1rGH6GNm0DpDO6lnFJnTBvH
kEnNSjU3b5BuYIw39wYfG3GE3sOsFuTnt0/KMWGB9M+FXqpNo08Yt3HXUfv2Lii0
eIm9JOLb1/CfmnCyCnVgkYKs2vORQmolAMSu+pqxuY1hb4GwfLRG+uY5wu6jA4fc
CpdFz8ylPmoEfptbIpAhvuh2t2QAPcOvHKSs3xA4hafeDLXG7mebmG7Rbft+gs9G
v8w4NMxrXiKoB6v7kR7ZOO7Jr1uRLUMn6prhVS+99v46QPyxGZDjiXO+VRohC2DG
LsqkgyhdGY8a1FXVeUAKVc0YTud4I1E1d135TqqpE9DsFmh/QgEP2QSk/XZl1zg=
=bWOj
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] secure text collaboration platforms

[Michael Rogers]

Sorry, I misremembered the problem I ran into when trying to configure Etherpad 
Lite with SSL support - the problem was with my certificate, not with Etherpad 
Lite. Thanks for the correction.

Cheers,
Michael

Pavol Luptak  wrote:

>On Wed, Oct 03, 2012 at 01:10:28PM +0100, Michael Rogers wrote:
>> As far as I know, the pad software used by PiratePad and similar
>> services doesn't support SSL. It might be possible to combine the
>
>This is not true - etherpad supports SSL natively (directives
>sslKeyStore and sslStorePassword ). I run it without problems.
>
>Pavol
>-- 
>___
>[wil...@trip.sk] [http://trip.sk/wilder/] [talker: ttt.sk 5678]
>
>--
>Unsubscribe, change to digest, or change password at: 
>https://mailman.stanford.edu/mailman/listinfo/liberationtech
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] hardware options for a computer phone, not a mobile phone...

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/10/12 16:39, John Case wrote:
> Ok, fine.  But out of curiousity, how much risk does a mobile phone
> with no sim card add to a solution like that ?
> 
> GSM, and 3G, are designed around the sim card, so I understand
> that basically nothing can happen at all without it - I feel
> relatively certain that a typical carrier deployed base station,
> etc., is "powerless" against my phone with no sim card inserted.
> 
> But what if I was very tinfoilhat-crazy-paranoid - what kind of
> scenario or attack could I be susceptible to if I had an actual
> *phone* with no sim card installed (as opposed to a device like
> samsung galaxy player that has no mobile radio installed AT ALL)
> ?

My Android phones (Huawei U8110 and Samsung Galaxy Nexus) allow
emergency calls when booted without SIM cards, suggesting they're
capable of talking to the GSM network.

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

iQEcBAEBAgAGBQJQkATsAAoJEBEET9GfxSfMtQEH/iqR1rWuy6Q+UO4VC8bg4FGI
EyqOyBaam5NmezI0vuQfM0IUWy74jeiFT8nly/e8Ei6om1nJ/4JUV4LpM7uVPrza
ZIXEbOautDDgDwM6Fm97xb5Pwk/UT0pm0E4FYwyifznwStuGF8kBt/+eyNEtIaaY
Bigo5HoctiYpbLRlsCgrQmNwZW4A50+mIzResBCuQU2A+pIUKxmG+Pz9TdzjRKx8
Nvf9aXKRVkjGhzSr0vHZ5A+zQOjlYfqxbwSp6sf4TLDRQR1Ulcg9YU2ucSSl002i
JRvLHFR8p0Ga3ZEoXBJqV9g5Xd3+6/0JAA+E0BsYa2bPWxbKAqjnWcc3T3ke0SA=
=Hw9V
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Syria's Digital Proxy War | The Atlantic

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'd be interested to hear the views of people on this list as to
whether they see themselves as being involved in a proxy war.

Cheers,
Michael

On 01/11/12 20:19, Rachel Fredman wrote:
> Of interest to many on this list:
> 
> 
> Syria's Digital Proxy War
> 
> 
> By Sean Lyngaas
> 
> /Iran and the United States are squaring off in a life-or-death
> battle for information./
> 
> RTR2YJLN-615.jpg A Free Syrian Army fighter speaks on a radio in al
> Qusayr. (Goran Tomasevic/Reuters)
> 
> There is a proxy war going on in Syria, one measured in megabytes
> rather than in arms. On one side, Iran is providing Bashar
> al-Assad's regime with the tools of digital dictatorship to locate
> and bait the Syrian opposition. On the other side, the United
> States is trying to help the opposition protect itself from such
> attacks and set up alternate channels of communication. The outcome
> of this proxy war will affect the lives of many Syrians and the
> credibility of the State Department's efforts to promote digital
> freedom internationally.
> 
> The Syrian regime has long been interested in improving its online 
> repression. Dlshad Othman, a member of the Syrian opposition and
> an Internet expert, says that in recent years the regime has sent
> its bureaucrats abroad for technical training in places like Dubai.
> But Assad's censorship efforts remained clumsy and at times
> ineffectual until the uprising against him began last year. He then
> re-opened social media to the public in order to better monitor and
> crush dissent, and confided in the Iranian Ministry of Intelligence
> and Security for surveillance techniques. We are now seeing Iran's
> sophisticated online crackdown on its own Green Movement in 2009
> being applied by Assad in Syria. Pro-regime hackers pose as
> dissidents 
> 
>
> 
in chat rooms to lure and locate the opposition before gunmen are
> dispatched to kill them.
> 
> Contrary to recent reports that the Syrian regime could unplug the 
> country from the web entirely, Assad considers the Internet a vital
> tool to winning the civil war. This is a cyber war, Othman told me.
> It is an opportune time for the United States to show that its
> support of digital freedom can save lives. If communications
> technology is the way in which the United States chooses to
> intervene in the Syrian conflict, why not unleash the full
> capabilities of American technology?
> 
> An argument against arming the rebels is the possibility of
> weapons ending up in jihadist hands. But is communications
> equipment just as dangerous? On the contrary, more coordinated and
> safer communications between commanding officers in the Free Syrian
> Army and the jihadists who have joined their cause may help reel in
> the latter in a post-Assad Syria.
> 
> There are currently two separate U.S. policies that are falling
> short of Washington's goal of safer and more widespread
> communication among the Syrian opposition. The first is American
> sanctions on Syria that make it more difficult for the regime's
> opponents to obtain vital anti-tracking software. With fewer tools
> to evade government surveillance, these Syrian activists are more
> vulnerable to Assad's death squads. The second is the State
> Department's distribution of satellite phones, modems, and other
> gear to the Syrian opposition through a training program based in 
> Istanbul. Reports that this equipment has only on occasion reached
> the front lines bode ill for the rebels and for America's future
> influence in Syria.
> 
> Secretary of State Hillary Clinton has made the freedom to
> communicate -- whether online, on the phone, or in the public
> square -- a central goal of U.S. statecraft over the last four
> years. The State Department has ramped up funding for projects
> promoting Internet freedom, with $30 million allocated last year on
> circumventing censorship.
> 
> But for every dollar the United States has spent on Internet
> freedom, countries like Iran and China have spent many times more
> in countermeasures. Iran has spent about $1 billion on an internal
> version of the Internet that analysts say is nearing completion.
> /The Washington Post /reported 
> 
>
> 
this week that there is a shortfall in funding for the State Department
> Internet freedom program. With budget cuts looming over many U.S. 
> foreign aid programs because of the fiscal crisis, the funding gap 
> between Tehran and Washington on the subject seems likely to
> widen.
> 
> Iran's Supreme Leader Ayatollah Ali Khamenei has called his
> country's investment 

Re: [liberationtech] Forbes recommends tools for journalists

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/12/12 20:12, Danny O'Brien wrote:
> I think these days you have to tie Forbes' (good) advice not to
> save everything with an encouragement to use full disk encryption.
> We're in an awkward space right now where we can't fully guarantee
> that data gets deleted off a modern flash (SSD) drive, even with
> previously strong deletion tools. And forensics software is good
> enough to pick up a lot of local clues about what you've used your
> own computer for, even if you think you've turned off all logs and
> removed the saving of sensitive data. Minimize what you record, but
> also encrypt.

Sorry to go off on a tech tangent after you've rightly pointed out
that this isn't simply a matter of choosing the right tech, but I'd
like to ask the list for a bit of advice regarding secure deletion
from SSDs.

Secure deletion is a problem we could solve in software, by encrypting
the data and then destroying the key to render the data unrecoverable,
*if* we had a few bytes of persistent, erasable storage in which to
store the key. (Storing the key on the SSD itself doesn't work,
because then we can't securely delete the key.)

I'm not aware of any suitable storage on current smartphones or
personal computers, so we may need to ask device manufacturers to add
(simple, inexpensive) hardware to their devices to support secure
deletion.

So I have two questions for the list: who should we try to persuade,
and how should we persuade them?

Cheers,
Michael

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

iQEcBAEBAgAGBQJQz5G1AAoJEBEET9GfxSfMFSoH/jQ0HtBhP2bDhYLGGXk7ESU1
onC5tMBFUvvQzsqmVeV/HmEciW+WPeJ942Oek7r0DEWiBseFF3tMzquG/Yc4pURn
hYaRNlEjIzPFyZ+9kXiU7cUwGozoThKw+CxwBB4LKSEOSlqn28EmPGsKG59seDrS
3PJtqPcYKCWqKXmhIu3Hzc3Zn5dsRKeWZYmv9nQm40kj3YrR4OPoz/roCT72OUDu
E/SRCmd/zgDSy556OJ8U0xu3KNU9JLebWxYV+HRfAyctbjCnDP63LD+ABjKr+lTn
lQnvXB9rJtB/yzyewiG++ZlT7bpzLZ5L5hI1UkHv8Udqyfnp463Azq88Plbi5MY=
=9K1+
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Forbes recommends tools for journalists

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/12/12 23:25, Eric S Johnson wrote:
>> I'm not aware of any suitable storage on current smartphones or 
>> personal computers
> 
> Isn't this exactly how the iOS (v4+) can be remotely "wiped" in a
> couple seconds? Everything's encrypted, so deleting the key ...
> 
> Or are we saying the iOS's storage of the key is insecure?

Hi Eric,

Good point - it slipped my mind before but I've also heard that the
iPhone uses hardware support of some kind for its encrypted storage.
Does anyone know the details? Is the key stored on a separate,
securely erasable medium, or on the SSD itself, protected only by the PIN?

Cheers,
Michael

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

iQEcBAEBAgAGBQJQz+gxAAoJEBEET9GfxSfMD3kH/0eW6hyfdgn+4HWZGmpVD4kQ
zxCQwNr9wfN/a6jb7HX8eAh8TRM/IR0EG/GoUTNCglu5islFGvyyv7osHrPzIUUy
epxLlM+VXVacsLcLb0BrmIzSW9vH/aKqS+N6Ebl4QNTm+T8x13zf25Rnczpqx3G/
37TfuAlSiCHpDXs/maBO/MrErhkpd8RXhq2YN4p+BcV8uh6MbBA5TtGyOx5NBjxB
lBY+bP2X261rzgwVSnvf5n+MhUtQB/HwgoBTw4nIUbj251VPmaeknYs4eOWC8pKY
dDL+PUwjiiykDmhOtVScHc30SCOKxf+0U08IyS2JDE625AJ8s3IEAcnvCwd/VqY=
=zsrj
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Forbes recommends tools for journalists

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/12/12 23:25, Eric S Johnson wrote:
>> Secure deletion is a problem we could solve in software, by
>> encrypting the data and then destroying the key to render the
>> data unrecoverable, *if* we had a few bytes of persistent,
>> erasable storage in which to store the key. (Storing the key on
>> the SSD itself doesn't work, because then we can't securely
>> delete the key.)
>> 
>> I'm not aware of any suitable storage on current smartphones or 
>> personal computers
> 
> Isn't this exactly how the iOS (v4+) can be remotely "wiped" in a
> couple seconds? Everything's encrypted, so deleting the key ...
> 
> Or are we saying the iOS's storage of the key is insecure?

A quick follow-up on this: iOS 4 and 5 store the encryption key for
the data partition in a special effaceable area of the SSD. The flash
translation layer, which maps logical to physical blocks, is
implemented in software, and thus the data partition can be securely
deleted when the device is wiped, by erasing the physical blocks of
the effaceable area.

However, secure deletion is all or nothing: if the device is wiped
before the adversary gains access to it, no data can be recovered. But
if the adversary gains access before the device is wiped, the device
can be booted with a custom ramdisk that can dump the contents of the
data partition - presumably including any deleted/overwritten data
left behind by the flash translation layer, since the custom ramdisk
can use its own software FTL to read the physical blocks.

That's not the end of the story: individual files within the data
partition can be further encrypted with keys derived from a
combination of a device-specific UID key and the user's passcode. Even
with a custom ramdisk, decrypting those files requires a brute force
attack on the passcode, which is slow because the device doesn't allow
direct access to the UID key and thus the brute force attack must be
run on the device itself.

TL;DR: wiping the device securely deletes everything, but if the
device isn't wiped, deleted data that wasn't protected by the passcode
can be recovered, and deleted data that was protected by the passcode
may be recoverable by brute forcing the passcode or learning it from
the user.

Source:
http://esec-lab.sogeti.com/dotclear/public/publications/11-hitbamsterdam-iphonedataprotection.pdf

Cheers,
Michael

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

iQEcBAEBAgAGBQJQ2L81AAoJEBEET9GfxSfMWzMH/0gjaOxitGgQnpq0tULWJe+9
+/i6vMlnFuLvPbVeYbV732hC89wGbxIks68hBc0eDCm5/rfnXH9AaCUpOlfQ+dlv
fgnrvFfbe+3hW1uHKo0R6fmx+/HUINW0UOxqaDn9hcIMbS+5J8mtuDpB8M8RwoWq
Y0q8LWZJfG8QojaMVTnTic+J8E4mde6sgFAvRGPhGz1ZoUZDxwgcEbsU25J949ZX
64K3pP6GM8/l/i0tQJzJDFEkLTKgRfa7nrXbX068pAXVbqsoOzTl7Qzl2T9q6fOk
B+zdI8hSv291OEQ20Bf7FHlEKWwG9mKEQWWJk+OaghmDsAr8j8lAZKNB4eh5t7M=
=N9sd
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Certificate authority and email

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 29/12/12 13:47, Jerzy Łogiewa wrote:
> Do any system besides WWW use the CA? SSL-guarded email in some
> case for ęxample? Is HTTPS all to worry about?

Hi Jerzy,

Yes, SSL-based email uses the same CA system as HTTPS.

Cheers,
Michael

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

iQEcBAEBAgAGBQJQ3xXoAAoJEBEET9GfxSfMSGsIAJGROW95jWYrzrz2Lso2+T/H
rEZGeuzQRQcvyPq4nVJv+wwXR40jZMck0aDUUS+ynCxAu8k2lK7ud17DXfQBDytx
lkCScvT/c9MfhEHpajvFTCtjA+BUBpPgrZ+w2idCMWp3MQSfWWqGuT0rAFJ+f7yu
ABDv250QsZu9BTCWJMc8SRGiBE1ijdrv+oL9Zzt+96Zo6isnPEzpKxuUCQ+UbuwW
gH32yPxUnX0oXUL7W435/Ogf/mqEo+Fv4k6wva3npcffbBTIvXErO4sOd7Ls4LUw
0lcK9ZCwaYf6NallBxGk1Kd6te62TYMYjSqGFZSVb0jB4jMtMvCi+V7efL6P7s0=
=+FOV
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Chromebooks for Risky Situations?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/02/13 15:52, Rich Kulawiec wrote:
> Many operating systems and applications and even application
> extensions (e.g., Firefox extensions) now attempt to discover the
> presence of updates for themselves either automatically or because
> a user instructs them to do. Is there any published research on the
> security consequences of doing so? (What I'm thinking of is an
> adversary who observes network traffic and thus can ascertain
> operating system type/version/patch level, installed application
> base/version/patch level, etc.)

I'd be interested to hear about rollback attacks on such mechanisms.
For example, Debian's security updates are signed, but they're fetched
over an unauthenticated channel. Can an attacker fool a Debian system
into believing that no updates are available?

Cheers,
Michael

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

iQEcBAEBAgAGBQJREoCaAAoJEBEET9GfxSfMWtQH/jfcN0wynzMtAfVJ91S4y84f
qiHbKYaNswQFjvLRzxTGw9J9GYwhaZF/I1BbfYvd6f5q7Vj+b44SkndQT8SDjsHt
4Bj96rD+K5u5lGWXJjVvJHR1k5EGg+MREKe/6Kj4SKT8gRPLY8Scs7A3ZkxoGkNj
S58e664+5Zb0lyezbnXqtf/smZ8jZ4IERam5JLpn0I0dTVeeT6r9W2h6gQoNZzHG
mp8X08r0xsV3vY3o2qrSPiA4EllKnxzam/HOOWIcLDKQzkRARI/wgZ67dkw0b3lE
kireffjEHGuwl64xrOUDrP0+LoyvQAnswlPphpyxrUCrP3ufMQ5wG1qEa9vm4Zo=
=S4z6
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] advice on securing a new computer

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/02/13 07:37, Douglas Lucas wrote:
> I should note the solution I came up with for this. "Use a firewall
> to monitor for suspicious outbound traffic." I guess that's the
> best solution there is short of disassembling the new machine and
> knowing what you're looking at.

I suppose one could imagine a Telex-like system for hiding exfiltrated
data in the random fields of an encrypted protocol, for reception by a
network middlebox. Especially if one had suitable middleboxes
installed in secret rooms all over the US. ;-)

Cheers,
Michael

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

iQEcBAEBAgAGBQJRGVZIAAoJEBEET9GfxSfMr0MH/0jZrf12C/HS0mRIfUYqcChC
Mn1bh4XiPi71XwlqC2BkvghEtNANwjPJorsBG61cBDx5e/pG+wwKKgQJkN+NpCVn
PCaxYgMHFfsD/TvFSbmVbQr1Acw58Wdnp6qvjS+RNuS4xKPw4570P8ph377h+tWX
vwtOHvnGWQE0j0xLLpHf5w7UJSICMFwsaTmJcf8i8KOTlVSi8iXHnBJ7N1kd92af
9Pmtza3+NpmH0QrPrCQr4abSVuVPKfTSLMikjLDyniaj29OpHqwzb0llPEegh09k
J5uGnIJ2jj4d+d3HOIIewW1TQWonrf7vS18HQjjAP+trPPaxoDzo7CLhlBywGE0=
=J2Yk
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Freeze the memory out of a galaxy nexus?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/02/13 18:32, Brian Conley wrote:
> Any idea why the researchers would posit that iOS devices may be
> less susceptible?

iOS has several classes of encrypted storage. For the
NSFileProtectionComplete class, the class key that protects the
individual file keys is erased from memory 10 seconds after the device
is locked. So I guess files encrypted with that class would be
unrecoverable via a cold boot attack if the device had been locked for
10 seconds.

http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf

Android uses a single key to protect all encrypted storage (excluding
apps that use their own encryption, eg SQLCipher), so that key must be
kept in memory whenever the device is running.

http://source.android.com/tech/encryption/android_crypto_implementation.html

Cheers,
Michael

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

iQEcBAEBAgAGBQJRJm4YAAoJEBEET9GfxSfMwi8H/37g4caSmxPQ1DKLkHALqS/u
IIUD1iCrxjAhglRgqMHLUZb/XX12lM+iQ8IqqMWNHQkrw9p04Amd/f+dR+MkAbsf
ndf0grkiIllTuPEm4kcLY9DNcAfH5VavFpoRoEMCKtEAPOtWHAPt93RTkjx6oLAJ
Y8vPHiG4Bndr2GckjpSkdpkIW4dt2uCMfZOd+ALtKnMpSmJpr2I7A8x+iexwIJXP
SLm77PP1rQrOCykvZN+dfuDWH8lYytX37fbabxy5S0VNZtfvPIT4QJIxWW62e1nm
6uE/zTIJlY5WZj6GSxYLsPpcn41Vj3Pfzk7TDT/iPoWSBabRpfLhzuqPK/L2/oo=
=zB77
-END PGP SIGNATURE-
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] CNN writer on leaving Facebook

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 25/02/13 19:03, Raven Jiang CX wrote:
> I think a subtle difference is what exactly the bargain entails. In
> the case of television advertising, it's a relatively
> straightforward exchange of your attention for entertainment.
> Facebook is asking for more than that. The marketing is less
> oppressive because they receive the addition payment of your
> personal information. No one really knows what that information in
> aggregate is worth or can be capable of achieving in the long term,
> so I suppose implicitly the users (at least those aware of this
> bargain) are betting on it being worth less than the services
> Facebook provides.

I don't think framing it as an individual bargain fully captures
what's going on here. Each user gives Facebook information not only
about themselves but about the people they know (including those who
don't use Facebook). So it's a social dilemma or tragedy of the
commons: the cost of each person's privacy choices is shared by
others. Each user of Facebook produces a negative externality that
affects those around them. As such, perhaps the appropriate metaphor
is not "personal information as property" but "surveillance as pollution".

Cheers,
Michael

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

iQEcBAEBAgAGBQJRLNj2AAoJEBEET9GfxSfMqSAH/RPSLGIRRVc6IyLJMAKBYSJE
UVHZ97boE2d9NlatEHenhGmDBoe7Tm2P2oZEnjWS/nazi3Z/mBCS3xOI0HVdH+xH
HcPhDIE/cV0FjhpKAPsW5lYqDQfr3XDauAlvLhzVeMEkzeC8ccDv8TztWEI1spzI
hX2DC9PtKEDuPjkDC50qRazuqWzyGwW3Dj4FGqo8xKRe0i7ZLQFuR9avoOKDI2hi
uUU6+h6P2ORwxotO41GRZHBaFtcGM+kcPS+llidRfuRDu42x57zqAbJRdd24xZAs
yoz9PE28pGe/x1UHMXdzt3bHyCPdoDyeEAloJ324c0+g9sMfr+Lznsmm9vQcfGs=
=ehnW
-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] Efficient digital one-way communication

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/03/13 14:25, Jens Christian Hillerup wrote:
> I basically just wanted to throw it out here. Does anybody have 
> experience in modulating data? Has this kind of digital one-way 
> communication been done in an activist setting before? Does it
> make sense to kick off a project aimed at creating a easily usable
> system capable of modulating and demodulating data at modest
> bitrates (>15KB/s)?

Hi Jens,

Last year I spent some time playing with audio encoding of data for
transmission over handheld radios. The state of the art here is dialup
modems - on a good day they can get 56,000 bits per second over a
channel designed for voice, but that requires advanced modulation and
error correction techniques. The radio hams have packet radio (AX.25
and APRS) running at 1,200-9,600 bps over long distances using simple
modulation and no error correction. Some early home computers used
audio cassettes for storage (300-1,200 bps, CUTS or Kansas City Standard).

If you want to support purely one-way communication (no acks), you'll
need to forward error correct the data. Hamming codes and parity
checks are simple to implement but they'll eat a lot of your
bandwidth; Reed-Solomon codes are more bandwidth-efficient but also
more complex.

Some Java code for modulation, framing and error correction is here if
you're interested:

http://briar.git.sf.net/git/gitweb.cgi?p=briar/sandpit;a=tree;f=src/net/sf/briar/sandpit/modem

http://briar.git.sf.net/git/gitweb.cgi?p=briar/sandpit;a=tree;f=src/net/sf/briar/sandpit/fec

Cheers,
Michael

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

iQEcBAEBAgAGBQJRNMBmAAoJEBEET9GfxSfMytEIAK2Y+r+22fKXbXCTFC2ALigw
NoeHiHu0wfz4phyPZ5Dqk21dvvOFtP2RJaf+XY70cHKaYw2NW3dWnKNRmshJKtfH
oCuZhjRAHhyy8xP+xJFNonEJgQrPkGHe7oFZ6FiqcpmOKL3RPU9G7oyrYYxr1Yas
IX5Oxn7N3dG5BmkrN25VLrEieRumLMzakmywkFb2wQE1aQ2RnnQ9/SUPMnTQiPnV
tK39FvSCJwbNVzmwZemVGMuiH/xiI3zJeIwtIK86HUEcKX9dS5Nk//b2al4RgXD/
mjwDD2ctBqu1JT7hMgOsETU37cU2BE14KpRfpR0mTzk6Nc8ZtA6KgW88lVku1u0=
=Cpee
-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] Efficient digital one-way communication

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/03/13 15:56, Jens Christian Hillerup wrote:
> Nice information, thanks. Would it be wrong to assume larger data 
> rates to be attainable on an FM "link" than over the telephone
> line? For music etc. FM has far superior sound quality in any
> case.

Good point - FM radio stations use 15 kHz of bandwidth for the mono
audio baseband, so I guess you'll have 30 kHz to play with if you
transmit in stereo, versus 3 kHz for a phone line.

> Another thing I didn't tell in my first mail is that I've been
> wanting to design a protocol for metadata, too, since it doesn't
> really make sense to decode and save half files anyway. It would
> also make it possible to send the file names and file sizes
> beforehand so the receiver can know how much of the file s/he has
> already received.

Interesting - I'm working on transport and messaging protocols that
are suitable for use over one-way channels. Ping me off-list if you're
interested in collaborating?

Cheers,
Michael

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

iQEcBAEBAgAGBQJRNMkTAAoJEBEET9GfxSfMGlQH+wRvRdMVqLrGVup5yr7hmHRg
G6587WtuDtY/piKiUEtGes3LcvZo7JB0gEuDpjL3aVIwewQzjwebx6/Xjarzmwxr
c1+scJ10/w52C6BYo6uUVul2XugkSv+2w7sGKIUFJ0QS/oNWdbfgstqHfLDAFBy6
eAFZubvPQE2Fi8oCIPXgYZAseb/L3fw90Kghkpxc6+r2/jAnSBz37LBlnJKipvsA
6IGJwASSESeDenU1x2NCrKfa7fLUQ5OuByxSdpqDHOGK091TkCP1ON8gqpYAvTMT
/+O0SVGJy1u1ec+wK2k/7d4WcliY8D+B4pJ1vZfrqk/SsmHqUfcLd1g66g5Bu/0=
=5rdp
-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] A tool for encrypted laptops

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/03/13 09:59, Julian Oliver wrote:
> For your Linux laptop why not just use an encrypted file-system and
> lid-switch? Close the lid and the machine hibernates. If you forget
> to close the lid then time it out to a screen lock. Can be done in
> a few lines of shell script with xtrlock and a
> /proc/acpi/button/lid/LID/state trigger.

Last time I tried it wasn't simple to get Linux to hibernate with an
encrypted swap partition. Are there now distros that support this out
of the box?

Cheers,
Michael

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

iQEcBAEBAgAGBQJRUZy8AAoJEBEET9GfxSfMvYEH/0nl+wEL8eoO2DAwc6kWvHhP
hlnKn3wju31Iy0pQoPdPu1hKYesAkI2C3WJsUB/zvqZqTrcaoK//KgLHaEaZD5J2
mxqyP1fOQjvy1lulMBRhklV94zAGqIRy9a941GjqbL8GUz+MS9HDdjr0Fptnfgw5
OoHJplww5QNQduvv0oAJxzQfftonoofX+z6U3LSIlN2VcbAU4uKsg9Z/5G8zGqBs
hoILNOP0PqqiE7dofoqfleTcIZC0c5qFYeS30ahRwqfpAkWtQnIDQwV3VmCvRgXk
bZWYyQt7H3k9zTSOED0ntjFyZvunsudPQ7bWkbGgCC5trrCxFoN2R5AQf9tmVOs=
=nPzo
-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] Fwd: SafeGDocs: encrypted documents in Google Drive

[Michael Rogers]

 Original Message 
Date:   Mon, 08 Apr 2013 11:03:51 +0200
From:   Carmela Troncoso 
To: p...@lists.links.org



Hello everybody,

in the last year we have been developing at Gradiant
(http://www.gradiant.org/en.html) a Firefox addon that allows users to
easily encrypt and share documents in Google Drive in such a way that
data is not accessible to the service provider. We are now releasing a
version and would love to have the feedback of the community both about
its usability and security.

You can download the addon here:
http://www.safegdocs.com/en/home.html

and find the associated academic papers here:
http://www.gradiant.org/images/stories/2010_cloudviews_googledocsprivacy.pdf
http://www.gradiant.org/images/stories/sharing_secure_documents_in_the_cloud.pdf

We look forward to your comments and suggestions.

Thanks many!
Carmela




--
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] Explaining Different Types of Trust?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Nick,

I think the kind of taxonomy you're talking about would be really
useful, both for educating users and for helping developers to focus
on the right threats. I'm currently reading "Folk Models of Home
Computer Security", which seems like it could provide some useful
landmarks:

http://prisms.cs.umass.edu/cs660sp11/papers/rwash-homesec-soups10-final.pdf

Cheers,
Michael

On 16/04/13 02:25, Nick M. Daly wrote:
> Hi folks,
> 
> Apologies for abusing the word "trust" some more, but I don't know
> what other word to use.  Feedback would be lovely.  Sorry for the
> cross-post.
> 
> So, one of the goals folks worked out during FOSDEM was that each 
> FreedomBox package should be able to explain to the user in a 
> straightforward way (1) who the user is trusting, (2) for what
> purpose, (3) how that trust can be abused, and why such abuse would
> be bad for me (4).
> 
> For example, with DNS requests (2), I trust my router, my ISP, my
> DNS host (possibly Google, if I use 4.4.4.4), and (if I'm unlucky)
> anywhere in-between (1).  Each of them can view the DNS requests I
> make and tamper with the responses (3), causing me to visit a
> fraudulent bank website, for example (4).  They could also record
> these requests permanently (3) allowing them to track (4) and
> advertise (4) relative to my movements.  Other harms based on that
> stored data are also imaginable, but perhaps too unlikely, in the
> average case, to be worth mentioning.
> 
> Similar profiles can be drawn up for other services, such as
> Jabber, where an attacker can fake my buddy list and my buddies'
> conversations, and so forth.
> 
> What are generic attacks that are service independent that would
> be widely useful here?  I'm thinking:
> 
> - Can Learn (Profile) - Can Influence (Lie)
> 
> What others would we need to cover all our (generic) bases? The 
> important bit is to list out the attack surfaces and explanations,
> on a per service basis.  Would it be possible to include generic
> explanations that can apply between services that cover the same
> purposes?  How would we organize this, at a framework level?
> 
> I appreciate your thoughts and your time, Nick
> 
> 
> 
> -- 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
> 

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

iQEcBAEBAgAGBQJRbRoRAAoJEBEET9GfxSfMRF8H/jWD/xrWy1v3bsVTYoZPBt/F
dD145+MDO+H3uF/PCpaFxGZM4IaE/zkehDmxHgs41uybnfqpYOfFUiiNdTdJQLxY
T08lBEMmPwZr80ZJ5jNcrLNQmUNQC8UtFyx6qJeszddZK0AaLBQKGVsKdgY4NP4O
gMnUV47N0JF8MKhQuIEk1FnvfLzS2joolqdUmwSOHfmx9u7SX5y4kM9GW98MlGK7
9HWW1tkuIWvIwe13MDhk48tQiNcMGTsSlDxR7OUctk93lTy3AD2LfWmp/maIbOk4
86TI4JBZdjKBLXNIwbUvNZi/N89Al3BtMB3bbrjtrMI6wG+LaLOjejz75PIDR34=
=2z5D
-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] Microsoft Accesses Skype Chats

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/05/13 17:08, Julian Oliver wrote:
> ..on Tue, May 14, 2013 at 11:04:11AM -0500, Andrés Leopoldo Pacheco
> Sanfuentes wrote:
>> I understand that the Skype traffic IS encrypted. The problem is
>> that Skype itself (and now, Microsoft) holds the key, not the
>> conversants..
> 
> Yes, this is correct. There's a good lesson here in encryption, key
> ownership and topology.

Another possible explanation is that the Skype client is submitting
the links (but not the entire contents of the chat) to Microsoft.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRkmVHAAoJEBEET9GfxSfMI5sIAIg6N5wwpAGR/Xr5y21H7yGI
wCsa/CSdasSdtbS7nd9LgL69uNgAkAg8MoF0MiWiXlJwr0wkDHRC0UC2Byw66WxO
HavdjBWkcxtMIub6tNgS/FpsXN72k6Jy4koEKx+T4UafwYO8j+g9BC0ZH17DmJIm
7Meob3gv4/qxlRhjcixYiEpCoVDWE4E9I/PRMxlNOESTi8qgZrBKtShzvbiS0KM7
mrUZCSbPFQ/JFF13d2WpSRHwF+RZ+XGZwM9KpoUcDRSYRORBaNnRya4Snac9s5j+
BtFnESMvNiUp9qsuEuK50GNuzbhhPfBpFeady9hudrNPmOMkKw7IQMlGAJie9iw=
=1WWF
-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] Privacy for the other 5 billion

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/05/13 22:44, R. Jason Cronk wrote:
> An interesting article that some on this list may find pertinent,
> though not really ground breaking
> 
> http://www.ifex.org/international/2013/05/29/biometrics_programs/ 
> 

This link leads to a meetup event about UX design - is this meant to
be a demonstration of the dangers of link shorteners?

Cheers,
Michael

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

iQEcBAEBAgAGBQJRqH24AAoJEBEET9GfxSfMZz0H/iCf++LjifiIRYh9+6PLl+At
zcOjd/72v6ogAekVfIZBfZFpal/qE/dB2L1Nv8lxu5SLsL6417EE9OIJL1qhfT+M
JX6Nw/y4kkI1Jf9yP08voO7CPSd3+zp12Y68z1Tz/sTBAiTaQBjnCBfPPI73Xmdv
ycY8J+3nzPe8jpoxN1Y90EkEdpR3XHo5nrnrv7i1RELDp61e8TiOQOjN4D2TeERg
gXpA+iG3u39L6VFPs3WiumWbzz4WoNB+oxi7oZTWUCh/hJGMHObCNjJZ9CkoNAf1
XxzADotYjsh49yxfqRm54peegEGuDMySytkTg2leOkglUttyl1zfUu4a0tfbinI=
=wyCP
-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] Flaming Google

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 31/05/13 16:01, Travis McCrea wrote:
> Services should have the option (as Google does) to pay for a 
> service, and not have to take part in advertising. I would love to 
> pay Facebook $5 a month, and not have any ads and no tracking.

Thought experiment: if you paid Facebook $5 to stop tracking you, what
information would you expect them to stop collecting?

It seems to me that a lot of the information they collect - such as
interactions with other Facebook users, or visits to sites displaying
Facebook buttons - involves communication between you and other
parties. It's not clear that you have a right to prevent those other
parties from disclosing that information to Facebook. So even if
Facebook were to agree not to collect data _from_ you, they could
still collect data _about_ you from those other parties - and thanks
very much for the $5.

The problem is that much of the information we consider private
involves relations between two or more parties, so it can't be treated
as any one party's personal property. You can't sell your privacy to
Facebook, or stop selling it to Facebook, because there's no distinct
entity called "your privacy" - it's inseparable from the privacy of
everyone you interact with.

I think we need to move beyond the conception of privacy as an
individual property right and recognise it as a collective right and a
collective responsibility. We can't buy our privacy back individually.

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

iQEcBAEBAgAGBQJRqMqbAAoJEBEET9GfxSfMsZsIAIQYSokPoSBnguSIB6ll9vF6
9VQT5g2HrXsnfKZ7re121DOfPUiGkA2YywIklpBH6kfJ7hOQhB5jjkJrDM2/7xVA
Ebb65p0oqkH4h3G2AnwDXYS8gvLqlqWRzYi2dzoheS50bzOeo6t/7SrkzkU9/QxG
j0ZOEuTxQ+7EtXjA7TbFHaW8B0cCXH3RX1uzxJ2QHdwSWnJekbCy2X1F26SVzHec
cpgL+lrsmBV59Cnt2+0uqCS9G/pGPOlR3L6shw9VJK41o+9xXcl9DXewy6Qz7g8z
4c4UfdQVP+jgXtjFMgryyP8S9DmHMYxvxQvBoQXIo8Gsv9eraA0k0QZWAzBIKrY=
=+oK2
-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] Anonymous Group Moderation?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/05/13 20:37, Bruce Potter at IRF wrote:
> I have a friend working in a politically volatile environment
> overseas environment who's interested in taking over a public
> e-mail group/listserv as a public participation service. The friend
> is based in the US, but the focus of the listserv is in a country
> where courts have held group moderators responsible for the content
> of various sorts of forums and discussion groups -- even if
> messages themselves are not moderated.
> 
> Because my friend would prefer to avoid litigation, and perhaps
> limits on his future international travel, he's looking for simple
> options that would allow him to set up a group anonymously. Can
> that be done?

Hi Bruce,

One option would be to set up an anonymous Google account and use it
to create a Google Group.

To set up the anonymous account you'll need a burner phone with a
prepaid SIM, which will be used to receive a confirmation code via
SMS. The phone and SIM should be bought anonymously with cash, ideally
from busy locations. A second-hand phone is less likely to be tracable
to the place you bought it than a new phone. The phone should only be
switched on while setting up the Google account; once you've received
the confirmation code, switch off the phone and dispose of the phone
and SIM card. The phone company will know the location at which the
SMS was received, so it's best to receive it in a busy location.

The anonymous Google account should be created and accessed via Tor -
if you *ever* access the account without going through Tor, your
anonymity will be lost. Don't visit any sites connected to your real
identity during a Tor session in which you access the anonymous account.

Another option would be to set up an anonymous Yahoo account and use
it to create a Yahoo Group.

At present, in the UK at least, you don't need a valid phone number to
create a Yahoo account, so you can skip all the cloak and dagger stuff
with the burner phone - just use Tor to create an anonymous Yahoo
account and give a fake phone number along with the other fake contact
details.

As with Google, the fake Yahoo account must *always* be accessed via
Tor, and you shouldn't visit any sites connected to your real identity
during a Tor session in which you access the anonymous account.

Hope this helps - I'd be interested to know how your friend gets on.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRryh1AAoJEBEET9GfxSfMlnoH/inp3MqVe5IG8ga64tmOmvVj
fb0ucZM7UEI+GSoqPkQnBcPmTkRnHtgeykLFcfS6uJvyziEM3C7qlygupvUWEeUj
+JPoDEv5ZOFHmL2LK6jZReZpatjHotASz7R4ibPCtgGPvTjwm+lwsMi+rS/i9jEK
jXuPpMjRHUY/IFf1piTBzbpoRaWxMdsdFXhBv1VTCUsPl065MZSsgiUSacJH34in
waPUBY4zc0JvuVAWbvreDQyBkMIn2JATLJe+2tTlgRTpd5Ut5nSjHa/DFP0rjMGH
3RU6B+kxBo2Lt6fv/GD9LYYJvnLHVjrjlpSP/uwcieXsi9KWOKVqFOeYm+a7Y2U=
=/+ec
-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] Top secret PRISM program claims direct access to servers of firms including Google, Facebook and Apple

[Michael Rogers]

"This law does not allow the targeting of any US citizen or of any person 
located within the United States."

Note the wording of this denial: the *target* of collection may not be a US 
citizen or a person located in the US. But if the *target* is, say, Al Qaeda 
and affiliated organisations, does the law prevent data about US citizens and 
persons located in the US from being collected and retained?

Cheers,
Michael


Eugen Leitl  wrote:

>
>http://www.guardian.co.uk/world/2013/jun/06/us-tech-giants-nsa-data
>
>NSA taps in to internet giants' systems to mine user data, secret files
>reveal
>
>• Top secret PRISM program claims direct access to servers of firms including
>Google, Facebook and Apple
>
>• Companies deny any knowledge of program in operation since 2007
>
>Glenn Greenwald and Ewen MacAskill
>
>The Guardian, Thursday 6 June 2013 23.05 BST
>
>A slide depicting the top-secret PRISM program
>
>The National Security Agency has obtained direct access to the systems of
>Google, Facebook, Apple and other US internet giants, according to a top
>secret document obtained by the Guardian.
>
>The NSA access is part of a previously undisclosed program called PRISM,
>which allows officials to collect material including search history, the
>content of emails, file transfers and live chats, the document says.
>
>The Guardian has verified the authenticity of the document, a 41-slide
>PowerPoint presentation – classified as top secret with no distribution to
>foreign allies – which was apparently used to train intelligence operatives
>on the capabilities of the program. The document claims "collection directly
>from the servers" of major US service providers.
>
>Although the presentation claims the program is run with the assistance of
>the companies, all those who responded to a Guardian request for comment on
>Thursday denied knowledge of any such program.
>
>In a statement, Google said: "Google cares deeply about the security of our
>users' data. We disclose user data to government in accordance with the law,
>and we review all such requests carefully. From time to time, people allege
>that we have created a government 'back door' into our systems, but Google
>does not have a back door for the government to access private user data."
>
>Several senior tech executives insisted that they had no knowledge of PRISM
>or of any similar scheme. They said they would never have been involved in
>such a program. "If they are doing this, they are doing it without our
>knowledge," one said.
>
>An Apple spokesman said it had "never heard" of PRISM.
>
>The NSA access was enabled by changes to US surveillance law introduced under
>President Bush and renewed under Obama in December 2012.
>
>
>The program facilitates extensive, in-depth surveillance on live
>communications and stored information. The law allows for the targeting of
>any customers of participating firms who live outside the US, or those
>Americans whose communications include people outside the US.
>
>It also opens the possibility of communications made entirely within the US
>being collected without warrants.
>
>Disclosure of the PRISM program follows a leak to the Guardian on Wednesday
>of a top-secret court order compelling telecoms provider Verizon to turn over
>the telephone records of millions of US customers.
>
>The participation of the internet companies in PRISM will add to the debate,
>ignited by the Verizon revelation, about the scale of surveillance by the
>intelligence services. Unlike the collection of those call records, this
>surveillance can include the content of communications and not just the
>metadata.
>
>Some of the world's largest internet brands are claimed to be part of the
>information-sharing program since its introduction in 2007. Microsoft – which
>is currently running an advertising campaign with the slogan "Your privacy is
>our priority" – was the first, with collection beginning in December 2007.
>
>It was followed by Yahoo in 2008; Google, Facebook and PalTalk in 2009;
>YouTube in 2010; Skype and AOL in 2011; and finally Apple, which joined the
>program in 2012. The program is continuing to expand, with other providers
>due to come online.
>
>Collectively, the companies cover the vast majority of online email, search,
>video and communications networks.
>
>
>
>The extent and nature of the data collected from each company varies.
>
>Companies are legally obliged to comply with requests for users'
>communications under US law, but the PRISM program allows the intelligence
>services direct access to the companies' servers. The NSA document notes the
>operations have "assistance of communications providers in the US".
>
>The revelation also supports concerns raised by several US senators during
>the renewal of the Fisa Amendments Act in December 2012, who warned about the
>scale of surveillance the law might enable, and shortcomings in the
>safeguards it introduces.
>
>When the FAA was first enacted, defenders of the statute argue

Re: [liberationtech] PRISM: NSA/FBI Internet data mining project

[Michael Rogers]

> Speaking just for myself, and if you quote me on this as speaking on anyone 
> else's behalf, you're a complete fool, if the government was able to build 
> infrastructure that could listen to all the traffic from a major provider for 
> a fraction of what it costs them to handle that traffic in the first place, 
> I'd be truly amazed--and I'd probably wonder why the company didn't outsource 
> their infrastruture
to the government, if they can build and run it so much more cheaply than the 
commercial providers.  ;P

We already know the NSA gets a copy of the traffic by tapping the backbone, so 
all it needs from the service providers is the keys to decrypt the traffic.

Cheers,
Michael
--
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] Building a encrypted mobile network

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Anthony,

On 08/06/13 13:36, Anthony Papillion wrote:
> 1. Location is a particularly thorny issue. Presentations at either
> HOPE or BlackHat demonstrated how easy it is to locate a mobile
> even if you're not the government with a massive budget and mad
> technology.
> 
> Perhaps routing the network connection through Tor may suffice? But
> I don't think so as something doesn't 'feel' right about that.
> Thoughts?

Routing the call through Tor wouldn't conceal the phone's location
from the mobile network. The caller and callee would both have to use
cell towers to reach the Tor network, so their respective mobile
networks would still know their locations, and any hacks that can
currently be used to trick the mobile network into revealing a phone's
location would still work.

In theory you could conceal who calls whom from the mobile network by
routing the call through Tor. However, in order to be able to receive
calls, the callee would either have to maintain a constant connection
to Tor (draining her battery and data allowance) or ask some third
party with a constant connection to Tor to send her push notifications
of incoming calls, which she could then answer by connecting to Tor.
The third party would know when the callee was receiving incoming
calls, though not necessarily from whom.

Even this would reveal quite a lot of information to the mobile
network. Alice starts sending data at 12:34:56. Bob receives a push
notification at 12:34:57. Bob starts sending data at 12:34:58. Alice
and Bob both stop sending data at 12:44:58. The inference is pretty
clear: Alice called Bob at 12:34 and the call lasted ten minutes.

Concealing these patterns would require users to send and receive
dummy data even when they weren't sending or receiving calls, which
would drain their batteries and data allowances. It would be possible
to build such a system, but I don't think anyone would use it.

> 2. Content is much easier to protect. My initial thought is to take
> a stock Android phone, replace the dialer with a SIP client capable
> of doing ZRTP, and customize the phone to tower communication so
> that all communication between the two is fully encrypted (and I
> don't mean the BS GSM encryption). Once the data gets on the
> network, it would be decrypted and calls would be connected.
> Content would be protected automatically when the user called ANY
> SIP device that supported ZRTP. Calls to PTSN would still be wide
> open.

It's not practical to use a custom protocol between the phone and the
tower - apart from the logistical issues of rolling out a new
protocol, carriers won't adopt a protocol that lacks "lawful
intercept" backdoors.

However, phone-to-tower encryption isn't needed if you have
phone-to-phone encryption, so I believe RedPhone does what you want
(but I haven't used it so I could be wrong).

Cheers,
Michael

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

iQEcBAEBAgAGBQJRtzfsAAoJEBEET9GfxSfMcfoH/jPBVjyJCBKThYy/kN14ZcNX
pwaOzHdpZ+MxHKo919Exu2XUn9nIHlrGB1sqL9azsxss+m/bTgfc9iXVrOXQLhNb
8fif2PYacKgZ7eyrV1lFYesDXbcpgrRkFI7qJodc3ukfgZx87pmHmogXRGGpVvGy
cx7X/+tXBPqi84Sq2tDRcPdX7eDRXxjoE6DK0YG6f9+KN3aPLfoFCQZrnMUzqgcG
6zvJrpuCvSiH1Uk5UMbjDGMsXempFf5kDTbThOhYJG2Fi+kOw9cOlsFx0z2QB5Yf
0dSRrTHPYOIxA+JwI0pRxhCnEOC8SEWCmQVzpzEww8RvK2/k0x5ZFBERtetxiRg=
=irF4
-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] Building a encrypted mobile network

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/13 17:47, Jonathan Wilkes wrote:
>> Concealing these patterns would require users to send and
>> receive dummy data even when they weren't sending or receiving
>> calls, which would drain their batteries and data allowances. It
>> would be possible to build such a system, but I don't think
>> anyone would use it.
> 
> I don't think it's out of the realm of possibility that somebody
> would have a device running orbot with a (non-exit) relay that sits
> at home, plugged in, running over wifi.  Or, some small plug
> computer with a headset hookup that functions the same.  Or on
> their main machine that just runs all the time.  All that's needed
> then is a mechanism to leave a text message when the other person
> isn't at home (Torchat, maybe Bitmessage, etc.).

Well yes, if you take the mobile out of mobile security, the problem
gets easier. ;-)

Seriously though, I agree that this could work really well on a
Freedombox or similar.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRuFRfAAoJEBEET9GfxSfMDTMH/35TjGWNl64DrZCvrWRmafO3
qMfufyA6dPPY+0rix7ptMOu4DSyMQ36Q05AdFM0HxB+c2O4wP9nHjSSFq8ba094D
/NobvVBrg0Rhn0hNEJ5nMf4yJV1O7LkV+jhDLBJZS+1dYybwJX9LqMQxlBYJnqZG
ykLxU0/fFG8XxAi+6fJjsbtO0gRAQqoaq4cByXa9FgtPnleXNaSPD+erGXGoKFIj
4Tbq8dEGOzSGhCK6KGxKn1QKwCxk38G/kxFlg1oZYrZgr3ePdr/5ch5x40by6tzn
jv4IqYC6I33+FKc1vcu4eEK+lw89/t9sqt/togHky3j2vhheqV4xbU3uVzF7dv8=
=aOCf
-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] the Blackberry and Surveillance?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/06/13 09:14, michael gurstein wrote:
> I haven`t been watching that closely but in the course of my
> following the current discussions on surveillance I have yet to see
> a reference to RIM/Blackberry...
> 
> Is this because it`s recent loss of market share means it isn`t of 
> particular interest (I would have thought the up to recent user
> demographics would rather make it of particular interest), because
> of some features which put it outside of the current surveillance
> stream, have I missed it in the current discussion, other?

Hi Mike,

As far as I know, the situation with BlackBerry is as follows. If
you're an enterprise customer, you generate your own encryption key
for BBM (I don't know whether it's used for email too), and run your
own server. RIM claimed in August 2010 that it didn't have access to
the encryption keys generated by enterprise customers and couldn't
observe the content of their communication. The statement didn't say
whether RIM could observe metadata.

http://blogs.thenational.ae/business/beep-beep/full-rim-customer-statement-on-blackberry-security-issues

If you're a non-enterprise customer, your BBM messages are scrambled
with a key that's built into all BlackBerry devices and known to RIM.

https://mailman.stanford.edu/pipermail/liberationtech/2013-April/008293.html

RIM has come under pressure from several governments to decrypt BBM
messages, so I think it's safe to assume that the key used for
scrambling non-enterprise BBM messages is widely known by now.

For both enterprise and non-enterprise customers, if you use a
third-party email provider, that provider will have access to content
and metadata regardless of what device you're using.

I don't know whether wireless carriers can observe the metadata of BBM
messages; they could collect the scrambled messages of non-enterprise
customers, for descrambling by anyone who knows the key.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRuHR1AAoJEBEET9GfxSfMfm4IAJYUc9eD5yZJr4G7kAC5wJSl
ZXwrATajTYS+VIxY6yHPe5tQoOMHBXbMF/41No/oua6CoOoU2UU++BHAtGsVarHE
koKujVdtn3Tp18Jy6uEru/5qHaNx7+n8FF7lcr72k/yRfgzBKREVH2hge6s2pCYO
NcEya2PxKGcwiCk1f3901JwqVoeYxjEVNn2Wjx65lFppX0imn23UALZgnPHQaxX3
t20BYNwz1g1iSiJg2ngxkdOgTeSXelwI0do4h1mEZtFtapfChdjRb9/rAWi1NOwS
T8Kos128nDk/0cDuqObONxZD01UjgPIUFxBVVnfjJnKm220r6z7IBpelmrgWi6Y=
=9cNa
-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] New Anonymity Network for Short Messages

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/13 17:52, Sean Cassidy wrote:
> I have created a simple anonymity network that broadcasts all
> messages to participants so that you cannot associate chatters.

Hi Sean,

A few quick questions:

* Do routers subscribe to prefixes, or is it only clients that do so?
If routers subscribe to prefixes, how do you ensure that all routers
subscribed to a given prefix form a connected subgraph?

* A passive observer can pretty quickly tell which prefixes a client
subscribes to by seeing which messages routers send her - her outgoing
messages can be ignored. So can't a global passive observer identify a
group of clients who all subscribe to the same prefix?

> struct dinet_packet { uint8_t id[16]; // prefix + random in the
> default client uint8_t data[1024]; uint8_t checksum[32]; // SHA-256
> checksum of the previous two fields, to avoid flooding the network
> with duplicate packets };

* Why is the checksum included in the packet? Each router can
calculate the hash of the previous two fields itself, and discard the
packet if the hash matches a previously seen hash. If the router
trusts the hash included in the packet, it's possible to poison a
router's duplicate detection cache by sending it a packet that has the
same checksum field as another packet but different data.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRuHkBAAoJEBEET9GfxSfMygkH/i7iLj0IhYRqP0Ux6DPjyyK8
zljvmL1cft8uhd3CTOz3sYGzJIiduQuDHG1UEEsNKNMJxETSgQXylQRKPodqPa5Z
a7XLjtyp2Y6Tx/5PC3CU7vtaXvnG+ZLrIsfXsjatQx6sEVoN7dMGPTP3jyaSJl4f
3fp2ZhT0CAFpzXrGnGfOdttoNaKo9KSFTcYIsp/jVdC1YCmaexHpF5j2QjQ8cX83
WEhSZAuhpAUzAwutFpC9H8rpxbcZstucq4TsbjlVsgV0v/UbdYB5Th0UGn6fTISY
z78PK+HU+Co/HXw7VQpd3CZq3Ng03/09na0ZvEbEZqpIwwJrzyZOffNnObd648k=
=SLCZ
-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] New Anonymity Network for Short Messages

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/06/13 16:52, Sean Cassidy wrote:
>> * A passive observer can pretty quickly tell which prefixes a
>> client subscribes to by seeing which messages routers send her -
>> her outgoing messages can be ignored. So can't a global passive
>> observer identify a group of clients who all subscribe to the
>> same prefix?
> 
> Prefixes are intended to be small in order to get a large amount
> of messages. Clients can (and should) connect to multiple endpoints
> and get messages for multiple prefixes, as well as respond on
> those prefixes. Perhaps there could be a control channel on the
> network to set up random pairs (or groups) of people in order to
> correspond their fake prefixes.

It would be good to see some back-of-an-envelope calculations of the
anonymity set size (or any other anonymity metric) as a function of
the number of clients and the number of fake prefixes each client
subscribes to. My intuition is that there will be lots of pairs of
clients who subscribe to the same fake prefix, fewer trios, even fewer
quartets, etc. So large groups who subscribe to the same prefix will
still stand out.

The control channel suggestion is interesting, but if the adversary
can monitor the control channel, won't real subscriptions stand out as
they won't have been arranged using the control channel?

Choosing an appropriate lifetime for fake subscriptions seems like a
difficult job. Presumably clients will want to join and leave
conversations, so their real subscriptions will change. The dynamics
of fake subscriptions will have to resemble the dynamics of real
subscriptions to avoid revealing the real subscriptions to a long-term
passive observer.

> The router does not trust the hash, but instead recomputes it and 
> checks it against the given checksum. It was intended to
> discourage attacks that just flipped a bit and flooded the network,
> but this is sort of a weak protection.

If the attacker can flip bits, surely she can also replace the hash in
the packet with a new hash calculated after flipping the bits?

> I also had envisioned that clients could monitor their messages
> from multiple endpoints (subscribe to themselves) and check that
> the checksum is still the same one that was sent. If they never
> receive that checksum, either the network is not connected
> properly, or there is some destructive tampering going on.

That sounds like a useful check, but it doesn't require the hash to be
included in the packet - clients can store the hashes of the messages
they send, calculate the hashes of the messages they receive, and
check that they receive all the messages they send.

So it still seems to me that the checksum field is redundant.

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

iQEcBAEBAgAGBQJRuKs6AAoJEBEET9GfxSfMgJkH/jn0cSbr+iQmeOlTR3C35WFZ
whnq/fsr0Vls/DNk8tHmK3sC+WNQa4bFPwUoEzAluFa1N/ENxIkcArZyAANyAB8+
Ar/xFBWM7yD1MbIJkY+ljyrFE5DIe3u/P4olvvzDvhiBQr4SPPDCLlKV+7YGC6lS
lxM/x8p2iYpAx6qh1TwlsDXfF20/45RgK50fFoB9vegylQCJ5pSlProm9Es9/YEX
c07+ab9LdV59M86yaPBQflniz7UH68dctoCGoKfihbtei4ic+AIv6sFAViti2tzj
b89fO1aNE5lMHutXkYRAmtaxTkuXIU+4Rz3+v3rZy4cYL30yVXIlipSG9TJvZ7g=
=IMVC
-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] Internet blackout

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/06/13 12:49, Rich Kulawiec wrote:
> I think a *possible* fix for it -- or perhaps "fix" is too strong a
> term, let me call it an "approach" -- is to remove the Path: header
> (among others) and use the article body's checksum as a unique
> identifier.  Thus node A, instead of telling node B "I have article
> 123456, do you want it?", would say instead, "I have an article
> with checksum 0x83FDE1, do you want it?" -- slightly complicating
> propagation, but not unduly so. I think this can be used to strip
> out all origination information: when A presents B with articles, B
> will not be able to discern which originated on A and which are
> merely being passed on by A.

This was exactly my jumping-off point for Briar: take Usenet, remove
the path header, remove cancellation messages, require message IDs to
be cryptographic hashes of the content, and require link encryption. :-)

> Encrypting everything should stop article spoofing.  (Although it 
> doesn't stop article flooding, and an adversary could try to
> overwhelm the network by injecting large amounts of traffic.
> Deprecating the Path: header actually makes this easier for an
> attacker.)

...and this is the point where I decided Usenet wasn't the best place
to start from. Spam pretty much killed conversation on Usenet - and
the spammers weren't even trying to kill it.

I have some ideas about how to limit spam/flooding in a decentralised
way, if we can assume the network's built on real-world social
relationships and some fraction of the users are willing to take part
in moderation - but so far they're untested.

> What all this does *not* give a real-time communications medium. 
> But I'm not at all sure that's desirable.  Over the past few
> years, I've slowly formed the hypothesis that the closer to
> real-time network communications are, the more susceptible they are
> to (adversarial) analysis.  I can't rigorously defend that -- like
> I said, it's just a hypothesis -- but if it's correct, then it
> would be a good idea, when and where possible, to make
> communications NON-real-time.

I agree - if you design the system to tolerate latency, there's scope
for using mix network-like techniques against traffic analysis. Many
attacks against mix networks are based on correlating messages
entering the network with messages leaving it; if the network's
peer-to-peer then messages don't enter or leave - the endpoints are
inside the network. And if the network uses store-and-forward, senders
and recipients don't have to be online at the same time, further
frustrating intersection attacks. But best of all, store-and-forward
networks can include nodes and edges that don't show up in the
adversary's traffic logs at all, because they only communicate over
sneakernet or short-range links like Bluetooth and wifi.

> I'm not saying this is "the" answer.  I'm not even sure it's "an" 
> answer.  But I think it might be the foundation for one.  Now if I
> could just find the funding to work on it for 6-12 months I'd be
> all set. ;-)

Come and work on Briar. We might even be able to find some funding. :-)

Cheers,
Michael

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

iQEcBAEBAgAGBQJRu2sPAAoJEBEET9GfxSfMWR8H/AtxcA41sgvmY1HW3EwDN0/w
z8LFbrYvimL/CI34eWvytzKU8on/GyS4nBhJ0PRW7KbBpDm9SKEpi83jXoBDNvrN
Ix4hM5dMdNp1dTZB8rI7NEWWOcpR/ChMfEHkV/EDtAZiQX3fzeC1rX3kx0PaqOne
a0SRjIxXF/wrfqNN405vvTT6POjI6AEKwHomNdb6mZLsW8X16F7ejn8vpFwkOHQ6
Q4manS2FzVMVb4VmbmjFmrAJqhAaSTxziYbxosJqXqGiy9bugAlcJ14KmE97k4rG
rqwM2wjSwiSJ9vdytbPE6Dmav3hpwKtYxzIDvZcN2z4kJ01h42Izah0qsxo=
=jCtk
-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] eternity USENET (Re: Internet blackout)

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/06/13 00:53, Guido Witmond wrote:
 Encrypting everything should stop article spoofing. (Although
 it doesn't stop article flooding, and an adversary could try
 to overwhelm the network by injecting large amounts of
 traffic. Deprecating the Path: header actually makes this
 easier for an attacker.)
> 
> Doesn't Freenet already solve these issues by actively
> distributing content even wider when someone wants to censor
> something. A sort of built in Streisand Effect.

Not exactly - Freenet replicates data when it's published or
successfully requested, which improves the availabilty of popular data
but doesn't prevent flooding.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRvs1sAAoJEBEET9GfxSfM7S0H/0A8E6OZfZCwGVbkSYmqPZhw
dPafy4+neTfqxw6rKRaJUw8VVtumeaT/5FFmmMXM3imEvRrLs3rHhxK1aj2ujb3T
16GEnzZcS6nGqJT9Fhvi0fzJfKSXTPu0iN1qWnAelMPtu9pPwHwJOSUu3/Rodg5F
s2KhomK7TTHoWs6uFuXbDm91y2JP9BOFREgrejUlqYV33UG6CyhaeId6YScg9cqv
ROvUVkJvIewIv4FQ26zk2mmF7ftQWMBKt4EkAEprlxsaCV2qridZDFySkssRoFYw
7r2srCLHK+arUWH18y87dgT2ZFUeKDWGsZhCtlW1vz5VTVEITbQ5uERBq0iwd1g=
=k3Ou
-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] Quick Guide to Alternatives

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/06/13 18:13, Anne Roth wrote:
> We have compiled this 'Quick Guide to Alternatives', based on
> Security in-a-box and more.
> 
> https://alternatives.tacticaltech.org

Hi Anne,

Thanks for making this resource available.

The descriptions of RedPhone and Ostel seem a bit inconsistent - or
maybe I don't understand the distinction that's being made.

"RedPhone ... encrypts voice communication data sent between two
devices that run this application. However it also becomes easier to
analyze the traffic it produces and trace it back to you, through your
mobile number. RedPhone uses a central server, which is a point of
centralization and thus puts RedPhone in a powerful position (of
having control over some of this data)."

"When using CSipSimple, you never directly communicate with your
communication partner, instead all your data is routed through the
Ostel server. This makes it much harder to trace your data and find
out who you are talking to. Additionally, Ostel doesn't retain any of
this data, except the account data that you need to log in."

It sounds like you're saying the use of a central server is a
disadvantage for RedPhone but an advantage for Ostel - which may be
true, but I don't understand why.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRwFjzAAoJEBEET9GfxSfMWc0IAJmTnY1IXKNkCKnj7P68ei0D
D9n4dlo6ZJ/yEIxYKoaji+bnFDuPVE5flkf1B58LqyIKxUOBds0XzLVmjDKGwrWZ
vv9Jna6Ic07isFvJPyoq4zpjfKRspIfCRHmZVyOkCbnuh3takMz74q3BibtI6Izu
STTVg3Fkw2fhfhQ0DSUEvU07s8rzBNwK4CNoikyxG9xF9ZwtlVLzOq5G0R9xoed8
0GxiJAzjCwLJm6saCkqHBilw4b0ky9JBNS/6hsZoXrY8v/Ps8CrNACcjkEHbH45O
mDd5vgNMDkI3pcKnoz7QUztRoi8KxE4YiGRzT6XKE7Mwb84ZW8OcumkuXQcJkaQ=
=FELY
-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] Encipher.it

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19/06/13 18:06, Steve Weis wrote:
> I also noticed the verification code might be susceptible to a
> timing attack: "if (hex_hmac_sha1(key, text) === hmac)"

It looks like the adversary might be able to bypass MAC checking
entirely: decryptNode() accepts a message if either the first 40 bytes
are a valid HMAC or the first 64 bytes are the hash of the plaintext.
If the adversary can guess the real plaintext then she can modify the
CTR ciphertext to produce a new plaintext and authenticate it by
replacing the MAC with the hash of the new plaintext.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRwtNxAAoJEBEET9GfxSfMpbMH/1Pcln56XtFQ1AFcwhKZlY/w
iDnnuq2DAsGFd7PtM/0fMq+amgtHOPWm0DzOxPa8TeOqcyXmsPqYYPLYH5kQ87Xa
T+AU377EZQoPNMazA88OkMhOPhwhxDkpTYaFXOwl6mRu4jPk3PLBimWZz1IU0jUY
52rGTT4fptsJwgGjFcATbw/k4RpE9TUpHguDhximadOim+suww1ymHK2kNeLwyOl
Bn/vPZtkoUzoOAgXEgUGONa4b3jlFHbcEEjxL2KtNjvG99X6RsrWq8XJmlOebKB7
CQaQio1kdiyLAuLUtBy9A36DBRTyOW8c72HYhNXiR2jeIEPXID5kHDLuPEEt1S0=
=qiN4
-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] to encrypt or not to encrypt?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It's unfortunate that Ars Technica has chosen that angle, since I
believe it misrepresents the situation: if you use encryption, the NSA
may indeed retain your encrypted traffic, but won't be able to read
it. If you don't use encryption, the NSA will be able to read your
traffic, and will retain it if it contains anything interesting, or if
you're not an American. So encryption is still a net gain for privacy.

Blending in is a red herring in my opinion - metadata (which isn't
subject to the restrictions discussed in the Ars Technica article)
reveals who talks to whom and when. That's sufficient to identify
persons of interest, regardless of whether they use encryption. Any
activist or journalist should assume they're already a person of
interest, thanks to their job and the people they talk to. Not to be
subject to surveillance would be something of a professional
embarrassment. ;-) So forget about blending in. Assume you're subject
to surveillance, and think about what steps you're going to take in
response.

Cheers,
Michael

On 21/06/13 16:41, dan mcquillan wrote:
> a few people who came to our university cryptoparty asked whether 
> they're just going to draw attention to themselves by encrypting
> email.
> 
> the latest leaks seems to give a firm 'yes', as the NSA
> specifically keeps encrypted comms indefinitely.
> 
> sample news item:
> http://www.techdirt.com/articles/20130620/15390323549/nsa-has-convinced-fisa-court-that-if-your-data-is-encrypted-you-might-be-terrorist-so-itll-hang-onto-your-data.shtml
>
> 

> 
> how would list members answer the question 'to encrypt or not to
> encrypt'?
> 
> cheers dan
> 
> 
> 
> -- 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
> 

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

iQEcBAEBAgAGBQJRxHajAAoJEBEET9GfxSfM2HkH/Rm25AIazNgkqxadf/vzXX+6
mF7r0OCJxskiItRiGIYPLQm82Ig7lPe2cKdi+B7EGkxe9e2CekgC5gFlY8m5b7dt
F9ivv//LjZnBscwHKNT4mZ073188BlsDRB0pSKQuYlZ1R8PCHfjM+U8l5nVaX0Ox
+tmwylPA5GKV9IQYtRHUlZlOd2wM2fmaaGMRZCdxOF/rk4m8fxZn/Emsj3Yq4IeG
syVZHqRwB6VkVA6YL5TllATpOqd+NE0JpwNPOsFUBVVN7XsUVeZeYIGx7k7lZ8AU
VI+dklvAIGDrkHEabnMhRQPABVh4XyWuwstJUPiDtMCDQ8f0vXz8tVAaGfN/p/Q=
=4kJw
-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] eternity USENET (Re: Internet blackout)

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/06/13 14:12, Rich Kulawiec wrote:
> One more generic comment/observation: clearly, Usenet or a
> Usenet-ish mechanism will run on a smartphone.  But I'm not sure
> that's a good idea.  Given the existence of things like CarrierIQ,
> the propensity of repressive governments to strongarm (or take
> over) telcos, the geolocation capabilities of cellular providers,
> the extant research on re-identifying putatively de-identified
> data, the epidemic of smartphone malware (including in "app
> marketplaces"), etc., I've kinda arrived at the point where I think
> "no smartphones" is sound advice.

I agree - "no smartphones" is sound advice. "No phones" is even
better. But the problem is, nobody follows that advice. So we have to
be pragmatic. Given that billions of people own mobile phones, carry
them everywhere, and use them for communication they'd like to keep
confidential, what's the best incremental improvement we can make?

As a sofware developer, the best incremental improvement I can make is
to develop apps that are more secure than the ones people currently
use. That's only a small piece of a huge puzzle that spans software,
hardware, law, economics and politics, but it's the piece I can reach.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRxHeoAAoJEBEET9GfxSfMlGMH/3T5svAB8g0/+EC5imfnUbWz
GvJYlhRaTyhwVfUAlje9BCs1S7fGozNQO3F9fTkP1fTesicvfSQZbM+Jt5k1zm6q
fw+K0gvCsUKeCSP30DhAZVKMsCnRZW5c4GWUeCYgUY1OG4cGqPMVgG4M/psiwZco
7xvUjdp3D43u52wierB3RTHfCHsMKck95foA4O8xEZOl+zypEXLluO8AQoQm8zYI
Kke0hG4YmuEjzJxBZ6vNyemaktCRHFwr4ILEQQB+T11gm9fOUFQXxH3R0GoGKkn/
MAIymUEavSK8dyhirwbSVPyYBVvQI6WP9wZ+j6pdEmTlSuzUb7amkgMegdFs2L8=
=6Jro
-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] to encrypt or not to encrypt?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/06/13 17:57, Joseph Lorenzo Hall wrote:
> What about the theory that by encrypting all the things we are
> feeding some massively large NSA cryptanalysis project that uses
> different flavors of ciphertext to find weaknesses? Very conspiracy
> theorist-y, but I've heard a few people say that maybe we shouldn't
> "donate" unnecessary ciphertext to such a project. :/

Sorry to be blunt, but that theory is nonsense. The NSA can't possibly
learn more from the ciphertext of an unknown plaintext than it could
learn by generating its own ciphertext from a known plaintext - which
would save the cost of a splitter cabinet, to boot.

Cheers,
Michael

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

iQEcBAEBAgAGBQJRxKFlAAoJEBEET9GfxSfMJDMIAKE/4EamX+E6xPExWNTWb2ct
ACpHkg2ovh6Ez8pS25h5arwicftWLo2fZUDicy6If0Vz2AWyr2iFBvknFezH+jlY
X1Af+oWwScYEV3UmPQCQInQmXzDziXYXYxE6W2Tpokq3pkVguyTaqKZsxVQhMc3T
oLZKGxKtXLaissBXDtLn/XRR5CNUsn1ZzSziJEynXO56gGut0eXGZIExdNCy8POt
Tc2KzDyPaX91t2Zz1ecNUEN6h4FgUCgTOQcAndz7i+0cUG/5V+XhwJazct+00tqS
LjasOQIU5ICCTEpJy3L2vxEB/jdDTZ21Xt+5WNdEMLOwXl56/DZkJc1chL6VRtA=
=EAd2
-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] DecryptoCat

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/07/13 20:35, Maxim Kammerer wrote:
> Writing secure software is relatively easy, and does not rely much
> on abstraction layers or whatever OOP ideology is popular at the
> moment. You just document each function' input/output, test it
> somehow, and check input/output requirements when calling any other
> function. The simpler, the better, it's not difficult.

This is contradicted by a mountain of evidence. The great majority of
developers clearly don't find it easy to write secure software. If
they did, we wouldn't see a constant stream of security patches for
new and old software alike. Google and Mozilla wouldn't have to run
competitions to find holes in their own browsers. There wouldn't be a
multi-million-dollar 0day black market. It wouldn't be possible for
the NSA (according to Snowden) to "simply own" the computer of any
person of interest.

Writing secure software is much, much harder than simply writing
comments, writing tests and coding defensively. You might as well say
that good government consists of wearing a suit, talking about laws,
and remembering not to have wars or recessions.

Cheers,
Michael

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

iQEcBAEBAgAGBQJR28w5AAoJEBEET9GfxSfMLT8H/RUK16xsgpomruwd+qZx3hl6
endDibCLoMFL4zWiTtupOMLjxhyvziZFeLKzLb7HGjch9f8tXKG6SRb1PuedIEAd
znZ8Myeg7somPbrdVnNQOHZycwIpYOpWRyo3ZLXl0enbv8H+RjfzVKB1NWmyvYLM
p5PnRJJOtKcuvkXon00uomVe3yHJrbF0ra8D03btv2+AuOU7pHqk6a+OyYJQMlOy
xFc4IAWVth8Z2MgfbQl0HGEvpdJbkwKWMJf1U8KfZHAr4IyrozGIAupBRRCGL88t
P3xZyDUO36n14uG7x6aSUD2pTe534wmWyWTU8+ABqLiMduqK/p0L9tBdRZqWMG8=
=5mEN
-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] Unique Opportunity: Input to CEOs of Smartphone Manufacturers

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ben,

I'd love to see hardware support for full-disk encryption and secure
deletion. Apple is streets ahead of Android in this respect: iOS's
disk encryption key depends on a unique key built into each device, so
brute-force attempts to decrypt the disk have to be run on the device
itself, slowing down such attacks. Android simply uses the screen lock
password to encrypt the disk, which is easy to brute-force.

iOS also has hardware support for secure deletion, making it hard or
impossible to recover data from the disk after the device has been
wiped. However, individual files may still be recovered if the entire
device hasn't been wiped. Android has no hardware support for secure
deletion, so there's no way to thoroughly wipe the device or an
individual file short of using a hammer.

So here's my wishlist for improving activists' digital security:

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

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

(3) A pony.

Cheers,
Michael

On 11/07/13 20:57, Ben Doernberg wrote:
> Hi all,
> 
> What would you change if you were the CEO of a major mobile device 
> manufacturer? One of my colleagues at WITNESS has a unique
> opportunity to make a presentation to the CEOs of these companies.
> He'll be discussing our work around verified video for human rights
> abuse documentation, but we'd also like to make a case for other
> priorities of the libtech world.
> 
> What changes could these CEOs make to protect activists' physical
> and digital security, make it easier for citizens to document and
> report human rights abuses, and generally make mobile devices more
> effective as human rights tools? We can't promise we'll get a
> chance to share all of them, but the more suggestions the better!
> 
> Thanks,
> 
> Ben
> 
> 
> -- 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
> 

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

iQEcBAEBAgAGBQJR3y2WAAoJEBEET9GfxSfMt+0H+wQSN+6I2PpJ3S9DnEPHMBDq
qaIvSspLHxselmI7dRCluKD2/0nl70G64cxp0FoV7lBW0RlmoiTPEKb/TyEQ7JTi
+nx1SZnrHyJ3H2QQVxd0ifBUYGmyavGygugi37zAVsGUpyRdW+iVEePyaZ18xNIo
eciBTtTZivwtiQRcleyWA1lA9TbbNXwtPJ2mk9J7Qh7Bwrjfh4Cky6OFKMuWxfvm
Y18+Cv51yfhkcDUuFLZbE29Xi9gWFgopUZynRxBd4tqXXvqo1gcG2tU+77p9+Hav
f7yuanuC153gIYmElFbhdK27s/sh6o7AYi4+S98lFgZe7vPjF2iKO8atfOp9Z54=
=CgaO
-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] 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] 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

Re: [liberationtech] CJDNS hype

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Caleb,

Thanks for your reply. I'm not trying to cause trouble for CJDNS, as
you put it - I'm just pointing out that robust routing without a
central authority is a problem with a long research history that
contains some widely applicable results. I think some of those results
probably apply to CJDNS, but I don't know much about how it works, so
I've responded inline asking for more detail on some of your responses.

More generally, could you explain how CJDNS detects and routes around
faults?

On 15/07/13 20:09, Caleb James DeLisle wrote:
>> 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.

Could you explain what a route prefix is and how you can be sure that
a set of Sybil identities will share a route prefix? How is the route
prefix used in detecting and routing around faults?

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

Could you explain why a set of Sybil identities will produce an
absurdly long path, and how you can be sure that the routing table has
already been populated with fast non-Sybil nodes?

It sounds like you're saying that a Sybil attack won't work because
the victims have already populated their routing tables prior to the
attack - but what about a new node joining the network after the
attack has started?

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

It's true that you can't feign low latency. But if low latency is the
way to get traffic routed through you, the adversary can add genuinely
fast nodes and links to the network, in order to attract lots of
traffic, in order to selectively drop certain traffic.

I don't see why you can't feign short labels. If short labels are
desirable, surely a node can store the label from each incoming packet
and replace it with an empty label, so the packet appears to originate
from the node itself? Then if a response is received, the node can
restore the old label (reversed) and send the packet on its way?

What's the basis for preferring one route over another in CJDNS?
Latency, hop count, label length, some mixture of those things?

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

Nevertheless, a node could selectively drop traffic bound for certain
recursive routing hops, while forwarding other traffic, right?

The point I was trying to make in my previous email is that whatever
information the packets carry to distinguish one packet from another,
the adversary can use that information to target certain packets while
maintaining the appearance of high overall reliability.

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

Is every packet signed with the corresponding private key? Seems like
that would be expensive.

> Can't spoof a switch frame source except to extend the length of
> the path beyond your node.

As I mentioned above, you can also truncate the path so it appears to
start at your node. That could be useful to the adversary if short
paths are used preferentially, for example.

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

iQEcBAEBAgAGBQJR5RehAAoJEBEET9GfxSfM63wIAJwR9RPImmHk2SobGbvxgGFd
58OdNmZaq/8CbmdbIXN/CaiaewkmWTA+5iQlKGPoKVatbZOFzl0XFXxrYF77giYa
z0vFQf7cDGTspStGfpKHqvs87rahzN7MCs8nV3nBXItaOnkglu96of3RhMrni0Xw
2tNBpOzNile38etFdcgnrSZt3JhecJcAwbPEj09WcVjtXcow435XJxeqvg3oUve4
esbj2dYvAHWIBl/BFjhCJEO8q9Yl0XfyE88TRg40pUyQM5qrr0UabCTX4LBa9Vz7
mA1lTjXVp7Lrw+qzwgwg2sNVKwC7Q8GKVfvtJL5axTQGdwPq38/slVCGTt6rrGM=
=x+AG
-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] Random number generator failure in Rasperri Pis?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19/07/13 13:03, KheOps wrote:
> Just came accross this article, apparently showing the bad quality
> of the hardware RNG in Raspberri Pi devices.
> 
> http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/
>
>  Quite interesting since (pseudo-) random numbers are heavily used
> in crypto. Interesting also to see another post on this topic,
> after the study of a random number generation procedure formerly
> used in Cryptocat and that was also problematic.

Is that what the article shows? Looks to me like the Raspberry Pi's
hardware RNG (/dev/hwrng) is being held up as an example of 'good
randomness' in contrast to the RANDU algorithm's 'bad randomness'.

Cheers,
Michael


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

iQEcBAEBAgAGBQJR6S5uAAoJEBEET9GfxSfMKS8H/2DHdwnwgiYjoXtrJuxF5iPQ
jao6vb0GJP423lLyLsc9smcm/XAYhtCC4uVObw5SeKKZ0sBIvpwotmjooY0mM9I/
wbgwzdJIIFr4y4QpLhZvc2gpbHyl9Ri1feQkRIKS+YTvEe6gIZPcEkkL0xUaqPfD
QXrL0HPom9T9Rv0Y7F5hmU1DoP1r+rTlFpcCvMlWdr6VT+9J9bftUg0P9bIs1g22
J1Kos3BBbHl5+xFcOauD2AcSMBPNs9VaaIvTXdBF34Zod/ehLYXBEAfKPsan1hN1
nJTB3lEPrH8HGnokSYO4xibLsYpxf1QTqu3OxdY9iq/B7oyug7HTOW+YZGA53X4=
=88Cb
-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] ENGAGE Open data community

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23/07/13 19:33, Mikael "MMN-o" Nordfeldth wrote:
> PSI is Public Sector Information. It's the common term in European 
> politics on the subject of open data within the public sector.
> 
> Usually it implies that any data a public sector organisation has
> or publishes should be freely licensed and available in a "raw
> form" (machine-readable format), to as low a cost as possible (to
> lower the threshold of using it):
> 
> http://ec.europa.eu/information_society/policy/psi/index_en.htm
> 
> Oddly enough, it's a quite popular thing within the European
> Union, despite its other attempts to destroy free flow of
> information.

Perhaps that's not so odd if we consider who's in a position to make
effective use of a giant blob of machine-readable data. Is it (a) the
average citizen, or (b) the consulting company set up by the former
public servant who collected that data?

Cheers,
Michael

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

iQEbBAEBAgAGBQJR8DWRAAoJEBEET9GfxSfMrcwH9RQZ5Cty7Gtsypnhx6dX4jqa
C5gWdj8Z+dcQqcO2KrIQ/znPj492hEsKr/jo+DmoyHXCI8na7zQcoRUmPm34WlVg
5q24QRhGlLoqOYmONdwttt3vNU/q3Y+FxZgyUh8h4iKCkpaToz5z+m131WzGSnqO
o3zRKhUebmeHsrUpCQuMAZ5iTuE4qGFn6G/ddJ/EX+CkMrle/w5QnJr8uVCyg4eb
/ax1h1iqoEJRmLpec2CO0LNs/ud3XXtil3OrGYJFf55W00v2gfPRTDtfDpu6YSHx
T/EoKejEmw1Da8jQScaD+xyaSkRfvMiAE4tJFN3idqEP8vSZqfG0Q0myENwfag==
=seGO
-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] PGP is hard to use and needs stuff installed on your computer. Use PassLok instead.

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/07/13 21:42, Francisco Ruiz wrote:
> PassLok performs public-key cryptography using the Diffie-Hellman
> key exchange rather than RSA, so you can use whatever secret key
> you want. Hopefully something that is both very hard to guess and
> easy to remember, so you never have to write it down. PassLok will
> help you to come up with a strong key, but won't force you in any
> way.

Hi Francisco,

It looks like you're generating a Diffie-Hellman key pair from a
passphrase using PBKDF2 with no salt and a single iteration. That's a
bad idea - the resulting key pair will be susceptible to a dictionary
attack by anyone who knows the public key, or a message encrypted with
the public key, or a message signed with the private key. Worse,
because you don't use salt, the dictionary attack can be carried out
in advance by building a rainbow table.

Cheers,
Michael

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

iQEcBAEBAgAGBQJR9DYyAAoJEBEET9GfxSfMNzsH/jU6WrzE7Y9jeLTtMBTahhJX
KpzdmHSYp3D457YxLj2WVP4hj0fqf2ygaers3N9O2QRNU69tkv/eZZdbezCGcdWr
FQ/Dg/hp7nMEKZTJEmkzKfxQUQkB7WRWxJsk9Bl15UehctsEPNkEcLT0SA75I8Q+
cWoEyfOF4/+jY+JgAoWi/rsU/G1Frlg/dwqS0MNvGTDLTvAeOPjJqlx+RWTG00kA
5SpoYYJJobxyR9b1GkbvapwaOSviuNGVYG8vNi5mNv/C55OGCWGIBm+L/RItf6Yl
8XNaSY9XJaVC1k6+q1QQTFlav8SzTBfzFLUoFcX+fOWd3gPgPtAjwfLv1moOuDc=
=DJzx
-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] PassLok updated based on feedback from LiberationTech

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Francisco,

On 30/07/13 23:09, Francisco Ruiz wrote:
> 4. A revamped Key strength meter, which won't give a perfect score
> until the user has appended his/her email to the Key. This is to
> combat a powerful attacker (like the NSA) who might be able to make
> a rainbow table containing public keys for a whole dictionary's
> worth of likely private keys (Thanks, Michael; not quite the same
> as adding a random salt, but I think this achieves the objective
> without inconveniencing the user too much).

This is a neat solution to increase the difficulty of dictionary
attacks without increasing the burden on the user's memory. However,
I'm still concerned that dictionary attacks (without rainbow tables)
would be quite easy to carry out. See the following article, for
example, which describes current techniques for cracking salted passwords:

http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

I'd recommend using PBKDF2 or scrypt with a high iteration count to
increase the cost of dictionary attacks. Perhaps the iteration count
could be determined automatically using your password strength
estimation algorithm, so weaker passwords would use more iterations?

Cheers,
Michael

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

iQEcBAEBAgAGBQJR+kNXAAoJEBEET9GfxSfMYnMH+wRWKY+gPIPyWGMyWhQkuOCb
5LtGHNnyJoCuvBN8z563HF8gjaMIDcsi6r4Z9qoBKh47Q3DN6WgAOqB13brKKBg0
VhfcjgGW8sRpvw1FGRUgg+O91ZQg+KsmvBjQetQ+u7HSj2TomreN1HV9UJWbNFUr
QwYzzhXs7DoXCGkrBwfOLqNIh2CrygPrBcP77PMTCc+NdmLm5mpLd5e1N8UAiL1u
ZKiBQUU7zknmRayjRbr4EjqEotQ41dTpjICcrAvRBxD5n5kz5sule/J+F6WiYDRA
Yk8LcQOQmXFmMdUWPKaC1NZCyPZGiaQGWcD7n/l6fk1bzX0ZD0gpNv5vFye4XYk=
=mPeB
-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] CJDNS hype

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Caleb,

On 01/08/13 17:20, Caleb James DeLisle wrote:
>> At this point, Alice knows that Carol is "real" in the sense that
>> someone owns Carol's private key and uses it to respond to pings.
>> But Alice has no way to determine whether Bob and Carol are
>> actually the same person. In other words, Alice can't tell
>> whether Carol is a Sybil.
> 
> Correct.

So if Alice can't tell whether Carol's a Sybil, presumably Alice can't
avoid sharing information about Sybils when sharing routing table entries.

So people who trust Alice to be honest and diligent can't trust her to
give them non-Sybil routing table entries.

> To rephrase, given the architecture, I don't know of any attack
> which would be effective enough to warrant specific defenses. Of
> course changing IP addresses to send SMTP spam or evade IRC bans
> could be considered a sybil attack.

I was thinking of more subtle attacks, such as dropping (some or all)
data packets while responding correctly to pings. Sybil identities
would serve two purposes in such an attack: filling as many routing
table slots as possible with attacker-controlled identities, and
evading fault detection by replacing any identities detected as faulty.

>> Yes, I agree that detecting and dropping faulty nodes is
>> pointless as long as there's no limit on the creation of
>> identities.
> 
> 
> This is not true. If I want to ban you, I won't express the ban as 
> your key where you can just make another, I'll express it as your 
> peer's key and the interface index which is used to get from him to
> you.
> 
> This way you can ban sybil edges if you can identify them.

That's a big if. Do you currently have a way to detect Sybil edges?

Returning to the example above: Alice's friend Bob tells her about his
friend Carol. Alice can't tell whether Carol's a Sybil. So if Alice
detects (somehow) that Carol is misbehaving, should she (a) ban Carol,
(b) ban the edge from Bob to Carol, (c) ban Bob, or (d) ban the edge
from Alice to Bob?

If it turns out that Carol is a Sybil created by Bob then (a) and (b)
are a waste of time - Bob can just create a new Sybil. If it turns out
that Carol wasn't created by Bob then (c) and (d) are collateral
damage: the attacker has caused a genuine node or edge to be banned.

Alice doesn't know whether Carol was created by Bob, so whatever
action she takes is useless at best and harmful at worst.

> The non-forwarding node attack does concern me since it's hard to 
> identify but again it is a physically local attack. The cjdns 
> implementation conservatively forwards to the physically nearest 
> node which makes any forward progress in address space and since
> the routing table is heavily duplicated, I'm likely to get to the 
> destination long before I reach a non-forwarding node.

Sorry, I don't understand how forwarding to the physically nearest
node at each hop will help to avoid faulty nodes.

It seems like you're assuming that by minimising the physical distance
covered by each hop, you can reach the destination without ever
travelling physically far from the source. But in the general case
that can't be true, because the destination may not be physically
close to the source.

Furthermore, the source and destination are at random points in the
address space, and every hop must make progress in the address space.
So even if the source and destination are physically close together,
there's no guarantee that there's a path between them where every hop
makes progress in the address space while remaining physically close
to the source.

What's more, the routing algorithm doesn't even try to find such a
path - it tries to find a path where every hop makes progress in the
address space while remaining physically close to the *previous hop*.

The difference is significant: if I walk without ever stepping far
from my previous step, I can still end up far from where I started.

So I'm not convinced that the routing algorithm avoids passing through
nodes that are physically distant from the source.

> After looking over the first couple pages of Eclipse Attacks on
> Overlay Networks: Threats and Defenses I can see a tablespace
> exhaustion attack based on answering every DHT query with a fake
> node which is numerically very close to the target. Unless they're
> physically close to the victim they won't normally be routed to but
> they will take up space in a size limited table which would reduce
> the duplication of the routing table causing packets to be routed
> further and making localized sybil attacks have a wider reach.
> 
> This attack, as with many others, depends on the implementation of 
> cjdns. Because there are hard rules preventing loops, we could
> adopt a new table population algorithm which favors physical
> diversity of nodes, mitigating this and other sybil type attacks
> without breaking the cjdns protocol.

Could you explain how favouring physical diversity of nodes would
mitigate e

Re: [liberationtech] CJDNS hype

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks yet again for the answers, Caleb! Responses inline.

On 02/08/13 19:03, Caleb James DeLisle wrote:
>> That's a big if. Do you currently have a way to detect Sybil
>> edges?
> 
> 
> Sure, I'd just run `cjdcmd traceroute` and look for the nodes
> whose names I don't recognize. Sure it doesn't scale but since
> attacks are localized, it doesn't have to. I waste 10 minutes and
> the attacker wastes their entry point into the network. Getting let
> in isn't automatic so getting thrown out doesn't need to be
> either.

Are you saying that your defense against the Sybil attack is to
manually blacklist anyone you don't recognise? And every other user is
supposed to do the same?

What happens if someone you recognise is automatically generating
names you don't recognise? Whack-a-mole...

> If you really wanted to automate the process, you could use
> heuristics.

What heuristics do you have in mind?

People have put years of research effort into designing automatic
Sybil defenses. The solutions they've come up with (SybilGuard,
SybilLimit, Gatekeeper, SybilInfer) are complex and heavyweight, and
they depend on assumptions about the structure of the social network -
in other words they're not off-the-shelf solutions that you could just
drop into cjdns later if the need arises.

>> It seems like you're assuming that by minimising the physical
>> distance covered by each hop, you can reach the destination
>> without ever travelling physically far from the source. But in
>> the general case that can't be true, because the destination may
>> not be physically close to the source.
> 
> 
> No, by minimizing the physical distance covered by each hop, you
> can reach *someone* who knows the full path to the destination
> without traveling physically far from the source.

This assumption doesn't scale. As the network grows, the probability
that any given node has a full path to the destination falls.

If you're already near the destination then sure, you can expect to
find a node with a full path to the destination. But in a large
network, you don't necessarily start near the destination, and you
can't necessarily get near the destination without passing near the
attacker.

On the other hand, in a small network, you're already near the
destination, but you're also already near the attacker.

I understand your argument that routing table entries pointing to the
attacker will tend to be localised around the attacker. But the same
applies to routing table entries pointing to the destination.

> The table is populated with physically close and numerically close 
> nodes, if the destination is physically close you'll probably know
> the full path already. If not then the physically closest node who
> is numerically closer to the target than you has a better chance
> because they're still physically close to you (and thus the target)
> and they're numerically closer to the target.

Sorry, I don't understand what you mean by "physically close to you
(and thus the target)". One doesn't imply the other.

>> The difference is significant: if I walk without ever stepping
>> far from my previous step, I can still end up far from where I
>> started.
> 
> 
> I think you're confusing "reaching the destination" with "reaching 
> someone who knows the way". There's only one destination but a 
> significant portion of nodes know how to get there.

As the network grows, the proportion of nodes who know how to get to
the destination falls.

>> Could you explain how favouring physical diversity of nodes would
>> mitigate eclipse attacks and Sybil attacks?
> 
> 
> Since sybil nodes are clustered in physical space, this would
> limit the physical scope of the tablespace exhaustion attack
> detailed above.

Bear in mind that the attacker can create arbitrarily large Sybil
regions of "physical" space. (We should probably avoid calling it
physical space - maybe social space would be a better name, because
it's defined by social relationships, not by geographical location.)

If the attacker creates a Sybil region of social space that's larger
than the non-Sybil region, and you try to ensure that your routing
table contains a diverse sampling of the whole social space, then your
routing table will tend to contain more Sybils than non-Sybils.

So it seems to me that favouring physical (social) diversity might be
a worse strategy than favouring physical (social) locality, in terms
of Sybil resistance.

> Also multiple simultaneous sybil attacks could be carried out
> using compromised but otherwise valid cjdns nodes.
> 
> I'd like to implement a payment system to limit the first attack,
> the second is an open question... How do you approach an attack
> where a large number of honest people suddenly become colluding
> adversaries?

I wouldn't worry about it - right now the network is vulnerable to
Sybil and black hole attacks that don't require compromising innocent
nodes.

Cheers,
Michael
-BEGIN 

Re: [liberationtech] CJDNS hype

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Caleb,

On 03/08/13 01:33, Caleb James DeLisle wrote:
> We could spend a long time discussing locally effective attacks on
> social networks and not be any closer to agreement.
> 
> Instead I think it's worth asking who your attacker is... I find
> that when people don't stop to ask who the attacker is, what he 
> wants and what resources he can apply on the attack, they end up
> with a default assumption that the attacker is everywhere and has
> infinite resources.
> 
> If you can give me a clear picture of the person who would use
> this attack, what they want from the attack and what resources they
> can bring to bear on the problem, I might be able to speak more to
> the issue.

Excellent point! The adversary I have in mind looks something like this:

* Can create adversarial nodes
* Can persuade a limited proportion of users to make direct
connections to adversarial nodes
* Can co-ordinate the behaviour of all adversarial nodes
* Can create low-latency, high-bandwidth connections between
adversarial nodes
* Can't monitor or tamper with direct connections between
non-adversarial nodes
* Can't break standard crypto primitives
* Aims to degrade the performance of cjdns for some or all users

>> What heuristics do you have in mind?
> 
> 
> Given a set of known evil nodes, find the longest common route 
> prefix(es) which contain all of the evil nodes. The last node
> along each common prefix is probably an edge.

How would you find a set of known evil nodes?

>> People have put years of research effort into designing automatic
>> Sybil defenses. The solutions they've come up with (SybilGuard,
>> SybilLimit, Gatekeeper, SybilInfer) are complex and heavyweight,
>> and they depend on assumptions about the structure of the social
>> network - in other words they're not off-the-shelf solutions that
>> you could just drop into cjdns later if the need arises.
> 
> 
> They operate under different constraints.

Could you elaborate on the differences? The systems I mentioned are
designed for use in P2P networks where the edges are based on
real-world social relationships and there's no central authority.
Isn't that similar to the cjdns setting?

> Everybody knows paths to those who are the numerically closest to 
> themselves no matter the physical distance. Since addresses are
> spread randomly throughout the network, it means that anyone given
> node is directly reachable from a few nodes in each physical
> locality of the network.

Let's consider what happens as the network grows. On average, each
node is pointed to by t routing table entries, where t is the size of
a node's routing table. As the network grows, the t entries pointing
to a given node will be spread more thinly across the network, unless
we increase t in direct proportion to the number of nodes. Increasing
t like that won't scale indefinitely, but for the sake of argument
let's assume it will scale well enough for whatever size cjdns grows to.

So wherever we start from, there's some nearby node that knows a
switching path to the destination. However, the length of that
switching path will increase (on average) as the network grows. Even
if we had a magic oracle that told us the shortest path to any
destination, that path would still be longer on average in a large
network than a small network.

Therefore if some proportion of the nodes are adversarial, the
probability of hitting an adversarial node on the way from a randomly
chosen source to a randomly chosen destination will increase as the
network grows.

>> If the attacker creates a Sybil region of social space that's
>> larger than the non-Sybil region, and you try to ensure that your
>> routing table contains a diverse sampling of the whole social
>> space, then your routing table will tend to contain more Sybils
>> than non-Sybils.
> 
> 
> The number of nodes and the way they're organized doesn't help. 
> They're all behind a common label prefix (the path to the sybil
> edge) and that label prefix would cause them to be seen as a
> cluster.

Unfortunately it's not that simple. You're assuming that from the
point of view of a given node, all the Sybils are behind a single edge
(an attack edge, in SybilGuard terminology). But a given Sybil may be
reachable via multiple attack edges. That's why SybilGuard and its
descendents are so complex: before sampling the network to look for
clusters, they have to ensure that there's only a single way for
samples to reach each node.

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

iQEcBAEBAgAGBQJR/+ApAAoJEBEET9GfxSfMa8kH/iK0/TIHXiHSAZoDReJJmljD
kPVxkMTa/ejYdRWdDZ2VV6wiTGS7OuMJ4gYk6e8k6mqc3PmcdS8gDRC0ZQBOve44
Oy6b4XtozOJBWB+5K1M4DRMQefoAxttrQD6v6C8ov1eyPqIIPcnPAYRUYufDdphK
VmGYFmbGNTvb2If7YfN1xVgbTX1Kyq+5oKAyFtJflMiBRZtFHgSRvVNoTIIfD2Sj
K2h0LriJTSvd4SW0/gxtSs20+ZxkjsitgAlaWNWwyvyJDWygYeIzU0KSDFegwnNd
3UtCOF1/WF784RoXwiHwVxAPp4AZ+yfRQ5hwuTRhiUYxCjfEPYRV9E1ckFskyIE=
=dVi8

Re: [liberationtech] CJDNS hype

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/08/13 19:55, Caleb James DeLisle wrote:
> This is good from a capabilities standpoint but it doesn't cover 
> motive which is hugely important to threat modeling. If someone
> has significant resources and their motive is "to cause mayhem",
> securing infrastructure against them is not really possible which
> is why traditional antiterrorism efforts seem incoherent.

Ah! I think you've uncovered an unstated assumption of mine that might
explain a lot of our disagreements.

This conversation started with a question about whether cjdns was
suitable for resisting government censorship. So the adversary I've
been imagining is a government: she has lots of resources, and will be
satisfied if she can make cjdns unusable for some or all users. I
should've made that assumption explicit a long time ago!

The attacks I've been describing - running a bunch of nodes,
infiltrating the social network, attacking the protocol from within,
creating Sybil identities to protect the infiltrators from detection -
are clearly very resource-intensive, and I wouldn't expect anyone less
powerful and organised than a government to carry them out.

Having said that, the adversary I've described isn't omnipotent -
she's a realistic adversary that we might realistically hope to oppose.

> Another motive for localized DoS is to force users to an
> unencrypted channel. If every time the police use encrypted radio
> you jam it, they may be tricked into using unencrypted channels.
> The main defense against this is not to have an insecure backup.

I agree with that defense, but unfortunately there's often an insecure
backup that's outside your control: users can switch to an entirely
different method of communicating.

If the adversary can disrupt cjdns without disrupting the legacy
internet, she can encourage users to switch back to the legacy
internet, where they can be censored and surveilled.

> Also note that localized network outages can be caused by wire
> cutters and/or wifi jammers so a protocol attack may never be the
> most effective approach.

True, but protocol attacks are more selective than physical attacks
and may be harder to attribute. (Of course, the adversary may use both
approaches at once.)

>> How would you find a set of known evil nodes?
> 
> cat-and-mouse games which is why I don't like this approach. You
> could send forwarded packets to nodes to whom you know a direct 
> path and then send them a direct packet asking if they got the 
> forwarded packet. You have to try it a few times to be sure the 
> endpoint is not fooling you and there are still more ways to
> detect and work around it.
> 
> It's not something I'm interested in ever implementing so it's not 
> really worth further discussion.

I agree that these cat-and-mouse games are pointless, which is why I'm
skeptical about vague answers like "use heuristics".

The point I was trying to make in my first email is that the Sybil
attack is actually an entire class of attacks. If you solve one
specific instance, the attacker can just use a different instance. The
same applies to Byzantine routing faults.

Faced with a class of attacks like that, it seems to me that you have
three options:

1. Decide that you can't defend against this class of attacks. This is
a perfectly legitimate option - every system has limits beyond which
it doesn't claim to work. Arguably, Tor succeeded where anonymous
remailers failed because Tor tried to defend against a less powerful,
but still realistic, adversary.

2. Demonstrate that you have a general solution to the entire class of
attacks. This is possible, but the resulting solutions may not be
practical to use - see Perlman's work on Byzantine robust routing and
the SybilGuard family of protocols for two examples.

3. Demonstrate that the entire class of attacks is irrelevant to your
system. For example, a system with no routing doesn't have to worry
about Byzantine routing faults.

It's possible that you've already chosen option 1 and I've
misunderstood the kind of adversary you aim to protect against, in
which case I apologise for wasting your time with this long thread
(although it's taught me a lot about cjdns - thanks for that).

- From our discussion so far, I don't think you've chosen option 2 or 3,
because I think we've established the following points:

* Sybil attacks can have (at least) a localised effect
* There's currently no detection or prevention of packet-dropping
attacks, as long as the attacker doesn't drop pings
* Even if a randomly chosen source and a randomly chosen destination
are each surrounded by trustworthy nodes, there isn't necessarily a
physical path between them that only passes through trustworthy nodes

It seems to me that those three points add up to a reasonable doubt
about whether cjdns could be disrupted by a combination of Sybil
attacks and packet-dropping attacks.

I don't think it would be fruitful to simulate a specific attack and
d

Re: [liberationtech] From Snowden's email provider. NSL???

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/08/13 17:43, Reed Black wrote:
> CryptoCat is served up by the Chrome app store. Do you have
> control over what binary gets distributed to who? Does any assurace
> exist beyond the app store's own signing validation?
> 
> I thought this was like webmasters and third-party script
> inclusions. They will be blind if Google or DoubleClick are
> compelled to selectively swap out the scripts they serve to
> millions of third-party sites.

If we assume that app stores aren't going away any time soon, we need
to address this problem: How can a user who downloads an app from an
app store be satisfied that it was built from published source code?

We might also think about how to solve the problem for apps downloaded
through browsers.

Verifiable builds are necessary but not sufficient here - they allow
an expert auditor to tell whether the binary she downloaded was built
from the published source, but an attacker might target the binaries
downloaded by certain other users without alerting the auditor. So we
also need a way for a non-expert user to tell whether the binary she
downloaded matches the one that was audited.

PGP signatures and hashes aren't currently usable by non-experts, and
signatures or hashes published through the same channel as the binary
can be tampered with in the same way as the binary.

Something along the lines of Certificate Transparency might be useful
here: a public log of software names, versions, and hashes, which a
browser or other download tool can use to verify downloaded binaries
without any manual steps needing to be taken by the user. Software
publishers would be responsible for adding entries to the log for
their own software and monitoring the log for entries added by anyone
else.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSBl+QAAoJEBEET9GfxSfMlVAIAJ/JEwbbZBdihiuUT6PEas9v
Bs/eOnr/+/oTvjVJc/OJvcSHXWr8ne97N3kGzBrQsS6HdiDoxZdUMC/9S+WGLQuG
boMD1MJH2qpPQzA7yG0ZDKWUodg+IvHZosC50ahC+su6zZ176Ic/8v4zzDDxnzF5
zLqtY/jhZSrvmdaWixx4yznmrWbOXo1zxb+ulSDZWZ4TIHZKC+890d4CVGDzFNjY
Yzyz0E3BRX7Ctkbt2dW/EqhBPKsG0FtMzwCsFMa6xPIUp5Ykf0YpQ0WF4n/sTJaO
8bY3HyAtxBAma/gZccDLP1OEkjPdaf27cxJNbcSoAYeKy4cqCOMWWXL/gLbuZqo=
=QkIa
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu or changing your settings at 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] From Snowden's email provider. NSL???

[Michael Rogers]

> The app store can't substitute a different binary (no developer signing key), 
> users can verify that the app was what the developer produced (via pulling 
> the binary and checking the hash), and advanced users can verify that what 
> the developer produced is what they produce via the replicable build process.

I don't know how the Apple or Chrome app stores work, but on Android the user 
doesn't have a standard way to obtain the developer's key, so the app store 
could sign a modified binary with any key.

In any case, verifying a signature or hash against a public key or expected 
hash (obtained how?) is currently a manual process that non-experts can't be 
expected to carry out, let alone understand. What I'm looking for is a way to 
automate that process to protect non-experts.

As far as I can see, locked-down platforms like iOS and ChromeOS make it 
impossible in theory to tell whether the trust root (Apple/Google) is providing 
binaries built from published source code, because there's no way to get a 
verifier onto the device unless it's also approved (and potentially tampered 
with) by the trust root. But I think the situation for browser-downloaded 
software and Android apps might be less bleak.

One aspect that concerns me is rollback attacks: if the verifier accepts 
binaries that aren't listed in the public log, can the adversary tamper with 
the identifying attributes of the tampered binary (name, URL, etc) so the 
verifier doesn't realise there's a log entry that the binary should match?

Cheers,
Michael
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Does anyone know a celebrity who feels strongly about privacy issues?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/08/13 21:32, Francisco Ruiz wrote:
> So, here's my question. Does any one know of a celebrity who cares 
> enough about computer security to be persuaded to take one minute
> of his/her time to read a hash before a camera?

I'd like to second Guido's objection that most people don't know what
a hash is, or have the skills or software required to verify one, so
this isn't an effective security measure for most people.

Even if it were, you'd have to ask the celebrity to read a new hash
for every version of the software, and the videos for old versions
could be used in a rollback attack.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSCf5oAAoJEBEET9GfxSfMUB4H/RTrYX1we2t1p9+TeXm21GV2
OWJkZvWLvfDmJqf/utJNoFH4wgLkDvziWrTCqGWbuDlPlmLzNTvGvIZio9i82cUT
tja1bnmPr17BDz5Msn8d4/BFdjrV957e1S3P2Tqx8GGaZFAYCi5EX57Q7G2Lvphj
4NDkDOFEfwfQ38azsBNokdUXo5Ek98I2SXv2GG3ac8N1a2HBVpsHr3lqfsZLDTyS
LrwM6dPCEWV+kd8+VsOjokKB8y7o9lUjLMmOvMtM4dC9bak8OoDy+fkxWkmMf48v
KBRqsPN6rasEmDxGRDtLZN0CAzEMGcmndJDqMY4tV/v9IgnLRScaMJaz8Fsc8cY=
=7Qy4
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Trsst: An Open and Secure Alternative to Twitter

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19/08/13 07:33, Ben Laurie wrote:
> Merkle trees (a la Certificate Transparency) are more efficient
> than chains. Also, if you did that, you could have a global log,
> and so prove against censorship of an entire blog.

I wonder if Twitter would be interested in publishing something like
this. Then if they were forced to censor a tweet in one jurisdiction
but not another, a third party could reassemble the uncensored stream
of tweets and use Twitter's signed hash tree to prove its authenticity.

Cheers,
Michael


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

iQEcBAEBAgAGBQJSEeW1AAoJEBEET9GfxSfM/TQH/juaDphcbowwxmL75Z3ApRYM
facSkfTQNE2SaRg+zSDOPxzir+YNbKKH5rK7yKDixF/nXf/QLkuwq0P/YEnwBCJl
5xYUd3CyNXxHj8x/7/dq7Idm1b6/rWmf/PtEDULIBzIKN4C4yyIoFpW29MDoy7gI
86NO9ksKBWn1hk4+AXfzUpCnakUYU5b6rA/S57qPlZ7DW8MzoVlNQVGKZy+JDVrN
TG/JsLl9nhunLl5r/32edGWxnni4sDYfA2JK3nsqnAmW4e0v9uNhUDkNu6KuxLFg
UhjT9XaoEiGpQFtjah8QWBKmbIPZstxwZ4r+KbQsdtjK152wzPcW9T1cSs1cWsY=
=wKv6
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Announcing Scramble.io

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 23/08/13 09:53, DC wrote:
> One difficult problem in public-key encryption is key exchange: how
> to get a recipient's public key and know it's really theirs. My
> plan is to make make your email the hash of your public key. For
> example, my address is *nqkgpx6bqscsl...@scramble.io (I borrowed
> this idea from Tor Hidden Services.)

Hi DC,

The simple, usable interface is really cool, I love it.

Obligatory crypto bikeshedding:

An 80-bit hash isn't long enough to prevent a second-preimage attack
by a well-funded adversary, but it's too long for users to memorise or
manually enter addresses. Perhaps a longer hash would be better?

When storing the private key on the server, you encrypt the private
key with a symmetric key derived from the user's passphrase. The
server could use a dictionary attack with rainbow tables to decrypt
the private key. You should use random salt and a key derivation
function designed for deriving keys from passwords, such as PBKDF2 or
scrypt, to derive the symmetric key.

How exactly is the symmetric key used to encrypt the private key? What
block cipher mode do you use? Is there authentication as well as
encryption?

Cheers,
Michael

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

iQEcBAEBAgAGBQJSF2aRAAoJEBEET9GfxSfMgikIAJeU459ig7XNufyyIuO9BAUF
/J0pd0g+pPspWoHvby8W6A1g0ZbTsGBVMbuEOx9BKuSA1FY1skLGZ+Ua6LZUX1ZQ
uLNHFs5+kP5lNelYw2oZp/QI63HExAgjMzrFryRl9/pC3Q49N/jdlN+Ssh5YHZ47
LhPNOtgZP4jTq3//T11f7T3fQ09PALrpgREGagfybfP598sEmLuQ2iA2kZNYWO/9
vSnYnQBaWXtmissF0znaOPELYlGGW/TMZMGWxSJ748pjpWB6fZR3/IlRXTaMrp76
8MVhjQP6MCi5AJpsDserQWscTaQyDTP/g7ZVGshreOFelPGjB4QwhFlBfjBEzr0=
=k3QU
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Announcing Scramble.io

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi DC,

Thanks for the reply. Responses to your responses inline. ;-)

On 23/08/13 21:51, DC wrote:
> The hash format (first 80 bits of SHA-1, encoded base32) is the
> same as Onion URLs use. How do they avoid preimage attacks? (I
> thought generating 2^80 keypairs and checking each one to see if
> the public key matches was simply too much work, maybe I'm wrong
> though.)

80 bits may not be enough to defend against a well-funded adversary
these days - that's one aspect of the Tor hidden services design that
"needs some love".

https://blog.torproject.org/blog/hidden-services-need-some-love

"...the current 80-bit security of onion addresses does not inspire
confidence against impresonation attacks."

> How exactly is the symmetric key used to encrypt the private key?
> What block cipher mode do you use? Is there authentication as well
> as encryption?
> 
> 
> (Currently I'm using the first 128 bits of a SHA hash as the key,
> then AES-128 symmetric encryption.)

What block cipher mode of operation do you use? If the mode of
operation requires padding, what padding scheme do you use? Do you
authenticate the ciphertext? If so, what MAC function do you use, and
how do you derive the MAC key?

These are nitpicky questions, but they could be important for security
if the server's compromised.

> ... after implementing your suggestion, it will be PBKDF2 instead,
> and I'll generate a random salt for each user. (That way, an
> attacker can only try to brute-force one account at a time, instead
> of all of them.)

Awesome!

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

iQEcBAEBAgAGBQJSGKGPAAoJEBEET9GfxSfMIkMH/ioS8guoBIfgNXowtEzNSrHh
akUNxgBQuklMs8ayo+lsWL3VU3/nmjz+gO4jia1mXuRDYTRbz3vmQl1XxhH++eeT
2ci3jCXkc0uLMJ9Do1XFSweO+RGw4qXh0fYNlzkKmNZ9u5b8Y4LOWxDgL60+Ah33
FINtoMG3y/DHthKhyrQc+5pavY5oXAjtom11Hpy03MC0SjhQaW/4WqOgd0hl1Cqa
hBkgd83YuqQ7Mqg4QBCdcL0xyPuQWKaGOPd1eDYUl2qyntpiUQJsMPVLTrNILPQW
xHhr7o7QvNga4MBqExUY1uimaVXwXqIZOGFaagRBZgF0buBIVWYoMsmiaXyfou4=
=bSd1
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Why_can't_email_be_secure

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 25/08/13 20:14, StealthMonger wrote:
> Will the other cypherpunks on this list please step forward and
> help me refute this toxic propaganda?  I don't have time to do it
> all myself.

It isn't propaganda. Or at least, it's true.

> All the problems cited in this Silent Circle blog and elsewhere
> were solved 20 years ago by tools such as anonymizing remailers and
> message pools.  Those tools are still in use today and can be used
> by anyone wanting confidential, authenticated, stealthy email.

Remailers haven't solved the email metadata privacy problem in theory
or in practice. In theory because of long-term intersection attacks;
in practice because not enough people use them to provide meaningful
anonymity, thus nobody starts using them, thus not enough people use
them...

A broadcast channel like alt.anonymous.messages won't scale to
widespread usage (which is needed for meaningful anonymity) and is
subject to fascinating dissection by Tom Ritter due to outdated
crypto, user-hostile implementations (worse even than PGP!) and the
aforementioned dearth of users.

http://ritter.vg/blog-deanonymizing_amm.html

I'm all for a revitalisation of remailer research, but let's not
pretend it's a solved problem.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSG2BGAAoJEBEET9GfxSfMgYsIAJuwYbaeGK4nzrFKy+CluPxI
hHg51MpfjTEBNKgEiUlXtHBVYp5U1d7kZQAPrsOu+8PBFeWt6ybEYRCTDmk2RxQ/
rN67m06/yECUZRqTHpmhhJGD/8seb6bjt6gXFX4yi6ltTD6yENeycc9tuz6M1pRn
nyJNkK9U0T8Aeu++HfWT9WEyPod43b73zFQ+a1VfbdEzi7udwo/0JqrDmFlC1gxA
eva5iosZ7qU6+J1VEEhz0GAiEkv9p6IfazHOgDmB8/WZ785diOm7002rcE/oPOC6
OUeRyQ47eAkNNcm3p2SyDWkRxbOJoagdqEO9XPScmW8jiUX3Krjmt9C/ldOqruE=
=BZAa
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] scrambler

[Michael Rogers]

Quoting the Scrambler website:
"The drawback of the one-time cypher pad encryption method is that to encrypt a 
message without reusing the one-time cypher pad requires it to be 256 times the 
size of the message. Encrypting a one megabyte file without reusing the 
one-time cypher pad requires it to be 256 megabytes. While it is recommended 
that you do not reuse one-time cypher pads, Scrambler will do so."

The author doesn't understand how to construct one-time pads, and flouts the 
most important rule of using them. Avoid this software like the plague.

Cheers,
Michael

Seth David Schoen  wrote:

>Michael Hicks writes:
>
>> ok so I guess I just send u guys the links and u check out my software and 
>> Vet it? This was made for people to be able to protect their privacy and the 
>> NSA can't hack it No One can it's impossible. all the information is at 
>> scrambler.webs.com
>
>It's true that no one can crack a one-time pad, which your software
>claims to implement.  A one-time pad might be useful for some people,
>though it's possible that they shouldn't then use a computer to encrypt
>and decrypt, because using a computer introduces new vulnerabilities
>(like radiofrequency emanations and remote software exploits).
>
>There might still be cryptographic vulnerabilities in the random number
>generation that your software uses.  There was recently a high-profile
>vulnerability in the random number generation provided by the Java
>implementation on Android, which allowed keys to be compromised.  If
>there were a similar vulnerability in the Java implementations people
>use with your software, it might have similar consequences -- which
>might not be the fault of your software, but might still undermine its
>security.
>
>A one-time pad is probably not very useful to most people who need to
>communicate securely because they have to find a safe way, ahead of
>time, to distribute and store the key material with each potential
>party that they may communicate with.  That's a pretty heavy burden,
>especially when people are meeting new contacts and wanting to
>communicate with those contacts (without having been able to arrange
>a prior physical key distribution).
>
>It also doesn't integrate easily with any form of communications
>other than exchanging files, although it would be possible to extend
>it to other things like e-mail or IM if you could manage the sequence
>numbers properly to avoid reusing key material (something our existing
>protocols don't really help with).
>
>If you read _Between Silk and Cyanide_, there's a good and interesting
>historical account of wartime military use of one-time pads.  One of
>the messages seems to be that it was quite expensive and cumbersome,
>though perhaps well worth it for the particular application.  It's hard
>to imagine many audiences prepared to actually bear these costs for
>many of their communications today.  We already see people complaining
>about the effort and overhead of things like PGP merely because some
>aspects of the key management are made explicit to the user.  For
>one-time pads _every_ aspect of key management is made explicit -- and
>manual, and requiring the exchange of physical objects!
>
>My intuition is that people who feel that one-time pads are necessary
>should probably learn to operate them by hand, the way the SOE agents
>in that book did.
>
>-- 
>Seth Schoen  
>Senior Staff Technologist   https://www.eff.org/
>Electronic Frontier Foundation  https://www.eff.org/join
>815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
>-- 
>Liberationtech is a public list whose archives are searchable on Google. 
>Violations of list guidelines will get you moderated: 
>https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
>change to digest, or change password by emailing moderator at 
>compa...@stanford.edu.
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Sociological studies of covert mass-surveillance organisations

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/09/13 10:00, Caspar Bowden (lists) wrote:
> AFAIK Deleuze, Foucault et al. did not say anything specifically
> about covert (mass-)surveillance, or analyse how the inherently
> secret nature of such organizations might be a causal element in
> theories of social control. Secret surveillance organizations are
> NOT Panoptic in a technical sense - they normally don't want you to
> know or fear they are watching (with tactical exceptions).

Is there anyone who's aware of overt surveillance and who doesn't at
least suspect that some form of covert surveillance also exists? And
isn't that suspicion enough to create a panoptic effect?

The prisoners don't know whether they're being watched at any moment,
or whether the watchtower is even occupied; the secret surveillance
organisation, the existence of which cannot be confirmed, corresponds
to the warden who may or may not be in the watchtower.

Wasn't the NSA closer to the panoptic ideal when it was No Such Agency
than now, when we know we're being watched?

Cheers,
Michael

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

iQEbBAEBAgAGBQJSI6hYAAoJEBEET9GfxSfM27kH+Kt8FGxycdshcGVp9JAJmjTp
JmCLCl+mdJFI+zn2T+evk+z28dKdfLg5Tia9+0u48PYxce41GsRJBs7xWVnLjEw5
e9sBOPTQVIjoy1QiD6jNijOozGA3VHOcTJkgCKGnRxHnPpR7OZ0amF2VUbDIS5YE
e48RVNNEmu7RyWaHJw8q+NYJ30mJA7WJep0FlgfmbS8c8ZmJ3SlXOwmyZqHtSmUe
pXqdIXRAwGlpfv5SH99JSuPk0m8CqNSNcS0nZWvtiqVerqTr4uMlXytz4mHv47HG
4mTAJ/vQ75nR7XH5s686sK9vSM5JHAf2a2LZUqUn3bYx5dTHpBkhsq9riBSMIA==
=gUxM
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

[liberationtech] Research on communication in ad hoc groups?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

Does anyone on the list know of any research into the way people
communicate in ad hoc groups? By an ad hoc group I mean a group formed
for the duration of a particular communication, such as the list of
people CCed in an email thread, as opposed to a group defined by a
topic, such as a mailing list or IRC channel.

I'm particularly interested in the way ad hoc groups evolve over time
- - eg as people are added to and removed from CC lists - and the extent
to which members of ad hoc groups also communicate with each other
one-to-one.

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

iQEcBAEBAgAGBQJSJJcpAAoJEBEET9GfxSfMACQIAIgyi8iYJ3sAfvMJKAz92nUB
GEGkc6VAjneu5/dXYQIvx8ABUlxKGSNvDgi5vAPGLTuHGtlLw1fpusIMWGJUDCWP
caSa4zgukH5LKMqVgso4d1K8t+z6ZIsvuZ20318kg3U3ZUlVv2KIQfOG9DZNW/cz
CuRtzHyHn6FJczhDrC/sHMTIti2q3Bggo//Ir3XZIyj8UE72E3nNxFKYXDIL4c+C
RYwGDB3rP3OyYSls/tHyrXfLNmpkxmTW2aqvUnr59X/tY/n9xxAz728ivzd6KfY3
aZLJFgQuPMxbuH3soorAVZ4HshyZ/CuWSKiIj5ngNrGYiFXP+ObQH+7xQviwwjo=
=nyM6
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Research on communication in ad hoc groups?

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks Yosem! "Networks of practice" seems to be a useful phrase for
turning up relevant research in the CMC and management literature, and
"group evolution" for the SNA literature.

Cheers,
Michael

On 02/09/13 20:20, Yosem Companys wrote:
> Computer-mediated communication literature has been studying this
> since the 1980s:
> 
> http://en.wikipedia.org/wiki/Computer-mediated_communication
> 
> The field has its own journal:
> 
> http://onlinelibrary.wiley.com/journal/10./(ISSN)1083-6101
> 
> Sociological approaches have studied how the choice to reply, cc or
> bcc forms social networks:
> 
> http://www.isi.edu/~adibi/Enron/Enron_Dataset_Report.pdf
> 
> 
> On Mon, Sep 2, 2013 at 6:48 AM, Michael Rogers
> mailto:mich...@briarproject.org>>
> wrote:
> 
> Hi all,
> 
> Does anyone on the list know of any research into the way people 
> communicate in ad hoc groups? By an ad hoc group I mean a group
> formed for the duration of a particular communication, such as the
> list of people CCed in an email thread, as opposed to a group
> defined by a topic, such as a mailing list or IRC channel.
> 
> I'm particularly interested in the way ad hoc groups evolve over
> time - eg as people are added to and removed from CC lists - and
> the extent to which members of ad hoc groups also communicate with
> each other one-to-one.
> 
> Thanks, Michael -- Liberationtech is a public list whose archives
> are searchable on Google. Violations of list guidelines will get
> you moderated: 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech. 
> Unsubscribe, change to digest, or change password by emailing 
> moderator at compa...@stanford.edu <mailto:compa...@stanford.edu>.
> 
> 
> 
> 

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

iQEcBAEBAgAGBQJSJfXCAAoJEBEET9GfxSfMYzwH/2Lhm+mQFSA0gTDVyaPo/ZE/
n9l4UKkyCefV1aeAoPgqJyzE+VnLtVDhH4wvNhJ9UcxnKtUb0lNwHE7SCHTXMd8l
AOVfQzDwqctY1bW96YqRtN77PZ1yQKntKT+fsDQvgvwANAr6nVsDNIFsIN1Ya3Qz
ypvL5Ptxs/cZa8rJ5to4IuVJtK7aRtWuRi060fUjXy1fb4LnOp+ub6hMVb8zRZ3y
y5L+lNCJanv7Tp8D7yuw16EjsmWfWOSKIrHFbW8X77WwxHowfOivukrI+BNsy5zY
URqWr0s36uiR2I7K3wjGUj9XGZPVmDa3nBAJNvpUrmbvAkEUNbL38bYzenLhTp4=
=+8vy
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] NYTimes and Guardian on NSA

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/09/13 21:10, Richard Brooks wrote:
> 
>> There is a massive difference between cryptanalysis and
>> decade-long, well-funded, and top-secret program to subtly weaken
>> international cryptographic protocols and sabotage industry
>> implementations.
> 
> 
> Their job is to collect information for the military. That their 
> work is top-secret should be obvious. That they try to weaken the
> crypto not used by the military and US gov. should also be taken as
> a given.

They have two jobs: to monitor foreign communication, and to secure
domestic communication against foreign monitoring.

http://www.nsa.gov/about/mission/

The argument for trusting NSA/NIST crypto standards has historically
been that weak crypto would make the first job easier but the second
job harder. We now have to re-examine that argument and ask whether
the NSA has been gambling with the security of US commercial,
government and military data (up to top secret level - the highest
level that relies on NSA/NIST-published standards) in order to further
its surveillance mission.

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

iQEcBAEBAgAGBQJSKemfAAoJEBEET9GfxSfMEOIH/0UEKnJkh+nL2gC2hNRp+N8S
hrQeBqLL5oBy2zBbgunXVTlTBA/3YFAmbqdXwnTlGeO9Oypns0cxap3P8bzBKxVr
V0jAWpe8edzZ47RyaKEI25op7K8pJnRHKPBgVIoUk8x0j6QkqJ+yV/C59in3u2e1
DPSJvddH408yo57qge90zh55OLM/FQKFnRM3U2fUnOAQrWkYkRqAsDDfh1XPYwaY
G0Lyuv/NRuJDoUgqIl8IXuB4ZBNxth72u0iSvoSD1q7npVU/vzkLttEwtb/4fSxc
J/wzGayX+9+zti3VrqGuW9HA7ya6ZYln7TN7ZYXU4CHLz4RuOlkUD9ac5xJzUl4=
=cPKX
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] NYTimes and Guardian on NSA

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 16:01, Richard Brooks wrote:
> Interestingly, with the DES standard there were some changes 
> introduced by NSA that were thought at the time to be backdoors, 
> since they were never justified.
> 
> Many years later, the community realized that these changes made 
> some obscure attacks less likely.

Yes, that anecdote often accompanied the argument that NSA wouldn't
risk peddling weak crypto. Clearly the balance of priorities within
the agency has shifted since DES. It's worth asking whether that shift
predated (a) the AES competition, (b) Suite B.

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

iQEcBAEBAgAGBQJSKgA/AAoJEBEET9GfxSfMMccH/iFmJ4bqzrOE+fT0sXJiXJuY
trew0gi1wlTqwZaCRysJj/oPRprbHaaUSvMXx+KUpBg9kZRt4IvzA6f24CHFL+y+
pHznE3OCZxM8COmnJOO6ij546oiZYfhY8nHyObLddxte6rzsh+phyrK6yZ3qB4Eh
XZfk+nEuiEj0s9QP9u8wrlgJev+qEv6yud/eB+meny7CpDwGQoLh37agjKjjEaYX
7KtArFoNVDoAnp0MBoscMDwv7JBcY6KxB996O7kVxSevY0B0Yes4r+fzwaaNVCZS
CIlD8uwePnDuDU3eOM73Fy7UGfFMEMEyOqYGyCBR+tDRriSZwPeu6+koicyrQgg=
=Q0MY
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] NYTimes and Guardian on NSA

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/13 19:25, Maxim Kammerer wrote:
> I don't see any evidence of said shift in priorities. NSA
> supported escrowed encryption in the 90's, and the alleged
> subversion of standards is most likely similar to escrowed
> encryption, but at the algorithmic level [1], where an adversary
> gaining access to key escrow requires computational / cryptanalysis
> effort that's equivalent to breaking the cryptosystem in question.
> 
> [1] https://en.wikipedia.org/wiki/Dual_EC_DRBG

Depends on what you mean by breaking the cryptosystem. Cracking all
instances of the Dual EC DRBG takes equivalent effort to cracking a
single instance of a backdoor-free elliptic curve cryptosystem.

http://rump2007.cr.yp.to/15-shumow.pdf

So the analogy with key escrow is a bit strained. With key escrow, the
adversary has to crack every key individually, whereas with a backdoor
the adversary only has to crack a single key to compromise all users.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSKlLAAAoJEBEET9GfxSfMr9cH/10ZDmMVU+izR62V3KgcKHOT
dJ+HwF0gkJ0FxeBd2xVA47XHbU3Shnni23XdJhS9l7YPlQdSGt07nu3O1srYALYg
a4vt/OCbkREov9F92OpAEsmkTFw0b2eE4+AwTjU5cJ6KnZ2zm7Fr312Z4m5D4SKQ
h2YNNzXimFCQ4GtTZvelqd7gYfpY7P6TFZWVz5uPqLAaX444Fo8ZsH6u6F4vlJMa
/gxDPjXS+5yPHHeYvsHjiiRBBcBYM4SfkmM2emuuOVOdmQOWmD4zRdHjXR82kYca
ZXpZnzXcfqZ5uma5n4tYXuexs+hjt88KCZQ5uBxwE8JMCxn0uyszsWHuazzrf6k=
=SzwW
-END PGP SIGNATURE-
-- 
Liberationtech is a public list whose archives are searchable on Google. 
Violations of list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Fwd: Firefox OS with built in support for OpenPGP encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13/09/13 10:04, Eugen Leitl wrote:
> Baseband processors leave the system wide open to all kind of
> attacks. Countermeasure would be running the 2G/3G/4G stack in an
> open source SDR radio, or using an open source VoIP device that
> connects by WLAN to a MiFi, which is considered part of the
> untrusted Internet.
> 
> The open source WLAN VoIP handset is more difficult than it
> appears. In practice you'll have to use e.g. Jitsi with an USB
> headset on a portable computer. Not exactly painless, and it opens
> you up to system compromises.
> 
> If anyone is aware of suitable dedicated hardware, I'd be thankful 
> for pointers.

The Samsung Galaxy Player (Samsung Galaxy S WiFi in some countries) is
essentially an Android phone without a baseband. I believe you can run
CyanogenMod on it.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSMuFgAAoJEBEET9GfxSfMN6MH/i9od0mmSAZAC5kxudPAfvbO
fqKJ4l9dlxnn/hlBvq0K+B3FPaLuqOQlnY8bxaGi1uMhCVBqiUUBC601Nk+Bv06m
MPO1sdpcYbW/cpPNxOqFthiiWpzm3ZR37ycB7gxtwx/AZDGfLGPefZHxX4Hb0Fif
7RIWS8LkYgHkc0JeFURYE/pkE1PZ088KaiTR7RRl4Ya0IZ37U3fmlvP5uahapM0N
l7AQQsVog70+8JFNNh4E2PWA6mwLG3MtUfvnvNiP7PBiFYv9i9knOqzczvgU8KXf
uZ5yxuLsBtmwOHQsp7KhXZ9SsJR4RkVwYMx9VYBW58lQIJ079a12RYbVAyQ0SGE=
=CTO/
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/09/13 11:03, Fabio Pietrosanti (naif) wrote:
> The user have only those two platform, a browser and a mobile phone
> with downloadable apps. Everything else requiring to install an
> application over a desktop computer is IMHO destinated to be a
> total failure.

So Skype, AIM and BitTorrent are total failures?

Cheers,
Michael

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

iQEcBAEBAgAGBQJSNfneAAoJEBEET9GfxSfMmW8IAJ9h7Ta2t/m/iBLeWVanJRV3
tI3eiipYY+jlfno/QW13KCsnaRJETDKi5+PXtXZgmuuZ4FeWExyp6mFGON0JwC6o
QQ75wDpicd0leUmcQlUagO10Vk+YVXCesGDOto0gP4w3SMrMguTCnT5J8cS0TOgd
/PkSkOmFf24fP/U6Qcd9BJkpyVkvrAUdqHslkHfcbXxAeS9UeWwUm0Lgrc+M2R3N
YyfXtBBzdkRsZvrwm1fjvOkLInBignd0vGBYOIABxt2D7ovWx0YHVTptnuEp2VMu
Cqch6zD8A31dzueikkmDeERY8EOX1sZ0/dYevqdUZDtf32wS8bf1bTgHWWK72JI=
=zcw4
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15/09/13 16:49, Jonathan Wilkes wrote:
> I'm not completely sure, but I don't think that is possible.
> 
> For example: regardless of privacy implications, discoverability on
>  Facebook is a feature.  Regardless of privacy implications, 
> suggestions for friends based on the social graph (and updates to
> it) is a feature.  I don't see how one could retain just those two 
> features in a p2p design with privacy in mind.

Friend suggestions can be based on a partial view of the social graph
- - for example, each user may be able to see their friends and their
friends' friends, which would enable an algorithm running on their own
device to suggest friends' friends who they may know, without anyone
(including the service providers) having a complete view of the social
graph.

Limited searching would also be possible using a partial view, and
would support the 'best' use cases for the feature (reconnect with old
friends, find that person you were talking to at that party) without
allowing people to look up complete strangers.

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

iQEcBAEBAgAGBQJSNf0mAAoJEBEET9GfxSfMzZIH/isBHqnfMhNdKTRQFHyEggMl
9L0Qn1sWOVqeiM13B7HylX1SkUNdJyQddfJC3RmoMqUfECV08LxW9j+YFGgpQ2/Y
+Qkd+vOmBVQ2fQeMv3WDFO1ikt+VASbDM69g4EGLQZiBiCf6agYlhokZuuYo62Tx
uIXft6GmOhgCNJhadfy68BGmkCYgtqTj+zVx4ytnwT79c6XUoQMyspPoCpEQTHvj
PkFHSs6n2ZuXPyWB69d3s/YwZF8rA9oMTuezXEMK7RadjB9hE2A+Int/OlxEdtzb
qkgQBgVhdxEbot8fUKBRlljwMqGOEZNlujB0NOWap7PKR1y56t8VBSu0JNOPjNk=
=SSoz
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/09/13 07:59, Brian Conley wrote:
> 
> On Sep 15, 2013 8:19 PM, "Michael Rogers"
> mailto:mich...@briarproject.org>>
> wrote:
> 
>> On 14/09/13 11:03, Fabio Pietrosanti (naif) wrote:
>>> The user have only those two platform, a browser and a mobile
>>> phone with downloadable apps. Everything else requiring to
>>> install an application over a desktop computer is IMHO
>>> destinated to be a total failure.
>> 
>> So Skype, AIM and BitTorrent are total failures?
> 
> Sure, from the perspective of privacy and security, at least re
> Skype and AIM.
> 
> If Fabio isn't talking about privacy and security I must have 
> misunderstood his entire post.

Unless I misunderstood, Fabio wasn't claiming that desktop apps are a
failure from a privacy or security perspective, but that users won't
install them, therefore we must focus on browsers and mobile apps. I
gave three counter-examples of popular desktop apps. I wasn't trying
to make any claims about their privacy or security, just their popularity.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSNt5DAAoJEBEET9GfxSfMLrgH/0JlOxaRJdVSnY8EVQddvqqM
GNtJHRS3K3dSYyWH0EoHo1fPZoHu6K6HDgJVqF6RUIMhfQZ9Syz9eIfrVCXamyS7
OC44CexMZ+Ncczun30bCIvLlAWYGmSsW5dlPgnRjIhM7treh7YxNJYzByOpD/sDN
rk7wYheHQr4fdOPnu07/e3nEYQPxKGhaFwU/zvRItt8JOzQ2Kujr3i1gO/XJI2fv
t8y0J8qxlgtdgcngGo5v5Ja5vmq6S1SsYpqZOt6pQQKV9kjKSIAEmg20qL3g/7LH
klf+emtyk1irb8poaKtBSsfdxkDKZ2QYJfZ6Hs+fescrmzFUdk8gCIX80BdW9WI=
=mC7y
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16/09/13 06:57, Jonathan Wilkes wrote:
> On 09/15/2013 02:32 PM, Michael Rogers wrote:
>> Friend suggestions can be based on a partial view of the social
>> graph - - for example, each user may be able to see their friends
>> and their friends' friends, which would enable an algorithm
>> running on their own device to suggest friends' friends who they
>> may know, without anyone (including the service providers) having
>> a complete view of the social graph.
> 
> If the network scales, and the average user has about 250 friends,
> how many users would it take to share their data with a third party
> to provide that third party a complete view of the social graph?

If the answer's greater than one, you still get more privacy than in a
centralised system.

I'm not sure we can expect any system to protect people's privacy if a
significant fraction of those people are willing to share everything
they know with a third party. But we can protect against more moderate
threats, like centralised providers that have an economic incentive to
spy on their users, and a legal duty to share the results of their
spying with the government.

>> Limited searching would also be possible using a partial view,
>> and would support the 'best' use cases for the feature (reconnect
>> with old friends, find that person you were talking to at that
>> party) without allowing people to look up complete strangers.
> 
> How does the network tell the difference between my search for an
> old friend and my search for a total stranger?

Your partial view of the network probably includes your old friend
(through mutual acquaintances), but by definition it doesn't include
any total strangers.

> Please push me back on the right track if I have a blind spot 
> here-- I'm having a difficult time seeing a technical difference 
> between a social network that allows partial views of the graph in
> order to maintain a semblance of privacy, and a system of
> distributing digital copies of music that tries to limit the number
> of times a file may be copied.

The difference is goodwill. It may be reasonable to give a piece of
information (such as a list of your friends) to each of your friends,
and ask them not to share it any further. It probably isn't reasonable
to try the same thing with 10,000 strangers, while simultaneously
trying to convince everyone who doesn't have the information that it's
the latest cool thing to have, which is what the music industry would
like to do.

> In fact, it seems worse in the case of partial graph views-- at 
> least with music copying there's an icon representing "the music" 
> and keystrokes or mouse clicks representing "the act of piracy"; 
> from the music industry's point of view (i.e., their concept of 
> "privacy") they can drill down on the alleged immorality or
> negative consequences of a user _doing_ those actions and persuade
> _some_ amount of people with such an argument.  With social
> networks as I know them, the variables that control which pieces of
> users' data get sent to what location, at what time, and how often,
> are hidden away from the day-to-day UX.  And even if they are put
> front and center, how does the user measure the moral hazard
> associated with allowing certain parts of their data to be accessed
> from one hop away, vs. two hops, etc.?

I wouldn't expect a P2P social networking app to provide a button
marked "share my friend's list of friends against her will". However,
even if it did, I think the immorality of pressing that button would
be pretty clear.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSOL+jAAoJEBEET9GfxSfMEskIAKDyjLt3JU62kOPNZ7rW2FW8
trpfYXoOvi+52b5GE52OXVppzNLlwOxYBMXWlJDK9OaxvS0Dfh0GgQ6hj1F9ZnJU
3YHkLxT/82zI+fU4tBalqW9ZZFvfbCetq00LuL7mOPmraEpRWNqVqBikGefwer7m
C/sJXWWAjnhsWy0Q8Dh0TjnK2Hxo6/eEqeXRlBf8+Vk830rZ7zCU2tpjFQXxMLFk
lLvXuS2PedtqBP3pQCkYiEqOU0fuCpSu1vIkSI4OBK86dks7TT9FfddaOvzYtnEX
jvOK2Sb1GTusFsY5t1DS+Bxd6ViCpUdmtk44MXcBRywugB9ucH55DZmx6iDkS/g=
=k5C9
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22/09/13 20:51, Jonathan Wilkes wrote:
> Goodwill is a pre-internet concept that is predicated on things
> like short human memories, and it wholesale ignores all the moral 
> hazards that come from being able to install a splitter on a
> single line and copying all data everywhere, private or not, for
> nearly nothing. Not to mention store it forever.  Not to mention
> retrieve it for next to nothing...

Either you think the internet has destroyed any meaningful notion of
friendship or we're talking at cross purposes.

Let's imagine that you and I are friends who belong to a P2P social
network. We make an encrypted connection between ourselves, over which
we exchange various confidential information, including lists of our
friends. My contention is that the goodwill between us as friends will
tend to prevent either of us from sharing that information against the
other's will. Thus your list of friends won't end up in the hands of
some marketing company, and neither will mine. Nevertheless, equipped
with lists of our friends' friends, we can search for acquaintances
old and new, just like on Facebook.

This doesn't require goodwill from Facebook or AT&T or the NSA or any
other centralised entity - it only requires goodwill between friends.
I don't believe that's an obsolete concept.

> Unfortunately the p2p model seems to be to make a prototype, or 
> even a working system, and stop at the point where it's minimally 
> functional, usually because funds are scarce.  That's unfortunate, 
> because for anything like an updated concept of goodwill to really 
> function in such a system the user _must_ know what the current 
> threats are and a way to accurately glean the mid-term and maybe 
> long-term threats.

There are plenty of failed P2P systems, just like there are plenty of
failed centralised systems. The floor of Silicon Valley is littered
with dead and dying Facebook clones. So I wouldn't dismiss the P2P
approach just because it's produced some failures.

> Otherwise you create a social network that looks like it has
> checks and balances built-in, but, e.g, no one really understands
> _why_ sharing beyond the first node is a danger and no one cares
> about honoring the premise (including the friend sharing the list
> in the first place).

I think those concepts are easier to grasp in the P2P setting than the
centralised setting, because they map to existing norms concerning
personal relationships and privacy - for example, if a friend sends
you a private message, there's a well-established norm that you don't
share that message. As long as the software implements normative
behaviour as the default, users will only break the norms if they're
determined to do so - and such violations will always be local in scope.

> Nearly every social network UX is designed to hide such risks, and 
> I don't see any examples of an alternative.  Does yours offer one?

There's no reason for an app to provide a user interface for acts that
harm other users. If someone wants to create their own "sell out your
friends" fork of the software then of course nobody can stop them. But
that's a small-scale violation of trust between that person and their
friends - it isn't really comparable to someone at Facebook or AT&T
copying strangers' data en masse to the NSA.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSQFxGAAoJEBEET9GfxSfMPwgH/0a3h9YOskYlXrhzVpthha7t
TMP5oi3HFfTrpgPB2yTHfTaNzD9bTKalTLawN7vvnDoaq+Eu9UIRny+dNYar2u4X
d5EHGSq+vv65X9M3X+b7QhAGy/G2ycNNgky1k/fse/Jzr2fg4yOkofSBmQyf
D5oYgAkvl3Ykhn3WSprUdQCUceG6a7Tr8ihsKcFLpXs0adiQfQsdcjmN9r2Acfsb
mKszf0rJFTOT0+7winhtdKTRoIeez42hVTD51tJDyaT+Jbl8VYTPIFIMVhH8u8gO
d6zWXcGUWALm5i1qNDguXlNfpZPy7LaFwgUj2P18K8H2scaCoYgGdiw6yiCmhBE=
=UOq0
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/09/13 05:21, Jonathan Wilkes wrote:
> Is Briar able to hide metadata that describes who is messaging
> whom within the network from an attacker with a splitter on the
> internet and a $50+ billion budget?

We'll see. :-) Briar moves communication off the internet wherever
possible, and when communicating across the internet it uses Tor
hidden services to conceal social relationships. So it may justify the
attacker's budget more than current systems do.

But I take your point that all digital communication is vulnerable to
surveillance, and that our individual choices to communicate digitally
may threaten our collective freedom. The question is, what should we
do about that? Even the postal service is digitally surveilled these
days - should we restrict ourselves to face-to-face conversations?
What about hidden microphones - should we have all our conversations
naked, inside Faraday cages?

It's clear that we can't stay sane and guarantee that we're free from
surveillance. So we have to make tradeoffs. I believe that P2P social
networks offer a better privacy/convenience tradeoff than centralised
social networks. They don't guarantee absolute privacy against an
adversary with unlimited powers - nothing can. But they're less bad
than current systems.

> It's probably better to say that goodwill does not address such
> moral hazards.  People can develop and maintain friendships over
> the internet, but currently doing so creates a toxic waste that
> silently eats away at our collective freedom.

Thanks, I understand better now what you mean by moral hazard. I don't
have an answer to your question of how communication tools should
explain that moral hazard to their users. I'm not sure it's even a
matter of explanation - informed individual choices may still lead to
collectively detrimental outcomes.

Surveillance is a collective problem, and as such it requires a
collective solution, which is to say a political solution. But that
doesn't mean technology is irrelevant - it can contribute to a
political solution in two ways. First, it can raise the cost and lower
the effectiveness of surveillance, making surveillance harder to
justify politically. Second, it can support political action by
enabling people to speak, associate and organise, in private and in
public. I think those are two reasonable goals for technologists to
set themselves, as part of a broader political effort against
surveillance.

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

iQEcBAEBAgAGBQJSQZofAAoJEBEET9GfxSfMv1QIALUAunmk6oQDkToR5ryPWOQy
Ip22NrEgIZw55QnzKYR/lRTJVoiRoAkakPisW7DrzVerGnyjKodsx2JRefaxKsHO
JUCM/E8uGCyTxOp4macWWHDjsOtFABgoSf1sLH81TfYqIwrC52wyM2T1njEDlLrG
phgdxkUHw1BX1BpVbaAhn0iSGRs/wC7j0qZ+6S3xMgPRM4pXxGLypC9WG4f1PWGS
42h+PWr02pNhPCEC+Ked3Lg+/ACHQf6atlV3gHT2NoqZy33eDbjLs6Rbo32EeLTl
3K7eC0wf11ICxh7Q+aSBNgbb+oZGDNxkxUP1IUDzmPDRTxLqLBUBnQPg7xk15YU=
=t6TK
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] uVirtus Linux, encrypted OS for Syria

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/09/13 15:23, Lorenzo Franceschi -Bicchierai wrote:
> Thoughts?

The update feature of uVirtus's Sanctuary VPN (OpenVPN obfuscated with
obfsproxy) is a bit concerning. The source code has been removed from
Github, but judging by the description on the uVirtus site, the client
downloads an encrypted list of proxies from an update server. The list
is encrypted with a key that's baked into the client. No integrity
protection is mentioned.

(The choice of encryption algorithm is odd - "Password Based
Encryption with MD5 and Triple DES". Perhaps that's for compatibility
with very old export-restricted versions of Java?)

As far as I can tell (again, going by the description on the site),
someone with access to a copy of the client could extract the
encryption key and forge a list of proxies. The forged list could then
be substituted for the real list by intercepting connections to the
update server, causing other clients to connect to proxies controlled
by the attacker.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSRcuGAAoJEBEET9GfxSfMPF4H/33xwYjOILGmG0psGHfdubq8
f1ZR9Cr7ghetRyRx1gNvrCxh2xBygSA9fUZA+GXJveZBzc4X95aDjhmQKNtvXdhC
zHrymKc6YQo/ijeE2uVpbbiJks+VVoTEqstF/bu6es+j+/SMUNenrzg2z7zkM7IQ
eAGS7Y7ge8qkyMT0KEmD2rtpGBaFjyKY5NEf0KjCtcrAoD08hycrvzuN8cYL7IDa
g+TLsfgtukMMw976qVrULkC+VrgYvuUOVyVNXO3VFBiTaYpdnb/XCXaK7KwSBF2X
aNxqr1+FEt/es9eTd3STAK3zKqf+g+2zq9N2qHYzLnW1dnl1h7E8al36w5RVOsk=
=O8FP
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] NSA-GCHQ meeting on Tor (with slides!)

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/10/13 16:42, Griffin Boyce wrote:
> There are some questions in my mind as to the legitimacy of this 
> document -- particularly given that a slide is marked 2007, but 
> references 2012. (In particular, neither Torservers nor TorButton 
> existed in 2007).

The first slide is dated "Jun 2012", with the following in a red box:
Derived From: NSA/CSSM 1-52
Dated: 20070108
Declassify On: 20370101

The first Egotistical Giraffe slide has a similar red box:
Derived From: NSA/CSSM 1-52
Dated: 20070108
Declassify On: 20371101

The Egotistical Giraffe slides use the date 24 October 2012 in an
example, and state that the Tor Browser Bundle is based on Firefox 10
ESR, which was true between 12 June 2012 and 22 February 2013.

https://blog.torproject.org/category/tags/firefox

My guess is that the slides come from 2012 and the Dated field in the
red boxes refers to something else - perhaps the start of the
programme to which the slides belong?

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

iQEcBAEBAgAGBQJSTvV0AAoJEBEET9GfxSfMAwYH/R/vvChln81L6erYUQwmlZvs
vFrpDx/Pqy7hr0QuH5gLFcROsyqeJoN2Gjub5s5pmvwi/825SuLZ26euD4iwt8bn
0CLd0u+oa3UPcxduMiwJF50VzwjpVQIp+xmYlBFzlVSwLRlm7pQqhHNhBNsrhXOO
Hnoro3/xZn5x/osZEvusxh7QlEveqy8rpo9dK5PJe0BsnVu3IPHY5ig1H/ysfiBv
boFaL0eRUEftsVHFTZGk5rmK5PXTrfstvv5+CrOXSKt2tjm6ExSVTsVX+TWPVW9d
xGDXvX4kprMTe+FgD3KrbSLX4xKjG6rYTUlRvYGU2Xgv8U4nOs1IhaL4tLMgc58=
=VlKC
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] 10 reasons not to start using PGP

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/10/13 01:14, carlo von lynX wrote:
>> No one anywhere has solved the problem of asynchronous,
>> forward-secret group cryptography.
> 
> I think you have to be a bit opportunistic about it. Briar does it
> somehow, if I understood correctly.

Yes and no. I think Elijah's referring to the problem of encrypting a
message to a group of recipients, so that any recipient can decrypt it
up until a certain time, and nobody can decrypt it after that. We
haven't solved that problem, but we do have a different solution for
asynchronous forward-secret group communication.

No crypto innovation is involved, it's just a matter of group members
disseminating the message over forward-secret pairwise links. I think
Retroshare might do the same... but who knows? ;)

Cheers,
Michael

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

iQEcBAEBAgAGBQJSWCifAAoJEBEET9GfxSfM4esH/0kheDnkp2Mo/Y8d7nkPWc0t
dhduAGTZg+kDkNyhXvCbrPoQ8yCHca6Os8Tg+yMrtNP2PHrz1w6nmdTLDCfFQ9pt
kWAT1klqG0wRMJKGwYXeUfukR2y04gNJvLhpPcE8XUehY2tRtF1myTWLr8CD4CJw
XG0E8YmkaUFeIFoH5+tW9uwsM+8Gl81U0zeZ279unAMOSmaxOccirZ4i2eWCqNEP
VZ8JWr0C8FHDI2A8PIh6nJGSBALkxADSrSicDdSfF7w1RILyz12+ot5RH4j7nZHv
3nx1GFCvA3wtySqcYsBWXNRZKgbu9JuAIq7LTVgyyPx6mXWzsxg0QdwnB8bpldc=
=vWGC
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Riseup registration process a bit odd...

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 29/10/13 16:50, Douglas Lucas wrote:
> That no one can see an HTTPS URL seems contradicted by this EFF
> "Tor and HTTPS" diagram: https://www.eff.org/pages/tor-and-https
> 
> For the diagram, if you click the HTTPS button to show what data
> is visible with only HTTPS enabled, you can see that some of the
> data is encrypted, but not the site name ("site.com" in the
> diagram).
> 
> Can anyone clarify?

The site name is visible, but not the rest of the URL.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSb92eAAoJEBEET9GfxSfMjpUH/RQDPP6H8Dz5NVNKHorfoxb0
ehAK4g99o51zt7B0123HMLnyTwK+uTOqMSwGuTFwFH0Ma/ohGOJ4FJPQs/MnkqOH
fOQCYjHN7w4IPg8PaaSO/MXmFEwK9sagQatz0T4HyKRZJba1+xJUVi+f1fch6ChF
GwAfevc7dW2GSCGUpUu4//rbF5ZxHTvDpKJJyXjCD/ME98i3IHBiHNpPK1SyE23B
SUTUFBWI2Qhw2heirYYbpI+gf96OTP+1veaMqBGvtLqSsGDBdgIFeRMVwjFBAa3m
RTiqX9BbDGwwgyF/gcpA0rkjTKPkQaDSUbHYOmMs/aKnVcUxEAGBX1B4FIxhA0Y=
=ScAS
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Exclusive: Inside America's Plan to Kill Online Privacy Rights Everywhere

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/11/13 11:29, Eugen Leitl wrote:
> 
> http://thecable.foreignpolicy.com/posts/2013/11/20/exclusive_inside_americas_plan_to_kill_online_privacy_rights_everywhere
>
> 
For users of Adblock Plus, the following rule allows access:

||foreignpolicy.com/sites/all/themes/fp/projects/identity/*

Cheers,
Michael

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

iQEcBAEBAgAGBQJSjfniAAoJEBEET9GfxSfMOhAH/j5j+BCdksuQDQphW7xJVAxt
FURTm1NP2wWGXtjUuZs1vYkylcOx41KMnhtbz+RcEuVuF2MYEgh44Uo9byioVEdt
zG+83d1mugmFwh0t2kAEL6HzO4PjQI2TdbZmbl2bx7rCgMVLJ3S1+woihr5WJfJr
Jf/SoFBeQKPO+WtgNDpOqoTW6dmvdYuFxkiocwf0ush0JCyxOoyz8M4KUZ+ro91Z
5MWswlfJZxoCBbWCEoY9c5j/kxUJ8GFcY7opXsrFf0RD1pyvZHcaACDkzLb416fi
Y+ryOOt/F6BO8y7Phtcn9tgv5rCAUxqw0+xpCmUMeTLeRWrFXHvLgH2fpTI/Xr0=
=+k9L
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Solutions to surveillance, beyond tech & legal

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/12/13 00:44, Yosem Companys wrote:
> Using this framework, it's clear that the media is focusing on the 
> regulative (laws) and parts of the cultural-cognitive (tech), but 
> ignoring the normative and affective, as Dan notes, including arts
> and humanities.

Perhaps we could see the fact that the media's interested in this
issue at all as an acknowledgement of the normative and affective
aspects - i.e. the appetite for surveillance stories comes from people
being upset that norms are being transgressed?

I do agree though that there's a lack of explicit engagement with
normative questions - the terrorism frame tends to exclude them. What
frame can we use to challenge the terrorism frame? Big Brother lacks
emotional traction and doesn't have much to say about norms either.

Cheers,
Michael

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

iQEcBAEBAgAGBQJSsXfgAAoJEBEET9GfxSfMxnIH/2cRoPGZYvw3GJt/flKyRyij
wULWTN1DXMJeytLfwMexFObAvg3e9g1BNTkrb/lvkxqN6tfGhDtD1wOLFL0aVKAL
XWvoSSu1uHQ2tHciYVWszDejIE2iO6xLraqO6C+uvqRlm9Kh+4UWE5v1mnvSJR9x
4M2dGivD4eOYpgPeNpsqBt+142DFULWODW2w1mnPqIZDDUdTFvoh4+3p9qnPNsma
b4wKpOYtLeV9wXkQ/esPBPn0ki6WhAudbYNYaTMxT8xOEjOr47QB5A+Y2g3bemJC
UJ1jyuMkY7l31qGzzXc4pgrhBGk+zMEdAF7pzR5YIXgUm1E5ekoywJCT+Prmydc=
=EEYX
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] [sunlightlabs] need advice on using hashes for preserving PII's utility for disambiguation while protecting sensitive info

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/02/14 20:56, Margie Roswell wrote:
> For all I know, the lack of implementations using this kind of 
> one-way transformation isn't about government sluggishness but 
> rather about its feasibility. I'd be very curious to hear folks 
> ideas on this score, though.  My general hunch is that something 
> must be possible -- even a few bits' worth of disambiguating 
> information would be hugely useful to us, and presumably you're
> not leaking important amounts of information by, say, sharing the
> last digit of a DLN. So there must be a spectrum of options. But as
> is probably apparent, I don't think I've got a handle on how to
> think about this problem rigorously.

Even if you had a perfect method of anonymising the individual
records, they might be reidentifiable by examining the whole dataset:

http://33bits.org/2010/06/21/myths-and-fallacies-of-personally-identifiable-information/
http://randomwalker.info/social-networks/
http://www.cs.utexas.edu/~shmat/shmat_oak08netflix.pdf

At the level of individual records, you could use modular
exponentiation to anonymise the data. You pick a prime modulus p, and
each organisation that's going to publish anonymised data picks a
random secret value. Organisation X with secret value x anonymises a
piece of data d by publishing d_x = d^x mod p, and organisation Y with
secret value y anonymises the same data by publishing d_y = d^y mod p.

If X and Y want to know which records they have in common, X takes the
data published by Y and calculates d_x' = d_y^x mod p = d^(yx) mod p,
and Y takes the data published by X and calculates d_y' = d_x^y mod p
= d^(xy) mod p. For each record in common, d_x' = d_y', but neither
can de-anonymise records published by the other that they don't have
in common.

This can be extended to more than two organisations: pass the records
round in a circle, and when they get back to you they've been
exponentiated by all the secret values (order doesn't matter). Now you
can see which records you have in common with all the other organisations.

(Maybe. IANAC.)

Cheers,
Michael

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

iQEcBAEBCAAGBQJS9NWaAAoJEBEET9GfxSfMyWcH/1Au9/066O/3AaPkkid8nBhq
2uuNjjLgDWzE+5aTIQGMzk9yy85TRKlXKdC4c9/n0UXxJjAUYxkLSoNkAD33ej36
s/oi3pI0C9OQ1MffJVCSImA+NwQ0QqDG6DOUBNPRoBUTr/nd5efbBRwWVtLSn50D
0QlLJYXUGGB+fSMZKyy368rrx5Ue8ICQOzIUyNJ3sWZsQEJo0nE8WJd1+89GlR45
XPRSUUma/5DCECl9gWBFq5pVuEtf29KoXV6QLCzagWCaAa2dNlCspoGp4bVlkBz9
UWMJRFHYDj9AxzUKt5Vi++uh6nYrTu++a7bXqOGJHb9y8VL54JHweEXNW2xWyog=
=BrUY
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Fwd: A new Mixmaster is in the works!

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/03/14 01:42, Cypher wrote:
> More features are under discussion. We would like your input on
> what features you would like to see. Please keep in mind that we
> are looking at functionality first. Secondly we are looking at
> introducing a desktop GUI for major operating systems. Lastly we
> want to make using remailers and encryption as seamless as
> possible.

This is great news! A couple of feature requests:

1. Forward secrecy. Maybe copy some ideas from Mixminion: link
encryption and periodic rotation of mix keys.

2. Make it useful for sender-recipient unlinkability as well as sender
anonymity. There are a few people who want to send email anonymously,
but there are many more people who want to send email privately to
recipients who know them. A remailer network that prevents metadata
eavesdropping would be useful to far more people - and would therefore
have a larger anonymity set - than a network that's mainly useful for
whisteblowing and bomb hoaxes.

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

iQEcBAEBCAAGBQJTKuB3AAoJEBEET9GfxSfMJdAH/RP2sfiCLxjoqkFO12g/FU/0
SFX8sER9T3OeiElFGJeIGOD7NtoVw4YMnXa4DiNWIONP47vHjIgzxzlGY8oSfgPj
2+tgJK+nrPrpc4VHbG/1JQ97/h+NCXyZtw8JNWSNWrs6A/K0sJsYvr9t/ZD+p+Vj
Db73A5GqG/pRPlVtIArhA0eS2LYF7uD2/Il2eCBrKjix89puck+ayiIvL0obWYE0
1cwoXJomtUjFfhix3zZc92GH7A0abTm18FmvSJMLWaKYpBhM0EFUAToTJioio0s1
olAgNTjdz47W9MDs/Gm2Zv5dFemUUoYL4lIFBGqe/8+o0V9mU22tqxkZNplUuy0=
=APtC
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Trsst Encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Michael,

What you're trying to do is very similar to ECIES. You should probably
use ECIES, which has received more review than your design. It's
implemented in BouncyCastle, and there was recently a thread on the
BouncyCastle mailing list about how to use it.

The cost of deriving the shared secret via ECDH will vastly outweigh
the cost of symmetric MAC and encryption operations, so there's little
point in cutting corners.

If you decide to stick with your own design, here are a couple of
comments:

On 19/03/14 16:01, Michael Powers wrote:
> (3) To ensure you can decrypt your own message, you encode one of
> the keys for yourself.  Might your private key be compromised when
> used with your own public key moreso than someone else's public
> key?

Good question - I don't know if it's safe to derive an ECDH shared
secret from a private key and the corresponding public key. An
alternative would be to save a random symmetric key alongside your
public/private key pair, and use that instead of a shared secret for
deriving the encryption and authentication keys for your own copy of
the message.

> * Takes the specified 32 bytes, appends its sha-256 digest, and
> xor * encrypts those 64 bytes with the sha-512 hash of the ECDH
> shared secret * and the entry id.

Are entry IDs supposed to be unique across all messages?

What happens if a sender accidentally reuses an entry ID? What happens
if Alice sends a message to Bob with entry ID n, and Bob sends a
message to Alice with entry ID n? The messages have the same shared
secret and entry ID, therefore the same shared hash.

The adversary can XOR the encrypted keys to get the XOR of the
unencrypted keys. Does it help the adversary in some way to know that
message 1 is encrypted with unknown key k1, message 2 is encrypted
with unknown key k2, and the XOR of k1 and k2 is x? I don't know, I'm
not a cryptanalyst. ;-) But it makes me uneasy that the adversary has
*any* knowledge about the keys.

> KeyAgreement keyAgreement = KeyAgreement.getInstance("ECDH",
> "BC"); keyAgreement.init(privateKey); 
> keyAgreement.doPhase(publicKey, true); byte[] sharedSecret =
> keyAgreement.generateSecret();

Make sure you validate the public key before using it. See SEC 1
section 3.2.2.1, and Java code here:

http://code.briarproject.org/akwizgran/briar/blob/master/briar-core/src/org/briarproject/crypto/Sec1KeyParser.java

> // generate 512 bits using shared secret and entry id MessageDigest
> sha512 = MessageDigest.getInstance("SHA-512"); 
> sha512.update(sharedSecret); 
> sha512.update(ByteBuffer.allocate(8).putLong(entryId)); byte[]
> sharedHash = sha512.digest();

This homebrew key derivation function is a reinvention of the
concatenation KDF from NIST SP 800-56A section 5.8. You should think
about why the NIST KDF includes extra inputs, such as the identities
of the parties in the key exchange and the output length, and why it's
so careful about delimiting the inputs.

> * Takes the specified 64 byte encoded input and xor decrypts it
> with the * sha-512 hash of the ECDH shared secret and the entry id.
> Then checks to * see if the last 32 bytes is the sha-256 hash of
> the first 32 bytes.

You're reinventing a MAC. Please just use a MAC.

> KeyAgreement keyAgreement = KeyAgreement.getInstance("ECDH",
> "BC"); keyAgreement.init(privateKey); 
> keyAgreement.doPhase(publicKey, true); byte[] sharedSecret =
> keyAgreement.generateSecret();

Validate the public key.

> // verify that the digest of first 32 bytes matches last 32 bytes 
> for (i = 0; i < 32; i++) { if (digest[i] != decoded[i + 32]) { //
> incorrectly decoded: we're not the intended recipient return null; 
> } }

You should use a constant-time comparison here to avoid timing
attacks. Something like:

boolean matches = true;
for (i = 0; i < 32; i++) {
matches &= (digest[i] == decoded[i + 32]);
}
if (!matches) {
// incorrectly decoded: we're not the intended recipient
return null;
}

> int maximumOutputLength = bufferedBlockCipher 
> .getOutputSize(inputLength); byte[] output = new
> byte[maximumOutputLength];

Now that you're using PKCS padding, this is simply the output length -
no need to truncate.

But anyway this is irrelevant - use ECIES!

Cheers,
Michael

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

iQEcBAEBCAAGBQJTKupbAAoJEBEET9GfxSfMqjEH/jtUZ4krXgyyIisNtynmQbYO
Ona2renHcbZr7ajBZgEMFGeuFK2dmH9v0aqrsTrnke3RLA2YN2gxe6pzvdJE6z6/
CoIwcPIAqe1bE2iZN/HiFrrLoamQqX2YiTRQbooCc2+FulmWJVs3tzaTFltwlS6U
MfADfNzbzPIgN1pZ3oZ75AMAzXvlTS8RF7zjiuE7WGWB0YkhMHe9BrbSL5n+7HSh
krrKAUscw1cXtlC+/g3KzR0wOtHd1Io5Y55GTJEj+X+q+enZ5AiJ+rJNHM/bwckw
EtY4vWwOu0NQjypJRpLweqeTD80lHFerqOT1nzOrXa4vnV8SnRR9mOL37UTUSAw=
=yytB
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
chang

Re: [liberationtech] Trsst Encryption

[Michael Rogers]

On 20/03/14 14:58, Guido Witmond wrote:
> On 03/20/14 14:17, Michael Rogers wrote:
>> You should use a constant-time comparison here to avoid timing
>> attacks. Something like:
>>
>> boolean matches = true;
>> for (i = 0; i < 32; i++) {
>>  matches &= (digest[i] == decoded[i + 32]);
>> }
>> if (!matches) {
>>  // incorrectly decoded: we're not the intended recipient
>>  return null;
>> }
> 
> Wouldn't this be vulnerable to a compiler-optimisation that
> short-circuits the &= operator?

Good point, maybe so!

> If so, will this be better?
> 
> // count the number of matches; must be equal to length.
> int len = 32
> int matchcount = 0
> for (i = 0; i < len; i++) {
>   matches += !(digest[i] == decoded[i + len]);
> }
> if (matches != len) {
>   // incorrectly decoded: we're not the intended recipient
>   return null;
> }

You can't add a boolean to an int in Java, but you could do this:

matches += (digest[i] == decoded[i + len]) ? 1 : 0;

Cheers,
Michael
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Trsst Encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/03/14 19:30, Yuriy Kaminskiy wrote:
> Note that all above variants may be NOT actually branchless and
> thus NOT really constant-time (depending on architecture, jvm
> implementation and options, etc). Most likely, resulting time
> difference won't be sufficient to be useful for attacker, but... (I
> doubt very much you can write guaranteed-constant-time code in java
> (and most other high-level languages) at all.)

Yeah it would be really nice if Java had some way to mark a block of
code "do no optimise".

> PS If you don't want to invent bicycle, there are boolean 
> java.security.MessageDigest.isEqual(byte [], byte[]) method.

Thanks for the pointer. The Javadoc doesn't say whether this is a
constant-time comparison. In OpenJDK 6 it isn't. In OpenJDK 7 it does
something similar to my original suggestion. So unfortunately it seems
like this might be a case where bicycle-invention is necessary.

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b27/java/security/MessageDigest.java#MessageDigest.isEqual%28byte%5B%5D%2Cbyte%5B%5D%29

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/java/security/MessageDigest.java#MessageDigest.isEqual%28byte%5B%5D%2Cbyte%5B%5D%29

Cheers,
Michael

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

iQEcBAEBCAAGBQJTLDYDAAoJEBEET9GfxSfMGPkIAK5G1yzYH7G9lWCt+lTO6MGo
7/rsNWFil0k3dBlI9oVcXEV7+eo+n3DygLdYBv/XmquDjEiVHDQd8j8hpDkjUv77
dNbJzrINgvAJScVfczfPTRemMfm+nuUTePN4T/g4CLTxybBfqr+I+cumrPq9Ez0+
IpzvoUT93NfQM3Z7bPbwTWj0mdm7BQtFau9m2fnUBeh0P+Vor1i1MTW/4pb6w47+
NAAib30nTK21ja8f3vSh5uJ/NEH9jLVaEnwL3lXOpc0DU2u+Hme73zFcVSnwk3gY
u4mll9lKN1bZk/8kYgd+EU1HG2EB/z0863I1GuPE87rF1MJwSFZ4Nom4uOy7Ziw=
=1uie
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Trsst Encryption

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/03/14 12:52, Michael Rogers wrote:
> Thanks for the pointer. The Javadoc doesn't say whether this is a 
> constant-time comparison. In OpenJDK 6 it isn't. In OpenJDK 7 it
> does something similar to my original suggestion. So unfortunately
> it seems like this might be a case where bicycle-invention is
> necessary.
> 

Sorry for the self-reply: wrong link. I resign from this thread. ;-)

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/security/MessageDigest.java#MessageDigest.isEqual%28byte%5B%5D%2Cbyte%5B%5D%29

Cheers,
Michael

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

iQEcBAEBCAAGBQJTLDdJAAoJEBEET9GfxSfMOCoH/j0g68J7m8zDAvFb6tZB7lUJ
QaCoU5mYf2uh64dW7j7e9rNZdV8P938gS5348V6Tb/UyQC8QXlF0dWbWALb3iQG8
ZU74LB+bMyhe2vtJKt86PnkwJR7MfrnZq2xIZowaxKWXtHqQS2BzsU2Q8sinu9By
78p9EYdiuxDOGK7BwtR4yqq93voBHKo0i/j8oOSWnj1OOmYOTgoPXVL08s7Iznvl
IIdt3ZoqM0UIuB/a8ZvhY+KCp1K/zXZIX9KmR2MOxKtFSLgz7LRBlv58i6lBAaXD
wA/4L2e4exNi0zUMfDihpjPpaj1Sp/yTbqlXH9SekrwHO1QNchEpS+H+qBtaXJk=
=55xn
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] US created secret Twitter network in Cuba

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It's news because it was a covert project, which USAID supposedly
doesn't engage in.

> "There will be absolutely no mention of United States government 
> involvement," according to a 2010 memo from Mobile Accord, one of
> the project's contractors. "This is absolutely crucial for the
> long-term success of the service and to ensure the success of the
> Mission."
> 
> The program's legality is unclear: U.S. law requires that any 
> covert action by a federal agency must have a presidential 
> authorization. Officials at USAID would not say who had approved
> the program or whether the White House was aware of it.

http://bigstory.ap.org/article/us-secretly-created-cuban-twitter-stir-unrest

Cheers,
Michael

On 03/04/14 14:54, Katy Pearce wrote:
> I don't see why this is news. Many people and organizations on this
> list are working on similar projects, funded by AID. The framing of
> the article with Cuban Spring and all that was problematic.
> 
> On Apr 3, 2014 6:09 AM, "Andrés Leopoldo Pacheco Sanfuentes" 
> mailto:alps6...@gmail.com>> wrote:
> 
> FYI
> 
> http://m.voanews.com/a/ap-report-us-secretly-created-cuban-social-media-network/1885374.html
>
> 
> 
> -- Liberationtech is public & archives are searchable on Google. 
> Violations of list guidelines will get you moderated: 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech. 
> Unsubscribe, change to digest, or change password by emailing 
> moderator at compa...@stanford.edu .
> 
> 
> 

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

iQEcBAEBCAAGBQJTPWiaAAoJEBEET9GfxSfMMSkH+wWh1ti1YHSY/fPqT7ArHDfX
8eooWsrtALw477qYdLvJ/IhmCeRqKl4NHuq4zKUTg5ef51H2HNnov6LcEAUqF/s/
EFORym+pufe3WWUKho6/81VzhemlLHLsh0iC35EEElKQc6O6uMvSfKhAO3iLPgi+
ygXEEKRj1fNIdcZjPRcs9KSMfOGhz5C2XgLoPbDyCtv7viZ2aq8OqGqPo7ZfCKU6
289HXS0oucyOGdvBc1UdjAfdZSD4HLbCnc7Is6yFklVODZRfGNk5PiiU0Z7v/5C2
dJ+zP+U/aWyy+4vXS+R2f+rj9W0bDL/JP9OvaKHz8bPCtEZeCjk1JamPriFSQrs=
=LNXy
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] Programming language for anonymity network

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Stevens,

I think it would be irresponsible to start a new project in C or C++
given the enormous number of security issues caused by memory handling
bugs in C and C++ code. Here's a quote from a Debian security advisory
I just received, which is typical of these advisories:

"Multiple memory safety errors, out of bound reads, use-after-frees
and other implementation errors may lead to the execution of arbitrary
code, information disclosure or denial of service."

These are entire classes of bugs that don't exist in safer languages.
Avoidable bugs like this are found every day in widely used, open
source software. Software that isn't widely used and open source
presumably has a similar density of bugs, but they're undiscovered or
undisclosed.

C and C++ programmers seem to think that memory handling bugs are
something that happens to other people. They're not. Every programmer
in every language makes mistakes, but in C and C++ simple mistakes can
have subtle and disproportionately serious consequences.

Cheers,
Michael

On 18/04/14 09:26, Stevens Le Blond wrote:
> 
> Hello,
> 
> We are a team of researchers working on the design and
> implementation of a traffic-analysis resistant anonymity network
> and we would like to request your opinion regarding the choice of a
> programming language / environment. Here are the criteria:
> 
> 1) Familiarity: The language should be familiar or easy to learn
> for most potential contributors, as we hope to build a diverse
> community that builds on and contributes to the code.
> 
> 2) Maturity: The language implementation, tool chain and libraries 
> should be mature enough to support a production system.
> 
> 3) Language security: The language should minimize the risk of
> security relevant bugs like buffer overflows.
> 
> 4) Security of runtime / tool chain: It should be hard to 
> inconspicuously backdoor the tool chain and, if applicable,
> runtime environments.
> 
> To give two concrete examples:
> 
> Using the C language + deterministic builds is an attractive option
> with respect to 1), 2) and 4), but doesn’t provide much regarding
> 3).
> 
> Java does better with respect to 3), however, it trades some of 3)
> and 4) as compared to C. Specifically, we are concerned that large
> runtimes may be difficult to audit. A similar argument may apply to
> other interpreted languages.
> 
> Given these criteria, what language would you choose and for what 
> reasons? We would also appreciate feedback regarding our criteria.
> 
> All the best, David, Nick, Peter, Stevens, and William
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJTVp7DAAoJEBEET9GfxSfMQMAIAL/P3WfYgLeNe9oa5SQhtTEO
JXdP41q7UNS1ZznRMY+gsKLNZr3bjaSfJiLqALVkNl8XpHQCAbMwFowxtmkcvah/
7ZwXhT2Y2OT3DwobnT/173T611I3+w6QG4AJULmVt02mU01XeUuN23UPVYNjOZ/M
ZQrbZ6E45kes7Qq2TAG8FwK4tTnmjzzEyr9W0VOH/x9j1+oes4t2BHAM8cpb7+cr
E0aJLAJCth0ICt0nK2Ms6R1T7NyrgdzQLI+YJ3PGiyz5ajxyEfohrvfPkfPPeAEW
nmLly6GSga/gmQzx7yLNgUj7h4tD1IMkC5CTWu4Yd1kd2LLF8kEto03rPf6+Au0=
=GMPw
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

Re: [liberationtech] IETF Draft: Pervasive Monitoring is an Attack

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Todd,

The draft has become RFC 7258.
https://tools.ietf.org/html/rfc7258

Cheers,
Michael

On 10/07/14 14:12, Todd Weiler wrote:
> Hi all,
> 
> This IETF draft  on Pervasive Monitoring is about to expire - in
> case anyone hasn't seen it, it's a very worthwhile read:
> 
> " Pervasive Monitoring (PM) is widespread (and often covert) 
> surveillance through intrusive gathering of protocol artefacts...
> PM is distinguished by being indiscriminate and very large-scale...
> The IETF community's technical assessment is that PM is an attack
> on the privacy of Internet users and organizations. "
> 
> http://archive.ml1.net/draft-farrell-perpass-attack-06.txt
> 
> Cordially, Todd
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJTvqv6AAoJEBEET9GfxSfMJcEIAL7Z2U6ae+rHmTfLy0K4v46K
SJRCHd5wJ4D1INPuz3Iwihy0FEfj4Yb6hlti1EH2qwBJNz7ICvVr2ZVjLlOf4R0L
dFLaco9a2DGDlSTI6X8LQpmQam/rIoWbNp8B2uyDthFFXjwZnQtpS6iuN2YoABtC
jFLStPPdem6mlZNHWus/YefUkMdpip6ptcvGJv9OI9sXkZj5kzsMyFHUgeCzfo1S
2fTx71Jpzoe/oR38jeTsoqQqpKu53/ipdzhkcEPkwMhTRdrJor3n/Dm9+2pZD4w1
cF3h7JSD/yQ2vPorCYCqyUWhsXdxkr6L+8eQ2bi9G/Za0MXuTz2X2t9jMz9MX4Q=
=iL6/
-END PGP SIGNATURE-
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.