Cryptographers hate GPG. GPG is ugly as sin†. Unfortunately (and I mean that only with a little bit of snark), GPG mostly still works, in the sense of standing up to active, informed attackers with modern techniques.
† For instance, look how it handles message integrity.
This is a slippery slope argument that ends in you arguing that the best tested cryptosystem in common use (TLS) is also insecure. All cryptosystems have vulnerabilities; the question is, how workable is the system after those flaws are fixed.
For the record, I respect the critiques practitioners have of GPG. Unfortunately, their alternatives tend to be ad-hoc. There should be a clean, simple, GPG-like standard, perhaps based on ECC and AE cipher constructions, to replace GPG. But until that happens, in the choice between ugly and workable vs. simple and fragile, ugly and workable is the right choice for most people.
As always I think you drastically underestimate how dangerous this stuff is because you've dedicated your career to it, while normal implementors --- even crypto enthusiasts (look at Tor and SSH) --- have little of the nuance required to get it right.
I like the fundamentals of TLS more than you do; I don't think it's a bad or needlessly complex protocol (except maybe session resumption). I see that reasonable people can differ on that point. But, very importantly, TLS is also a vehicle for collecting and implementing the best known methods in cryptography. I think you tend to overlook that.
As always, my opinions are as a software security practitioner and not as a cryptographer, since I am not one.
The appearance and track record† of the code in OpenSSL does the credibility of TLS no favors, and it is totally understandable why someone who had to deal with software security for a platform that ships and depends on OpenSSL would become allergic to it.
But, two responses to that:
* First, what Joel Spolsky says about rewrites. Sometimes code is ugly for a reason. Clean rewrites of OpenSSL will inevitably introduce bugs. Introducing bugs in SSL†† implementations is perilous.
* Second, there are mature alternatives to OpenSSL. For instance, most? browsers don't use it.
† In fairness, that's because OpenSSL dates back to a time when nobody was getting C software security even close to right.
†† I use TLS and SSL interchangeably, which is a foible I should work on correcting, but the difference doesn't matter much here.
Hey, Since you mentioned TLS/SSL: I can't seem to find an answer to this question: Does my browser or system, need to contact the CA each time it encounters a new SSL Cert, or is having the root certificate enough?
Your browser does not need to contact a CA to verify the signature in an SSL certificate, but may in some cases want to contact the CA to check for revocation.
GPG is big and complicated. The more code you have the more likely it is that you'll have security vulnerabilities. (This is especially true for code like GPG which reads attacker-provided inputs, since it allows the attacker to pick which of many code paths get invoked.)
They don't publish their key derivation scheme, but I'd be shocked (and pleased) to find that they were savvy enough to actually use PBKDF2 or even stretched SHA1. Believe it or not, plenty of commercial vendors literally take the ASCII of the password as the key.
I'd also worry, based on that spec, that the Arq developers believe the SHA1 hashes they store are fully equivalent to a deliberate MAC.
I should have noted that Arq's git-like scheme makes them inherently more careful about storage and data integrity (under non-adversarial conditions) than Jungledisk. My perusal of their site was casual. I really don't know much about them and am not offering a professional opinion.
I emailed you asking for professional help in reviewing the security aspects of Arq. I'm not an expert, and I'd like to get it right. If anybody else has the expertise to do this review, please email me at stefan@haystacksoftware.com.
In general, if you're an indie developer and you're doing custom crypto stuff, I'm happy to do a consult free of charge. You'll probably find other software security firms are similarly willing to do that kind of stuff, just like the good law firms will tend to do up-front consults for free.
Full-on software reviews, particularly by consultants competent enough to review crypto, are very expensive. You can probably get away without doing one, as long as you get good advice and have people to bounce ideas and problems off of.
Karmically, being someone to bounce ideas and problems off of has paid off for Matasano dramatically, so, anyone else reading this thread, consider this an open invitation.
I'm in the process of getting an app review done by a security expert. Then I can answer that question (hopefully) definitively. (I'm the author of Arq)
I'm happy to cross-check this stuff with you in private, if you'd like a free consult from another professional (reiterating something I said on Twitter a minute ago).
I took a look https://www.tarsnap.com/gettingstarted.html and I don't understand why "If you have multiple machines, you almost certainly want to create a separate key file for each machine."? Can you explain why, if I'd like to access the same data from the different machines? Or is the main assumption that every machine has its own, nor shareable, backup? Isn't the main advantage of an online service to have the same data accessible from more machines?
Tarsnap isn't Dropbox. It's a backup system. Its cost structure and security model is optimized for backup, which is why you can't e.g. read your Tarsnap files from a web interface at Tarsnap.
