CFB1 vs CFB8 vs CFB128 is feedback size, not key size
The number after CFB is a feedback step, not a key length: CFB1, CFB8 and CFB128 use a 128-bit block. Read legacy names without inventing weak keys.
A name such as AES-256-CFB1 carries two numbers, and they answer different questions. The 256 is the AES key length. The 1 is the CFB feedback, or segment, size, a property of how the mode advances its state. Read as if the 1 were a key length, the name looks like a catastrophic misconfiguration, which is why the question keeps coming back.
Decide which of three quantities you are looking at before judging the name: key size, block size, or segment size. Only the first is a security parameter in the usual sense.
Three numbers, three quantities
AES accepts 128, 192 or 256-bit keys and has a 128-bit block whichever you choose. The block size belongs to AES, not to the mode. The CFB suffix is the third quantity: how much data the mode consumes and feeds back per step. The OpenSSL AES documentation lists those shift sizes explicitly for the CFB variants.
CFB1 feeds back one bit at a time, CFB8 one byte, CFB128 a full block. All three use the same 128-bit block cipher internally; what changes is how many bits of each computed block are used per operation. That is why the suffix moves cost and buffering behaviour rather than key strength.
| Name | Key | AES block | Feedback |
|---|---|---|---|
| AES-256-CFB1 | 256 bits | 128 bits | 1 bit |
| AES-256-CFB8 | 256 bits | 128 bits | 8 bits |
| AES-256-CFB128 | 256 bits | 128 bits | 128 bits |
Why the block size never changes
AES is a block cipher with a fixed 128-bit block, and modes are constructions built around it. None of them shrink the block to match the segment size. A CFB1 implementation still computes a full AES block and takes one bit of the result. The other bits are discarded for that step, which is exactly where the efficiency cost lives.
So a one-bit feedback does not imply a one-bit key, and a name cannot be ranked by its suffix. CFB128 is not four times stronger than CFB32; it processes larger segments.
What the segment size actually changes
Segment size changes how much ciphertext is fed back per step and how much plaintext each step can carry. It also changes error propagation and buffering behaviour, which matters for stream-like use. Byte-oriented segments line up with buffers, bit-oriented ones do not.
In practice the protocol chooses the mode, not the operator. A VPN data channel uses the construction its protocol specifies, with its own integrity protection, and a library listing only tells you which names exist.
Reading an unqualified CFB label
An unqualified CFB label needs its implementation context. In the OpenSSL 1.0.2 headers, EVP_aes_128_cfb is a macro for EVP_aes_128_cfb128, with matching aliases for 192 and 256-bit keys. That is an API naming convention from one branch, not a claim that every library, file format or GUI expands the abbreviation the same way. Check the header or documentation for the version in front of you.
If a legacy profile says CFB and the peer accepts it, the negotiated parameters are recorded somewhere: a log, a configuration dump, an API response. Read those instead of inferring the segment size from a display string.
What a mode name does not tell you
The name describes encryption behaviour and nothing else. A VPN still needs integrity protection, key derivation and peer authentication, and CFB supplies none of them. Swapping CFB8 for CFB1 is not a cosmetic change either: the wire behaviour differs and both peers must support the same construction. Nor does a name in a library prove the deployed gateway accepts it for its data channel.
For anything maintained, use the protocol's complete protection arrangement and the operator's policy, and record library and gateway versions, the exact option and the negotiated result. The old name explains what you are reading; it does not justify reviving the configuration.