The non-padding `0`s are removed too

[xmh0511]

use byte_aes::{Decryptor,Encryptor};
fn main(){
    let key = "c4ca4238a0b923820dcc509a6f75849b".to_string();
    let buf:[u8;4] = [1,0,0,1];
    let mut en = Encryptor::from(&buf[..]);
    let encrypt_buf = en.encrypt_with(&key);
    println!("{encrypt_buf:?}");

    let mut de = Decryptor::from(encrypt_buf);
    let clear_buf = de.decrypt_with(&key);
    println!("{clear_buf:?}");   // [1,1]
}

The result will be [1,1] while the original text is [1,0,0,1].

[omkarium]

@xmh0511 Glad that you pointed it. But this cannot be an issue. Here is the code which removes the zeros. You can find it in the decrypt.rs file.

 // Stich the Vec<u> by removing the padded 0's we have appended during the encryption opertaion
  let stich_bytes = decrypted_bytes.into_iter().filter(|x| *x != 0).collect::<Vec<u8>>();

The reason I am doing this is because we have to remove the padded 0's added in the library.rs file while splitting the vec into chunks of 16 bytes. In most input files, there is no guarantee that you would always get byte count perfectly divisible 16.

Regardless of what I am using for padding, your input variable "let buf:[u8;4] = [1,0,0,1];" won't make a valid String. Because Strings in rust has to be utf-8 valid. The numbers 1 and 0 you used are not valid utf-8 to begin with. If the input you provide is not valid utf-8, then what are you trying to encrypt? Can that be any useful information? Let me know if that makes sense. Thanks

Ps: If your goal is to safely encrypt and decrypt files, then I recommend my other project called rufendec

[xmh0511]

@omkarium Hi, I use this library to encrypt and decrypt pure bytes and send them over tcp/udp, that is, these bytes could be any valid u8 values, not just a valid String, I think this library should cover this common scene(implied by this library's name). Thanks.

BTW, I saw your another project rufendec, if it works on Ecb mode, I think it has the same issue as here since the bytes in a file can be 0.

[omkarium]

@xmh0511 You are right and I should have chosen the name of the library a bit careful. Sorry for that. Your use case is valid though but this library is not provided for network encryption. Regarding my other project, the Ecb mode is relying on the byte-aes library as your might already know and it suffers the same problem. Instead, you can choose to go with GCM mode in Rufendec which does not rely on byte-aes and its much more robust, but still these are only to work on valid utf8 and not your use case.

But still even for your use case I don't see how you would be able to achieve that using block ciphers such ECB or CBC. Maybe you have to look into libraries which implement other modes used in sockets encryption such as stream ciphers (CFB and OFB).

[omkarium]

@xmh0511 I will check if I can replace the padding from zeros to something else and try with your example. If you think of some fix please suggest.

[xmh0511]

The workaround I am using is to encode the bytes through base64 such that the data does not contain 0. However, I think this is not good. Why doesn't byte-aes just use GCM mode as done in Rufendec to process bytes, which can of course process the UTF-8 String?

[xmh0511]

The solution to this issue is to use PKCS7Padding, https://en.wikipedia.org/wiki/Padding_(cryptography)#PKCS#5_and_PKCS#7. The current way is ZerosPadding, which causes this issue.

Zero padding may not be reversible if the original file ends with one or more zero bytes, making it impossible to distinguish between plaintext data bytes and padding bytes.

[xmh0511]

https://github.com/omkarium/byte-aes/pull/2

[omkarium]

@xmh0511 I am closing this issue now. Thanks again.