Least Authority Blog

What's the point? Tarsnap is modestly cheap and extremely secure, and there other backup services which are equally cheap and almost as secure. Use at least 2x services always, so Tarsnap going down or bust (heaven forbid) isn't a big deal. There is never a perfect real-world solution, but risk mitigations that reduce risk at a higher levels of abstraction is how to get real, production-grade fault-tolerance the easier way than dredging up edge-case issues without offering usable alternatives.

SpiderOak uses end-to-end encryption, but I wouldn't trust it completely https://spideroak.com/opendownload

rsync.net is also pretty usable, but I wouldn't trust there is any in-flight or at-rest security http://www.rsync.net/

Tahoe LAFS provider https://leastauthority.com/ (it's possible to run your own Tahoe LAFS servers on cloud/colo boxes on several providers)

The best-practice mitigation to allow backups on less secure providers is encrypt locally (end-to-end encryption effectively) and distribute restore keys to a decent quorum of managers/founders/supervisors.

Having done offsite LTO tape vaulting and formal disaster recovery / business continuity planning at the organization level, it's a whole lot cheaper, easier and more flexible to use multiple cloud providers for most real use-cases (apart from multiple PiB datasets).

One of the Cryptodog devs here - no Chrome 0days in our possession (yet).

The code's all on Github: https://github.com/Cryptodog/cryptodog. No signed extensions or apps yet, but you can clone and run locally for testing purposes, or use the hosted client linked there.

So far, we've been focusing on refactoring, fixing surface bugs, and making the UI more attractive and intuitive -- none of the underlying cryptography has been touched. It also performs slightly faster than stock Cryptocat. Since Nadim took down his XMPP server, we've had to create our own, but the backend is identical to his setup.

Of course, Cryptodog is by no means the best solution for E2E chat, just as Cryptocat wasn't. The best we can hope to achieve without a complete codebase overhaul is a reasonable level of security (https://leastauthority.com/static/publications/LeastAuthority-Cryptocat-audit-report.pdf). However, it's still a fairly usable app that can afford casual users protection against basic threats, like corporate data mining.

Issue postings, pull requests, and other miscellaneous contributions are all welcome.

Yup, here are a number of articles on the subject

https://leastauthority.com/blog/debunking-the-nothing-to-hide-rhetoric/

https://www.techrepublic.com/blog/it-security/why-nothing-to-hide-misrepresents-online-privacy/

http://www.msnbc.com/msnbc/surveillance-you-may-have-nothing-hide

https://www.wired.com/2013/06/why-i-have-nothing-to-hide-is-the-wrong-way-to-think-about-surveillance/

https://www.zdnet.com/article/privacy-is-innately-flawed-nothing-to-hide-does-not-exist/

https://mashable.com/2013/06/13/julian-sanchez-nsa/

https://www.techdirt.com/articles/20130613/12180423457/if-youve-got-nothing-to-hide-youve-actually-got-plenty-to-hide.shtml

https://www.washingtonexaminer.com/tim-carney-even-law-abiding-people-should-oppose-surveillance

https://www.chronicle.com/article/Why-Privacy-Matters-Even-if/127461/

https://uproxx.com/technology/prism-why-you-should-care-even-if-you-have-nothing-to-hide/

https://reason.com/2013/06/12/three-reasons-the-nothing-to-hide-crowd/

https://www.schneier.com/blog/archives/2006/05/the_value_of_pr.html

tahoe-lafs, https://tahoe-lafs.org/trac/tahoe-lafs , is "an open source, secure, decentralized, fault-tolerant, peer-to-peer distributed data store and distributed file system."

It has the server-level RAID you desire. The FAQ states: ``You know how with RAID-5 you can lose any one drive and still recover? And there is also something called RAID-6 where you can lose any two drives and still recover. Erasure coding is the generalization of this pattern: you get to configure how many drives you could lose and still recover. You can choose how many drives (actually storage servers) will be used in total, from 1 to 256, and how many storage servers are required to recover all the data, from 1 to however many storage servers there are. We call the number of total servers N and the number required K, and we write the parameters as "K-of-N".''

It's a very active open source project, with full-time contributors (I think?), funded by their commercial arm, https://leastauthority.com/ .

You can't be serious. It's using libsodium in one part of the code, so therefore ALL cryptography uses libsodium? You do know that Bitcoin has already switched most of the secp256k1 stuff away from OpenSSL and to libsecp256k1, and ZCash will follow suit?

But more importantly than that it uses libsnark for the actual clever bits, which has already been critically broken[1] precisely because it is so new and poorly tested.

Even the cryptography in ZeroCash/ZeroCoin is too new to be trusted with a financial system. That is not alarmist, that is practical. Relying on old, established cryptography is precisely why Bitcoin hasn't been trivially broken, and the zk-snarks cryptography will need to go through the same peer-review and refinement process over the next decade or two.

[1] https://leastauthority.com/blog/a_bug_in_libsnark.html

SHA1 is long past its expiry date. NIST has been recommending to move away from it since 2010, and it outright banned it last year. And when the NSA-influenced NIST recommends something, you know you should be doing it at least 3 years earlier. Someone like NSA or even a drug cartel can pretty easily break it now.

This is a 2 year old article:

https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

If you're worried about the performance overhead of SHA2, just use Blake2, which is actually faster than SHA1 and even MD5:

https://leastauthority.com/blog/BLAKE2-harder-better-faster-stronger-than-MD5.html

http://bench.cr.yp.to/results-sha3.html#amd64-titan0

https://blake2.net/