NaCl: Networking and Cryptography library 
Computer Aided Cryptography Engineering 
ECRYPT II 

Secretkey encryption: crypto_streamC++ interfaceC++ NaCl provides a crypto_stream function callable as follows: #include "crypto_stream.h" std::string k; std::string n; std::string c; size_t clen; c = crypto_stream(clen,n,k); The crypto_stream function produces a clenbyte stream c as a function of a secret key k and a nonce n. The function raises an exception if k.size() is not crypto_stream_KEYBYTES. It also raises an exception if n.size() is not crypto_stream_NONCEBYTES. C++ NaCl also provides a crypto_stream_xor function callable as follows: #include "crypto_stream.h" std::string k; std::string n; std::string m; std::string c; c = crypto_stream_xor(m,n,k); The crypto_stream_xor function encrypts a message m using a secret key k and a nonce n. The crypto_stream_xor function returns the ciphertext c. The function raises an exception if k.size() is not crypto_stream_KEYBYTES. It also raises an exception if n.size() is not crypto_stream_NONCEBYTES. The crypto_stream_xor function guarantees that the ciphertext has the same length as the plaintext, and is the plaintext xor the output of crypto_stream. Consequently crypto_stream_xor can also be used to decrypt.
C interfaceC NaCl provides a crypto_stream function callable as follows: #include "crypto_stream.h" const unsigned char k[crypto_stream_KEYBYTES]; const unsigned char n[crypto_stream_NONCEBYTES]; unsigned char c[...]; unsigned long long clen; crypto_stream(c,clen,n,k); The crypto_stream function produces a stream c[0], c[1], ..., c[clen1] as a function of a secret key k[0], k[1], ..., k[crypto_stream_KEYBYTES1] and a nonce n[0], n[1], ..., n[crypto_stream_NONCEBYTES1]. The crypto_stream function then returns 0. C NaCl also provides a crypto_stream_xor function callable as follows: #include "crypto_stream.h" const unsigned char k[crypto_stream_KEYBYTES]; const unsigned char n[crypto_stream_NONCEBYTES]; unsigned char m[...]; unsigned long long mlen; unsigned char c[...]; crypto_stream_xor(c,m,mlen,n,k); The crypto_stream_xor function encrypts a message m[0], m[1], ..., m[mlen1] using a secret key k[0], k[1], ..., k[crypto_stream_KEYBYTES1] and a nonce n[0], n[1], ..., n[crypto_stream_NONCEBYTES1]. The crypto_stream_xor function puts the ciphertext into c[0], c[1], ..., c[mlen1]. It then returns 0. The crypto_stream_xor function guarantees that the ciphertext is the plaintext xor the output of crypto_stream. Consequently crypto_stream_xor can also be used to decrypt.
Security modelThe crypto_stream function, viewed as a function of the nonce for a uniform random key, is designed to meet the standard notion of unpredictability ("PRF"). For a formal definition see, e.g., Section 2.3 of Bellare, Kilian, and Rogaway, "The security of the cipher block chaining message authentication code," Journal of Computer and System Sciences 61 (2000), 362–399; http://wwwcse.ucsd.edu/~mihir/papers/cbc.html.This means that an attacker cannot distinguish this function from a uniform random function. Consequently, if a series of messages is encrypted by crypto_stream_xor with a different nonce for each message, the ciphertexts are indistinguishable from uniform random strings of the same length. Note that the length is not hidden. Note also that it is the caller's responsibility to ensure the uniqueness of nonces—for example, by using nonce 1 for the first message, nonce 2 for the second message, etc. Nonces are long enough that randomly generated nonces have negligible risk of collision. NaCl does not make any promises regarding the resistance of crypto_stream to "relatedkey attacks." It is the caller's responsibility to use proper keyderivation functions. See Validation regarding safe message lengths. Selected primitivecrypto_stream is crypto_stream_xsalsa20, a particular cipher specified in "Cryptography in NaCl", Section 7. This cipher is conjectured to meet the standard notion of unpredictability.
Alternate primitivesNaCl supports the following secretkey encryption functions:
Beware that several of these primitives have 8byte nonces. For those primitives it is no longer true that randomly generated nonces have negligible risk of collision. Callers who are unable to count 1,2,3,..., and who insist on using these primitives, are advised to use a randomly derived key for each message. Beware that the aes (AESCTR) functions put extra requirements on the nonce: each message actually uses a range of nonces (counting upwards for each 16byte block), and these nonces must not be reused for other messages. Randomly generated nonces are safe. VersionThis is version 2019.03.19 of the stream.html web page. 