[botan-devel] PKCS5_PBKDF2::derive_key() length check

Maricel Gregoraschko maricelgregoraschko at yahoo.com
Sat Apr 4 01:06:42 EDT 2015

Hi Jack,I'm sorry for the false alarm, I somehow hadn't noticed the "min", I was looking at a very similar piece of code, and had some heap corruption at the same time that I automatically blamed on derive_key() without further checking; that corruption turned out to be because of using different runtime libraries in the by client app vs the botan lib.
But here is another one for you (same botan version):Botan::Pipe pipeTest(Botan::get_cipher("AES-256/CBC/CTS", aesCipherKey, aesIv, Botan::ENCRYPTION),    //Botan::Pipe pipeTest(Botan::get_cipher("AES-256/CTR-BE", aesCipherKey, aesIv, Botan::ENCRYPTION),        new Botan::DataSink_Stream("d:/test/test.out", true));    pipeTest.process_msg("123456789012345678"); //18 bytes
    pipeTest.process_msg("12345678901234567890"); //20 bytes
You end up with a 56 byte file test.out instead of the expected 38 (18+18+20).Change to CTR-BE and you get 38 bytes.Looking at the code, the problem seems to be a remnant CTS_Encryption::position value that is not reset between messages. Adding position = 0;at the end of CTS_Encryption::end_msg() in cts.cpp fixes it for me.
Thanks for looking!PS: Any thoughts on which random generator class is currently favored, Randpool (as described in the documentation), or HMAC_RNG, which is actually used by AutoSeeded_RNG?Best regards,
      From: Jack Lloyd <lloyd at randombit.net>
 To: botan-devel at randombit.net 
 Sent: Friday, April 3, 2015 11:55 PM
 Subject: Re: [botan-devel] PKCS5_PBKDF2::derive_key() length check
On Mon, Mar 23, 2015 at 04:13:38PM +0000, Maricel Gregoraschko wrote:

> Hi,I'm using the stable version of botan (1.10.9), and looking at
> the source code of PKCS5_PBKDF2::derive_key(), in
> src/pbkdf/pbkdf2/pbkdf2.cpp/pbkdf2.cpp,I notice that  the derived
> key length is not checked to be a multiple of the mac algorithm
> output length. If you pass say 31 for key derived length, it will
> write 32 bytes, last byte into unallocated memory.  Maybe a check
> could be useful (I haven't looked if it was added in the development
> branch). 

Hi Maricel,

Do you have an example that replicates this issue? Looking at
the code I do not see how additional data could be copied, since
the key write is bounded by:

      size_t T_size = std::min<size_t>(mac->output_length(), key_len);

where key_len is, at this point in the code, the remaining bytes to write out.

I also tried to replicate it using:

#include <botan/pbkdf2.h>
#include <botan/sha2_32.h>
#include <botan/hmac.h>
#include <iostream>

int main()
  using namespace Botan;
  PKCS5_PBKDF2 pbkdf(new HMAC(new SHA_256));

  const byte salt[4] = { 0xAA, 0xAA, 0xAA, 0xAA };
  SymmetricKey key = pbkdf.derive_key(31, "foo", salt, sizeof(salt), 1000);
  std::cout << key.as_string() << "\n";

and additionally there are tests in 1.10.9 for PBKDF2 producing a
various 'odd' sized outputs (14, 30, etc byte), neither of which which
do not cause any warnings about overwrites under valgrind on my


botan-devel mailing list
botan-devel at randombit.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/botan-devel/attachments/20150404/7728381a/attachment.html>

More information about the botan-devel mailing list