100 reputation
4
bio website
location
age
visits member for 1 year, 4 months
seen Jul 19 '13 at 20:37

Jul
19
comment multiple keys via HKDF - whats better, one or two applications of HKDF-extract
@hunter: note the "probably", i.e., I just guess. Expanding to 256 bit and splitting might be completely equivalent - what I tried to say is that I see it as a variant of a), as only one extract operation is done.
Jul
19
comment multiple keys via HKDF - whats better, one or two applications of HKDF-extract
I never said they are 128 bit randomness, I explicitly wrote the strings are variable-length. Also, your answer was wrong even if your assumption would have been true: Your claim that the purpose of KDFs is to expand small keyspaces and increase brute force costs linearly is simply wrong. It's correct for PBKDFs, though, as I remarked to you.
Jul
19
comment estimating entropy/randomness as fail-safe mechanism
The purpose is not to detetc true randomness with any accuracy, but to detect likely failure of randomness. It's probably better to wrongly detect a random string as not random enough and take an emergency brake then to use a failing entropy source. I agree that the accuracy is a problem - I don't think false positives would be a problem, but I am afraid the number of actual failures that could be detected is too low to be of any practical use. Still, maybe I am wrong, and then it would be nice to know.
Jul
19
comment multiple keys via HKDF - whats better, one or two applications of HKDF-extract
The HKDF RFC stresses that different keys should use different info strings, so while that option exists, it's probably a weaker variant of a).
Jul
19
asked multiple keys via HKDF - whats better, one or two applications of HKDF-extract
Jul
19
revised repeated use of HKDF-extract on the same PRK
edited body
Jul
19
accepted repeated use of HKDF-extract on the same PRK
Jul
19
comment repeated use of HKDF-extract on the same PRK
added link to question
Jul
19
revised repeated use of HKDF-extract on the same PRK
added se link
Jul
18
asked repeated use of HKDF-extract on the same PRK
Jul
18
comment using random encrypted RSA challenge as key material
Finally got it to be accepted - i'll ask about multiple HKDF extracts separately.
Jul
18
accepted using random encrypted RSA challenge as key material
Jul
18
comment estimating entropy/randomness as fail-safe mechanism
The motivation for my question is that it is one thing to implement a reasonable generator for IV values that seems to work (i.e. encryption and decryption work), but hard to actually verify it - the encryption would work just as well with bogus IV values, but security would be completely lost. These cases are hard to catch using traditional testing techniques - apart from visually looking at IVs, there is little to verify their soundness.
Jul
18
comment estimating entropy/randomness as fail-safe mechanism
Regarding failure modes: An example of a failure mode could be a compiler bug that causes the IV value not to be calculated at all, but isntead being left at it's previous value, or using some semi-random data garbage left on the stack etc. The original program might be secure and correct while being tested, and might malfucntion somewhere else. The idea is having an extra failsafe mechanism, not something that is guaranteed to work.
Jul
18
comment estimating entropy/randomness as fail-safe mechanism
I mean in production installations, and preferably executed continually (so cost is important). Take as example CBC mode AES used for repeated messages - monitoring the IV value for randomness continously would allow the sender to stop sending when a catastrophic IV failure is detected.
Jul
18
comment using random encrypted RSA challenge as key material
As for the original scheme: the actually implemented scheme uses a different (auth) HMAC key for the response, and uses HKDF on different parts of the challenge to derive (message) HMAC and cipher key. However, the extra effort of using HKDF for the auth reply seems well worth it, and answers the next question I wanted to ask, namely what kind of hash mechanism to use for the reply.
Jul
18
awarded  Commentator
Jul
18
comment using random encrypted RSA challenge as key material
One minor additional question though: in other replies I read that using hkdf-expand for more than one key (using the same extract data) is not correct - I was under a different impression after reading the rfc, but re-reading indeed doesn't seem to allow multiple expand steps for the same PRK. It's not a problem in this case (one could use different parts of the challenge), I just wonder about this in general.
Jul
18
awarded  Scholar
Jul
18
comment using random encrypted RSA challenge as key material
Hmm, I have trouble setting your answer as the accepted answer (clicking has no effect) :( Ah, and now I really understand your answer: using a hkdf also for the reply is a great idea.