Does this PBKDF2-SHA1 payload hint at a cryptographic security issue?

Question

Blockchain first 16 encrypted bytes, IV, and iter_count – all encoded in Base64:

Yms6xqrzCfFsQadVZ5gQonMtnQAAAAAAAAAAAAAAAAAAAAAQJwAA69tYNg==

Does it looks like “correct” PBKDF2-SHA1 or does AAAAAA… indicate that something was broken?

During the login attemp to blockchain.info I get a response with a base64-encoded payload, that in fact authorizes my encrypted PBKDF2-SHA1 wallet. I have had no success trying to decrypt this (original BCI server/utils). I am absolutely sure that I’m using the correct passphrase (it's written on paper and was used successfully in 2016 and earlier 2017 before application update).

Anyway, the reason I’m asking if this looks like something suspicious and/or broken is that during my other analysis projects I never met a Base64 payload starting with 21 "A":

<Buffer 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c6 aa f3 09 f1 6c 41 a7 55 67 98 10 a2 73 2d 9d f0 b0 39 32 ec e9 96 22 ab 2f 76 ff 6b 2b c5 c9 c1 5a ... >

When I compare that to my other newly created accounts, this seems to be a bit weird, since all other accounts produce payloads with a more random sequence at start… for example 3pV6yxnoKYKjj….

Do those 21 As in that one payload (related to one specific account) point to a security or cryptographic problem?

Answer 1

So lets take a look at this in hex:

626B3A C6AAF309F16C41A755679810A2732D9D 00000000000000000000000000000000 10270000 EBDB5836

This is bk: in ASCII, then 16 bytes of ciphertext, followed by an all zero IV, then a iteration count in hexadecimals : 10,000 (0x2710 in little endian), followed by what I presume is a 4 byte checksum or key check value.

So from a cryptographic standpoint this looks correct, unless an all zero IV is not acceptable.

Notes:

• You cannot just start with character A when reading the IV. Byte boundaries for base 64 are within the characters for 3 out of 4 boundaries (or 5 if you count the one for the next byte). So you should always first convert the base 64 to hex.

• Instead of 16 bytes of ciphertext I would expect 16 bytes of salt, used for the key derivation function. If those are random then it is alright to use an all zero IV, as the key would be different even if the same password is used; the random salt would make sure of that.