DSTU7624 partial blocks support

[tonywasher]

Hi
I note that the new KCCM and KGCM Modes for DSTU7624 only work on whole data blocks and throw an exception if partial blocks are used.

Are there any plans to remove this restriction?

It is very restrictive on the use of these modes and also impacts on the use of KGMac and DSTU7624Mac, which also only work on whole blocks

[peterdettman]

Yes, we're aware of the issue and plan to add partial block support when we can; it's how the original submission came to us. Also, excepting perhaps KGMAC, we've been unable to find appropriate test vectors (for partial block inputs), so if you can suggest a source for these it would be a big help. We can reasonably infer how it's supposed to work, but that's not really enough.

[tonywasher]

Unfortunately I have no access to specifications or test vectors. As you say it is easy to infer how it is supposed to work, and I have in fact built extensions along these lines in a BC fork on GitHub (if you're interested). I did find several separate problems in the KCCM implementation, which occur even in the full block situation.

The most interesting one was the use of counter, which is initialised and reset but never changed, and which I assume was intended to be incremented on each block as per CTR mode.

[peterdettman]

Yeah, the KCCM counter looks wrong, since CCM should be using the block cipher in CTR mode. That must mean that some of the test vectors are wrong also, so we'll need to review it all.

I found your branch with the KGCM changes, thanks. Am I reading it right that a final partial block is simply padded with zeros for input to the MAC? Do you know if that interoperates with any other implementation? I ask because I have this vague notion that the GMAC padding should be a 1 bit followed by 0s, but I am unsure exactly where I read that.

[tonywasher]

Yes, that is the implementation I chose.

I have (now) had a quick look at the GCM implementation, and for partial blocks, it simply stops the Xor operations as soon as it hits the end of the buffer, which has the same effect as padding with zeros. I believe that it therefore mirrors GCM and that I lucked out!!

The 1-bit followed by zeros is found in the Poly1305Mac, and is the padding that I arbitrarily chose for the DSTU7624Mac in the absence of the specification.

[tonywasher]

Small correction. Poly1305 is a 0x01 byte followed by zeroes. CMac is a 0x80 byte followed by zeroes (ISO7816d4 padding)

[lonewasp]

KGCMBlockCipher.CalculateMac works incorrectly for not BlockSize aligned data on decryption (MAC check fails). Most likely last "incomplete" block is processed with portion of MAC suffix, while on encryption it is filled with zeroes.

[dghgit]

We've tried to draw a line under this as best "makes sense" - in the absence of formal test vectors we cannot do much more. Partial block support for the cipher modes has been added. Changes on https://www.bouncycastle.org/betas