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

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.
Mar
20
comment Of what use is my code for finding prime numbers of a certain size?
Nor enough storage capacity to record them all.
Mar
20
comment How dangerous is it to encrypt with AES 256 if the end user knows the unencrypted value?
If you don't need to disclose the data, why send it to the client at all (encrypted or otherwise)? You should have a clear idea of what kind of attack you're attempting to protect against before simply throwing encryption at a problem and thinking it will improve security.
Mar
14
comment Block cipher mode with diffusion on ciphertext
Listen to @RichieFrame. Use the right tool for the job — you're trying to hammer a square peg into a round hole.
Mar
13
revised Of what use is my code for finding prime numbers of a certain size?
deleted 7 characters in body
Mar
13
comment If the text was compressed before using traditional cryptography, how much difficulty increases for frequency analysis attack?
The OP is talking about classical ciphers, not modern ones.
Mar
13
answered Of what use is my code for finding prime numbers of a certain size?
Mar
12
comment Repair AES-128 decrypted file
One could be a large number. :)
Mar
11
answered Repair AES-128 decrypted file
Mar
11
comment Is the 1st Encrypted Block Less Secure Than Subsequent Ones?
The second block depends on the key, plaintext, and previous ciphertext block. But the previous ciphertext block is known to an attacker, just like the IV is for the first block. Hypothesize that an attacker somehow know the first block of plaintext (say it's attacker-controlled). It's clear that this provides no additional information that could be used to break the second ciphertext block; the only input to the second encryption block that depends on that is the IV (the previous ciphertext block), but the attacker already knows it.
Mar
11
answered What is the probability of finding 4 equal bytes?
Mar
10
comment Known plaintext, unknown 128 bit block cipher
If you can control part of the plaintext that gets encrypted, you can potentially break this trivially.