Description
Users have been having trouble with variable block sizes in practice. The problem is the implementation, and I think the root cause is a bad fit under the current library design. Reported problems on the mailing list include Threefish-1024 IV specification issue/documentation...or bug?
The bigger engineering problem is, variable block ciphers are a bad fit under the current design. We specify security parameters, like min and max key length and iv length, as template parameters. Later we rely on virtual functions and dynamic dispatch to override the default template parameters. Worse, users have to specify the block size they want through a Name::BlockSize parameter because a constructor is not available to take the block size (the SetKey(byte* key, size_t keylen, unsigned int size) ctor was taken for variable rounds). The design makes the interface a bit fragile and introduces subtle breaks, It also makes the existing interfaces harder to use correctly.
We are going to remove the support we added under Issue 408, Add support for variable block sizes. The same algorithms will still be available, but they will need a class for each block size. For example, instead of Threefish we will offer a class with the block size in the name:
Threefish256Threefish512Threefish1024
This issue will track removal.
The thing that really bothers me about this one is, the fellow who posted on the mailing list used the library as advertised. He did the same thing folks have been doing for 25 years when using block ciphers. But because of the extra gyrations required for the variable block size, he did not arrive at the correct result. I'm not going to tolerate 25 years of user troubles.
Activity