Padding PlainText

[dangvohoanganhvn]

Hi Michael

bool encrypt(uint8_t *dst, size_t &ioDstLen, uint8_t *src, size_t srcLen, size_t srcFrontMargin) override
	{
		if(srcFrontMargin > srcLen)
			return false;

		src += srcFrontMargin;
		srcLen -= srcFrontMargin;
		memset(src + srcLen, 0xff, 16); // pad end of packet
		srcLen += 16;
		uint16_t cksum = in_cksum(src, srcLen) + (m_complete ? m_txSalt : 0);
		src[srcLen++] = cksum >> 8;
		src[srcLen++] = cksum & 0xff;

Why dont use varied size as CBC encrypt ? Is that your intention or a bug

[zenomt]

note: the source you pasted above is from the PlainCryptoAdapter, not the FlashCryptoAdapter. the PlainCryptoAdapter is only meant for testing; it is not intended for any real use because it doesn't do any actual cryptography. see the last paragraph of the "Cryptography Adapter" section of the main README. here always adding 16 bytes of "padding" is to test the padding consumer in the RTMFP packet parser.

if you look at the FlashCryptoAdapter, you'll see that it implements the cryptography profile defined in RFC 7425, including AES-128-CBC. the length of a CBC is always a multiple of the underlying block cipher's block size, so padding must always be accommodated. we designed this padding scheme to avoid potentially wasting an entire block on padding (which PKCS#7 would have done) if the plain packet ended up being a multiple of the block size. RTMFP itself supports padding (see Section 2.2.4 of RFC 7016), and the cipher definition of the Flash Cryptography Profile takes advantage of this (see Section 4.7.2 of RFC 7425).

TL;DR: this is intended, and follows Section 4.7.2 of RFC 7425.