[liberationtech] BabelCrypt: The Universal Encryption Layer for Mobile Messaging Applications
This [0] may of interest to people implementing secure IM. Instead of creating an IM app from scratch and hoping for wide adoption, babelcrypt is a keyboard app. One installed an an android smartphone, the keyboard passes encrypted data to an existing IM app such as whatsapp or Fb messenger. Using certain android APIs, it can also access content on the screen to display received messages. [0] http://www.iseclab.org/people/mweissbacher/publications/babelcrypt_fc.pdf -- 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] Proposal for more-trustable code from app stores; comments welcome.
On Thu, Sep 25, 2014 at 10:00 AM, Nick liberationt...@njw.me.uk wrote: But to be honest I'm not sure why people who are happy to use a completely proprietary mobile computing system would care that much about this. There is a difference between trusting Google and the manufacturer VS trusting the hundreds of proprietary apps and how they'll use your data... The attack surface is much smaller in the former... Nick -- 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. -- 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] Foxacid payload
if Google start actively looking for bugs, aren't they going to have a ranking per vendor every year to incentive bad vendors to improve? What are the other means they can incentive vendors, without making too much of a fuss that users don't loose confidence in web security overall? On Thu, Jul 17, 2014 at 11:07 PM, Richard Brooks r...@g.clemson.edu wrote: On 07/17/2014 05:57 PM, Griffin Boyce wrote: Andy Isaacson wrote: this is exactly why some who have received these payloads are sitting on them, rather than disclosing. Hmmm, that seems pretty antisocial and shortsighted. While the pool of bugs is large, it is finite. Get bugs fixed and get developers to write fewer bugs going forward, and we'll rapidly deplete the pool of 0day and drive up the cost of FOXACID style deployments. Forcing deployments to move to more interesting bugs will also give insight into IAs' exploit sourcing methodologies. Solidarity is really important here. Increased security for those who actively set honeytraps doesn't really scale at all, and most people will never reap the rewards of this work. =/ Forcing the government and defense contractors to burn through 0day at a high rate is far, FAR better than coming across one or two on your own and hiding it. These backdoors need to be revealed if we're to protect ourselves. Let's sunburn these motherfuckers. You are forgetting moral hazard. Why are there so many bugs? The laws relieve software manufacturers of liability for the flaws of their programs. It is cheaper to let clients do the testing for you. If a 3rd party like Google takes over the software testing for free, there is even less incentive to make the slightest effort to test pre-release software and make non-faulty products. You will not exterminate all the bugs, you will give the bug makers (software manufacturers) more incentive to flood the world with faulty products. Which I think is why the open source/free products are more reliable than the commercial ones. The economic incentives are to build crap quickly. If you are not doing the work for profit motives, you can afford to make a decent product. -- 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. -- 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] Coursera to join censor club by blocking Iran IP space
Iranian users are very aware of proxies to access internet due to internal censorship. They will just use them to access coursera :); I doubt it will have much impact on users. On Thu, Jan 30, 2014 at 10:03 AM, andreas.ba...@nachtpult.de wrote: Coursera says its not them, its an US export regulation. And this is related to all sanctioned countries, including Syria, Sudan and Cuba, not only Iran. I don't think that Coursera decided to do this by itself. Stanford University also offers Coursera courses btw. Andreas Source: http://blog.coursera.org/post/74891215298/update-on-course-accessibility-for-students-in-cuba -Original Message- From: Nima Fatemi n...@redteam.io Sender: liberationtech-boun...@lists.stanford.edu Date: Thu, 30 Jan 2014 09:22:33 To: liberationtech@lists.stanford.edu Reply-To: liberationtech liberationtech@lists.stanford.edu Subject: [liberationtech] Coursera to join censor club by blocking Iran IP space -- 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. -- 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. -- 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] Coursera to join censor club by blocking Iran IP space
proxy != tor ;) Maybe they can also use lantern and google uProxy... On Thu, Jan 30, 2014 at 10:06 AM, andreas.ba...@nachtpult.de wrote: The problem is the bandwith. Coursera works with video streams, that means that you can't practically use e.g. TOR. -- *From: * wasa bee wasabe...@gmail.com *Date: *Thu, 30 Jan 2014 10:04:40 + *To: *andreas.ba...@nachtpult.de; liberationtech liberationtech@lists.stanford.edu *Subject: *Re: [liberationtech] Coursera to join censor club by blocking Iran IP space Iranian users are very aware of proxies to access internet due to internal censorship. They will just use them to access coursera :); I doubt it will have much impact on users. On Thu, Jan 30, 2014 at 10:03 AM, andreas.ba...@nachtpult.de wrote: Coursera says its not them, its an US export regulation. And this is related to all sanctioned countries, including Syria, Sudan and Cuba, not only Iran. I don't think that Coursera decided to do this by itself. Stanford University also offers Coursera courses btw. Andreas Source: http://blog.coursera.org/post/74891215298/update-on-course-accessibility-for-students-in-cuba -Original Message- From: Nima Fatemi n...@redteam.io Sender: liberationtech-boun...@lists.stanford.edu Date: Thu, 30 Jan 2014 09:22:33 To: liberationtech@lists.stanford.edu Reply-To: liberationtech liberationtech@lists.stanford.edu Subject: [liberationtech] Coursera to join censor club by blocking Iran IP space -- 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. -- 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. -- 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] LUKS Self-Destruct feature introduced in Kali Linux
assuming credential info (IV, pwd-encrypted key,etc) is stored with no recognizable format (not ASN1, no header), it should look indistinguishable from other encrypted data on disk. So how feasible is it to brute-force the location of the key + pwd? That must take time. What if cred data is scattered over the disk rather than written as a continuous blob? How much mitigation would that introduce? I'm just wondering what kind of hardening could be used against non-reliable erase features. Note that if you use an SSD with block management and wear levelling done in OS, you should be able to delete securely. The problem is mainly for MMC. On Thu, Jan 30, 2014 at 9:00 AM, Maxim Kammerer m...@dee.su wrote: On Sat, Jan 18, 2014 at 5:02 AM, Pranesh Prakash pran...@cis-india.org wrote: This above description seems to me to be an extreme case of 2FA. Is it actually useful? As noted in Liberté Linux FAQ [1]: NOTE: Modern flash memory devices with wear leveling (as well as modern HDDs with automatic bad sectors remapping) cannot guarantee that the original OTFE header and its backup have been erased. Also, the developers implemented the functionality by finding some old cryptsetup patch and applying it. I can't think of a scenario where this functionality would be useful. Reminds me of Greenwald using his boyfriend as a data mule -- simultaneously trusting and mistrusting cryptography due to lack of understanding of the concepts involved. If you want to move data safely, encrypt it with an automatically-generated password of sufficient entropy, and transmit the password separately -- there is no need to transmit the whole LUKS keyslot, which is large, and is just a technical detail. [1] http://dee.su/liberte-faq -- Maxim Kammerer Liberté Linux: http://dee.su/liberte -- 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. -- 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] LUKS Self-Destruct feature introduced in Kali Linux
well, encryption software are already hard to use Greenwald struggled with the software for a while, but then gave up and blew off Snowden. Snowden then got in touch with Laura Poitras, who was already an expert on encryption http://www.dailykos.com/story/2013/08/28/1233355/-Can-anyone-help-me-set-up-PGP-encrypted-E-mail-It-s-the-mark-of-an-investigative-reporter How much would your not-so-technically-complicated solution cripple usability? You might argue that if you're encrypted ur data + afraid of being coerced to reveal the key, then ur a sufficiently high target to take the extra hassle... On Thu, Jan 30, 2014 at 3:25 AM, Charles Haynes hay...@edgeplay.org wrote: Yes it's useful but it's maybe more complicated than necessary. You encrypt the information and make sure the decryption key is sent to a safe destination via a different route. While in transit you cannot be compelled to give up encryption keys because you do not have them (unlike a TrueCrypt hidden volume.) When you arrive safely at your destination you retrieve the decryption key and restore your data (unlike a self-destruct.) -- Charles -- 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. -- 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] Heml.is - The Beautiful Secure Messenger
https://whispersystems.org/ already has an open-source secure messaging, voice and more. Has anyone reviewed their code? Does anyone use it? Why not build on top of it? On 10/07/13 14:07, Nick wrote: noone said it would be closed source. That's peoples guess. Like, your guess, I guess. According to their twitter account, the answer is maybe: https://twitter.com/HemlisMessenger/statuses/354927721337470976 Peter Sunde (one of the people behind it) said eventually, but in my experience promises like that tend to be broken: https://twitter.com/brokep/status/354608029242626048 and the feature 'unlocking' aspect of the project - to be indication of a proprietary code base. Frankly I can't see how they could get the feature unlock funding stuff to work well if it's proper open source. As I'd expect people to fork it to remove such antifeatures. It's a pity, as several new funding models have been successful recently which are compatible with free software, but this doesn't look to be one of them. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
Re: [liberationtech] How CyanogenMod’s founder is giving Android users their privacy back | Ars Technica
On 18/06/13 05:46, Yosem Companys wrote: Since not all applications are malicious, users will be able to enable Incognito Mode on a per-app basis. The option will be available within each application’s individual settings. the first thing that bad apps (at least some) do is syphon out data right when u open them. if u need to go to setting to turn the incognito option on, there is a risk the damage is already done by the time u get to the settings. I may exaggerate a little of course... but that suggests an installation screen with set default incoginito yes/no prompt could be of use... it might degrade usability (an extra screen to interact with), user may default to the OK button (so incognito maybe should be default). On starting the app from grid, maybe a toast informing the incognito status may also be useful... well, just thoughts... -- 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
