Reputation
3,045
Top tag
Next privilege 3,500 Rep.
Protect questions
Badges
6 27
Newest
 Informed
Impact
~59k people reached

Apr
28
comment Looking for encryption algorithm not subject to known-plaintext attack with IV reuse
Based on your clarification about disk writes, it sounds like you're trying to reinvent disk encryption. Why not use a preexisting mode purpose-built for this use-case, such as XTS?
Apr
9
comment Salsa20-GCM composition secure?
Might as well use ChaCha20 these days over Salsa20.
Apr
8
comment Creating a random password based off of a prime number
I'm having trouble still understanding your use-case. Algorithms like AES require 128-bit or 256-bit byte buffers as keys. What cipher are you feeding this 512-bit integer into?
Apr
8
comment Creating a random password based off of a prime number
Generating cryptographically strong random numbers is not hard. And a base64-encoded 128-bit random symmetric key is only 44 characters long. What do you believe you gain by performing voodoo with prime numbers?
Apr
7
comment Why would an Initialization Vector be supplied externally?
Another simple likelihood is that there are many cases where you need to perform encryption with a specific IV that's determined by part of the protocol, and can't be random. So an encryption appliance would need to provide APIs to support these types of use.
Apr
7
comment What is the probability of breaking the AES algorithm?
You should be orders of magnitude more worried about security being compromised through a flaw in whatever software you're writing, than in it happening through AES being broken.
Apr
3
comment Solve a problem, thought it was hash length extension, hours later, am I wrong?
Yes, you need to include the padding. This is often not as big a hurdle as you might think. That said, just use an HMAC which is designed for this sort of thing.
Apr
2
comment Are there any valid, and person readable, checksums possible?
You are conflating your requirements. Readability can be handled by an encoding of arbitrary data, e.g., Bubble Babble.
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
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.