Slashdot Mirror

← Back to Domains

Domain: guardianproject.info

Stories and comments across the archive that link to guardianproject.info.

Stories · 3

  1. UK ISP Tests SIM Card That Forces All of Your Mobile Data Through Tor (vice.com)

    Yro · Privacy · · posted by BeauHD · from the middle-finger-to-surveillance dept. · 46 comments
    An anonymous reader quotes a report from Motherboard: [O]ne UK grassroots internet service provider is currently testing a data only SIM card that blocks any non-Tor traffic from leaving the phone at all, potentially providing a more robust way to use Tor while on the go. "This is about sticking a middle finger up to mobile filtering, mass surveillance," Gareth Llewelyn, founder of Brass Horn Communications, told Motherboard in an online chat. Brass Horn is a non-profit internet service provider with a focus on privacy and anti-surveillance services. Tor is a piece of software and a related network run by volunteers. When someone runs Tor on their computer or phone, it routes their traffic through multiple servers before reaching its final destination, such as a website. That way, the website owner can't tell who is visiting; only that someone is connecting from Tor. The most common way people access Tor is with the Tor Browser Bundle on desktop, or with the Orbot app on Android.

    But, in some cases, neither of these totally guarantee that all of your device's traffic will be routed through Tor. If you're using the Tor Browser Bundle on a laptop, and then go to use another piece of software, that app is probably not going to use Tor. The same might stand for Orbot running on older iterations of Android. Nathan Freitas, from The Guardian Project which maintains Orbot, said with newer versions of Android, you can lock down device traffic to only work if a specific VPN is activated, including Orbot's. This SIM card, however, is supposed to provide a more restricted solution in the event that other approaches don't quite work.     The UK-exclusive SIM card requires that users create a new access point name on their device. It also requires Orbot to be installed and running on the device itself.

  2. NSA-resistant Android App 'Burns' Sensitive Messages

    It · Encryption · · posted by Unknown · from the many-have-tried dept. · 183 comments
    angry tapir writes "Phil Zimmermann's Silent Circle, which halted its secure mail service shortly after Lavabit, has released a messaging application for Android devices that encrypts and securely erases messages and files. The application, called Silent Text, lets users specify a time period for which the receiver can view a message before it is erased. It also keeps the keys used to encrypt and decrypt content on the user's device, which protects the company from law enforcement requests for the keys." Seems similar to pieces of the Guardian Project.

  3. Report from HOPE: Cryptocat And Encryption in the Cloud

    Yro · Encryption · · posted by Unknown · from the meow-meow-encryption dept. · 29 comments

    In a world increasingly dominated by the cloud, privacy is often sacrificed for convenience. Imagine a world where you could use cloud services without allowing the provider to read your data. Author of Cryptocat (a browser-based secure chat system) Nadim Kobeissi shared the problems he faced developing Cryptocat, his solutions, and future of client-side cryptography. Read on for more.

    Update: 07/18 03:48 GMT by U L : Slides (PDF) from and video of the talk are now online.

    Despite giving workshops on Off- the-Record messaging to Middle Eastern Activists, Kobeissi found that adoption was low because of the complexity of installing new chat software, plugins, generating keys, verifying your friends, etc. Especially when the person on the other end had not been taught how to use OTR. At the end of the talk he gave some reasons why North American users may find it easier: we develop this software and export it so we have a community of developers available for support, whereas in the Middle East this is foreign software lacking context.

    Since he was interested in client-side cryptography and there was a clear problem getting people to securely communicate, he set out to experiment with the former while solving the latter. He identified several problems thwarting success:

    • Code delivery is insecure (will it be intercepted and modified? Can you trust the original server?). Compounding this, code in browsers is ephemeral, making it nigh impossible to trust.
    • The JavaScript random number generator, while fine for most uses, is not good enough for encryption (its only seed is the current time, making it vulnerable to attack).
    • There are no standardized primitives for working with cryptography algorithms in JavaScript, and libraries available at the time were not very good.
    • Browser sandboxing was often incomplete and exploitable (a situation which has improved, but new bugs are still occasionally found). If the sandbox breaks, all bets are off.

    To each problem there is a solution. For code delivery, Chrome apps proved ideal. There are interesting client side security features, bundles can be signed, sandboxing is effective (aside from the occasional convoluted exploit), and you only have to verify the source once. For encryption, he developed his own implementation of the Fortuna CSPRNG and several cryptography primitives in JavaScript, using keypress timing, mouse movement, window position, etc. for entropy (on mobile devices, the accelerometer has proven useful). Chrome later added their own implementation (which has access to the system entropy source) with Firefox support coming soon.

    But where to go from here?

    We need an API for transparent encryption: it should be as enforceable and easy as https. We need a full crypto toolkit in the browser, protected key storage (the author suggested protected JavaScript variables), OpenSSL compatibility (certificate formats, not the horrendous C API). And we need secure communications usable by mere mortals.

    The W3C formed a web cryptography working group six months ago, with a specification due in 18 months.

    Working with the Guardian project, the Cryptocat developers hope to introduce AweSoMe (always secure messaging), which aims to build a suite of utilities for easy and secure messaging (guaranteed message delivery, verifiable end-to-end encryption, and control over logging).

    Development of Cryptocat2 is in progress, using XMPP rather than their experimental protocol, and mpOTR which extends OTR with group chat features and newer ciphers. The specification is half complete, and contributions were encouraged.

    Although secure chat for the masses is being worked on, there is still much work to be done on securely storing data in the cloud. Luckily, the lessons learned developing Cryptocat will apply to future projects.