On Apr 18, 11:35 am, jerry <[email protected]> wrote: > Some additional thoughts about this issue. In the PKCS_EncryptionPadding > Scheme::Unpad() function, it appears that the PKCS#1 padding algorithm first > determines if the bit length of the block is not modulo 8, then it expects > the first byte of the cryptogram to be 0x00. If the bit length is mod 8, > then it expects the first byte to be 0x02. > > In my case, since the bit length is 1024 (128 bytes), the first byte should > be 0x02, which is what I get. Can anyone confirm that an even byte-length > cryptogram when decrypted should have the first byte be 0x02 in all cases? I > have already hacked the solution to assume the first 0x00 is missing and > that the first byte must be 0x02, but I want to make sure I'm not taking > advantage of an accidental coincidence; rather, I hope that because the bit > length mod 8 is 0, that the initial first byte should be 0x02. > > PKCS_EncryptionPaddingScheme::Unpad(const byte *pkcsBlock, size_t > pkcsBlockLen, byte *output, const NameValuePairs > <http://www.cryptopp.com/docs/ref/class_name_value_pairs.html> ¶meters) > const00054 {00055 bool invalid = false;00056 size_t > maxOutputLen = MaxUnpaddedLength > <http://www.cryptopp.com/docs/ref/class_p_k_c_s___encryption_padding_s...>(pkcsBlockLen);00057 > 00058 // convert from bit length to byte length00059 if > (pkcsBlockLen % 8 != 0)00060 {00061 invalid = > (pkcsBlock[0] != 0) || invalid;00062 pkcsBlock++;00063 > }00064 pkcsBlockLen /= 8;00065 00066 // Require block type > 2.00067 invalid = (pkcsBlock[0] != 2) || invalid;00068 00069 > // skip past the padding until we find the separator00070 size_t > i=1;00071 while (i<pkcsBlockLen && pkcsBlock[i++]) { // null > body00072 }00073 assert(i==pkcsBlockLen || > pkcsBlock[i-1]==0);00074 00075 size_t outputLen = pkcsBlockLen - > i;00076 invalid = (outputLen > maxOutputLen) || invalid;00077 > > Thanks for any confirmation of my code reading.
Shooting from the hip (and if I recall correctly)...... CalculateInverse uses Integers (ie, the class) so it is dropping what it believes to be non-significant leading null bytes. Jeff -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com.
