[botan-devel] Why is max_keylength_of() deprecated and how to avoid using?

William K. Foster wkf at alum.mit.edu
Sat Jul 16 08:02:56 EDT 2011


Hello Jack,

I am not clear on how to get the specific implementation in order to ask it
for the actual key length it will use.

My current code looks something like this:

  Botan::AutoSeeded_RNG _rng;
  const std::string _cipherSpec(getCipherSpec()); // e.g. "AES-256/CBC/CTS"
  const std::string _cipherAlgo(specAlgorithm(_cipherSpec)); //
specAlgorithm is for above example "AES-256" (grabs up to the first slash).
  const bool _isECB(isECBMode(_cipherSpec)); // Whether portion after first
slash is "ECB", so not true for above example where it is "CBC".

  // Here is troubling line which I use to create master symmetric key:
  const unsigned int _keyLength(max_keylength_of(_cipherAlgo)); // In bytes.

  const unsigned int _blockSize(block_size_of(_cipherAlgo)); // In bytes.
  const Botan::SymmetricKey _masterKey(_rng, _keyLength);
  const Botan::InitializationVector _iv(_rng, _isECB ? 0 : _blockSize);
  Botan::Keyed_Filter *_cipherFilter(get_cipher(_cipherSpec, _masterKey,
_iv, ENCRYPTION));
  Botan::Pipe *_pipe(new Pipe(_cipherFilter)); // Encrpytion.

How would I get the specific implementation? What class represents the
specific implementation? What method on the specific implementation provides
the actual key length?

Should I do something like this?

      const BlockCipher* cipher_proto =
global_state().algorithm_factory().prototype_block_cipher(_cipherSpec);
      const u32bit key_len = cipher_proto->maximum_keylength();

Thanks.

-William


On Fri, Jun 24, 2011 at 1:08 PM, Jack Lloyd <lloyd at randombit.net> wrote:

> On Fri, Jun 24, 2011 at 09:04:34AM -0700, William K. Foster wrote:
> >
> > Other than replicating this code, I see no way to avoid this deprecated
> > interface, I do not understand why it should go away.
> >
> > I have a name of algorithm and need its maximum keylength.
>
> The issue is that the result this function is giving you isn't
> necessarily correct. Currently it happens to be correct most of the
> time, but there are several corner cases I know of where it will not
> produce the correct result, and can envision that this will become
> more rather than less common over time.
>
> As an example, the basic implementation of CAST-128 supports keys
> between 11 and 16 bytes long, and Blowfish 1 to 56 bytes long. But
> OpenSSL's supports 1 to 16 bytes for CAST-128, and 1 to 72 for
> Blowfish, and both of these are wrapped in the OpenSSL engine.
> CryptoAPI's RC2 only supports 128 bit keys, where OpenSSL's and the
> core libraries support a range. Etc, etc.
>
> The reason all this is a problem is because you are not really asking
> a question about the algorithm, but the specific implementation you
> are going to try to use. This may be a subset, or in some cases a
> superset, of what the 'official' algorithm definition says is
> supported. So the real solution is to first get a specific
> implementation, then ask it, then use it for whatever you were going
> to use it for.
>
> -J
> _______________________________________________
> botan-devel mailing list
> botan-devel at randombit.net
> http://lists.randombit.net/mailman/listinfo/botan-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20110716/1cd04c36/attachment.html>


More information about the botan-devel mailing list