QCA
For those Cipher sub-classes that are block based, there are modes that require a full block on encryption and decryption - Cipher Block Chaining mode and Electronic Code Book modes are good examples.
Since real world messages are not always a convenient multiple of a block size, we have to adding padding. There are a number of padding modes that QCA supports, including not doing any padding at all.
If you are not going to use padding, then you can pass QCA::Cipher::NoPadding as the pad argument to the Cipher sub-class, however it is then your responsibility to pass in appropriate data for the mode that you are using.
The most common padding scheme is known as PKCS#7 (also PKCS#1), and it specifies that the pad bytes are all equal to the length of the padding ( for example, if you need three pad bytes to complete the block, then the padding is 0x03 0x03 0x03 ). PKCS#5 padding is a subset of PKCS#7 padding for 8 byte block sizes. For explanation, see http://crypto.stackexchange.com/questions/9043/what-is-the-difference-between-pkcs5-padding-and-pkcs7-padding/9044#9044.
On encryption, for algorithm / mode combinations that require padding, you will get a block of ciphertext when the input plain text block is complete. When you call final(), you will get out the ciphertext that corresponds to the last part of the plain text, plus any padding. If you had provided plaintext that matched up with a block size, then the cipher text block is generated from pure padding - you always get at least some padding, to ensure that the padding can be safely removed on decryption.
On decryption, for algorithm / mode combinations that use padding, you will get back a block of plaintext when the input ciphertext block is complete. When you call final(), you will get a block that has been stripped of ciphertext.
Documentation copyright © 1996-2024 The KDE developers.
Generated on Mon Nov 18 2024 12:15:57 by doxygen 1.12.0 written by Dimitri van Heesch, © 1997-2006
KDE's Doxygen guidelines are available online.