- cypherpunks - lists.cpunks.org

Moonlet
by Sean Alexandre 11 Aug '13

11 Aug '13

--------------------------------------------------------------------- Moonlet >From http://moonlet.is/: --------------------------------------------------------------------- Moonlet will be a small scale personal cloud services collective. Our goal is to pool together about 20-40 peoples' resources to pay for the hosting and sysadmin time necessary to replace most or all of the cloud services we use with ones we can trust. Our goals are: * To offer cloud-replacement services at a reasonable price to members * Security and privacy are primary priorities * Ensure a useable and well-integrated solution that replicates the hassle-free convenience of the better existing cloud services * Document the process clearly so other people can replicate the experience Why The impetus for this is twofold: First, cloud providers are proving unreliable in terms of continued provision of services and respect for user privacy. Second, paying for it on one's own is either expensive in terms of time, or money. Almost all the software exists to duplicate all the cloud offerings one might want to use, but getting it up and working is time consuming. Current status As of June 2013, we are actively recruiting members to get this collective started. When we have enough people able to commit to a year of membership, we will set definitive pricing for the first year, hire an administrator and announce a launch date. How to get involved... --------------------------------------------------------------------- Moonlet FAQ >From http://eldan.co.uk/moonlet/faq.html --------------------------------------------------------------------- We are currently recruiting members. When we have enough people, we anticipate creating a legal entity to hold money, hire the sysadmin and so on. This will probably be a co-op, though details are to be confirmed. Everything that follows will be shaped by the needs of the group. Service set This set will evolve as we get feedback from members, but it will look something like: * Email, with a solid webmail interface and IMAPS (GMail) * Caldav, with a web calendar interface (Google Calendar) * Secure online https file share (Dropbox/etc.) * Encrypted backup, based on Tahoe-LAFS (Dropbox/etc.) * VPN Endpoint * Hosted to-do list (RTM/Google calendar tasks) * XMPP/Jabber (Google Talk) * VM instances (personal web hosting/other private services) * Secured etherpad lite instance (Google docs) * Shell access within VMs * Hosted RSS reader (Google Reader) * Hosted photo sharing (Flickr) * Hosted wordpress instances (Blogger/etc.) * Status.net instance (Twitter) * SIP server, with assistance in configuring ZRTP (Skype) * Wiki instances (PBWiki/etc.) * Hosted bookmarking tool (Del.icio.us/Pininterest) * Local configuration of hosted services (not tech support) * Configuration of mobile devices As we learn which are most important to people, and what the resource needs & prerequisites are for some, we will decide which to include at launch, add later or drop. For some things, for instance etherpad lite, we may decide to offer a feature bounty as a group to developers to make the software a better replacement -- in that case, to support a bit more formatting, for working on more complex documents. Some stuff, like getting a mobile device working without any public cloud accounts, may take some time and integration research, but in general, we're targeting a relatively tech-savvy audience, at least to start with. If you've already got a lot of this stuff set up, the benefit for you is that you get to not think about it any more. Hosting Tentatively, the primary hosting location will be Iceland because of its favorable legal jurisdiction and good international connectivity. We are considering a second jurisdiction for redundancy, potentially in the Netherlands. Unfortunately for North Americans, nowhere on our continent is suitable. The server(s) will be running appropriately hardened Linux installs with services segmented into VMs and encrypted physical disks and backups, etc. We'll probably recruit both a primary and a backup admin, for human fault tolerance. Costs Exact pricing will depend on both the number of people who join and the exact costs for sysadmin time and hosting. We anticipate a range of EUR50-100 per month, with a strong impetus to reach the lower end of the range. If costs come in higher than expected we may recruit a larger number of members to spread the burden. We generally favor simplicity in pricing, but may have to itemize charges for services that are costly to provide and used at wildly varying rates by different individuals - most likely backup beyond a modest initial disk quota. Discounts We are considering asking initial members to pay for a year of service in advance, to help handle setup costs, in exchange for which we will offer a discount. We anticipate prices dropping after all services have been rolled out, but can not guarantee this. We will offer some sort of group discount, but are figuring out details. If you have suggestions for how to take advantage of group signups to streamline the admin work, please let us know - the more we can achieve that, the bigger a group discount it makes sense to offer. Questions, suggestions? ...

3 4

Re: [Freedombox-discuss] [James Vasile] tinc rollout and fbox
by Eugen Leitl 11 Aug '13

11 Aug '13

----- Forwarded message from Sandy Harris <sandyinchina(a)gmail.com> ----- Date: Sat, 10 Aug 2013 15:37:06 -0400 From: Sandy Harris <sandyinchina(a)gmail.com> To: freedombox list <freedombox-discuss(a)lists.alioth.debian.org> Subject: Re: [Freedombox-discuss] [James Vasile] tinc rollout and fbox Nick Daly <nick.m.daly(a)gmail.com> wrote: > There's been some recent work on Tinc that I'm really excited about. > ... > Poke at it, let me know what you think. Their docs include this paragraph: " On the 15th of September 2003, Peter Gutmann posted a security analysis of tinc 1.0.1. He argues that the 32 bit sequence number used by tinc is not a good IV, that tinc’s default length of 4 bytes for the MAC is too short, and he doesn’t like tinc’s use of RSA during authentication. We do not know of a security hole in this version of tinc, but tinc’s security is not as strong as TLS or IPsec. We will address these issues in tinc 2.0. Gutmann is a well-known and respected expert. His best-known paper was one back in the 90s on reading "erased" disk drives and what bit patterns it took to block that. Most "secure erase" utilities around use those suggestions (even though current drives are quite different, so those may be inappropriate now). He has done /a lot/ of other stuff as well. The current Tinc release is 1.0.21 My reading of that is that Tinc has known problems and they probably will not be fixed soon. To me, that means it is not ready for serious consideration as a component for FreedomBox. _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

DIY Spy Germicide
by John Young 11 Aug '13

11 Aug '13

DIY Germicide: http://prism-break.org http://lockerproject.org/ https://securityinabox.org/ http://eyebeam.org/research/calls/request-for-proposals-prism-break-up

1 0

Re: [tor-talk] Secure email with limited usable metadata
by coderman 10 Aug '13

10 Aug '13

On Sat, Aug 10, 2013 at 4:34 AM, Mike Hearn <hearn(a)google.com> wrote: >... > You may be interested in checking out Pond... > https://pond.imperialviolet.org/ > > It is an email-like messaging system that runs over Tor, has forward > security, tries to beat traffic analysis, ... this is the kind of messaging i would use - leaving all the complexities and drawbacks of traditional email behind. and StealthMonger: while the theory and design of latest generation anonymous remailers are suitable for secure mail, the practical realities render them unusable. effort on real-time protocols that can defend against traffic analysis, or other non-email systems like pond would be better spent.

1 0

Obama On NSA 9 August 2013
by John Young 10 Aug '13

10 Aug '13

http://cryptome.org/2013/08/obama-nsa-13-0809.htm

1 0

NSA Today on Missions, Authorities, Oversight, Partnershps
by John Young 10 Aug '13

10 Aug '13

NSA statement today on Missions, Authorties, Oversight, Partnerships: http://cryptome.org/2013/08/nsa-13-0809.pdf

3 2

Re: [cryptopolitics] Silent Circle and Secure Email
by Adam Back 10 Aug '13

10 Aug '13

(Thanks for the link.) It says hushmail had a simplified web-only version (no java applet) and that the disclosure of client emails did not involve pressured code changes (at least code shipped to clients), rather that as a natural consequence of the way passwords would be processed on the server side and decryption happened on the server side so hushmail had the passwords, private keys, and decrypted plaintexts at leas in memory to hand over on request. Adam On Fri, Aug 09, 2013 at 08:59:53PM -0400, Jeffrey Walton wrote: >On Fri, Aug 9, 2013 at 8:56 PM, Adam Back <adam(a)cypherspace.org> wrote: >> ... >> >> Its less clear what lavabit were talking about. Perhaps something similar >> in terms of an SMTP interoperability encryption gap, or alternatively about >> being pressured to modify code (which people seem to assume, but I didnt see >> explicitly stated). >> >> There were some hushmail rumors about code modification some years back - >> does anyone know what actually at hushmail? >Encrypted E-Mail Company Hushmail Spills to Feds, >http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/.

1 0

Re: [cryptopolitics] Silent Circle and Secure Email
by Adam Back 10 Aug '13

10 Aug '13

Reading what Jon Callas wrote he said silent circle interoperated with unencrypted SMTP email (unencrypted other than SSL over the transport), and they used some bump in the wire PGP thingy that encrypts incoming email with the silent circle users public key, and presumably sends out cleartext possibly SSL SMTP where available, for non silent-circle recipients. Clearly therefore anyone tampering with the SSL (and often those mail transport systems are not that smart about SSL as there is no security UI) or just getting the NSA camel's nose inside the silent circle SSL termination point prior to encrytion. As they didnt think that would end well they decided to close it down. Alternatively they might have considered disabling the mail-in and mail-out features. Its less clear what lavabit were talking about. Perhaps something similar in terms of an SMTP interoperability encryption gap, or alternatively about being pressured to modify code (which people seem to assume, but I didnt see explicitly stated). There were some hushmail rumors about code modification some years back - does anyone know what actually at hushmail? Adam On Fri, Aug 09, 2013 at 08:46:57PM -0400, Jeffrey Walton wrote: >On Fri, Aug 9, 2013 at 2:43 PM, Jeffrey Goldberg <Jeffrey(a)goldmark.org> wrote: >> On Aug 9, 2013, at 11:45 AM, Jeffrey Walton <noloader(a)gmail.com> wrote: >> >>> I'd be interested in hearing more with respect to Silent Circle >>> complicity in crimes against the American people if they supplied >>> secure email. >> >> I think you may have missed the point in the Lavabit wording of this announcement. >> >> It looks like they were saying that complying with law enforcement requests (handing >> over data or putting a back door in their systems) would be "complicity in crimes >> against the American people.” >> >Thanks Jeffrey. I thought it might have been that, but the word >"crime" removed the possibility in my mind's eye. I guess I would have >worded it differently.

1 0

Nuclear Weapons Control Systems and NATO Super-Radar shut down by occupy group NOMOUS at NISCEMI, SICILY Re: [cryptome] NSA Today on Missions, Authorities, Oversight, Partnershps
by Wilfred Guerin 09 Aug '13

09 Aug '13

Nuclear Weapons Control Systems and NATO Super-Radar shut down by occupy group NOMOUS at NISCEMI, SICILY On Fri, Aug 9, 2013 at 10:14 AM, John Young <jya(a)pipeline.com> wrote: > NSA statement today on Missions, Authorties, Oversight, Partnerships: > > http://cryptome.org/2013/08/**nsa-13-0809.pdf<http://cryptome.org/2013/08/nsa-13-0809.pdf> > > > >

1 0

Breaking PRISM and friends
by Nick Thomas 09 Aug '13

09 Aug '13

Hi all, Only a decade or two late to the party... anyway, in the past few days since the PRISM / XKeyscore / etc leaks came to my attention, I've been considering schemes that breaks the kind of passive, drag-net collection of communications data from listening points on submarine cables and the like. I think I've found one, so I thought I'd share. Code is in very, very early stages at the moment; https://github.com/lupine/hide-eid has half of a first pass, and a bit of documentation on why it might work. I'm hoping to have it in a state where you could run a pair of VPN providers servicing a few customers each within a few days. As-is, scalability is suspect, though. The short how-it-works is that it stops the IP header (which typically reveals who is talking to whom, even if the IP payload is encrypted) from being personally-identifying information. If your access ISP runs it, and your hosting ISP runs it too, you benefit from an anonymity set equal to all the source's customers. As long as there's no sniffing going on in the first and last mile, anyway. Combined with IPsec on those miles, or a vetted path if it's short enough, you can reduce the amount of cable that personally-identifying IP headers are sniffable on, from a few thousand miles, to perhaps a couple of feet - on which you can focus CCTV, if you're *really* paranoid; or even nothing at all, if you have the same box terminating the IPsec tunnel and the hide-eid wrapper/unwrapper. The theoretical background is from the location/identity separation protocol stuff. Intermediaries don't actually need to know which person (well, EID) the packet is from, or for; they just need to know where to send it (which RLOC) so that a person can pick it up. This scheme is basically that, imagined as a least-effort overlay on the existing IP network. And it doesn't break as many protocols as cgNAT, since source and destination both know the EID of destination and source. Feedback of any sort is extremely welcome. Particular areas of concern are scaling it (especially given how the crypto works), how the crypto works and if there's a more sensible way (key exchange with M:N different ISPs to take advantage of symmetric ciphers is worrisome), and whether there's a better way to get L/ISP with hidden EIDs deployed to a subset of the internet than a hack of this magnitude. I'm still fairly skeptical that it can make a noticeable difference, but it seems promising enough for me to keep it up in the short term, at least. If it ends up being useless, there's still tor. There's always tor. /Nick

3 4