Weak PBKDF2 parameters for password-encrypted private-key export in jose

## Summary Use of Password Hash With Insufficient Computational Effort in the jose library allows an attacker who obtains a password-encrypted private-key export to recover the private key through an offline password-cracking attack. When jose exports a password-encrypted private key with `jose_jwk:to_der/2` (`JOSE.JWK.to_der/2`), the `jose_jwk_der:to_binary/3` function in `src/jwk/jose_jwk_der.erl` serializes the key as a `PKCS#8` `EncryptedPrivateKeyInfo` using the PBES2 scheme with hardcoded key-derivation parameters: PBKDF2-HMAC-SHA256 with an iteration count of 2048 and an 8-byte (64-bit) random salt. Neither value can be overridden by the caller. Both values are far below current guidance (OWASP recommends on the order of 600,000 iterations for PBKDF2-HMAC-SHA256, and NIST recommends salts of at least 128 bits), so the key-stretching work factor is roughly 300 times lower than intended and the short salt reduces the cost of precomputation across keys. The symmetric encryption (AES-256-CBC with a 16-byte random IV) is not affected; the weakness is entirely in the derivation strength. An attacker who obtains one of these exported blobs (for example from a backup, configuration repository, object storage, or logs) can mount a cheap offline dictionary or brute-force attack against the export password, and success yields the full private key. This issue affects jose: from 1.10.0 before 1.11.13. ## Workarounds When exporting a password-encrypted private key with `jose_jwk:to_der/2` (`JOSE.JWK.to_der/2`), use a long, high-entropy passphrase, since the weak key-derivation work factor only meaningfully lowers the cost of cracking guessable passwords. Restrict access to exported `EncryptedPrivateKeyInfo` blobs and keep them out of backups, repositories, object storage, and logs that an attacker could read.