Timeline for Deriving a key from a pseudo-random string
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 31, 2019 at 5:53 | vote | accept | mc9 | ||
| Jan 30, 2019 at 22:00 | answer | added | Maarten Bodewes♦ | timeline score: 1 | |
| Jan 30, 2019 at 10:18 | history | edited | mc9 | CC BY-SA 4.0 |
deleted 18 characters in body
|
| Jan 30, 2019 at 10:09 | comment | added | mc9 | @Elias Thanks, please see my edit for my intention with this design. Are you saying it might be better off to create two separate keys (one for encryption and another for authentication), based on this circumstance? | |
| Jan 30, 2019 at 10:06 | history | edited | mc9 | CC BY-SA 4.0 |
purpose
|
| Jan 30, 2019 at 7:34 | comment | added | Elias | Could you explain what you are trying to achieve with this construction? Why are you using the same key for different purposes? This is against best-practices. | |
| Jan 29, 2019 at 22:36 | history | edited | mc9 | CC BY-SA 4.0 |
deleted 2 characters in body
|
| Jan 29, 2019 at 21:58 | history | edited | mc9 | CC BY-SA 4.0 |
added 1100 characters in body
|
| Jan 29, 2019 at 21:13 | history | edited | mc9 | CC BY-SA 4.0 |
deleted 9 characters in body
|
| Jan 29, 2019 at 19:55 | history | edited | mc9 | CC BY-SA 4.0 |
added 8 characters in body
|
| Jan 29, 2019 at 19:48 | history | edited | mc9 | CC BY-SA 4.0 |
added 132 characters in body
|
| Jan 29, 2019 at 14:17 | answer | added | Brolf | timeline score: 0 | |
| Jan 29, 2019 at 12:17 | answer | added | Anonymous20DB28 | timeline score: 0 | |
| Jan 29, 2019 at 10:32 | comment | added | mc9 | Thanks for your comment. I forgot to mention that the server should not know the client's secret key. Therefore I think the step 3 is necessary. But I wonder if 1 iteration is enough in step 3. I have updated the question. | |
| Jan 29, 2019 at 10:28 | history | edited | mc9 | CC BY-SA 4.0 |
added 125 characters in body; edited title
|
| Jan 29, 2019 at 10:15 | comment | added | kelalaka | This is not double hashing, this is a double password-based key derivation. PBKDF functions are used to derive keys from passwords and they also aim to reduce the brute-force attacks as done on hashcat. You don't need this. | |
| Jan 29, 2019 at 10:11 | history | edited | mc9 | CC BY-SA 4.0 |
typo
|
| Jan 29, 2019 at 10:10 | comment | added | Daniel |
I don't think k0 is really acting as a proper secret key then, is it? Because in that case, the hash of k0 is not really useful for any cryptographic purpose (e.g. you cannot execute any cryptographic primitive like a signature or encryption using the hash of the secret key instead of the secret key itself). Thus, what you probably mean is that k0 is acting as the user password towards the server, essentially, and in that case you don't really need to use the double hashing; simply follow standard guidelines for password hashing (e.g. crackstation.net/hashing-security.htm).
|
|
| Jan 29, 2019 at 10:10 | review | First posts | |||
| Jan 29, 2019 at 10:19 | |||||
| Jan 29, 2019 at 10:08 | history | asked | mc9 | CC BY-SA 4.0 |