Few questions about password hashing
Hello or Salaam everyone, I have a few questions regarding password hashing in general. And would very much appreciate any advice (just try not to use harsh words, please ;) ) Before that, I want to tell you something brief about what I'm doing. Basically I'm building a product that you can call in common terms as a social media website. For starters, you can think that it is meant to be a replacement for facebook/twitter. One that would respect your privacy (centrally). Actually it is much more than that, but that is not relevant here. Now this is not an advertisement, I'm not even naming it. I respect the purpose of this mailing list. But I just want to make clear my good intentions, and inform you about "to what end" I might use your valuable suggestions on which you may spend your valuable time. Also, I know that it is a huge undertaking. And on that account I tell you that I have spent 7+ best years of my life, entirely dedicated to pressing out the details of how to not repeat the mistakes of the current crop and how to do the right thing. How to make it into a neutral platform from the get go, and how to not make it a means of lot of bad things. libgcrypt is an important tool, that can help me build such a product (like it has helped other such good intended projects). But Cryptography is not my forte, it might be yours, and that is exactly why I'm writing this email. I'm working on the login system currently, running FreeBSD 11 / Apache / C CGI Questions, in no particular order (correct me if I'm wrong anywhere): : - FreeBSD recently replaced the RC4 algorithm with ChaCha20 in arc4random. While the libgcrypt is using SHA1 in its CSPRNG. 1. Is SHA1 secure in this role? For how long approximately? Are there plans to replace it with another algorithm in future? 2. How do both of them (arc4random and libgcrypt CSPRNG) compare in critical areas like security and efficiency? - I see that (perhaps) Bcrypt is not available as a hash function in libgcrypt. I thought that it was (and is) a corner stone of password security? I don't understand. It is not a new hash function like Argon2, but an old one. I'm currently thinking of storing user passwords as salted bcrypt hash in a DB. 1. What are the reasons behind it not being there in libgcrypt (if so)? Is it not recommended? 2. I recently saw this: https://packages.debian.org/stretch/bcrypt , are all current bcrypt implementations using ECB mode and are considered unsafe? 3. If it is still considered safe, would it be implemented anytime soon in libgcrypt? On a side not, I recently saw this: https://www.openwall.com/presentations/Passwords14-Energy-Efficient-Cracking/ - I do not yet fully understand the concept of KDFs and HMAC from the common texts (even after reading a few times), 1. Are they an option for me to use instead of common hashing? I heard a bit about the memory hard scrypt algorithm. - What is the ideal flow of the authentication system in terms of cryptography? I know there are a lot more steps, but I'm just asking about the broad ones. Here is what I have in mind: 1. Take form data from user, and sanitize it (specially for overflow and malicious code in submitted form). 2. Make a connection to DB, and check if user exists (if not, then log it, throw error, and exit) 2.5 Allocate secure memory ? <-- not sure about this 3. Retrieve Unhashed Salt (before bcrypt) <-- I'm not sure about this step, should it be hashed salt or unhashed salt 4. Concatenate the Salt with User submitted password and hash it 5. Compare this hash with the hash in DB (stored salted hash) 6. explicit_bzero , the string that contained plain password submitted by the form, the string containing salt (retrieved from DB), and the strings containing both hashes ? 7. generate 2-3 session keys (that only work in combo for one session) using CSPRNG (should be hashed using SHA-384 perhaps??) and set cookies for session management X. At some point use mlock ? I do not understand what "preventing the swapping out" means here. X. At what point do I need to free the secure memory (if used) at the earliest? - I see that minimum secure memory allocated is 16384 (This is 16kb? 8bit = 1byte?) in libgcrypt when using GCRYCTL_INIT_SECMEM; 1. Is this going to be enough in my case? 2. If not, how do I arrive at a reasonably efficient and safe size? I mean how do I calculate my secure memory need here? - If I use "GCRYCTL_USE_SECURE_RNDPOOL" 1. Do I still need gcry_random_bytes_secure convenience function? Can I just use gcry_randomize instead of it, and secure memory will be automatically allocated? 2. In the format of gcry_random_bytes_secure and gcry_random_bytes, I do not see a "buf" argument. Then how are these two functions used? I mean, where are the random bytes generated callable from? - For error handling, I hear that libgpg-error is required by the libgcrypt. 1. Does it requires any additional headers? 2.
Re: Newbie Question about initialization
On Fri, 23 Nov 2018 15:18, gnupg-users@gnupg.org said:
> gcry_version_check(1.8.4)
gcry_check_version requires a string with the version number or NULL.
Thus
--8<---cut here---start->8---
const char *s;
if ((s=gcry_version_check ("1.8.4")))
printf ("Version of Libgcrypt okay; got version=%s\n", s);
--8<---cut here---end--->8---
You can use NULL if you only want to initialize the library or to get
the version number.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpKeFaRUUEda.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Error after secret key list.
Hi,
if you can compile a not too old gpg version, you might be able to apply
this patch. It should show you the fingerprint of the cuplrit.
--8<---cut here---start->8---
diff --git a/g10/keyid.c b/g10/keyid.c
index a9034ee46..3694c26cc 100644
--- a/g10/keyid.c
+++ b/g10/keyid.c
@@ -975,7 +975,12 @@ keygrip_from_pk (PKT_public_key *pk, unsigned char *array)
if (!gcry_pk_get_keygrip (s_pkey, array))
{
- log_info ("error computing keygrip\n");
+ char *hexfpr;
+
+ hexfpr = hexfingerprint (pk, NULL, 0);
+ log_info ("error computing keygrip (fpr=%s)\n", hexfpr);
+ xfree (hexfpr);
+
memset (array, 0, 20);
err = gpg_error (GPG_ERR_GENERAL);
}
--8<---cut here---end--->8---
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgp2uyz7te0OO.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Error after secret key list.
On Fri, 23 Nov 2018 18:56, dirk.gottschalk1...@googlemail.com said: > I saw the Listing in the debugging log. I tried this also. > gpg -k does not show this message, but two messages regarding two keys, Hmmm, not easy to debug by mail. > gpg: bad data signature from key 2894CD20EE47166D: Wrong key usage > (0x19, 0x2) That is bug we introduced in 2.2.10 or so which was fixed in 2.2.11. It is just wrong diagnostic. > Could this be the reason for this error message? No. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpTd0QDWJCFS.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Error after secret key list.
Hello. Am Freitag, den 23.11.2018, 16:41 +0100 schrieb Werner Koch: > On Thu, 22 Nov 2018 16:38, gnupg-users@gnupg.org said: > > After listing the keys, gpg reports: gpg: error computing keygrip > Looks like you have a garbled key or one with an unknown encryption > algorithm. Not easy to pinpoint because that diagnostics comes from > the deep innards of gpg. > Do you see any error if you run gpg -k ? The secret key listing does > internally a listing of each public key and looks for a macthing > secret key. I saw the Listing in the debugging log. I tried this also. gpg -k does not show this message, but two messages regarding two keys, one from a person who is known as Werner Koch. Does anyone know this guy? ;) These are the messages I get: gpg: bad data signature from key 2894CD20EE47166D: Wrong key usage (0x19, 0x2) gpg: bad data signature from key A588F0D2ABD0CAF6: Wrong key usage (0x19, 0x8) I'm not gonna say you messed up your keys. I think, my .kbx is some kind of messed up. Or did you do nasty things to your key, for testing purposes? I don't think so. Could this be the reason for this error message? I'll delete your key and the other one from my key ring and re-import it from the servers. Probably this solves the problem. Deleting the keys re-importing them didn't solve the problem. Any hints? Thanks for your help. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac signature.asc Description: This is a digitally signed message part ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Newbie Question about initialization
Hi, can anyone tell me the syntax of the gcry_cry_version function? Does it work in this way: gcry_version_check(1.8.4) ?? Sent from ProtonMail mobile___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Error after secret key list.
On Thu, 22 Nov 2018 16:38, gnupg-users@gnupg.org said: > After listing the keys, gpg reports: gpg: error computing keygrip Looks like you have a garbled key or one with an unknown encryption algorithm. Not easy to pinpoint because that diagnostics comes from the deep innards of gpg. Do you see any error if you run gpg -k ? The secret key listing does internally a listing of each public key and looks for a macthing secret key. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpBDWbpl0HJq.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
