meta user
network profile
| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | 9 hours ago | |
| stats | profile views | 137 |
|
Aug 1 |
comment |
Purpose of outer key in HMAC I don't think this is correct. With HMAC, any collision in the inner function is immediately and automatically a collision for the full HMAC (same as for the construction that CodesInChaos asked about). So what you describe is not actually a benefit of HMAC. |
|
Aug 1 |
comment |
Can I use a key-derivation-function as the hash function H in SRP? @RickyDemer, turns out that's not a problem. First, collision-resistance is not a big issue for this particular application. Second, PBKDF2 is already adequately collision-resistant. |
|
Jul 29 |
comment |
What is the name of this kind of protocol @amccormack, no reason you should be embarassed! It is closely related to the three-pass protocol, which you might have been remembering (in fact, if I were going to explain the three-pass protocol, starting off with the insecure xor variant is not a bad way to explain the basic concept). |
|
Jul 29 |
comment |
Can I jettison MAC if I already have SHA1(M)? @Fixee, See my answer (which I edited recently to elaborate) for explanation why. A full explanation is too long to fit into this comment box. "padding attacks rely on being able to change the message" - This is not correct. |
|
Jul 29 |
comment |
Can I jettison MAC if I already have SHA1(M)? "I believe those attacks can be avoided if you're really careful in the implementation" - Nope. Your belief is misplaced. They cannot. There are some protocols where, no matter how careful you are in implementation, if you implement the specified protocol, you will be vulnerable. If you read the papers I cited, you will find examples. Or, read the detailed example I added to the end of my answer. |
|
Jul 29 |
comment |
Can I jettison MAC if I already have SHA1(M)? @CodesInChaos, I understand that the existence of the kind of attacks I described is surprising and counter-intuitive, but it turns out it doesn't matter whether you agree or not; what matters is that the attack is possible. |
|
Jul 29 |
comment |
Can I jettison MAC if I already have SHA1(M)? @Fixee, sure, the ciphertext may be different but the decrypted message may be the same (once you remove padding). Thus, there is no perturbation to the "message" but there is a perturbation to the ciphertext. Thus, the attacker's ciphertext might still be accepted, even though it is different from what Bob sent. Remember, you're hashing the message, not the ciphertext, so your scheme does not ensure that the ciphertext is effectively immutable. A detailed example is too long to fit in a comment box, but read about padding oracle attacks and other chosen-ciphertext reaction attacks. |
|
Jul 29 |
comment |
Can I jettison MAC if I already have SHA1(M)? @Fixee- "any adversarial message is overwhelmingly likely to just be rejected" - I believe this is incorrect. It may be true for a randomly constructed ciphertext, but an adversary can be smarter than that. |
|
Jul 29 |
comment |
Can I jettison MAC if I already have SHA1(M)? Poncho, @Fixee was on the right track. In fact, there are some tricky attacks on confidentiality. Therefore, I do not think I would call this scheme secure. (Your answer considers only integrity, but integrity is only half of the story.) See my answer for elaboration. |
|
Sep 27 |
comment |
Public key generation in homomorphic encryption schemes @Andrei, thank you. Can you answer the question that both PulpSpy and I asked about what is the point of encrypting messages if it is impossible to decrypt? |
|
Sep 27 |
comment |
Public key generation in homomorphic encryption schemes @Andrei, thanks! It helps to hear that you are talking about distributed key generation. I presume this means that you want $n$ parties to work together to generate a single public/private keypair, so that any $n$ of them can jointly decrypt, but no $n-1$ of them are able to decrypt. But, I'm still confused: the original question says you don't need the private key, but your comment says you don't need the public key. Which is it? Actually, I'm a bit puzzled how you wouldn't need either. You're going to encrypt message but there is no way to ever decrypt: can that possibly be right? |
|
Sep 27 |
comment |
Can a computationally unbounded adversary break any public-key encryption scheme? Thanks for your comments, @Ninefingers. Let's take this to meta. |
|
Sep 26 |
comment |
Is the following statement about PRG true or false? This answer is technically correct if you use the asymptotic definition of PRG, but only if $\ell$ is superpolynomially larger than $k$. Moreover, in practice the asymptotic definition of PRG is not a good one; and if you use a concrete-security definition of PRG, then you find the construction is secure. |
|
Sep 26 |
comment |
Is the following statement about PRG true or false? This sounds like a homework question. Is it a homework question? |
|
Sep 26 |
comment |
How to fairly select a random number for a game without trusting a third party? The protocol with pieces of paper is secure, but the protocol with electronic exchanges of messages is not. There's a subtle attack here, which I've described in my comments on PulpSpy and Ilmari's answers: the attacker can copy someone else's commitments and thereby influence/bias the final random number. If you want to use electronic messages, you need to hash everyone's $x_j$ values, rather than summing them. |
|
Sep 26 |
comment |
How to fairly select a random number for a game without trusting a third party? Actually, there's a subtlety here. Using the sum of the $r_i$s is not secure. Using a variant of the attack I described on @PulpSpy's protocol, a malicious participant Bob can force the sum to be even, which means that the final "random" number is not actually random. The fix is the same as I described in my comment on Pulpspy's answer: you should hash all of the $x_i$ values (rather than summing them). |
|
Sep 26 |
comment |
How to fairly select a random number for a game without trusting a third party? P.S. The fix is, instead of XORing the $r_i$s, you can hash them. e.g., the final random number is $H(r_1 || r_2 || ...)$, not $r_1 \oplus r_2 \oplus ...$. |
|
Sep 26 |
comment |
How to fairly select a random number for a game without trusting a third party? Actually, there's a subtlety here. Using the XOR of the $r_i$s is not secure. An attack: Suppose there are two participants, Alice and Bob. Alice is honest, picks $r_1$ randomly, and publishes $h_1 = H(r_1)$. Bob is malicious and rather than picking his own random number and hashing it, just copies Alice's hash: i.e., Bob publishes $h_1$. In the second round, Alice reveals $r_1$. Bob reveals the same thing. Now the final random number will be all-zeros. This allows a malicious Bob to force the final "random" number to be all-zeros, so it isn't random after all. |
|
Sep 26 |
comment |
Public key generation in homomorphic encryption schemes I'm having a hard time understanding the question. What exactly do you want to accomplish? The standard specification of El Gamal already describes how each participant can generate their own keypair. What more do you need? What is wrong with the answer "run the standard procedure to generate a keypair, and keep the public key"? |
|
Sep 26 |
comment |
Can a computationally unbounded adversary break any public-key encryption scheme? I read the original question, and your characterization is not accurate. It says: "Show the following: [...] If there is a public-key encryption scheme [...] then there is a function A [that breaks the encryption scheme]". Moreover, as I already mentioned, reuse of randomness attacks are not in scope, so your attack does not actually solve the question as originally asked. This is not a matter of opinion; it is a matter of mathematics. I'm sorry that you are taking it personally, but I assure you that I do not have a problem with you -- my interest is in ensuring accuracy. |
