Support for bcrypt - password hashing

Gentle reminder... could you provide some example on using KEYD0500 as the information in the manual is not sufficient.

Question also remains to extend the Qc3EncryptData API for bcrypt, argon2, ... type of hashing algorithms.

Can you tell me which KEYD0500.KeyType to use ?

Also the algorithm to be used is unclear from the documentation.

QC3ENCDT / Qc3EncryptData API meets this requirement by using key description format name "KEYD0500".

Password Based Key Derivation Function 2 (PBKDF2) is documented in PKCS#5. https://tools.ietf.org/html/rfc8018

QC3ENCDT / Qc3EncryptData API does have support for PKCS#5 using key description format name "KEYD0500".
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/apis/qc3decdt.htm#keyd0500

As input into that function format, you specify an iteration count from 1 to 10,000 iterations which increases the work factor. It is standard to specify 1000 or more iterations.

Another input to that function format is the salt parameter. It is recommended to generate the salt with the generate pseudorandom number API (Qc3GenPRN) with a salt length of up to 16 bytes.

Another item in that function format is the passphrase up to 256 characters in length which can be specified in the CCSID of choice for your application.

Please review the API documentation and see if the KEYD0500 format provides the functionality needed.

All audits refer to the fact that SHA versions, while their hashing is fine, are to fast and are therefore susceptible for brute force attacks. If you Google SHA and password hashing you'll find hundreds of links which all confirm this like for example; https://dusted.codes/sha-256-is-not-a-secure-password-hashing-algorithm

Also texts like the one following are often presented by auditors and even with links like the one you provided, it is still hard to counter their references like "SHA-1 in itself was never safe for password hashing. The hash algorithm itself doesn't have a work factor parameter nor does it have a salt as input.

These are requirements for run-of-the-mill passwords that do not have as much security as a good symmetric key. For this reason password hash algorithms have been invented, also known as password based key derivation functions (PBKDF). The difference between a password hash and a PBKDF is mainly how the result is used: directly as a password hash to compare with a stored password hash or as symmetric key for input in a symmetric cipher or MAC algorithm.

Well known password hash algorithms are PBKDF2, bcrypt, scrypt and of course the already mentioned Argon2. The latter two also contain options for configuring memory hardness, to overcome hardware based attacks."

We can resort to SHA in the mean while but are audit levels are getting higher and higher and the next time when they request the source code of our algorithm the discussion starts all over again (and we get a fail despite your link).

Please see NIST.SP.800-131A Revision 1: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf
Section 9 states approved hash functions and their acceptable uses.
SHA-1, SHA-2 (224, 256, 384, 512, 512/224,512/256), and SHA-3 (224, 256, 385, 512) are all acceptable for password hashing.

Since SHA-2 is cross platform, it should be acceptable for your GDPR compliance.
Is there some reason you have found SHA-2 to be unacceptable for your needs?

Double of http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=118459

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - Security
Operating system - IBM i
Source - None

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - Power Systems
Product - IBM i
Component - Languages - Other
Operating system - IBM i
Source - None