Reputation
3,485
Top tag
Next privilege 3,500 Rep.
Protect questions
Badges
6 28
Newest
 Nice Answer
Impact
~74k people reached

Mar
27
comment The effect of truncated hash on entropy
@fgrieu That doesn't make sense to me. If there is marginally less entropy in the 128-bit truncated hash than in the full 256-bit output, then it should follow that there is as much entropy in the half that was discarded. But that sums to much more than the original entropy that went in.
Mar
26
reviewed Reviewed Can machine learning analyze random number generator?
Mar
26
reviewed No Action Needed RSA: If I know n, e, p, and q, how do I calculate d using the extended euclidean algorithm?
Mar
26
reviewed No Action Needed Is Encryption without knowing the input directly possible at all?
Mar
26
reviewed Leave Open Key length requirement in a simple XOR implementation
Mar
26
reviewed Close NTRU Encryption
Mar
26
reviewed Leave Open What is this cryptosystem called?
Mar
26
reviewed Leave Open RSA: If I know n, e, p, and q, how do I calculate d using the extended euclidean algorithm?
Mar
25
comment Are modes of operation algorithms practical?
Furthermore, there is no need for you to re-blaze well-trodden ground. In general, unless you have specific requirements that they don't solve, you should use GPG for data at rest, TLS for data in motion. If you are typing the letters A-E-S into your code, you're doing it wrong.
Mar
23
comment Should I remove these use cases of MD5/SHA1 from my program?
As a concrete example, your entire method for generating request entropy is bunk. Literally every value being used (besides a single static value) is attacker-controlled.
Mar
23
comment Should I remove these use cases of MD5/SHA1 from my program?
I'm downvoting this for the simple fact that you asked a question, got an answer you didn't like from a respected community member, and jumped to defend your original decisions. While libraries like OpenSSL have had vulnerabilities, anything you write yourself is infinitely more likely to contain more and worse ones. Triply so given the cryptographic voodoo in the code you've provided. I sincerely encourage you to heed tylo's advice and scrap your code entirely for something that has high-level APIs for accomplishing your particular security goals.
Mar
23
comment What is the best hash for HMAC?
BLAKE2b is faster than MD5 and SHA-1 on modern 64-bit systems and has a native keyed hashing mode that is a suitable equivalent for HMAC. That said, HMAC's security proof only requires the compression function to be a PRF. While MD5 is broken and SHA-1 is likely not far behind, none of their broken properties are relevant to HMAC. HMAC-MD5 and HMAC-SHA1 are still unbroken (albeit distasteful).
Mar
21
comment Replacing the PRF in PBKDF2 with Keccak
From the proof's abstract: "This paper proves that HMAC is a PRF under the sole assumption that the compression function is a PRF... it also helps explain the resistance-to-attack that HMAC has shown even when implemented with hash functions whose (weak) collision resistance is compromised. We also show that an even weaker-than-PRF condition on the compression function... suffices to establish HMAC is a secure MAC as long as the hash function meets the very weak requirement of being computationally almost universal."
Mar
21
comment Replacing the PRF in PBKDF2 with Keccak
Not quite, but that's beside the point. Again, SHA-2 and SHA-3 are both NIST protocols. Please explain why you believe that one of them is backdoored by the NSA while the other one remains free of NSA involvement. Additionally, explain how this invalidates the fact that we have an actual mathematical security proof of the HMAC construct used by PBKDF2 under the sole assumption that the compression function chosen is a PRF. Collision resistance is not a necessary property under the HMAC security proof.
Mar
21
comment Replacing the PRF in PBKDF2 with Keccak
If you're convinced SHA-2 is backdoored by the NSA, an assertion for which there is no serious evidence in favor (circumstantial or otherwise) and a decade and a half of cryptanalytic evidence against, why would you expect SHA-3 to be any different? But again, the point is moot. It doesn't matter what compression function you use in PBKDF2 as long as it approximates a PRF, with a strong preference towards compression functions that minimize the performance penalty on general purpose hardware versus specialized hardware.
Mar
21
comment How many attempts does it take to crack a 32-bit password hash with this scenario?
$2^{32}$ attempts will give you a 100% chance at having cracked all hashes. $2^{31}$ attempts will have a 50% chance of having cracked particular hash, which is the mean.
Mar
21
comment How many attempts does it take to crack a 32-bit password hash with this scenario?
$2^{32}$ attempts would enumerate the entire hash output space. It would take $2^{31}$ attempts to have a 50% chance of cracking a single hash.
Mar
21
comment Replacing the PRF in PBKDF2 with Keccak
And, to reiterate your earlier point, Keccak is slower on general purpose CPUs right now than it is in hardware. A critical component of a slow KDF is to minimize any disadvantage the defender has when compared to an attacker, and Keccak currently is weaker than SHA-2 in that regard. Furthermore, while no professional cryptographer I know of has serious reservations about SHA-2 due to NSA involvement, the point is moot. PBKDF2 is built on HMAC, whose strongest security proof requires only that the underlying function is a PRF.
Mar
21
comment Replacing the PRF in PBKDF2 with Keccak
If there's no reason in particular to avoid using SHA-2, just use SHA-2. SHA-3 is currently intended as a ready alternative in the event that the SHA-2 family of ciphers is broken, but that is not yet the case.
Mar
20
comment Is it safe to prefix the a key with a known value?
It's probably a bad idea to use a value like this directly, in that some ciphers may not have been studied under partial key secrecy. At the very least, I would run a key like this through something like HKDF (or even simply a hash function) to evenly distribute the entropy in the key. With that done, the only weakness should be the reduced keyspace.