Reputation
4,040
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
9 30
Newest
 Pundit
Impact
~117k people reached

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$.
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.
Oct
9
comment Encrypt hash using hash of hash?
It might be helpful if you explained how the client and server pre-establish K. That said, if an attacker knows P, the can trivially calculate K and B(P). If an attacker doesn't know P, what attack does this thwart?
Oct
9
comment Encrypt hash using hash of hash?
You're encrypting (C, B(P)) with K = H(B(P)), but you never send K to the server. If you send K to the server, an eavesdropper can decrypt (C, B(P)), so there's no point in encrypting it in the first place. Furthermore, combining standard primitives is no less prone to error than inventing your own wholesale.
Oct
9
comment Encrypt hash using hash of hash?
How does the server ever learn K = H(B(P))? Also, what are your goals? What is the standard approach for what you're trying to accomplish, how does it fall short of your security requirements, and how do you believe this scheme improves upon the situation?