PBKDF2-HMAC-SHA2 test vectors

Asked 26/2, 2011 at 23:48 Answered 29/12, 2020 at 10:34

There are test vectors for PBKDF2-HMAC-SHA1 in RFC6070. There are test vectors for HMAC-SHA2 in RFC4231.

But so far I haven't found test vectors for PBKDF2-HMAC-SHA2 anywhere.

I'm most interested in SHA256, so I'll post some vectors I calculated with my implementation. I'd be happy if someone could verify/confirm them, or contribute their own.

Ecru answered 26/2, 2011 at 23:48 Comment(1)

You might consider writing an RFC that describes how to use PBKDF2-HMAC-SHA256 in RFC 2898, and includes the test vectors also. You should do it for all the SHA2 hashes. – Systemic 27/2, 2011 at 17:13

I implemented PBKDF2 using the standard hashlib and hmac modules in Python and checked the output against both the RFC 6070 vectors and the vectors you posted – it matches.

Here are the vectors I get with a larger dkLen to match the larger digest output size. This is the output of pbkdf2-test-vectors.py sha256, which takes about 10 minutes to run.

PBKDF2 HMAC-SHA256 Test Vectors

Input:
  P = "password" (8 octets)
  S = "salt" (4 octets)
  c = 1
  dkLen = 32

Output:
  DK = 12 0f b6 cf fc f8 b3 2c
       43 e7 22 52 56 c4 f8 37
       a8 65 48 c9 2c cc 35 48
       08 05 98 7c b7 0b e1 7b (32 octets)


Input:
  P = "password" (8 octets)
  S = "salt" (4 octets)
  c = 2
  dkLen = 32

Output:
  DK = ae 4d 0c 95 af 6b 46 d3
       2d 0a df f9 28 f0 6d d0
       2a 30 3f 8e f3 c2 51 df
       d6 e2 d8 5a 95 47 4c 43 (32 octets)


Input:
  P = "password" (8 octets)
  S = "salt" (4 octets)
  c = 4096
  dkLen = 32

Output:
  DK = c5 e4 78 d5 92 88 c8 41
       aa 53 0d b6 84 5c 4c 8d
       96 28 93 a0 01 ce 4e 11
       a4 96 38 73 aa 98 13 4a (32 octets)


Input:
  P = "password" (8 octets)
  S = "salt" (4 octets)
  c = 16777216
  dkLen = 32

Output:
  DK = cf 81 c6 6f e8 cf c0 4d
       1f 31 ec b6 5d ab 40 89
       f7 f1 79 e8 9b 3b 0b cb
       17 ad 10 e3 ac 6e ba 46 (32 octets)


Input:
  P = "passwordPASSWORDpassword" (24 octets)
  S = "saltSALTsaltSALTsaltSALTsaltSALTsalt" (36 octets)
  c = 4096
  dkLen = 40

Output:
  DK = 34 8c 89 db cb d3 2b 2f
       32 d8 14 b8 11 6e 84 cf
       2b 17 34 7e bc 18 00 18
       1c 4e 2a 1f b8 dd 53 e1
       c6 35 51 8c 7d ac 47 e9 (40 octets)


Input:
  P = "pass\0word" (9 octets)
  S = "sa\0lt" (5 octets)
  c = 4096
  dkLen = 16

Output:
  DK = 89 b6 9d 05 16 f8 29 89
       3c 69 62 26 65 0a 86 87 (16 octets)

Matinee answered 27/2, 2011 at 23:47 Comment(12)

I was able to reproduce all your results correctly in JavaScript using the SJCL library. – Arty 18/8, 2011 at 9:20

As well as varying the output size, it might be necessary to extend the input size in test case 5 to have the same effect as the RFC test vectors - passwordPASSWORDpassword at 24 octets exceeded the output size of the SHA1 output, but doesn't exceed the size of your SHA256 output. It's possible this misses some codepaths the RFC test vectors follow - although probably not; I suspect the password would have to exceed the 64-byte block size to make a difference in either case. – Pricket 9/9, 2011 at 14:6

Thanks so much for posting test vectors! Can you post one with 64 or more bytes? – Waftage 11/4, 2013 at 20:6

Almsot forgot: I was able to replicate yours with an implementation I did based on the RFC – Waftage 11/4, 2013 at 21:1

Encoding is one source for incompatibilities. Personally I prefer using UTF-8 bytes. – Nighttime 30/10, 2013 at 2:6

Confirmed using the Java PBKDF2 functionality. – Circumscription 15/9, 2015 at 0:40

Warning: the "default" character encoding of PBKDF2 is UTF-8. You may want to test special characters as well. Java would fail that because it only complies with Windows-1252 (ASCII + 128 special characters). – Circumscription 15/9, 2015 at 0:48

@MaartenBodewes Java uses "Unicode" (actually UTF-16) for Strings and chars, and supports hundreds of encodings to/from bytes for I/O and similar things like crypto. The default encoding varies; for Windows it is (usually?) cp1252 but other platforms are different. For crypto exactly reproducible data is vital so you should use an explicit encoding not the default, typically UTF-8 to support the broadest data, especially here where 2898 recommends (but doesn't require) UTF-8. – Proliferous 15/9, 2015 at 14:48

@Proliferous I know that, but the PBKDF2 implementation only uses the lower 8 bits of the char values in the char[] (because of security considerations). This maps more or less to Windows-1252, though I would strongly recommend to keep to ASCII for Java. – Circumscription 15/9, 2015 at 14:54

Confirmed using OpenSSL::PKCS5 in Ruby. See this gist. – Dyson 30/3, 2016 at 21:39

Did anyone consider putting this into an RFC, yet? – Noisemaker 20/11, 2017 at 9:0

Find test vectors here: datatracker.ietf.org/doc/html/rfc7914#section-11 – Ensign 22/11, 2021 at 22:34

Test vectors for PBKDF2-HMAC-SHA256:

Input values were taken from RFC6070; c is the number of rounds.

Input:
 P = "password" (8 octets)
 S = "salt" (4 octets)
 c = 1
 dkLen = 20
Output:
 DK = 12 0f b6 cf fc f8 b3 2c 43 e7 22 52 56 c4 f8 37 a8 65 48 c9


Input:
 P = "password" (8 octets)
 S = "salt" (4 octets)
 c = 2
 dkLen = 20
Output:
 DK = ae 4d 0c 95 af 6b 46 d3 2d 0a df f9 28 f0 6d d0 2a 30 3f 8e


Input:
 P = "password" (8 octets)
 S = "salt" (4 octets)
 c = 4096
 dkLen = 20
Output:
 DK = c5 e4 78 d5 92 88 c8 41 aa 53 0d b6 84 5c 4c 8d 96 28 93 a0


Input:
 P = "password" (8 octets)
 S = "salt" (4 octets)
 c = 16777216
 dkLen = 20
Output:
 DK = cf 81 c6 6f e8 cf c0 4d 1f 31 ec b6 5d ab 40 89 f7 f1 79 e8


Input:
 P = "passwordPASSWORDpassword" (24 octets)
 S = "saltSALTsaltSALTsaltSALTsaltSALTsalt" (36 octets)
 c = 4096
 dkLen = 25
Output:
 DK = 34 8c 89 db cb d3 2b 2f 32 d8 14 b8 11 6e 84 cf
      2b 17 34 7e bc 18 00 18 1c


Input:
 P = "pass\0word" (9 octets)
 S = "sa\0lt" (5 octets)
 c = 4096
 dkLen = 16
Output:
 DK = 89 b6 9d 05 16 f8 29 89 3c 69 62 26 65 0a 86 87

Ecru answered 26/2, 2011 at 23:55 Comment(6)

I think dkLen = 20 reflects the digest size, so for SHA-256 you should use 32. dkLen = 25 should be larger than the digest size, so that it covers the code path dealing with multiple T blocks; maybe 40. – Matinee 27/2, 2011 at 21:23

@aaz: No. dkLen is the Derived Key Length. The digest size is specified in the algorithm by hlen which isn't an input to the PBKDF2 function directly... – Coomer 7/3, 2011 at 1:29

@Coomer – Yes. I meant that the dkLen for the testcases was chosen to match the hLen of the PRF being used. So when adapting the testcases for a different PRF the dkLen should be adjusted. – Matinee 7/3, 2011 at 1:58

dkLen < 32 is a valid test, but dkLen >= 32 would help a lot since if it's under 32, it'll just crop off the extra octets – Waftage 11/4, 2013 at 19:52

There should be at least a test > 32. On the other hand, I've got no problem replicating the above test values. – Circumscription 15/9, 2015 at 0:47

Good for testing a key length that is greater then hLen. ``` Input: P = "password" (8 octets) S = "salt" (4 octets) c = 4096 dkLen = 100 Output: DK = c5 e4 78 d5 92 88 c8 41 aa 53 0d b6 84 5c 4c 8d 96 28 93 a0 01 ce 4e 11 a4 96 38 73 aa 98 13 4a f7 ad 98 c1 b4 58 ce 3f d7 4c a3 5b eb a3 cd a7 b8 d1 03 8d 6a 87 07 1b 91 8f 83 74 05 f3 fe 77 28 ff e7 f0 97 6f c3 5d d8 2f c0 e5 e4 6c e9 ce 26 a7 88 b2 c7 d1 83 fa 5b f8 d9 60 7e ec d7 1d 01 b4 f1 19 ``` – Hazardous 30/1, 2019 at 23:20

I should probably finally post what I did awhile ago based on this very question!

At my Github repository, I have compiled test vectors for

PBKDF2-HMAC-SHA-512
PBKDF2-HMAC-SHA-384
PBKDF2-HMAC-SHA-256
PBKDF2-HMAC-SHA-224
PBKDF2-HMAC-SHA-1 And for the crazy or those with ancient systems without even SHA-1 support:
PBKDF2-HMAC-MD5

Tests started with RFC6070 and those in the answer by @ChristianAichinger above for PBKDF2-HMAC-SHA-256, and added a few dozen more to implement more stringent tests, such as boundary conditions around certain sizes of password and salt (15/16/17 bytes, 63/64/65 bytes, 127/128/129 bytes, 1025 bytes etc.), large iteration counts, large output size counts, and so on and so forth.

I then gathered up many instances of PBKDF2, and validated these test vectors against every major implementation I was able to find (all also included in the above repository, sometimes including Windows MinGW executables and generally including Linux compilation instructions), including

Python (hashlib)
Python (warner's custom code)
C (OpenSSL)
C (PolarSSL)
C++ (Cryptopp)
.NET 4.5 (@Jither's DeriveBytes)
SQL Server (custom code, PBKDF2-HMAC-SHA-1 and PBKDF2-HMAC-SHA-512 only right now)

Given that I'm seeing identical results across 7 implementations using 5 different languages using multiple major cryptographic libraries, I'm extremely confident that not only are the test vectors provided accurate, but that the implementations provided can be used as a set to validate any other test vector set desired. If they all agree, then it's correct.

Paramour answered 20/1, 2018 at 5:36 Comment(2)

I think people would find your test vectors a lot more useful if you distributed them in a more easily accessible format than an ODS spreadsheet – I think JSON format would be the ideal. – Justifiable 22/11, 2020 at 10:5

The test vectors can be found in pbkdf2_test.sh at github.com/Anti-weakpasswords/PBKDF2-GCC-OpenSSL-library or any of the related PBKDF2 implementation repositories. The ODS spreadsheet is explicitly to generate test vectors; feel free to write up =CONCATENATE statements for JSON or any other output you like. – Paramour 21/11, 2022 at 4:1

As part of RFC-7914 (scrypt specifications) there are test vectors provided for PBKDF2 with HMAC-SHA-256 (since scrypt uses PBKDF2 internally).

Here they are:


   PBKDF2-HMAC-SHA-256 (P="passwd", S="salt",
                       c=1, dkLen=64) =
   55 ac 04 6e 56 e3 08 9f ec 16 91 c2 25 44 b6 05
   f9 41 85 21 6d de 04 65 e6 8b 9d 57 c2 0d ac bc
   49 ca 9c cc f1 79 b6 45 99 16 64 b3 9d 77 ef 31
   7c 71 b8 45 b1 e3 0b d5 09 11 20 41 d3 a1 97 83

   PBKDF2-HMAC-SHA-256 (P="Password", S="NaCl",
                        c=80000, dkLen=64) =
   4d dc d8 f6 0b 98 be 21 83 0c ee 5e f2 27 01 f9
   64 1a 44 18 d0 4c 04 14 ae ff 08 87 6b 34 ab 56
   a1 d4 25 a1 22 58 33 54 9a db 84 1b 51 c9 b3 17
   6a 27 2b de bb a1 d0 78 47 8f 62 b3 97 f3 3c 8d

Interestingly, dkLen goes over 32 (the size of a SHA-256 block), so it does test that the concatenation of the intermediate hash blocks works.

Enriqueenriqueta answered 29/12, 2020 at 10:34 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags