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. What are the advantages of using the inbuilt error reporting of libgpg-error
than normal error reporting in C? This question holds true for memory
management as well.
- I could really use a simple chart that shows the salt length/password length
requirement of different algorithms used in libgcrypt. It is a suggestion. I
had hard time arriving at the facts about bcrypt:
password length min 8, maximum 56 in crypt(3)/FreeBSD, salt size should be
exactly 128bit or 16bytes (correct me if I'm wrong)? End result is of variable
size? or fixed size?
These are most of the questions I have at this point.
Thank you in advance. Honestly I cannot give you anything in return, but I know
that Almighty is a witness to all good deeds, and knows the deepest and
slightest of intentions we have when we do good (or bad). If a person does a
good thing/deed and expects a reward from only him, know that he is the best to
reward, fully capable of doing everything (including calculating a more than
generous reward of ones deed. In both this world and hereafter)
Sent with [ProtonMail](https://protonmail.com) Secure Email.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
