<?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());
Writing a Python client should be relatively straightforward, should anyone want to.
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?
Crypto 101 is a ~200 page book that is far richer in detail and examples. It also covers a lot of primitives (one-time pads, hash trees, etc.) that we eschewed for the sake of brevity.
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 .
This is an excellent point. Cryptography is not a trivial field to master.
(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.)
When PHP 7 is released later this year, PHP users will finally be able to quickly and easily leverage a CSPRNG in their projects.
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 wrote this library so PHP 5.x users can import this in their project and write code that takes advantage of this new PHP 7 API. Particularly random_int(), which is suitable for random string generation (e.g. random password generator).
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! :)
Agreed. It's a red flag for "expect more exploitable issues to be found around the corner" and can result in biased distributions, but it by itself does not break a RNG.
Encrypt-Then-MAC just makes sense. If the first thing you do when you receive a blob of encrypted data is check that it's authentic (in constant-time!), the attack surface is greatly reduced.
If you build something open source and it gets incredibly popular, security researchers will also probably come to you. This creates its own problems, of course. (Can't have problems without PR.)
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.)
If you are a business, then definitely yes. But the average self-taught developer will not have the resources available to hire a security consultant.
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.
CTR saves you the trouble of padding your plaintext before encrypting, thus eliminating an entire class of cryptography attacks (i.e. padding oracles). The security margins of CBC and CTR are otherwise similar.
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.
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.)
> * 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...
Writing a Python client should be relatively straightforward, should anyone want to.
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.