| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 1 year, 9 months |
| seen | 3 hours ago | |
| stats | profile views | 137 |
|
Sep 7 |
comment |
Is there some way to generate a non-predictable random number in a decentralised network? Actually, your protocol is vulnerable to a classic attack. Suppose there are two parties, Alice and Bob, and Bob goes last. Then, Bob can ensure the final bit will be 0 as follows. Bob can copy Alice's commitment, then copy Alice's opening of the commitment, which ensures that $b_1=b_2$ and thus the final coin is always 0. To fix this, you could compute the final coin as $H(b_1,\dots,b_n)$, or use other standard fixes. |
|
Sep 3 |
comment |
Is Porticor's “homomorphic” key encryption something that can really be done or is it just marketing hype? See also How is CipherCloud doing homomorphic encryption? for a related topic (though not identical). |
|
Sep 1 |
comment |
verify contents, but not order Either approach will work. Mixnets might be more efficient. Mixnets also might be easier to understand, depending upon what you find more intuitive. Or, they might not. It's just one more approach you could consider. (I don't immediately see any reason to think that one will be more of a "bother" than the other, or any reason to think that using zero-knowledge proofs would be inherently superior to mixnets, or vice versa.) And btw, many mixnet schemes do use zero-knowledge proofs internally. |
|
Aug 28 |
comment |
Secure Hash Function based on AES @Thomas, no, that's not likely to be enough. Lots of people have studied how to build a hash function out of AES, and the consensus view is: it's not a very promising direction. You're probably not going to get something of adequate strength out of AES (at least, not something simple and as fast as AES). We could spend all day going back with various proposed schemes and showing how they're broken, but let's jump past all that to the bottom line: this is not a promising direction to build a hash function. |
|
Aug 26 |
comment |
Is there a way to make RC4 (ARCFOUR) secure, or is it completely broken? @KevinJin, I think you should ask a separate question for those issues. But really, my recommendation is: don't do any of those things. Instead, use TLS. It will provide a secure way to establish a secure connection between the client and server. |
|
Aug 25 |
comment |
Is there another resource for Carter-Wegman-style message authentication? Are you looking for something from the theory perspective (e.g., how to design or analyze a universal hash function)? Are you looking for something from the applied perspective (e.g., how to use Carter-Wegman hashing for message authentication in your application)? The answers will be very different in these two cases. |
|
Aug 25 |
comment |
Is there another resource for Carter-Wegman-style message authentication? This should probably be migrated to Crypto.SE. |
|
Aug 24 |
comment |
Security considerations for partially shared password databases Cross-posting is frowned upon on Stack Exchange. Please pick one site to focus on, and ask the moderators to close the other one by using the "flag" button. Thank you! |
|
Aug 23 |
comment |
Why can't Homomorphic encryption schemes support algorithms with conditions/branching? @Also, It's a standard elementary result in computer science that any poly-time computation (say, taking a n-bit input and producing a 1-bit output) can be converted into a poly-size circuit. e.g., This is part of the Cook result for why SAT is NP-complete. For more details, you might ask on the Computer Science Stack Exchange site, as that result does not involve any crypto. |
|
Aug 12 |
comment |
Which block cipher modes of operation allow a predictable IV? @acidzombie24, Bouncy Castle supports EAX mode and is available for .NET. See EAXBlockCipher. |
|
Aug 10 |
comment |
Blum Blum Shub vs. AES-CTR or other CSPRNGs Tom, your point is well taken. Thank you for taking the time to explain. (Although, if you are operating in a regime where there is no proof of security, there is no longer any clear reason to use BBS instead of, say, AES-CTR.) |
|
Aug 4 |
comment |
Is it possible to match encrypted documents using user-defined search terms? SHA512 and MD5 are not encryption. They are hashes. |
|
Aug 3 |
comment |
Blum Blum Shub vs. AES-CTR or other CSPRNGs "Use a 2048-bit modulus, and you will be fine." - Not quite. This is a widespread misconception. In fact, if you use a 2048-bit modulus, you've rendered the proof of security irrelevant. There is no proof that 2048-bit BBS is secure. There's no proof that the security of BBS with a 2048-bit modulus has anything to do with the security of factorization or QRP: the QRP might be hard, factoring a 2048-bit number might be hard, but breaking 2048-bit BBS could be easy, for all we know. The proof of security doesn't rule this out. See my answer for explanation why. |
|
Aug 3 |
comment |
Blum Blum Shub vs. AES-CTR or other CSPRNGs (cont.) As I explain in my answer, for BBS to be provably secure, you need a really big modulus -- far larger than anything you would ordinarily use with RSA. If you're using BBS with a 2048-bit modulus, you're using something that has no proof of security (using BBS this way renders the security warranty null and void; the proof is no longer applicable), so you've negated the only possible benefit of BBS. If you use BBS with a much larger modulus, the resulting thing is dog-slow. BBS is a nifty theoretical construct, but of negligible relevance to practical crypto-engineering. |
|
Aug 3 |
comment |
Blum Blum Shub vs. AES-CTR or other CSPRNGs @AndrewSmith, not quite! That's a popular misconception. The security of BBS is related to the hardness of factorization. However, as I explain in my answer, there is no guarantee whatsoever that BBS with a 2048-bit modulus offers any security at all. (I think the same is true even for a 4096-bit modulus.) I know this sounds like it contradicts everything you've read about BBS, but it's actually not a contradiction: the proof of security for BBS comes with some fine print that almost never gets mentioned, and which makes the proof far less useful than most people realize. |
|
Aug 1 |
comment |
Can I use a key-derivation-function as the hash function H in SRP? @Aidenn, sorry, no, I don't have any source for this, alas. Sorry about that. (It's a perfectly fair question. I wish I had a better citation or analysis for you!) |
|
Aug 1 |
comment |
Does TLS use RC4-drop[n]? @B-Con, none of the answers to that question actually answer this question. |
|
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). |