Shulou(Shulou.com)06/01 Report--

The problem of getting bigger after encryption

Anyone who has done    encryption should have the experience of "files get bigger after encryption". Bigger is bigger, for daily use and APP development or server development, a few kilobytes is fine, but if you are using RF (radio frequency) communication, then a few bytes will lead to an increase in communication failure rate, so for such a scenario, you need to make sure that ciphertext is as long as plaintext, preferably shorter.

   because the shorter point is the work of the compression algorithm, which has nothing to do with the encryption algorithm itself, we will not analyze it here. Today we take the command line tool of openssl as an example to learn how to ensure that the ciphertext length is equal to the plaintext length.

Why is the ciphertext longer than the plaintext?

Why does    grow on the side after encryption? To be safer! So where did it grow to be safer?

1. Grow in filling

two。 Grow up in salt

The main purpose of    filling is to solve the problem of packet encryption, and the length of plaintext is not an integer multiple of the packet. In order to simplify the filling rule, if the plaintext is a multiple of the packet, fill an entire packet.

The image above is an encrypted sample of aes-128-cbc with plaintext of 128bits, filled with an entire 128bits padding block.

   salt is a random factor generated by secret key and IV. In order to solve the problem of generating the same ciphertext with the same plaintext and secret key, because salt must participate in the operation, salt is usually spliced at the front of the plaintext in the form of plaintext. Salt is usually 16 bytes in length, the first 8 bytes is a fixed magic number, and the last 8 bytes are random numbers. In this way, the ciphertext with salt will add at least one plaintext header message with a length of 16 bytes.

The figure above is a sample output with salt and plaintext of one byte and ciphertext of 161byte.

How to control the length of ciphertext and plaintext?

Since the growth of    is caused by padding and salt, to ensure the same length, you need to remove padding and salt. Of course, the premise of removing padding requires that the length of plaintext is a multiple of the packet, otherwise the encryption will report an error.

The above image is a screenshot of nopad and nosalt. We are looking at a comparison image, as follows:

Special warning to be careful of the parameters of-a

  -an in the parameter in openssl is to encrypt or decrypt the result of the base64 processing, if it is encryption is base64 encoding, and vice versa is decoding. Base64 encodes key input characters with less than 3 bytes into 4 bytes. If you accidentally use this option, you will find that the ciphertext length is filled up a lot.

   important things said three times, using-a will be longer! If you use-a, it will get longer! If you use-a, it will get longer!

Further recommendation of learning materials

   uses openssl to encrypt AES

   uses openssl to do SSL/TLS/HTTPS experiment

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.