Reputation
3,901
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
8 30
Newest
 Enlightened
Impact
~101k people reached

Nov
23
comment argon2 versus bcrypt/PBKDF2 password hashing security gain
@otus: You're right; it's been awhile since I've read the scrypt paper. I'll update the answer.
Nov
23
answered argon2 versus bcrypt/PBKDF2 password hashing security gain
Nov
21
comment For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?
In that video, he references (what I believe is) this paper which proves CBC under several notions of security. The only thing the paper appears to require of IVs in CBC mode is unpredictability to an attacker. The BEAST attack he mentions is possible because the IV fails the test of unpredictability, not secrecy. You'll also note that he mentions in literally the next sentence that his main advice is to not use CBC, which I fully agree with.
Nov
20
comment For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?
This is a pretty great example of how trying to add security to a system by blinding throwing more crypto at it can actually weaken security.
Nov
20
comment For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?
The requirements for an IV in CBC mode are uniqueness and unpredictability. A counter is insufficient.
Nov
20
comment For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?
You are inventing imaginary vulnerabilities where none exist. If cryptographers considered cleartext IVs to be a weakness, block cipher modes would have been designed in ways that didn't have such a weakness. Please do not try to be clever. Please do not try to invent your own crypto. Please just use off-the-shelf libraries that handle all of these details for you.
Nov
20
comment Keyless integrity checking with SHA-256
You're throwing the baby out with the bathwater; if you hypothesize state-level actors with arbitrary crypto-breaking capabilities, they can break any crypto. Keep in mind that creating and exploiting a chosen-prefix collision attack is considered more difficult than merely finding a collision (given a break in the underlying hash function). The answer to why not use a different hash function is because the described application doesn't require or benefit from resistance to length-extension attacks. You should choose primitives based on the capabilities actually required for your use-case.
Nov
20
comment Keyless integrity checking with SHA-256
The attack you suggest is a special-case of second preimage resistance: given $x$, it should be computationally infeasible to find a second preimage $x' != x$ such that $H(x) = H(x')$. In this case you're actually reducing the scope of the resistance to $x'$ of the form $x' = x\vert\vert y$.
Nov
19
answered Keyless integrity checking with SHA-256
Nov
18
comment Is it secure to use ciphertext feedback with RC4?
In general, I don't think you'll find that people are overly willing to spend time and/or effort analyzing bespoke novel constructions around broken ciphers.
Nov
18
comment Is it an overkill to add external integrity check to the AES-GCM encoding?
In a nutshell, using more than the minimum amount of crypto necessary is more likely to weaken security than improve it.
Nov
16
comment How does a Hashing algorithm always result in a digest in a fixed size?
Padding. This converts any message into a unique message with length divisible by a given block size.
Nov
16
comment How does a Hashing algorithm always result in a digest in a fixed size?
To give a quick idea to OP, one way to achieve this is to (for instance), break an arbitrary-length message into fixed-size blocks, operate on the first block, combine it with the second block (XOR, ADD, whatever), operate on this result, combine it with the third block, and so on.
Nov
16
comment Is there any relation between two strings with the same MD5 hash?
I'm not sure your first argument holds. If you have $2^{128}+1$ bit strings, two of them will have the same MD5, but it doesn't necessarily follow that any two such bitstrings don't have some sort of simple function relating the two. It's unlikely that this is the case, but I would posit that the simple fact that we've found colliding strings in less than $2^{128}$ (thus, tautologically, they have a "more simple" relation than simply having equal MD5 hashes) actually makes this more probable.
Nov
15
comment Is there any relation between two strings with the same MD5 hash?
You might have to clarify what you mean by relation. They're clearly identical in nearly every byte. And obviously, they have the relationship that their MD5 hashes are identical.
Nov
11
answered Hash email address with a non-random salt for moderate security?
Nov
9
comment Is there a standardized tree hash?
blake2b is probably along the lines of what you're looking for.
Nov
5
comment Best practises to generate IV for AES-CTR in this scenario
To explain my previous comment, a cloud storage application that will store tens of billions of files almost certainly will need stronger security requirements than "everything is encrypted" — if that's truly the only thing, to check a box, then full-disk encryption is probably good enough. If not, the solution will almost certainly require more thought and design than simply encrypting everything with a single key.
Nov
5
comment Best practises to generate IV for AES-CTR in this scenario
Furthermore, from the sound of your question it looks like you might be encrypting these files "because security", without actually considering what type of attack/attacker you're actually defending against. And your edited second approach is functionally no different than simply using a single key.
Oct
27
comment How to key an HMAC with keys from separate mutually untrusted parties?
$k_1=k_2$ is obvious, but such a relationship needn't be. Assuming the key mixing step is XOR as described by @RickyDemer (which is the "correct" answer assuming an incompetent party and not a malicious one), an adversarial party can generate some secret key $k_s$ at random that they share with evil third parties, and set $k_2 = k_1 \oplus k_s$. Now all the malicious users know that the "real" authenticating key is $k_s$, but there is absolutely no way for the user acting in faith to know that there's a trivial relationship between $k_1$ and $k_2$.