bs : bytes? start : exact-nonnegative-integer? end : exact-nonnegative-integer?
Equivalent to (subbytes bs start end) if bs is not subsequently mutated, but avoids making a copy.
Some cryptographic operations require a source of cryptographically secure pseudo-random numbers. Some of these, such as generate-cipher-key, are handled at the Racket level and use crypto-random-bytes. Other operations, such as generate-private-key, RSA signing with PSS padding, and many more, use the crypto provider’s internal CSPRNG. This section contains notes on crypto providers’ CSPRNG initialization.
libcrypto The libcrypto foreign library automatically seeds its CSPRNG using entropy obtained from the operating system (as described here).
gcrypt The libgcrypt foreign library seems to perform some default CSPRNG initialization, but I don’t know the details.
nettle The crypto library creates a Yarrow-256 instance and seeds it with entropy obtained from crypto-random-bytes. The instance is reseeded when a certain number of entropy-consuming operations have been performed since the last reseed.
PSS padding for RSA signatures is, in principle, parameterized by the salt length. A standard choice is the length of the digest to be signed. By default, libcrypto uses the maximum possible salt length when signing and infers the salt length when verifying, as documented for EVP_PKEY_CTX_set_rsa_pss_saltlen. See also this discussion. Unfortunately, other libraries do not directly support this behavior and it is nontrivial to work around it. Thus for greater compatibility, this library defines 'pss padding to use the digest length and 'pss* to be the libcrypto-specific behavior.
If ECDSA is used with a digest longer than the bit-length of the curve, gcrypt either fails to correctly truncate the digest or otherwise handles it by default in a way incompatible with libcrypto and nettle. Consequently, this library truncates the digest before passing it to gcrypt for signing.
GCrypt does not expose operations to compute EC and EdDSA public keys from the private keys, so reading a private key in PrivateKeyInfo or OneAsymmetricKey form may fail if the optional public key field is missing.
Sodium provides only “all-at-once” encryption and decryption functions. Consequently, encryption and decryption contexts using sodium ciphers produce no output until cipher-final is called.