You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To use CFB to make a self-synchronizing stream cipher that will synchronize for any multiple of x bits lost, start by initializing a shift register the size of the block size with the initialization vector. This is encrypted with the block cipher, and the highest x bits of the result are XOR'ed with x bits of the plaintext to produce x bits of ciphertext. These x bits of output are shifted into the shift register, and the process (starting with encrypting the shift register with the block cipher) repeats for the next x bits of plaintext. Decryption is similar, start with the initialization vector, encrypt, and XOR the high bits of the result with x bits of the ciphertext to produce x bits of plaintext, then shift the x bits of the ciphertext into the shift register and encrypt again. This way of proceeding is known as CFB-8 or CFB-1 (according to the size of the shifting).
For comparison, openssl these are aes-128-cfb1 and aes-128-cfb8, and in Python PyCrypto, segment_size:
Trying to port some code which used the Rust OpenSSL crate for CFB in 8-bit mode, first attempt using RustCrypto crates but not yet supported RustCrypto/block-ciphers#28, maybe will switch if it is implemented or to this module if possible.
The text was updated successfully, but these errors were encountered:
I am sorry to see this now. But I don't think cfb1 and cfb8 is a good idea. For the following reason:
This crate has NEVER been conducted. There is no security guarantee.
Less feedback size leads to more times to call function to encrypt or decrypt a block. As an estimate, cfb8 is 16 times slower than cfb128, and cfb1 is another 8 times slower than cfb8. I can't tell you if this can improve security and it is worth or not. But I know that in pure Rust-lang code, they will be really slow.
In the new cryptography practice, AES CFB and OFB are both not recommended. Maybe CTR or GCM are OK. However AEAD might be the best choice now, which hasn't been supported by this crate.
In fact, when I start writing the CFB code, I've considered the custom feedback size problem. At that time I thought it would be very complicate and give up supporting it.
Anyway, I will re-consider this. But I'm not sure whether supporting cfb1 and cfb8 or not. Probably not.
Can aes_frast CFB mode be used with segment sizes other than the block size? From the code https://github.com/KaneGreen/aes_frast/blob/master/src/aes_with_operation_mode.rs#L228 it doesn't appear so:
/// The feedback size is fixed to 128 bits, which is the same as block size.
but this would be useful for streaming, effectively converting the block cipher into a stream cipher. https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Feedback_(CFB)
For comparison, openssl these are aes-128-cfb1 and aes-128-cfb8, and in Python PyCrypto,
segment_size
:Trying to port some code which used the Rust OpenSSL crate for CFB in 8-bit mode, first attempt using RustCrypto crates but not yet supported RustCrypto/block-ciphers#28, maybe will switch if it is implemented or to this module if possible.
The text was updated successfully, but these errors were encountered: