PBKW does not clearly specify algorithm and encoding parameters

[bannable]

Ambiguous Encoding Structure

The specification for PBKW, both V1/3 and V2/4, do not specify the concatenation order or encoding of the encryption return value. The layout is instead specified instead by the local-pw and secret-pw Types.

For PBKW V1/3, where it reads:

Return h, s, i, n, edk, t.

It should instead read similar to the PIE spec:

Return h || Base64Url(s || int2bytes(i) || n || edk || t)

Similarly, the Decryption operations do not specify the layout of the encoded payloads, and assume that items such as t have already been extracted without providing information on the correct way to do so.

Compare to PIE, where it is clear in the algorithm definition what the encoded layout is:

Decode b from Base64url. The first 48 bytes of the decoded bytes will be the authentication tag t. The next 32 bytes will be the nonce n. The remaining bytes will be the wrapped key, c.

V2/V4 specification does not match reference implementation

Step 2 of V2/V4 En/Decryption states:

k = Argon2id(pw, s, mem, time, para)

However, the reference implementation passes an additional digest size parameter of 32.

Inclusion of parallelism degree is problematic

The inclusion of the para limit makes little sense: libsodium has no support for producing hashes that set parallelism degree through any API at all.

As the specification assumes implementers are using libsodium, it would make more sense to either exclude support for parallelism degrees entirely.

crypto_generichash calls

The specification is missing the length parameter for crypto_generichash calls. This matters because libsodium-php uses a default value of crypto_generichash_BYTES (32), whereas libraries such as RbNaCl use crypto_generichash_BYTES_MAX (64) instead.