New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove variable block size support for block ciphers #535
Labels
Comments
noloader
added a commit
to noloader/cryptopp
that referenced
this issue
Nov 17, 2017
noloader
added a commit
that referenced
this issue
Nov 18, 2017
noloader
added a commit
that referenced
this issue
Nov 18, 2017
Algorithm name was returning " Threefish-32(32)" instead of "Threefish-256(256)"
This was referenced Jan 4, 2018
noloader
added a commit
that referenced
this issue
Jan 19, 2018
noloader
added a commit
that referenced
this issue
Jan 19, 2018
noloader
added a commit
that referenced
this issue
Feb 18, 2018
noloader
added a commit
that referenced
this issue
Jul 2, 2018
This should have occured when we yanked the variable block size experiment
noloader
added a commit
that referenced
this issue
Oct 14, 2018
This should have been removed around January 2018 with the other functions.
noloader
added a commit
that referenced
this issue
Oct 14, 2018
This should have been removed around January 2018 with the other functions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 (theSetKey(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:Threefish256
Threefish512
Threefish1024
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.
The text was updated successfully, but these errors were encountered: