Re: [cryptography] the Zcash Open Source Miner Challenge (and about Zcash in general)
On Wed, Nov 9, 2016 at 3:07 PM, Jaromilwrote: > > ...but ZCash feels a bit scammy. Its pumped up entry on the market > burnt a lot of people's money... is it just their fault being stupid? … > Sincerely, I'm not trolling. Seeing there is some space for a civil > conversation, I'd be interested in reading answers from the Zcash ppl > themselves here, what they are going to make out this market hype > stun. I'm a big fan of all Z- things (ZFS, ZSh, Zorro) but > ZCash still.. meh. how about helping us understand? I'm not quite sure what your question or objection is. Can you spell it out? I and the Zcash dev team have no control over the market price. We don't operate an exchange, we haven't bought or sold any ZEC, we have never given anyone investment advice, and we've always striven in our public communications to be clear about the risks and limitations of the Zcash project. Sincerely, Zooko ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] the Zcash Open Source Miner Challenge (and about Zcash in general)
Hi folks! I've been quiet on this list for a while now. I've been hard at work on creating a Bitcoin-like cryptocurrency with zero-knowledge-based crypto: https://z.cash This is the most sophisticated crypto that I've ever seen someone attempt to deploy at scale to the Internet. (By all means feel free to reply and teach me about counter-examples to that generalization.) There's a lot going on there. To jump into the technical side, I'd suggest the Zcash protocol spec: https://github.com/zcash/zips/blob/master/protocol/protocol.pdf . For an introduction to the bigger picture, probably our blog (https://z.cash/blog/) and FAQ (https://z.cash/support/faq.html). Okay the reason I'm writing today is to let you know about the Zcash Open Source Miner Challenge: https://zcashminers.org/ The Zcash company has donated $30,000 for prize money to reward better open-source implementations of Equihash by Biryukov & Khovratovich: https://www.internetsociety.org/sites/default/files/blogs-media/equihash-asymmetric-proof-of-work-based-generalized-birthday-problem.pdf Jump in! The worst that can happen is that you get the fun and education of implementing an interesting new proof-of-work algorithm. :-) Regards, Zooko ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Should Sha-1 be phased out?
On Tue, Oct 20, 2015 at 8:00 AM, Joachim Strömbergsonwrote: > > Esp in embedded space, md5 is still very, very common even in new > designs. And SHA-1 is the new black. > > A typical setup is that someone has found out that there is a secure > hash function called md5 and decided to implement it in their new > system. When told that md5 is in fact broken since ages, the response is > usually a at the moment-decision that it is not used for security, and > that the application doesn't really have any security implications (i.e. > that the service performed by the system has no value). Yep. Actually the post-hoc rationalization is usually that collision-resistance isn't needed, only (2nd-)pre-image resistance. Some of the time this is actually true, but I think the people making the claim don't really know whether it is true. I think what they typically do is spend 60 seconds trying to imagine how they could attack their own system using collisions, and then having failed to find such an attack, they conclude that collision-resistance isn't needed for their system. Here's one of my favorite examples of this methodology, from Linus Torvald: http://git.vger.kernel.narkive.com/9lgv36un/zooko-zooko-com-revctrl-colliding-md5-hashes-of-human-meaningful#post2 So, my attempted contribution to this pattern was to help specify BLAKE2, so that instead of telling people "MD5 is broken! Switch to this secure but slower hash function!" we could tell them "MD5 is broken! Switch to this secure but faster hash function!" https://blake2.net/acns/slides.html It remains to be seen if they are any more responsive to the new argument than they have been for the last couple of decades to the old argument. Regards, Zooko ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] hashes based on lots of concatenated LUT lookups
Dear Eugen: There have been several experiments in this direction, using memory-hard proofs-of-work. For example, this was the motivation for Litecoin (https://en.wikipedia.org/wiki/Litecoin) to use scrypt in its Proof-of-Work. To my knowledge, the state-of-the-art design is John Tromp's Cuckoo PoW: https://github.com/tromp/cuckoo In my opinion, this is a promising direction to take. It might still succumb to centralization-of-mining in the long-term, but maybe not. There's a possibility it would settle into an economic equilibrium in which independent/hobbyist/small-time mining is sufficiently rewarding, but customized, large-scale, vertically-integrated mining is not rewarding enough to justify its costs. Among anti-mining-centralization techniques that I've studied, this is the only one that is easy to implement in the near-term, and doesn't come with too many complications and risks for near-term deployment. For the contrarian view, arguing that ASIC-resistance is either undesirable and/or impossible, see this whitepaper by andytoshi: http://download.wpsoftware.net/bitcoin/asic-faq.pdf . I disagree with the conclusions, but it makes some good arguments. For a survey of state-of-the-art ideas about Proof-of-Stake — ideas which *aren't* easily implementable and which *do* come with complexity, uncertainty, and risk — see Vitalik Buterin's latest opus: https://blog.ethereum.org/2014/07/05/stake/ . That guy is a good thinker and writer! And he appears to have been reading my mind. As well as adding in a bunch of ideas that were not in my mind, from such sources as http://eprint.iacr.org/2014/452.pdf . Regards, Zooko ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
On Mon, Oct 28, 2013 at 6:49 AM, Richard Elling richard.ell...@gmail.com wrote: I hate to keep this thread going, but it cannot end with an open-ended threat... please, let's kill it off nice and proper. Hey, I don't want to waste anyone's time, including my own. If nobody is interested in this — possibly including the original author of the patch, Saso Kiselkov, judging from ¹ — then by all means let's drop the subject. ¹ http://article.gmane.org/gmane.os.illumos.zfs/3103 However, in case someone out there is reading this… Do you agree that if the attacker does not have DDT key (including the hash) of the future intended write (ignoring the fact that we haven't invented a properly working time machine yet) that this attack is extraordinarily difficult to conduct with any hope of a fruitful outcome? If so, let's kill this thread. I'm not sure what you mean about the future intended write. The risk I was talking about was that an attacker can cause two blocks (on someone else's ZFS system) to hash to the same fingerprint. Assuming that “the DDT key” is the secret which is prefixed to the block contents in the current patch, then I agree it is extremely difficult to cause two blocks to hash to the same fingerprint. A way to be more precise about how difficult it is, is to talk about what property we depend on the hash function to have in order to prevent this attack. If the attacker steals the secret, or if there is some variant of ZFS which shares that secret among multiple parties ², then the property that we rely on the hash function to have is “collision-resistance”. If the attacker doesn't have the secret, then the property that we rely on the hash function to have one which is closely related to, and even easier-to-achieve than, “MAC”. ² http://article.gmane.org/gmane.os.illumos.zfs/3015 Functions which, in my opinion, have this easier-to-achieve-than-MAC property include SHA-256, HMAC-MD5, Skein, BLAKE2, and BLAKE2-reduced-to-5-rounds. Almost all cryptographic hash functions have this property! One of the few cryptographic hash functions which I would be not so confident in is Edon-R. It *probably* still has this property, but it might not, and cryptographers haven't studied it much. Functions which, in my opinion, have the much harder-to-achieve “collision-resistance” property include SHA-256, Skein, BLAKE2, and *probably* BLAKE2-reduced-to-5-rounds. I'll let the fact that there is no future dedup run and there is no replace blocks later in ZFS fall quietly in the forest with nobody listening. I'm sorry if I've misunderstood; I'm not an expert on ZFS. If you'd like to take some of your valuable time to explain it to me, I'll spend some of my valuable time to learn, because I'm interested in filesystems in general and ZFS in particular. If not, I'm pretty sure everything I've written above is still true. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-ced276b8 Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-4984dade Powered by Listbox: http://www.listbox.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [zfs] [Review] 4185 New hash algorithm support
On Tue, Oct 22, 2013 at 6:05 AM, Schlacta, Christ aarc...@aarcane.org wrote: If any weakened algorithm is to be implemented, how can we know how weak is too weak, and how strong is sufficient? Each professional Cryptographer has given different opinions and all those at our immediate disposal have now been biased. A good way to do that is use an algorithm that has attracted interest from a large number of independent cryptographers. If many cryptographers have invested extensive effort trying to find weaknesses in a algorithm, and haven't reported any, then we can feel more confident that it is less likely to harbor undiscovered weaknesses. Among the algorithms we've been talking about in this thread, SHA-256, HMAC-MD5, Skein, Keccak, and BLAKE are all in this category of being well-studied. Cryptographers publish it if they find a weakness in a reduced-round variant of an important algorithm. You can see a summary of the best results against weakened variants of BLAKE in ¹ (Table 1). ¹ http://eprint.iacr.org/2013/467 The rows labeled perm. and cf. are attacks on just one component of the hash, not the whole algorithm. The # Rounds column shows how many rounds of a reduced-round variant would be vulnerable to that attack. Don't forget to look at the Complexity column, too! That shows (roughly) how many calculations would be necessary to implement the attack. Yes, almost all of them are computations that are completely impossible for anyone to actually execute in the forseeable future. But still, they are the best attack that anyone has (publicly) come up with against those weakened variants of BLAKE so they serve as a heuristic indicator of how strong it is. Among the well-studied algorithms listed above, BLAKE is one of the best-studied. It was one of the five finalists in the SHA-3 contest, and in the final report of the contest ², NIST wrote “The cryptanalysis performed on BLAKE […] appears to have a great deal of depth”. Here is a list of research reports that analyzed BLAKE: ³. ² http://dx.doi.org/10.6028/NIST.IR.7896 ³ https://131002.net/blake/#cr Now, BLAKE2 is not necessarily as secure as BLAKE. We could have accidentally introduced weaknesses into BLAKE2 when making tweaks to optimize it. The paper ¹ looked for such weaknesses and reported that they found nothing to make them distrust BLAKE2. We use a stream cipher named ChaCha ⁴,⁵ as the core of BLAKE and BLAKE2, and nobody has found any weakness in ChaCha. Again, that doesn't mean we didn't manage to screw it up somehow, but I think it helps! If anyone found a weakness in ChaCha, it would *probably* also show them a weakness in BLAKE2, and vice versa. ⁴ https://en.wikipedia.org/wiki/ChaCha_%28cipher%29#ChaCha_variant ⁵ https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-02 In sum, there has been a lot of independent analysis of BLAKE2, BLAKE, and ChaCha, and I hope there will be more in the future. If you use a reduced-round version of BLAKE2, you can look at these results to see whether anyone has published an attack that would break that reduced-round version. Of course, more rounds is safer against future breakthroughs. It was in that context that I recommended that ZFS use the most rounds of BLAKE2 that it can while still being faster than Edon-R. ☺ That will probably be around 5 rounds. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. --- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] my comment to NIST about reduced capacity in SHA-3
Date: Tue, 1 Oct 2013 15:45:27 -0400 From: zooko zo...@zooko.com To: Multiple recipients of list hash-fo...@nist.gov Subject: Re: On 128-bit security Folks: Here are my personal opinions about these issues. I'm not expert at cryptanalysis. Disclosure: I'm one of the authors of BLAKE2 (but not one of the authors of BLAKE). I personally do not believe that there is any secret agenda behind this proposal, even though I believe that there was a secret agenda behind Dual EC DRBG. One reason that I believe that the motivation behind this proposal is the stated motivation of improving performance, is that Joan Daemen told me in person in January of 2013 that the Keccak team had considered defining a reduced Keccak to compete with BLAKE2, but had decided against it because they didn't want to disrupt the SHA-3 standardization process. Apparently they changed their minds, and apparently their fears of disruption turned out to be prescient! I also do not think that a security level of 2^256 is necessarily better than a security level of 2^128. *Maybe* it is better, but I'm not aware of any examples where that sort of distinction has turned out to matter in practice, and I can't really judge if it is likely to matter in the future (except, of course, if you forget to take into account multi-target issues…). I suspect nobody else can, either. However, even though I *personally* would have confidence that a Keccak with a 256-bit capacity would be safe and would be free of maliciously induced weakness, I want a standard to be widely accepted in addition to being safe. This is the Caesar's wife must be above suspicion argument. It isn't enough to make a secure standard, but also we need other people to have confidence in it. And, I don't know if we can persuade people that no it isn't actually backdoored/weakened. It may be the kind of thing where if that's the conversation we're having then we've already lost. Would it make sense to go ahead and standardize SHA3-as-a-replacement-for-SHA2 by standardizing the form of Keccak which is most widely accepted by cryptographers and which is closest to what was studied during the contest, and then separately offer SHAKE and reduced-for-speed-Keccak as additional new things? A lot of uses of secure hash functions don't need to be particularly efficient. In my slides about BLAKE2 (https://blake2.net/acns/slides.html) I argue that there are use-cases where efficiency is critical, but it is equally true that there are common and important use cases where a 576-bit capacity Keccak would be fine, e.g. public key certificates. --- Joan Daemen, one of inventors of AES and one of the inventors of Keccak (SHA-3), replied to my mailing list post as follows: Date: Fri, 4 Oct 2013 05:08:07 -0400 From: Joan DAEMEN joan.dae...@st.com To: Multiple recipients of list hash-fo...@nist.gov Subject: RE: On 128-bit security Hello all, Zooko wrote: I personally do not believe that there is any secret agenda behind this proposal, even though I believe that there was a secret agenda behind Dual EC DRBG. One reason that I believe that the motivation behind this proposal is the stated motivation of improving performance, is that Joan Daemen told me in person in January of 2013 that the Keccak team had considered defining a reduced Keccak to compete with BLAKE2, but had decided against it because they didn't want to disrupt the SHA-3 standardization process. Apparently they changed their minds, and apparently their fears of disruption turned out to be prescient! Yes, Zooko and I met at the end-of-Ecrypt II event on Tenerife early 2013 (24° C in January!). I don't remember our conversation in detail, but I I'm sure Zooko is citing me correctly because that is what we were thinking about at the time. Actually, what we had in mind was to propose something like Keccak2 to compete with BLAKE2 by drastically cutting the number of rounds, e.g., down to 12 rounds for Keccak-f[1600], but otherwise keeping the algorithm as it is. That might have sent the wrong message indeed, but we just didn't do it. In contrast, the capacity is an integral parameter of the Keccak family that we even proposed as user-tunable in our SHA-3 submission. Matching the capacity to the security strength levels of [NIST SP 800-57] is simply exploiting that flexibility. Kind regards, Joan, also on behalf of my Keccak companions --- Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Reply to Zooko (in Markdown)
Dear Jon: Thank you for your kind words and your detailed response. I am going to focus only on the issue that I think is most relevant and urgent for your customers and mine. That urgent issue is: what's the difference between the now-canceled Silent Mail product and the products that you are still offering, such as Silent Text? I don't understand why the Lavabit shutdown and the related domestic surveillance disclosures imply that Silent Mail was unsafe in any way that wouldn't also mean Silent Text is unsafe. Before I go on, I'd like to point out a critical fact that some readers might not be aware of: Ladar Levison, the owner of Lavabit, now claims that he is being threatened with jail time *for having shut down the service*: http://investigations.nbcnews.com/_news/2013/08/13/20008036-lavabitcom-owner-i-could-be-arrested-for-resisting-surveillance-order?lite This changes the equation, because it means not only can the U.S. federal espionage authorities say Backdoor all of your customers or close your business., they can also say Backdoor all of your customers or go to jail.. As the owner and CEO of a privacy-protecting service (https://LeastAuthority.com) and a U.S. citizen, and as the father of three precious boys who do not want to be separated from me for any length of time, this concerns me greatly. Now, maybe the U.S. espionage authorities wouldn't make that threat again. Maybe Ladar Levison's resistance will teach them that it was a mistake. I don't know, but we have to take into account this possibility for now. Your decision to shutter the Silent Mail product was made because of such possibilities. But your decision to *keep* the Silent Text service (and the others) still operating while shutting down the Silent Mail service would make sense only in the following scenario: Attacker: We're here to compel you to give us access to the confidential communications of all of your customers. Silent Circle: But, to do that we would have to change our client — for example, change its random number generator to produce output that we can predict — and then upload a software update to the Apple and Google app stores, and then wait for all of our customers to automatically upgrade to the new version! Attacker: Oh, well in that case nevermind. Why do you think that this scenario is plausible? I don't think it is plausible. Instead, I think the conversation would go like this: Silent Circle: … and then wait for all of our customers to automatically upgrade to the new version! Attacker: Okay. Do that. Now, there is a big, complex, and interesting question about how to enable others to *verify* the security of software. It is not impossible, as you suggested. Good progress on enabling independent verification of security is being made, by Whisper Systems (https://whispersystems.org/), my own company LeastAuthority.com, the Tor Project (https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise), Gitian (https://gitian.org/), Debian (https://wiki.debian.org/ReproducibleBuilds), and Bitcoin (https://en.bitcoin.it/wiki/Release_process). But before we get into the nuts and bolts of how to facilitate verification of end-to-end security, I want to hammer on the first issue: before going forth to try to improve an issue, we should first admit to our current customers and to the public that the issue exists. We shouldn't mislead our customers into thinking that they are safe from something that they are not. Silent Circle's closure of Silent Mail for the stated reason is inconsistent with its continued operation of the Silent Text service. The stated reason was that the US federal government could compel Silent Circle to backdoor the Silent Mail service. That same reason applies today to the Silent Text service and the other services that Silent Circle is still operating. To be clear, I'm not asking you to shut down your other services. I think that would be a loss for everyone. And I'm not asking you to magically fix all of the problems by tomorrow. I know, in part from your detailed letter, that you are currently working on improving some parts of your process, and I think that there are other techniques that you could use (including licensing your source code as Free and Open Source software) that would help. But I understand the challenges of running a business, actively serving customers, and performing sophisticated engineering all at once. I know that improvement takes time. What I'm asking you to do is to *be clear* with your customers and with the public about the current limitations. Currently, the US federal espionage agencies can compel Silent Circle to secretly provide access to all of Silent Circle's customers' private communications. That's too bad. But it is fixable! But to fix it starts with admitting what the problem is. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Service Rep https://LeastAuthority.com Freedom matters.
[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-to-anti-snooping-app-silent-circle/ .. _²:
[cryptography] LeastAuthority.com announces PRISM-proof storage service
Dear people of the cryptography@randombit.net mailing list: For obvious reasons, the time has come to push hard on *verifiable* end-to-end encryption. Here's our first attempt. We intend to bring more! We welcome criticism, suggestions, and requests. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. --- LeastAuthority.com Announces A PRISM-Proof Storage Service Wednesday, July 31, 2013 `LeastAuthority.com`_ today announced “Simple Secure Storage Service (S4)”, a backup service that encrypts your files to protect them from the prying eyes of spies and criminals. .. _LeastAuthority.com: https://LeastAuthority.com “People deserve privacy and security in the digital data that make up our daily lives.” said the company's founder and CEO, Zooko Wilcox-O'Hearn. “As an individual or a business, you shouldn't have to give up control over your data in order to get the benefits of cloud storage.” verifiable end-to-end security -- The Simple Secure Storage Service offers *verifiable* end-to-end security. It offers “end-to-end security” because all of the customer's data is encrypted locally — on the customer's own personal computer — before it is uploaded to the cloud. During its stay in the cloud, it cannot be decrypted by LeastAuthority.com, nor by anyone else, without the decryption key which is held only by the customer. S4 offers “*verifiable* end-to-end security” because all of the source code that makes up the Simple Secure Storage Service is published for everyone to see. Not only is the source code publicly visible, but it also comes with Free (Libre) and Open Source rights granted to the public allowing anyone to inspect the source code, experiment on it, alter it, and even to distribute their own version of it and to sell commercial services. Wilcox-O'Hearn says “If you rely on closed-source, proprietary software, then you're just taking the vendor's word for it that it actually provides the end-to-end security that they claim. As the PRISM scandal shows, that claim is sometimes a lie.” The web site of LeastAuthority.com proudly states “We can never see your data, and you can always see our code.”. trusted by experts -- The Simple Secure Storage Service is built on a technology named “Least-Authority File System (LAFS)”. LAFS has been studied and used by computer scientists, hackers, Free and Open Source software developers, activists, the U.S. Defense Advanced Research Projects Agency, and the U.S. National Security Agency. The design has been published in a peer-reviewed scientific workshop: *Wilcox-O'Hearn, Zooko, and Brian Warner. “Tahoe: the least-authority filesystem.” Proceedings of the 4th ACM international workshop on Storage security and survivability. ACM, 2008.* http://eprint.iacr.org/2012/524.pdf It has been cited in more than 50 scientific research papers, and has received plaudits from the U.S. Comprehensive National Cybersecurity Initiative, which stated: “Systems like Least-Authority File System are making these methods immediately usable for securely and availably storing files at rest; we propose that the methods be further reviewed, written up, and strongly evangelized as best practices in both government and industry.” Dr. Richard Stallman, President of the Free Software Foundation (https://fsf.org/) said “Free/Libre software is software that the users control. If you use only free/libre software, you control your local computing — but using the Internet raises other issues of freedom and privacy, which many network services don't respect. The Simple Secure Storage Service (S4) is an example of a network service that does respect your freedom and privacy.” Jacob Appelbaum, Tor project developer (https://www.torproject.org/) and WikiLeaks volunteer (http://wikileaks.org/), said “LAFS's design acknowledges the importance of verifiable end-to-end security through cryptography, Free/Libre release of software and transparent peer-reviewed system design.” The LAFS software is already packaged in several widely-used operating systems such as Debian GNU/Linux and Ubuntu. https://LeastAuthority.com Title: LeastAuthority.com Announces A PRISM-Proof Storage Service LeastAuthority.com Announces A PRISM-Proof Storage Service Wednesday, July 31, 2013 LeastAuthority.com today announced “Simple Secure Storage Service (S4)”, a backup service that encrypts your files to protect them from the prying eyes of spies and criminals. “People deserve privacy and security in the digital data that make up our daily lives.” said the company's founder and CEO, Zooko Wilcox-O'Hearn. “As an individual or a business, you shouldn't have to give up control over your data in order to get the benefits of cloud storage.” verifiable end-to-end security The
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On Tue, Aug 13, 2013 at 5:16 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 8/13/13 11:02 AM, ianG wrote: Super! I think a commercial operator is an essential step forward. How so? Centralization via commercial operators doesn't seem to have helped in the email space lately. It helps because we at LeastAuthority.com (https://LeastAuthority.com/about_us ) can spend our days improving the performance and reliability of our ciphertext storage servers and contributing patches back to the free-and-open-source client (https://Tahoe-LAFS.org ). If we weren't running LeastAuthority.com, we would presumably have to get different jobs which would take a lot of time away from LAFS hacking! It helps our customers because they can avoid doing the effort and expense of setting up and managing servers, and instead pay us a monthly fee to maintain those servers and the storage of their ciphertext. Also our customer and business partners like having the option of hiring us for support when they are integrating the free-and-open-source LAFS software into their own products. Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com Freedom matters. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] ANNOUNCING Tahoe-LAFS v1.10
ANNOUNCING Tahoe, the Least-Authority File System, v1.10 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.10.0 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst Tahoe-LAFS is the first distributed storage system to offer provider-independent security — meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst The previous stable release of Tahoe-LAFS was v1.9.2, released on July 3, 2012. v1.10.0 is a feature release which adds a new Introducer protocol, improves the appearance of the web-based user interface, improves grid security by making introducer FURLs unguessable, and fixes many bugs. See the NEWS file [1] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.rst file [2].) COMPATIBILITY This release should be compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. Except for the new optional MDMF format, we have not made any intentional compatibility changes. However we do not yet have the test infrastructure to continuously verify that all new versions are interoperable with previous versions. We intend to build such an infrastructure in the future. The new Introducer protocol added in v1.10 is backwards compatible with older clients and introducer servers, however some features will be unavailable when an older node is involved. Please see docs/nodekeys.rst [14] for details. This is the eighteenth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the foreseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file COPYING.GPL [4] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file COPYING.TGPPL.rst [5] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD, and probably most other systems. Start with docs/quickstart.rst [6]. HACKING AND COMMUNITY Please join us on the mailing list [7]. Patches are gratefully accepted -- the RoadMap page [8] shows the next improvements that we plan to make and CREDITS [9] lists the names of people who've contributed to the project. The Dev page [10] contains resources for hackers. SPONSORSHIP Atlas Networks has contributed several hosted servers for performance testing. Thank you to Atlas Networks [11] for their generous and public-spirited support. And a special thanks to Least Authority [12], which employs several Tahoe-LAFS developers, for their continued support. HACK TAHOE-LAFS! If you can find a security