https://letsencrypt.org/2016/04/12/leaving-beta-new-sponsors...
What Let's Encrypt does against state-level actors is let people easily use HTTPS instead of HTTP without subjecting their users to self-signed certificate warnings.
A government could still MITM the connection but that requires an active attack rather than passive surveillance. And active attacks are subject to detection. So it protects against undetectable mass surveillance.
Our blog posts in particular:
https://paragonie.com/blog/category/security-engineering
A reading list we maintain for application security (and some crypto stuff):
For example, developers know not to roll their own cryptography, but how can someone who has never rolled their own crypto evaluate existing libraries? There are a lot of bad ones out there, and "I didn't roll my own crypto" doesn't equate to "I used a well-studied library thought to be secure by industry experts".
Consequently, we delved into specific recommendations and explained why we include them in our list.
https://paragonie.com/blog/2015/11/choosing-right-cryptograp...
(Historical context, this was published after I discovered CVE-2015-7503 in Zend Framework 2. A lot of my peers said it was good, but I don't recommend code until I've audited it. Lo and behold, I found a problem with their RSA implementation.)
For our reading list: We focus on application security, not physical security (e.g. data center security, full disk encryption), social engineering (e.g. phishing, scamming), or system security (e.g. malware and OS-level exploit mitigation).
Application security can encompass cryptography, information theory, etc. but the target audience is programmers.
Material for any programming language will be considered for inclusion, but some absurd ones (e.g. Brainfuck) will probably be declined.