|
Oct 13 |
awarded | Scholar |
|
Oct 13 |
accepted | BCrypt's 72-character limit and using it as a general digest algorithm |
|
Oct 12 |
awarded | Supporter |
|
Oct 12 |
comment |
BCrypt's 72-character limit and using it as a general digest algorithm As for "iPhone syndrome": ouch. I disagree, but I see your point. SHA-3 was an example; surely NIST isn't themselves saying that it's worse than SHA-2, either? The reason I didn't go with HMAC+SHA-2 to begin with (I'm aware rolling your own is a bad idea) was that in my limited searching around, there were concerns about it after the SHA-1 issues that surfaced, hence looking further. Searching some more it seems those concerns have faded somewhat now that quite some time has passed and nothing horrible has reared its head. Would you say the latter is an accurate summary? |
|
Oct 12 |
comment |
BCrypt's 72-character limit and using it as a general digest algorithm Thanks for weighing in with the clear pointers. Some questions: I opted for BCrypt not so much for 'slow' as much as for 'can be made slow enough for bruteforce not to be viable', even as technology progresses. If I understand, you're saying: as the secret is controlled, increase the entropy of the secret rather than the 'slowness' of the algorithm, in order to achieve the same resistance, correct? Regarding the confidentiality: I don't really understand the link to the question; what am I missing? Do you think some of the plaintext used for the MAC should be confidential? |
|
Oct 12 |
awarded | Student |
|
Oct 12 |
asked | BCrypt's 72-character limit and using it as a general digest algorithm |
|
Oct 12 |
awarded | Autobiographer |