paragon_init

> * I shouldn't have to know what a pem is, and I shouldn't have to open() one.

Agreed, but what you're requesting is separate from the work being discussed in this blog post, and both are actually compatible.

For the PHP community, we made Certainty - https://github.com/paragonie/certainty

You can just...

  <?php
  use ParagonIE\Certainty\RemoteFetch;
  // cURL boilerplate
  $ch = curl_init();
  curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
  curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);

  // Fetch the latest CACert bundle, verify its authenticity, save it locally  
  $fetcher = new RemoteFetch('/path/to/certainty/data');
  $latestCACertBundle = $fetcher->getLatestBundle();
  curl_setopt($ch, CURLOPT_CAINFO, $latestCACertBundle->getFilePath());

For Python specifically, there may be some value in storing the relevant PEM files into something like SigStore. That could be an easier proposal for the PyCA team to consider.

Has there been any serious discussion about incorporating the results of PQCRYPTO in your protocol so Zcash is still secure and viable (at >= 2^128 security level) after the development of practical quantum computers?

http://pqcrypto.eu.org

This blog post is digestible in a few minutes. Crypto 101 can occupy a novice for a few hours. Given the hard choice of one of the two, we would encourage anyone interested to read Crypto 101 over our blog post, as they'll walk away with a much more detailed understanding .

The title is a reference to a meme ("You wouldn't download a car!") and also a reference to some absurdly bad cryptography, e.g. http://www.cryptofails.com/post/87697461507/46esab-high-qual...

(I've updated the title to read "Basic Cryptography for Developers" instead of "Cryptography for Developers" so as to not accidentally make someone think they know it all.)

    random_bytes(int) - Generate a string of random bytes from the OS (e.g.. /dev/urandom)
    
    random_int(int, int) - Generate an unbiased random integer between two integers

We cannot declare the 1.0.0 stable release until the PHP team makes a design decision about how to handle errors in their version of the library. We currently throw an Exception; they might decide to return false and raise an E_WARNING error. Until the outcome is known, we're in limbo.

This library has not been subject to a paid audit by a security team, but it has been reviewed by several prominent members of the PHP community (and a few security/crypto folks outside of PHP land).

I believe it to be more secure than any other PHP implementation of these features. That said, more review and scrutiny would be greatly appreciated! :)

Thomas's answer probably has to do with the risks of decrypting a stream and being unable to authenticate it first. (See also: the Cryptographic Doom Principle.)

Instead of throwing money at the problem, you can instead choose to teach yourself more about the subject. We maintain a curated list on Github for people interested in learning about application security for this very reason.

https://github.com/paragonie/awesome-appsec

But if you're a company and your operating budget is in the millions of dollars hire a security consultant!

GCM is far more preferred to either CBC or CTR because it's less for the implementer to screw up.

NaCl's ChaCha20-Poly1305 is even better, because it's fast and constant-time.

'cperciva made the CTR+HMAC recommendation here: http://www.daemonology.net/blog/2009-06-11-cryptographic-rig...

Properly authenticated encryption that uses CBC+HMAC-SHA2 with PKCS7 padding is probably okay, but new developments should prefer AEAD modes above all else, and CTR+HMAC-SHA2 if no AEAD modes are available.

(The kind folks in ##crypto on freenode have pointed out to me that CTR also allows random-access decryption, where CBC mode does not. We haven't ever implemented this feature and cannot comment on it.)

https://github.com/nehbit/aether-public

EDIT: Done. :)