> The immediate pain point is the class constant BLOCKSIZE, which becomes a
> moving target. That could be worked around with MINIMUM_BLOCKSIZE,
> MAXIMUM_BLOCKSIZE, and making BLOCKSIZE a sane default, similar to the way
> keys are described. Or, we could signal that Blocksize() must be used by
> making BLOCKSIZE equal to 0xffffffff.
>
This is a little trickier than I expected. A cipher in a vacuum has a few
uncomfortable places like above. A cipher with a mode is where the pain
lies:
// 128-bit key, 256-bit blocksize
AlgorithmParameters params = MakeParameters
(Name::BlockSize(),
32)
(Name::IV(),
ConstByteArrayParameter(iv, 32));
CBC_Mode<Kalyna>::Encryption enc; // Line 1
enc.SetKey(key, 16, params); // Line 2
On mode construction (line 1), CBC_Mode (and other modes) size some buffers
based on the block cipher's blocksize. The problem is, the key (and other
parameters) have not been set (line 2), so the blocksize is mostly unknown.
You can see it by tracing calls to ResizeBuffers() in modes.h
(https://github.com/weidai11/cryptopp/blob/master/modes.h).
I think we can work around it by using a lazy resize strategy in the mode,
but I'm concerned about how deep it could cut.
Does anyone have any thought or opinions on it?
Jeff
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
