3 ms·
A comment and a question: 1. It should be fairly trivial to test that your implementation is giving exactly the same output as the c libs (once you have chosen
by weichi 16y ago
A comment and a question:
1. It should be fairly trivial to test that your implementation is giving exactly the same output as the c libs (once you have chosen a particular random number that feeds into the algorithm). It seems like the trickiest part of testing will be ensuring that you are using the same character set everywhere.
2. Why is it important to have a "cryptographically strong" PRNG? Doesn't this just turn into a salt? Does a salt generator really need to be cryptographically strong?
Someone please correct me if I am being naive here.
- inklesspen 16y ago1. I worry I might have a bug that returns the proper output for some inputs, but improper output for other inputs. 2. Cryptographically strong random numbers isn't strictly required for a bcrypt salt, I guess. But if I'm building something which I plan to share with other people, I'd rather err on the side of too strong.
- wladimir 16y agoIn cryptography you should always use a "cryptographically strong" PRNG, even (especially) if in doubt. There have been to many mistakes with lousy random number generators undermining what would otherwise have been a strong security mechanism.
- weichi 16y agoBut we're talking about generating a salt here. As I understand it, the reason you use a salt is to make it much harder to brute-force a dictionary of passwords ahead of time. I don't see how the use of a cryptographically strong PRNG is going to provide any additional security here. What am I missing?
- wladimir 16y agoI don't know. But if I were to design such a system I'd use a cryptographically secure PRNG just to be sure. It's no extra work and has no drawbacks.