Timeline for Can I use PBKDF2 as a stream cipher?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 24, 2016 at 10:34 | history | edited | Ilmari Karonen | CC BY-SA 3.0 |
make the title more descriptive
|
| Dec 24, 2016 at 10:30 | vote | accept | Viktor Pti | ||
| Dec 24, 2016 at 0:53 | history | tweeted | twitter.com/StackCrypto/status/812461238663913475 | ||
| Dec 23, 2016 at 20:33 | answer | added | Ilmari Karonen | timeline score: 8 | |
| Dec 23, 2016 at 15:08 | history | edited | e-sushi | CC BY-SA 3.0 |
deleted 11 characters in body
|
| Dec 23, 2016 at 13:37 | comment | added | Viktor Pti | Alas, I'm afraid these conditions are not satisfied in my case. RNG is pseudo-, and probably not even crypto-. Iteration count of even 1000 has too high impact on performance. Platform is completely insecure. And the whole task is not even serious encryption, in fact it's just a piece of obfuscation (since key distribution is weak as @dave.zap mentioned). Anyway, thanks for clarification! | |
| Dec 23, 2016 at 13:17 | comment | added | fgrieu♦ | If the salts are indeed different (which is likely for 8 bytes produced by a good TRNG, until about $2^{32}$ uses), the iteration count high enough considering the password strength, and the platform secure, then yes XOR-ing with the output of PBKDF2-HMAC-SHA1 is an unbroken encryption method as far as we know. The salt needs to be made available for decryption (e.g. put at start of ciphertext in clear on known length. Again, this does nothing to insure integrity and proof of origin. | |
| Dec 23, 2016 at 12:51 | comment | added | Viktor Pti |
@fgrieu Available PBKDF2-HMACSHA1 API (Rfc2898DeriveBytes) takes password and salt (at least 8 bytes). Is it reasonably safe to use one base secret password and different public prng-salts as IVs to produce different keys (gammas)?
|
|
| Dec 23, 2016 at 11:39 | answer | added | dave.zap | timeline score: 1 | |
| Dec 23, 2016 at 10:48 | comment | added | fgrieu♦ | That's fine enough for a single plaintext per password (although PBKDF2-SHA-1 is far from the best entropy-stretching function around). For more, the lack of IV implies keystream ("gamma") is reused, which is a well-documented disaster. Independently: like AES-CTR, this provides no integrity insurance. | |
| Dec 23, 2016 at 10:46 | history | edited | Viktor Pti | CC BY-SA 3.0 |
added 3 characters in body
|
| Dec 23, 2016 at 10:36 | history | edited | Viktor Pti | CC BY-SA 3.0 |
added 3 characters in body; edited tags
|
| Dec 23, 2016 at 10:21 | review | First posts | |||
| Dec 23, 2016 at 10:56 | |||||
| Dec 23, 2016 at 10:20 | history | asked | Viktor Pti | CC BY-SA 3.0 |