Parameters/gcryctl to digest algorithms?
wk at gnupg.org
Tue Mar 25 13:11:02 CET 2014
On Tue, 25 Mar 2014 08:20, dbaryshkov at gmail.com said:
> I'm adding 10 more, and there might be even more in future. I planned
> to use gcry_cipher_ctl to select s-box for the symmetric cipher.
> Is it a suitable solution?
I would agree to ctl codes if they are used to install S-boxes from the
applications. However, that raises a couple of other problems and I
doubt that this is a save on memory or cycles. Also you would need two
identifiers to select a particular algorithm.
> gcry_md_ctl to select s-box? I'm particularly concerned about
> MAC algorithms, because there I would need one algo number
> for each 34.11-94 S-BOX (there are 2 currently, 1 being
What is the problems. We have at least 65535 algorithm numbers and if we
take advantage of the used int and the requirement for a 32 bit platform
there are actually 2^31 algorithm ids. Where do you see the problems?
You need more reserved space? Would 0x400 .. 0x4ff be enough? After
all the s-boxes needs to be part of the code. I also believe that we
should only add s-boxes which are in real use or expected to be used
Obviously it does not make sense to have a macro for each variant but a
specification which reserves a range along with a base id does the job.
Switch statements listing all algorithms would only list the base ID
and the compiler would be happy.
The only overhead I can see is that looking up the algorithm is a tiny
bit slower - but that is invisible compared to the actual cycles the
Now, if the design of the cipher considers s-boxes similar to a key, we
need to account for that and add an API to install an s-box into a
> much to clobber algo space, thus I'd like to use
> gcry_mac_ctl at least for "imitiovstavka" MAC algo.
I see no reason why we should not do the same with MAC algos. Now it
is still time to somehow sync the MAC algo numbers with the Hash algo
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gcrypt-devel