[liberationtech] Cryptocat Project Report 2012-2013

[Nadim Kobeissi]

Download the report: https://project.crypto.cat/documents/report-1213.pdf

The Cryptocat Project’s goal of bringing
private, encrypted and accessible instant
messaging to the masses was never
perceived as easy. We were beset with new
technologies and a seemingly impossible
challenge. Striking a balance between
security and accessibility has been one of
the most difficult challenges in computer
security for years before Cryptocat was
conceived.

Last year was the first entire year that
Cryptocat had for itself, and the year where
we started making great progress. Spring
and Summer saw Cryptocat presented at
conferences from New York City to Rio de
Janeiro. In Autumn we released Cryptocat 2,
the first major revision of our software.
Cryptocat was encouraged and criticized,
met with skepticism and praise. For a
project trying to tackle such difficult
problems, this was our best case scenario.
Cryptocat is now used by thousands daily. It
has found a surprisingly broad user-base,
from transgender counselors to journalists.
We’re achieving our goal to make private
communications accessible.

Cryptocat is being built so that anyone can
chat on the Internet without being surveilled,
even if they’re not a computer scientist. It
works in your browser, it’s colorful and it has
a cat. This is what we’ve accomplished in
2012, and what we’re looking to do in 2013.


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

[liberationtech] Comprehensive overview of IG related processes

[Marcin de Kaminski]

Hi!

I'm looking for a tool (or list) that visualizes the multitude of
Internet Governance related processes going on atm. Is anyone aware of
such a service?

/Marcin
-- 
Marcin de Kaminski
PhDc Sociology of Law, University of Lund - www.soclaw.lu.se
Lund University Internet Institute - www.luii.lu.se
Cybernorms Research Group - www.cybernormer.se
Personal homepage - www.dekaminski.se

Email: marcin.de_kamin...@soclaw.lu.se
Phone#: +46-(0)768-045151
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

Re: [liberationtech] Fwd: [Crypto Stick News] Vulnerabilities of Self-Encrypted SSDs

[Andreas Bader]

On 01/14/2013 06:23 PM, André Rebentisch wrote:
> fyi, André
>
>  Original-Nachricht 
> Betreff:  [Crypto Stick News] Vulnerabilities of Self-Encrypted SSDs
> Datum:Mon, 14 Jan 2013 17:14:51 +0100
> Von:  n...@crypto-stick.com
> Antwort an:   webmas...@crypto-stick.com, n...@crypto-stick.com
> An:   n...@crypto-stick.com
>
>
>
> Researchers found vulnerabilities of self-encrypted SSDs. From the abstract:
> "Self-encrypting drives (SEDs), such as Intel's SSD 320 and 520 series, are
> widely believed to be a fast and secure alternative to software-based
> solutions like TrueCrypt and BitLocker. [...] In this sense, hardware-based
> full disk encryption (FDE) is as insecure as software-based FDE. We also show
> that (2) there exists a new class of attacks that is specific to
> hardware-based FDE [Full Disk Encryption]. Roughly speaking, the idea of
> these attacks is to move an SED from one machine to another without cutting
> power, i.e., by replugging the data cable only. [...] Some machines are
> arguably more vulnerable when using SEDs." Watch the videos... [1]
>
> This article: http://www.crypto-stick.com/node/74
>
> [1] https://www1.cs.fau.de/sed
>
>
> --
> Unsubscribe, change to digest, or change password at: 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech
>
>
Here is a german speech from the 29C3 in Hamburg, Germany, where the
problems of SEDs are also mentioned:
Unsecure SEDs Youtube


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

Re: [liberationtech] Fwd: [Crypto Stick News] Vulnerabilities of Self-Encrypted SSDs

[Julian Oliver]

"Roughly speaking, the idea of these attacks is to move an SED from one machine
to another without cutting power, i.e., by replugging the data cable only."

Ouch.

..on Mon, Jan 14, 2013 at 06:23:41PM +0100, André Rebentisch wrote:
> 
> fyi, André
> 
>  Original-Nachricht 
> Betreff:  [Crypto Stick News] Vulnerabilities of Self-Encrypted SSDs
> Datum:Mon, 14 Jan 2013 17:14:51 +0100
> Von:  n...@crypto-stick.com
> Antwort an:   webmas...@crypto-stick.com, n...@crypto-stick.com
> An:   n...@crypto-stick.com
> 
> 
> 
> Researchers found vulnerabilities of self-encrypted SSDs. From the abstract:
> "Self-encrypting drives (SEDs), such as Intel's SSD 320 and 520 series, are
> widely believed to be a fast and secure alternative to software-based
> solutions like TrueCrypt and BitLocker. [...] In this sense, hardware-based
> full disk encryption (FDE) is as insecure as software-based FDE. We also show
> that (2) there exists a new class of attacks that is specific to
> hardware-based FDE [Full Disk Encryption]. Roughly speaking, the idea of
> these attacks is to move an SED from one machine to another without cutting
> power, i.e., by replugging the data cable only. [...] Some machines are
> arguably more vulnerable when using SEDs." Watch the videos... [1]
> 
> This article: http://www.crypto-stick.com/node/74
> 
> [1] https://www1.cs.fau.de/sed
> 
> 
> --
> Unsubscribe, change to digest, or change password at: 
> https://mailman.stanford.edu/mailman/listinfo/liberationtech

-- 
Julian Oliver
http://julianoliver.com
http://criticalengineering.org
--
Unsubscribe, change to digest, or change password at: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech

[liberationtech] Fwd: [Crypto Stick News] Vulnerabilities of Self-Encrypted SSDs

[André Rebentisch]

fyi, André

 Original-Nachricht 
Betreff:[Crypto Stick News] Vulnerabilities of Self-Encrypted SSDs
Datum:  Mon, 14 Jan 2013 17:14:51 +0100
Von:n...@crypto-stick.com
Antwort an: webmas...@crypto-stick.com, n...@crypto-stick.com
An: n...@crypto-stick.com



Researchers found vulnerabilities of self-encrypted SSDs. From the abstract:
"Self-encrypting drives (SEDs), such as Intel's SSD 320 and 520 series, are
widely believed to be a fast and secure alternative to software-based
solutions like TrueCrypt and BitLocker. [...] In this sense, hardware-based
full disk encryption (FDE) is as insecure as software-based FDE. We also show
that (2) there exists a new class of attacks that is specific to
hardware-based FDE [Full Disk Encryption]. Roughly speaking, the idea of
these attacks is to move an SED from one machine to another without cutting
power, i.e., by replugging the data cable only. [...] Some machines are
arguably more vulnerable when using SEDs." Watch the videos... [1]

This article: http://www.crypto-stick.com/node/74

[1] https://www1.cs.fau.de/sed


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

Re: [liberationtech] Gmail SSL Certificate Churn?

[Nick Daly]

Sky, the cert fails because I'm (very, very slowly) trying out
different PGP-SSL bridges (it's four or five projects down, at this
point).  Right now, this means that my cert is self-signed, and that
it can be verified by checking the PGP signature on the authentication
statement:

http://lists.alioth.debian.org/pipermail/freedombox-discuss/2012-June/003880.html

So far, I've learned that this approach isn't very scalable. :)

You can check the site without HTTPS by going to:
www.betweennowhere.net/blog/2013/01/gmails-changing-ssl-certificates/

The betweennowhere.net site just redirects to the
https://www.betweennowhere.net site anyway.

On Sat, Jan 12, 2013 at 9:44 PM, Sky (Jim Schuyler)  wrote:
> Rapidly means several days to a week for google.com. We (Cyberspark.net)
> watch the Google.com SSL certs (not gmail) and it takes at least a few days
> as they roll new certs onto multiple IP addresses (round robin DNS). I have
> only monitored this for the last two years, but it's been the same both
> years. I have never understood why they don't or can't deploy the new certs
> more rapidly, and it does set off repeated alarms within our systems. But as
> long as they are valid and properly signed we just watch and smile.
>
> DNS rotates the address for Google.com among a number of IP addresses, and
> they don't update all of those servers at the same time, so it appears to
> our monitors as "thrashing" back and forth between the old and the new
> certs.
>
> I wonder if anyone in the group knows whether there's any good reason they
> should or shouldn't push new certs on all machines at the same time?
>
> (Nick -- would like to see what you have online, but won't blast thru a
> certificate warning. Perhaps you have it somewhere else.)
>
> -Sky
>
>
> On Jan 12, 2013, at 2:57 PM, John Adams  wrote:
>
> Additionally, while you're complaining about other people's SSL
> certificates, you should fix yours. :)
>
>
>
> On Sat, Jan 12, 2013 at 2:54 PM, John Adams  wrote:
>>
>> Google has stated publically that they rapidly roll their SSL
>> certificates. Nothing to see here, no blog post to write, move along now...
>>
>> -j
>>
>>
>> On Sat, Jan 12, 2013 at 2:19 PM, Nick M. Daly 
>> wrote:
>>>
>>> Hi folks, can you help me understand how to interpret this data?  It
>>> appears that Gmail's SSL certificate changed fairly frequently during
>>> the month of December.  That seems wrong to me.  What's this all mean?
>>>
>>>
>>> https://www.betweennowhere.net/blog/2013/01/gmails-changing-ssl-certificates/
>>>
>>> The weirdest part isn't how the 0E:66... certificate disappeared on
>>> November 20th (or December 5th), but how it came back into circulation
>>> on or around December 20th.
>>>
>>> Thanks for any clarification you can offer on this situation,
>>> Nick
>>>
>>> --
>>> 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
>
>
>
> --
> 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