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

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
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
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$.
Oct
27
comment How to key an HMAC with keys from separate mutually untrusted parties?
If the other side is totally adversarial, there's literally nothing you can do. They can leak any key material whatsoever to a third party. Or they can have a third party provide them whatever data they wish, and authenticate it with the key.
Oct
27
comment How to key an HMAC with keys from separate mutually untrusted parties?
Be careful when making this assumption. What happens if user 1 gives user 2 $k_1\in\{0,1\}^{256}$ chosen randomly, and user 2 gives user $k_2=k_1$? In this case, $k_2$ was provided by user 2, but it is not independent of $k_1$. What level of hostility can you expect from user 2? Incompetence or malice? If they are totally untrusted, they could simply hand over any keys to a third party. Or are you simply trying to work around the possibility of them using a bad RNG out of ignorance?
Oct
21
comment How to implement HMAC SHA-256
Also note that K^ipad is an XOR, which will not change the length of K. That said, SHA-256 can input of arbitrary length (for practical intents and purposes).
Oct
13
comment Encrypt hash using hash of hash?
ELB terminates TLS, but the point is the load balancing in front of your server, not TLS termination. I'm not sure why you think AESNI wouldn't help for session negotiation, since the heavy lifting is virtually entirely AES operations. AESNI wouldn't help in your case, since none of your operations actually use AES.
Oct
12
comment Encrypt hash using hash of hash?
Even Google doesn't bother with TLS offloading appliances any more, particularly since AESNI instructions in modern CPUs. If they don't need it, you don't either. A 24-7 operations team to avoid denial of service attacks is absolutely ludicrous, fantastical thinking. And the effort of keeping up-to-date with OpenSSL patches is no extra work if you're also keeping up-to-date with all of the other software on your server. It also pales in comparison to the effort of writing and maintaining your own custom authentication protocol.
Oct
9
comment Inverting One-Way Functions
An intelligent adversary would notice the trivial pattern after two or three tries. Brute force is what you use when you have no better cryptanalytic tool at your disposal.
Oct
9
comment Encrypt hash using hash of hash?
B(P) alone thwarts a dictionary attack on the database if B is a hash with a large work factor, and the introduction of these extra mechanisms does not improve upon the situation. TLS protects against eavesdroppers (your protocol does not — e.g., it fails trivially to an active man-in-the-middle). A bespoke authentication protocol (and as a consequence, a bespoke implementation) is far more likely to contain exploitable flaws than simply following standard best practices by encrypting data over the wire with TLS, and protecting passwords at rest with bcrypt or scrypt.