- cypherpunks - lists.cpunks.org

Groklaw shuts down
by Riad S. Wahby 21 Aug '13

21 Aug '13

http://www.groklaw.net/article.php?story=20130818120421175 " My personal decision is to get off of the Internet to the degree it's possible. I'm just an ordinary person. But I really know, after all my research and some serious thinking things through, that I can't stay online personally without losing my humanness, now that I know that ensuring privacy online is impossible. I find myself unable to write. I've always been a private person. That's why I never wanted to be a celebrity and why I fought hard to maintain both my privacy and yours. " -=rsw

6 6

Google to encrypt cloud storage
by rysiek 21 Aug '13

21 Aug '13

OHAI, PRISM caused a ot of fear but now we can finally feel safe again -- Google will encrypt all Google Drive storage with user-supplied keys: http://it.slashdot.org/story/13/08/16/239253/ So our data will be perfectly safe with them, right? Right?.. ;) Seriously, though, this is very, very bad for us. Normals will point to that and say "hey, Google does the Right Thing and we can be safe there, so we should all use Google now. They have encryption and stuff." -- Pozdr rysiek

8 18

Changing IP address to access public website ruled violation of US law
by rysiek 20 Aug '13

20 Aug '13

Hi there, You have probably already heard about that, but... Changing IP address to access public website ruled violation of US law: http://arstechnica.com/tech-policy/2013/08/changing-ip-address-to-access-pu… -- Pozdr rysiek

2 2

Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
by Eugen Leitl 20 Aug '13

20 Aug '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Sat, 17 Aug 2013 11:52:58 +0300 From: ianG <iang(a)iang.org> To: cryptography(a)randombit.net Subject: Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 16/08/13 22:11 PM, zooko wrote: > On Tue, Aug 13, 2013 at 03:16:33PM -0500, Nico Williams wrote: >> >> Nothing really gets anyone past the enormous supply of zero-day vulns in their complete stacks. In the end I assume there's no technological PRISM workarounds. > > I agree that compromise of the client is relevant. My current belief is that > nobody is doing this on a mass scale, pwning entire populations at once, and > that if they do, we will find out about it. > > My goal with the S4 product is not primarily to help people who are being > targeted by their enemies, but to increase the cost of indiscriminately > surveilling entire populations. > > Now maybe it was a mistake to label it as "PRISM-Proof" in our press release > and media interviews! I said that because to me "PRISM" means mass surveillance > of innocents. Perhaps to other people it doesn't mean that. Oops! My understanding of PRISM is that it is a voluntary & secret arrangement between the supplier and the collector (NSA) to provide direct access to all information. By 'voluntary' I mean that the supplier hands over the access, it isn't taken in an espionage or hacker sense, or leaked by an insider. I include in this various techniques of court-inspired voluntarianism as suggested by recent FISA theories [0]. I suspect it is fair to say that something is PRISM-proof if: a) the system lacks the capability to provide access b) the operator lacks the capacity to enter into the voluntary arrangement, or c) the operator lacks the capacity to keep the arrangement (b) secret The principle here seems to be that if the information is encrypted on the server side without the keys being held or accessible by the supplier, then (a) is met [1]. Encryption-sans-keys is an approach that is championed by Tahoe-LAFS and Silent Circle. Therefore I think it is reasonable in a marketing sense to claim it is PRISM-proof, as long as that claim is explained in more detail for those who wish to research. In this context, one must market ones product, and one must use simple labels to achieve this. Otherwise the product doesn't get out there, and nobody is benefited. iang [0] E.g., the lavabit supplier can be considered to have not volunteered the info, and google can be considered to have not volunteered to the Chinese government. [1] In contrast, if an operator is offshore it would meet (b) and if an operator was some sort of open source distributed org where everyone saw where the traffic headed, it would lack (c). > Regards, > > Zooko > > _______________________________________________ > cryptography mailing list > cryptography(a)randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

[cryptography] Reply to Zooko (in Markdown)
by Eugen Leitl 20 Aug '13

20 Aug '13

----- Forwarded message from Jon Callas <jon(a)callas.org> ----- Date: Fri, 16 Aug 2013 23:04:38 -0700 From: Jon Callas <jon(a)callas.org> To: Zooko Wilcox-OHearn <zooko(a)leastauthority.com> Cc: cryptography(a)randombit.net Subject: [cryptography] Reply to Zooko (in Markdown) X-Mailer: Apple Mail (2.1508) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Also at http://silentcircle.wordpress.com/2013/08/17/reply-to-zooko/ # Reply to Zooko (My friend and colleague, [Zooko Wilcox-O'Hearn](https://leastauthority.com/blog/author/zooko-wilcox-ohearn.html) wrote an open letter to me and Phil [on his blog at LeastAuthority.com](https://leastauthority.com/blog/open_letter_silent_circ…. Despite this appearing on Silent Circle's blog, I am speaking mostly for myself, only slightly for Silent Circle, and not at all for Phil.) Zooko, Thank you for writing and your kind words. Thank you even more for being a customer. We're a startup and without customers, we'll be out of business. I think that everyone who believes in privacy should support with their pocketbook every privacy-friendly service they can afford to. It means a lot to me that you're voting with your pocketbook for my service. Congratulations on your new release of [LeastAuthority's S4](https://leastauthority.com) and [Tahoe-LAFS](https://tahoe-lafs.org/trac/tahoe-lafs). Just as you are a fan of my work, I am an admirer of your work on Tahoe-LAFS and consider it one of the best security innovations on the planet. I understand your concerns, and share them. One of the highest priority tasks that we're working on is to get our source releases better organized so that they can effectively be built from [what we have on GitHub](https://github.com/SilentCircle/). It's suboptimal now. Getting the source releases is harder than one might think. We're a startup and are pulled in many directions. We're overworked and understaffed. Even in the old days at PGP, producing effective source releases took years of effort to get down pat. It often took us four to six weeks to get the sources out even when delivering one or two releases per year. The world of app development makes this harder. We're trying to streamline our processes so that we can get a release out about every six weeks. We're not there, either. However, even when we have source code to be an automated part of our software releases, I'm afraid you're going to be disappointed about how verifiable they are. It's very hard, even with controlled releases, to get an exact byte-for-byte recompile of an app. Some compilers make this impossible because they randomize the branch prediction and other parts of code generation. Even when the compiler isn't making it literally impossible, without an exact copy of the exact tool chain with the same linkers, libraries, and system, the code won't be byte-for-byte the same. Worst of all, smart development shops use the *oldest* possible tool chain, not the newest one because tool sets are designed for forwards-compatibility (apps built with old tools run on the newest OS) rather than backwards-compatibility (apps built with the new tools run on older OSes). Code reliability almost requires using tool chains that are trailing-edge. The problems run even deeper than the raw practicality. Twenty-nine years ago this month, in the August 1984 issue of "Communications of the ACM" (Vol. 27, No. 8) Ken Thompson's famous Turing Award lecture, "Reflections on Trusting Trust" was published. You can find a facsimile of the magazine article at <https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf> and a text-searchable copy on Thompson's own site, <http://cm.bell-labs.com/who/ken/trust.html>. For those unfamiliar with the Turing Award, it is the most prestigious award a computer scientist can win, sometimes called the "Nobel Prize" of computing. The site for the award is at <http://amturing.acm.org>. In Thompson's lecture, he describes a hack that he and Dennis Ritchie did in a version of UNIX in which they created a backdoor to UNIX login that allowed them to get access to any UNIX system. They also created a self-replicating program that would compile their backdoor into new versions of UNIX portably. Quite possibly, their hack existed in the wild until UNIX was recoded from the ground up with BSD and GCC. In his summation, Thompson says: The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect. Thompson's words reach out across three decades of computer science, and yet they echo Descartes from three centuries prior to Thompson. In Descartes's 1641 "Meditations," he proposes the thought experiment of an "evil demon" who deceives us by simulating the universe, our senses, and perhaps even mathematics itself. In his meditation, Descartes decides that the one thing that he knows is that he, himself, exists, and the evil demon cannot deceive him about his own existence. This is where the famous saying, "*I think, therefore I am*" (*Cogito ergo sum* in Latin) comes from. (There are useful Descartes links at: <http://www.anselm.edu/homepage/dbanach/dcarg.htm> and <http://en.wikipedia.org/wiki/Evil_demon> and <http://en.wikipedia.org/wiki/Brain_in_a_vat>.) When discussing thorny security problems, I often avoid security ratholes by pointing out Descartes by way of Futurama and saying, "I can't prove I'm not a head in a jar, but it's a useful assumption that I'm not." Descartes's conundrum even finds its way into modern physics. It is presently a debatable, yet legitimate theory that our entire universe is a software simulation of a universe . Martin Savage of University of Washington <http://www.phys.washington.edu/~savage/> has an interesting paper from last November on ArXiV <http://arxiv.org/pdf/1210.1847v2.pdf>. You can find an amusing video at <http://www.huffingtonpost.com/2012/12/24/universe-computer-simulation_n_233…> in which Savage even opines that our descendants are simulating us to understand where they came from. I suppose this means we should be nice to our kids because they might have root. Savage tries to devise an experiment to show that you're actually in a simulation, and as a mathematical logician I think he's ignoring things like math. The problem is isomorphic to writing code that can detect it's on a virtual machine. If the virtual machine isn't trying to evade, then it's certainly possible (if not probable -- after all, the simulators might want us to figure out that we're in a simulation). Unless, of course, they don't, in which case we're back not only to Descartes, but Godel's two Incompleteness Theorems and their cousin, The Halting Problem. While I'm at it, I highly, highly recommend Scott Aaronson's new book, "Quantum Computing Since Democritus" <http://www.scottaaronson.com/democritus/> which I believe is so important a book that I bought the Dead Tree Edition of it. ([Jenny Lawson](http://thebloggess.com) has already autographed my Kindle.) Popping the stack back to security, the bottom line is that you're asking for something very, very hard and asking for a solution to an old philosophical problem as well as suggesting I should prove Godel wrong. I'm flattered by the confidence in my abilities, but I believe you're asking for the impossible. Or perhaps I'm programmed to think that. This limitation doesn't apply to just *my* code. It applies to *your* code, and it applies to all of us. (Tahoe's architecture makes it amazingly resilient, but it's not immune.) It isn't just mind-blowing philosophy mixed up with Ken Thompson's Greatest Hack. Whenever we run an app, we're trusting it. We're also trusting the operating system that it runs on, the random number generator, the entropy sources, and so on. You're trusting the CPU and its microcode. You're trusting the bootloader, be it EFI or whatever as well as [SMM](http://en.wikipedia.org/wiki/System_Management_Mode) on Intel processors -- which could have completely undetectable code running, doing things that are scarily like Descartes's evil demon. The platform-level threats are so broad that I could bore people for another paragraph or two just enumerating them. You're perhaps trusting really daft things like [modders who slow down entropy gathering](http://hackaday.com/2013/01/04/is-entropy-slowing-down-your-andr… and [outright bugs](http://android-developers.blogspot.com/2013/08/some-securerandom-thou…. Ironically, the attack vector you suggest (a hacked application) is one of the harder ways for an attacker to feed you bad code. On mobile devices, apps are digitally signed and delivered by app stores. Those app stores have a vetting process that makes *targeted* code delivery hard. Yes, someone could hack us, hack Google or Apple, or all of us, but it's very, very hard to deliver bad code to a *specific* person through this vector, and even harder if you want to do it undetectably. In contrast, targeted malware is easy to deploy. Exploits are sold openly in exploit markets, and can be bundled up in targeted advertising. Moreover, this *has* happened, and is known to be a mechanism that's been used by the FBI, German Federal Police, the Countries Starting With the Letter 'I' (as a friend puts it), and everyone's favorite The People's Liberation Army. During Arab Spring, a now-defunct government just procured some Javascript malware and dropped it in some browsers to send them passwords on non-SSL sites. Thus, I think that while your concern does remind me to polish up my source code deployment, if we assume an attacker like a state actor that targets people and systems, there are smarter ways for them to act. I spend a lot of time thinking, "*If I were them, what would I do?*" If you think about what's possible, you spend too much time on low-probability events. Give yourself that thought experiment. Ask yourself what you'd do if you were the PLA, or NSA, or a country starting with an 'I.' Give yourself a budget in several orders of magnitude. A grand, ten grand, a hundred grand, a million bucks. What would you do to hack yourself? What would you do to hack your users without hacking you? That's what I think about. Over the years, I've become a radical on usability. I believe that usability is all. It's easy to forget it now, but PGP was a triumph because you didn't have to be a cryptographer, you only had to be a techie. We progressed PGP so that you could be non-technical and get by, and then we created PGP Universal which was designed to allow complete ease of use with a trusted staff. That trusted staff was the fly in the ointment of Silent Mail and the crux of why we shut it down -- we created it because of usability concerns and killed it because of security concerns. Things that were okay ideas in May 2013 were suddenly not good ideas in August. I'm sure you've noted when using our service our belief in usability. Without usability that is similar to the non-secure equivalent, we are nothing because the users will just not be secure. I also stress Silent Circle is a *service*, not an app. This is hard to remember and even we are not as good at it as we need to be. The service is there to provide its users with a secure analogue of the phone and texting apps they're used to. The difference is that instead of having utterly no security, they have a very high degree of it. Moreover, our design is such to minimize the trust you need to place in us. Our network includes ourselves as a threat, which is unusual. You're one of the very few other people who do something similar. We have technology and policy that makes an attack on *us* to be unattractive to the adversary. You will soon see some improvements to the service that improve our resistance to traffic analysis. The flip side of that, however, is that it means that the device is the most attractive attack point. We can't help but trust the OS (from RNG to sandbox), bootloader, hardware, etc. Improvements in our transparently (like code releases) compete with tight resources for improvements in the service and apps. My decisions in deploying those resources reflect my bias that I'd rather have an A grade in the service with a B grade in code releases than an A in code releases and a B service. Yes, it makes it harder for you and others, but I have to look at myself in the mirror and my emphasis is on service quality first, reporting just after that. Over time, we'll get better. We've not yet been running for a year. Continuous improvement works. I'm going to sum up with the subtitle of the ACM article of Ken Thompson's speech. It's not on his site, but it is on the facsimile article: To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software. Thank you very much for your trust in us, the people. Earning and deserving your trust is something we do every day. Regards, Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 3.2.0 (Build 1672) Charset: us-ascii wj8DBQFSDxJ+sTedWZOD3gYRAiDiAJ0bR0EOetfQpPSTDtWX1qyn6wcIcACfbi5Z M9oM0D1yL77QHaw6RnEEFIU= =7StS -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

[cryptography] open letter to Phil Zimmermann and Jon Callas of Silent Circle, re: Silent Mail shutdown
by Eugen Leitl 20 Aug '13

20 Aug '13

----- Forwarded message from Zooko Wilcox-OHearn <zooko(a)leastauthority.com> ----- Date: Fri, 16 Aug 2013 21:46:10 +0000 From: Zooko Wilcox-OHearn <zooko(a)leastauthority.com> To: cryptography(a)randombit.net Subject: [cryptography] open letter to Phil Zimmermann and Jon Callas of Silent Circle, re: Silent Mail shutdown also posted here: https://leastauthority.com/blog/open_letter_silent_circle.html This open letter is in response to the `recent shutdown of Lavabit`_ , the ensuing `shutdown of Silent Circle's “Silent Mail” product`_, `Jon Callas's posts about the topic on G+`_, and `Phil Zimmermann's interview in Forbes`_. Also, of course, all of this is unfolding in the context of the `2013 Mass Surveillance Scandal`_. Dear Phil and Jon: Hello there! It is good to have a chance to chat with you in public. Please accept the following in the spirit of constructive criticism in which it is intended. For those readers who don't know, I've known you both, personally and professionally for decades. You've each written texts that I've learned from, inspired me to follow your example, we've worked together successfully, and you've mentored me. I have great respect for your technical abilities, your integrity, and your general reasonableness. Thank you for the all of that and for holding fast to your principles today, when we need it more than ever. Now: Your job is not yet done. Your customers are currently vulnerable to having all of their communications secretly monitored. I just subscribed to the service at https://SilentCircle.com, and after I paid $120 for one year of service, it directed me to install the Silent Text app from Silent Circle on my android phone, which I did. Now, when I use that Silent Circle app to send text messages to other Silent Circle customers, I have no way of verifying whether it is really encrypting my message on my own phone, and if it is really keeping the encryption key only for me, or if it is leaking the contents of my messages or my encryption keys to you or to others. If some attacker, for example the U.S. Federal Government — or to pick a different example the Zetas Mexican drug cartel — were to coerce Silent Circle into cooperating with them, then that attacker would simply require Silent Circle to distribute an update to the app, containing a backdoor. There is no way for me to verify that any given version of Silent Text, including the one that I just installed, is correctly generating strong encryption keys and is protecting those keys instead of leaking them. Therefore, how are your current products any safer for your users that the canceled Silent Mail product was? The only attacker against whom your canceled Silent Mail product was vulnerable but against whom your current products are safe is an attacker who would require you to backdoor your server software but who wouldn't require you to backdoor your client software. Does that constraint apply to the U.S. Federal Government entities who are responsible for PRISM, for the shut-down of Lavabit, and so much else? No, that constraint does not apply to them. This was demonstrated in the Hushmail case in which the U.S. DEA asked Hushmail (a Canadian company) to turn over the plaintext of the email of one of its customers. Hushmail complied, shipping a set of CDs to the DEA containing the customer's messages. The President of Hushmail `emphasized`_ in interviews with journalists at the time that Hushmail would be able to comply with such orders regardless of whether the customer used Hushmail's “client-to-server” (SSL) encryption or its “end-to-end” (Java applet) encryption. .. _emphasized: http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ Phil had been Chief Cryptographer of Hushmail years earlier, and was still a member of the Advisory Board of Hushmail at the time of that case. He commented about the case at that time, and he also `stated`_, correctly, that the Hushmail model of *unverified* end-to-end encryption was vulnerable to government coercion. That's the same model that Silent Circle uses today. .. _stated: http://www.wired.com/threatlevel/2007/11/pgp-creator-def/ You have just taken the courageous act of publicly shutting down the Silent Mail product, and publicly stating your reasons for doing so. This, then, is your opportunity to make your stance consistent by informing your customers of the similar dangers posed by the software distribution practices currently used by Silent Circle (along with most of the rest of the industry). I don't know the perfect solution to the problem of the *unverifiability* of today's software. But being frank about the current approach and the vulnerability that it imposes on users is the first step. People will listen to you about this, now. Let's start talking about it and we can start finding solutions. Also, warn your users. Don't tell them the untruth that it is impossible for you to eavesdrop on their communications even if you try (as your company seems to be on the borderline of doing in public statements like these: [ `¹`_, `²`_]). .. _¹: http://www.forbes.com/sites/parmyolson/2013/07/15/corporate-customers-flock… .. _²: http://techcrunch.com/2013/08/08/silent-circle-preemptively-shuts-down-encr… We're trying an approach to this problem, here at LeastAuthority.com, of “*verifiable* end-to-end security”. For our data backup and storage service, all of the software is Free and Open Source, and it is distributed through channels which are out of our direct control, such as Debian and Ubuntu. Of course this approach is not perfectly secure — it doesn't guarantee that a state-level actor cannot backdoor our customers. But it does guarantee that *we* cannot backdoor our customers. This currently imposes inconvenience on our customers, and I'm not saying it is the perfect solution, but it shows that there is more than one way to go at this problem. Thank you for your attention to these important matter, and your leadership in speaking out about them. (By the way, LeastAuthority.com is not a competitor to Silent Circle. We don't offer voice, text, video, or email services, like Silent Circle does/did. What we offer is simply secure offsite *backup*, and a secure cloud storage API that people use to build other services.) Regards, Zooko Wilcox-O'Hearn .. _recent shutdown of Lavabit: http://boingboing.net/2013/08/08/lavabit-email-service-snowden.html .. _shutdown of Silent Circle's “Silent Mail” product: http://silentcircle.wordpress.com/2013/08/09/to-our-customers/ .. _Jon Callas's posts about the topic on G+: https://plus.google.com/112961607570158342254/posts/9uySMokvg7k .. _Phil Zimmermann's interview in Forbes: http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-big-privacy-probl… .. _2013 Mass Surveillance Scandal: https://en.wikipedia.org/wiki/2013_mass_surveillance_scandal _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- 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

Fwd: Freedom Hosting Owner Arrested, Tormail Compromised, Malicious JS Discovered
by David Vorick 19 Aug '13

19 Aug '13

It's possible that the attack in the paper isn't perfectly effective. It's also possible that the government isn't aware of the paper, or at least hasn't organized enough yet to mount an attacked based off of this paper. (some beauracrat in power is spending money on this piece of malware, wants all resources behind it, or maybe other political bullshit, and so as always the government is slowing itself down) And finally, it's possible that TSR uses additional layers of protection, like VPN through countries outside of US jurisdiction, so that even when you unwrap tor TSR remains hidden. On Mon, Aug 12, 2013 at 9:46 AM, David Vorick <david.vorick(a)gmail.com>wrote: > It's possible that the attack in the paper isn't perfectly effective. > It's also possible that the government isn't aware of the paper, or at > least hasn't organized enough yet to mount an attacked based off of this > paper. (some beauracrat in power is spending money on this piece of > malware, wants all resources behind it, or maybe other political bullshit, > and so as always the government is slowing itself down) > > And finally, it's possible that TSR uses additional layers of protection, > like VPN through countries outside of US jurisdiction, so that even when > you unwrap tor TSR remains hidden. >

7 9

Re: Google to encrypt cloud storage
by John Down 19 Aug '13

19 Aug '13

If memory serves me right, when was revealed information about Colossus 2 (built in 1940x), it was pretty astonishing that it has computation power as very specialised computation device same as compared generic computation device with Pentium platform running C program which is doing same. So they were equal in solving these specific problem of decrypting messages. Now you can make assumptions what they should have very specialised hardware-based for solving tasks of decrypting AES, etc On Mon, Aug 19, 2013 at 11:14:52AM +0000, Lodewijk andré de la porte wrote: > AES-128 is obviously not secure enough against NSA-type attacks. It works > against the random raid of the servers, the exploitative sysadmin and > perhaps even the remote exploit in the software. It also allows Google to > run storage nodes at a lower security level, which might help them smooth > operations. > > Nothing there to help against the agencies.

1 0

MailPile: self-hosted webmail with built-in PGP/GPG
by rysiek 19 Aug '13

19 Aug '13

Hi there, As the topic states -- there's a neat project of a webmail that has PGP/GPG support built-in from the start with the idea of making it as easy to use as possible (or more). MailPile: http://www.mailpile.is/ There's an IndieGoGo campaign to fund its development, 3/4 funded already: http://www.indiegogo.com/projects/mailpile-taking-e-mail-back -- Pozdr rysiek

1 0

see something, say something stamps
by David Honig 19 Aug '13

19 Aug '13

see something, say something US custom stamps Featuring Sysadmin E. Snowden and a typical meme font. Any copyright issues to be aware of? I wish to God these calculations could be done by a steam engine," Babbage complained

9 8