-/*
- * RSA
- * ---
- *
- * A RSA engine consists in two functions, for public-key and private-key
- * operations (modular exponentiations). In both cases, the same buffer is
- * used as source and destination.
- *
- * Key elements are provided as arrays of bytes, in big-endian unsigned
- * encoding (leading zeros are correctly skipped, hence signed encodings
- * can also be used). The source/destination array (x[]) is an array of
- * bytes that, per PKCS#1 rules, MUST have the same length as the modulus,
- * exactly: missing or extra leading bytes, even of value 0x00, are not
- * tolerated for x[].
- *
- * Parameter validation: the engine MUST gracefully handle incorrect key
- * parameters (e.g. an even modulus); it needs not detect all cases of
- * incorrect key parameters. For public key operations, the engine MUST
- * validate the length of x[] (it must match the numerical length, in
- * bytes, of the modulus); it MUST also check that the provided x[]
- * decodes to an integer that is numerically less than the modulus. For
- * private key operation, the engine may assume that the length and
- * contents of x[] are appropriate (it MUST NOT allow an invalid value
- * to result in a buffer overflow, but an invalid input x[] may result
- * in an undetected invalid output).
- *
- * Constant-time requirements: the following information may leak through
- * execution time and memory access pattern:
- * -- the actual bit length of the modulus;
- * -- the actual bit length of each prime factor;
- * -- the byte lengths as provided to the function calls.
+/** \file bearssl_rsa.h
+ *
+ * # RSA
+ *
+ * This file documents the RSA implementations provided with BearSSL.
+ * Note that the SSL engine accesses these implementations through a
+ * configurable API, so it is possible to, for instance, run a SSL
+ * server which uses a RSA engine which is not based on this code.
+ *
+ * ## Key Elements
+ *
+ * RSA public and private keys consist in lists of big integers. All
+ * such integers are represented with big-endian unsigned notation:
+ * first byte is the most significant, and the value is positive (so
+ * there is no dedicated "sign bit"). Public and private key structures
+ * thus contain, for each such integer, a pointer to the first value byte
+ * (`unsigned char *`), and a length (`size_t`) which is the number of
+ * relevant bytes. As a general rule, minimal-length encoding is not
+ * enforced: values may have extra leading bytes of value 0.
+ *
+ * RSA public keys consist in two integers:
+ *
+ * - the modulus (`n`);
+ * - the public exponent (`e`).
+ *
+ * RSA private keys, as defined in
+ * [PKCS#1](https://tools.ietf.org/html/rfc3447), contain eight integers:
+ *
+ * - the modulus (`n`);
+ * - the public exponent (`e`);
+ * - the private exponent (`d`);
+ * - the first prime factor (`p`);
+ * - the second prime factor (`q`);
+ * - the first reduced exponent (`dp`, which is `d` modulo `p-1`);
+ * - the second reduced exponent (`dq`, which is `d` modulo `q-1`);
+ * - the CRT coefficient (`iq`, the inverse of `q` modulo `p`).
+ *
+ * However, the implementations defined in BearSSL use only five of
+ * these integers: `p`, `q`, `dp`, `dq` and `iq`.
+ *
+ * ## Security Features and Limitations
+ *
+ * The implementations contained in BearSSL have the following limitations
+ * and features:
+ *
+ * - They are constant-time. This means that the execution time and
+ * memory access pattern may depend on the _lengths_ of the private
+ * key components, but not on their value, nor on the value of
+ * the operand. Note that this property is not achieved through
+ * random masking, but "true" constant-time code.
+ *
+ * - They support only private keys with two prime factors. RSA private
+ * key with three or more prime factors are nominally supported, but
+ * rarely used; they may offer faster operations, at the expense of
+ * more code and potentially a reduction in security if there are
+ * "too many" prime factors.
+ *
+ * - The public exponent may have arbitrary length. Of course, it is
+ * a good idea to keep public exponents small, so that public key
+ * operations are fast; but, contrary to some widely deployed
+ * implementations, BearSSL has no problem with public exponent
+ * longer than 32 bits.
+ *
+ * - The two prime factors of the modulus need not have the same length
+ * (but severely imbalanced factor lengths might reduce security).
+ * Similarly, there is no requirement that the first factor (`p`)
+ * be greater than the second factor (`q`).
+ *
+ * - Prime factors and modulus must be smaller than a compile-time limit.
+ * This is made necessary by the use of fixed-size stack buffers, and
+ * the limit has been adjusted to keep stack usage under 2 kB for the
+ * RSA operations. Currently, the maximum modulus size is 4096 bits,
+ * and the maximum prime factor size is 2080 bits.
+ *
+ * - The RSA functions themselves do not enforce lower size limits,
+ * except that which is absolutely necessary for the operation to
+ * mathematically make sense (e.g. a PKCS#1 v1.5 signature with
+ * SHA-1 requires a modulus of at least 361 bits). It is up to users
+ * of this code to enforce size limitations when appropriate (e.g.
+ * the X.509 validation engine, by default, rejects RSA keys of
+ * less than 1017 bits).
+ *
+ * - Within the size constraints expressed above, arbitrary bit lengths
+ * are supported. There is no requirement that prime factors or
+ * modulus have a size multiple of 8 or 16.
+ *
+ * - When verifying PKCS#1 v1.5 signatures, both variants of the hash
+ * function identifying header (with and without the ASN.1 NULL) are
+ * supported. When producing such signatures, the variant with the
+ * ASN.1 NULL is used.
+ *
+ * ## Implementations
+ *
+ * Three RSA implementations are included:
+ *
+ * - The **i32** implementation internally represents big integers
+ * as arrays of 32-bit integers. It is perfunctory and portable,
+ * but not very efficient.
+ *
+ * - The **i31** implementation uses 32-bit integers, each containing
+ * 31 bits worth of integer data. The i31 implementation is somewhat
+ * faster than the i32 implementation (the reduced integer size makes
+ * carry propagation easier) for a similar code footprint, but uses
+ * very slightly larger stack buffers (about 4% bigger).
+ *
+ * - The **i15** implementation uses 16-bit integers, each containing
+ * 15 bits worth of integer data. Multiplication results fit on
+ * 32 bits, so this won't use the "widening" multiplication routine
+ * on ARM Cortex M0/M0+, for much better performance and constant-time
+ * execution.