Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] An encryption project

Julian Oliver julian at julianoliver.com
Mon Jan 28 09:37:37 PST 2013


..on Mon, Jan 28, 2013 at 07:18:00AM -0800, Yosem Companys wrote:
> From: Paul Christian <phosne at gmail.com>
> To: cryptography at randombit.net
> 
> Hi Folks,
> 
> I am new to the list and have in interest in encryption, but not much
> experiance in breaking/testing or a details understanding of modern methods.
> 
> I am interested in developing some technology to allow a user to
> communicate as securly as possible between a termial on an unsecure network
> and another users.
> 
> ie encrypted message from browser to user on another computer. Under
> circumstances that the senders life may depend on it being secure.
> 
> I have a few ideas in mind, but two important questions;
> 
> is it worth while? - is ssl good enough? ( it doesn't seem to be from my
> reading)

TLS/SSL is itself pretty good (symmetric keys for data transport encryption,
asymmetric for auth), though only as good as the trusted certificates themselves
- if you're using certs that have been stolen, cracked or are otherwise bogus an
attack vector opens up there. Thus, it all breaks down at point 3, in this list:

    http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x64.html

Schneier has a good point regarding CAs and trust:

    http://www.schneier.com/blog/archives/2011/10/the_security_of_4.html

The problem is quite significant, after all:

    http://www.computerworld.com/s/article/9219663/Hackers_may_have_stolen_over_200_SSL_certificates

There's the BEAST attack, though OpenSSL v1.0.1 and onward support a new TLS and
so this is largely mitigated now.

'SSL stripping' (Moxie Marlinspike) is one strategy: It MiTMs the connection
(w/ARP cache poisioning etc), detects a request for a resource via SSL
(sslsniff) and brokers the SSL connection for the client - doing all the
handshaking and key generation on the client's behalf. The server is
none-the-wiser. It then serves the 'stripped' resource back to the target as
HTTP, logging the payload alongside.  This relies on the user not noticing that
the URL prepend has changed from "https" to "http" in their URL bar (something
Google responded to by making their SSL URL bar very yellow):

    http://www.thoughtcrime.org/software/sslstrip/

Have you looked into WebRTC? This is a browser-to-browser, realtime (RTC)
communication (media/VoIP/filesharing etc) project with a Javascript API.
Security is with SRTP and DTLS (AFAIK). 

It's currently supported in the nightly builds of Firefox:

    http://www.webrtc.org/

Cheers,

-- 
Julian Oliver
http://julianoliver.com
http://criticalengineering.org



More information about the liberationtech mailing list