Skip to main content
Version: 0.1.24

AES OFB

AES OFB (Output Feedback) turns the block cipher into a keystream generator: the IV (or the previous keystream block) is encrypted repeatedly to produce the next 16 bytes of keystream, which are XORed with the plaintext. The keystream does not depend on the plaintext or ciphertext, so encryption and decryption are symmetric. No padding is required. Processing is sequential—there is no random access to the keystream.

How it works:

  • The IV is encrypted to produce the first keystream block.
  • That keystream block is XORed with the first 16 bytes of plaintext to produce ciphertext.
  • The same keystream block (not the ciphertext) is encrypted again to produce the next keystream block, and so on.
  • Decryption uses the same keystream: XOR ciphertext with the same keystream to recover plaintext.

Security implications:
OFB provides confidentiality when the IV is unique. Reusing (key, IV) for two messages allows an attacker to recover plaintext by XORing the two ciphertexts. OFB does not provide authentication; add an AEAD or Encrypt-then-MAC for integrity. OFB is less common than CTR; use it only when required by a specification or legacy system.

Recommended use cases:

  • Legacy or protocol compatibility when OFB is mandated.
  • Streaming encryption where a feedback-based mode is required and CTR is not an option.

Prefer AES-GCM, AES-CTR (with MAC), or ChaCha20-Poly1305 for new designs; use OFB only for compatibility.

When to use​

  • Streaming encryption where you need a feedback-based mode (e.g. legacy or protocol compatibility). OFB turns the block cipher into a keystream generator; the keystream is then XORed with the plaintext.

What to be careful of​

  • IV must be unique. Reusing (key, IV) for two messages allows an attacker to recover plaintext by XORing ciphertexts. Use a unique IV per encryption.
  • No authentication. OFB does not detect tampering. Add an AEAD or Encrypt-then-MAC if integrity matters.
  • Sequential. Keystream is generated sequentially; no random access. Prefer CTR if you need random access or simpler semantics.
  • Rarely preferred. CTR is more common and often better supported; use OFB only when required by a spec or legacy system.

Practical deployment​

  • Prefer AES-GCM, AES-CTR (with MAC), or ChaCha20-Poly1305 for new designs. Use OFB only for compatibility.
  • If you use OFB: (1) use a unique 16-byte IV per encryption; (2) add authentication (Encrypt-then-MAC) and verify before decrypting; (3) document the mode clearly for maintainers.

API​

noxtls_aes_encrypt_ofb​

noxtls_return_t noxtls_aes_encrypt_ofb(const uint8_t* key, const uint8_t* data, uint32_t data_len, const uint8_t * iv, uint8_t* output, noxtls_aes_type_t type);

AES Encrypt in OFB Mode Output Feedback mode: The keystream is generated by repeatedly encrypting the IV (or previous keystream). The keystream is XORed with the plaintext. Supports arbitrary-length data.

Parameters:

  • key — is a pointer to the encryption key
  • data — is a pointer to the plaintext to be encrypted
  • data_len — is the length of the plaintext in bytes
  • iv — is the Initialization Vector (16 bytes). Required.
  • output — is the output buffer where the encrypted plaintext will be placed
  • type — is the AES variant, 128, 192, 256

Returns: noxtls_return_t: NOXTLS_RETURN_SUCCESS on success; otherwise a specific return code.