Stephan Mueller <smuel...@chronox.de> wrote: > Could you please help me finding the function _gcry_thread_context_set_fsi?
It's in a branch: https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7340/ In the commit: https://dev.gnupg.org/rCfa87b8de038878704c381ac1e63cafee78e9b798 In the file: https://dev.gnupg.org/source/libgcrypt/browse/gniibe%252Ft7340/src/fips.c$81 My intention is that those two functions may be provided by non-libgcrypt implementation. In that case, replacing the functions by use of ERRNO is possible. Writhing the code, I thought about general cases; There could be multiple causes for FIPS 140 compliance. If we will change _gcry_kdf_derive with GCRY_KDF_PBKDF2 to finish its computation under FIPS mode, possible causes are: - passphrase length too small - salt length too small - iteration number is too small - minimum key size is too small I wonder if all of these should be recorded within the FIPS service indicator. It could be done by implementing a chain of causes (while it's only "unsigned long" value now in my branch). Shall I do something like: - recording a chain of causes within the FIPS service indicator (heavy implementation) - ERRNO implementation as an alternative (#ifdef, perhaps), only retains the last cause (or the first one) (light implementation) My opinion is that exposing implementation detail (for ERRNO use) is not good, at least for starting point. -- _______________________________________________ Gcrypt-devel mailing list Gcrypt-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
