A stream cipher operates on streams of plaintext one bit or byte at a time. The output is always the same length as the input. There is no 'decrypt' mode: to decipher just encrypt again with the same key.
[New in v5.0] There are three stream ciphers available in this API: ARCFOUR, Salsa20 and ChaCha20. All operate on input streams of bytes of any length. ARCFOUR uses a key which can be any length (16 or 32 bytes are recommended). Salsa20 and ChaCha20 both require the key to be exactly 16 bytes (128 bits) or 32 bytes (256 bits) and require a unique IV or nonce for each message encrypted with a given key. ChaCha20 also uses an optional 32-bit integer counter. It is up to the user to provide a unique IV and to pass its value separately to the recipient. It is an error to specify a key or IV of the wrong length for Salsa20 or ChaCha20.
| Algorithm | Key length | IV required? | IV length | Counter |
|---|---|---|---|---|
| ARCFOUR (RC4) | any | No | n/a | No |
| Salsa20 | 16/32 bytes | Yes | 8 bytes | No |
| ChaCha20 | 16/32 bytes | Yes | 8/12/16* bytes | Optional* |
* The default counter is zero. The counter is ignored if the IV length is 16 bytes.
[Superseded in v5.0]
In early versions, we used the made-up name "PC1" to describe the ARCFOUR algorithm in order to to avoid proprietary restrictions on the RC4 name.
The old PC1 functions
PC1_Bytes, PC1_Hex and PC1_File
are now superseded by
CIPHER_StreamBytes,
CIPHER_StreamHex and
CIPHER_StreamFile,
respectively, using the more common algorithm name "ARCFOUR".
Note that there are known weaknesses with the ARCFOUR algorithm. [RFC4345] recommends dropping the first 1536 bytes in the keystream. The implementation in this toolkit does not do that. To workaround, prefix your input with 1536 dummy bytes, then throw them away.