Reputation
22,122
Next tag badge:
98/100 score
23/20 answers
Badges
4 30 80
Newest
 Constituent
Impact
~483k people reached

Jan
30
revised Merkle hash tree updates
added 1680 characters in body
Jan
30
comment Merkle hash tree updates
@user3150164, sure you can. You can do an order-preserving update by simply inserting the new value in the correct location (and if necessary deleting the old value) -- still trivial, nothing that would rise to the level of novel, publishable research. If you have a specific kind of operation that you can't see how to handle, I suggest you ask a specific question about that, but the question you actually asked was a very broad question, and I think my answer explains the answer to that broad question.
Jan
30
comment Rock-paper-scissors over network, how to protect from cheating server?
@Dillinur, yes, probably. See the paper published at IEEE Security & Privacy 2014 and other concurrent/subsequent work along those lines. Feel free to research those papers and write a detailed answer if you feel so inspired!
Jan
30
answered Merkle hash tree updates
Jan
30
comment Hardness assumptions on composite order bilinear groups
I suggest you stick to one question per question. This site format doesn't work so well when you have more than one question in your question.
Jan
30
revised Usage of GF(p^m) fields, where p != 2
There is no reason for part of the answer to be in a quote block.
Jan
30
comment Achieving 32-bit verification code with 16-bit CRC?
I'm voting to close this question as off-topic because it is not about cryptography. (Questions about non-cryptographic checksums are off-topic; this site is for situations where there is an adversary, not about generic error detection mechanisms for non-adversarial situations.) See our help page for details of what is on-topic.
Jan
23
comment Hiding and Binding key in Groth-Sahai NIZK proof system
Please don't use images as the main content of your post. It's not accessible to the visually impaired and it's not indexed via search.
Jan
17
awarded  Guru
Jan
15
comment Formal security of recycled random blinding in a Paillier scheme
@Dave, for a fixed subset of the $R$'s, the chances of a collision are the same. Now count the number of such subsets. You'll find that there are exponentially many subsets, so once you sign a reasonably large number of messages, the probability that there exists some such multiplicative relationship is close to 1.
Jan
15
revised Formal security of recycled random blinding in a Paillier scheme
added 677 characters in body
Jan
15
comment Formal security of recycled random blinding in a Paillier scheme
@Dave, I think some of your details are a bit off there: there's no reason that $R_a R_b = R_c R_d$ would require $a+b=c+d$.
Jan
15
comment Possible to use an accumulator to “license” or restrict the qty of certificates being used?
This might not be obvious, but the way this site works is that we expect all requirements to be in the question. This is not a discussion forum. Comments exist only to help you improve the question/the answer, and can disappear at any time. If you've worked out that the question needs to be revised/refined, you should edit the question accordingly -- and the same goes for your answer. Again, it's not a discussion forum, and readers shouldn't have to dive into some discussion in the comments to understand what the question is.
Jan
15
comment Possible to use an accumulator to “license” or restrict the qty of certificates being used?
Understood. But as I wrote... "that isn't quite what the question asked for". The question asked us to prevent issuing more than $n$ certificates. The answer doesn't mention this caveat. If the answer proposes a scheme that achieves something less than what was asked for, and where it might not be obvious that this is the case, it would be helpful to explain the limitations, describe what properties it does achieve, and explore whether the resulting scheme might still be adequate in practice or not. I suspect some child CA's might potentially be OK with their private key leaking.
Jan
15
comment Integrity protection in wireless sensor networks
For the future: 1. One question per question please. This site format doesn't work so well when you have a bunch of different questions stuffed together. 2. Please do more research before asking. We expect you to do a significant amount of research and self-study. Many of your questions are already answered in standard resources (textbooks, online resources, other questions on this site).
Jan
15
comment Possible to use an accumulator to “license” or restrict the qty of certificates being used?
This proposed solution doesn't work. A signer can still re-use the nonce to sign multiple messages. Therefore, this scheme doesn't prevent a child CA from issuing more than the allowed number of certificates. (Of course, if the child CA does issue more than the allowed number of signatures, it might allow others to forge signatures that look like they came from the child CA, so it might have some negative consequences for the child CA, but that's a bit delicate and isn't quite what the question asked for.)
Jan
14
comment Possible to use an accumulator to “license” or restrict the qty of certificates being used?
This answer doesn't work. I think you are confused about what a $n$-time signature scheme is. A $n$-time signature scheme is a signature scheme that is secure as long as it is used only $n$ times. There is no guarantee that it's impossible to sign $n+1$ messages, and indeed every $n$-time signature scheme I've ever seen does allow signer to sign $n+1$ messages if he wishes (though this could enable others to forge additional signatures).
Jan
14
answered Formal security of recycled random blinding in a Paillier scheme
Jan
14
reviewed Approve TimeStamp in Cache-time attacks on AES
Jan
14
comment TimeStamp in Cache-time attacks on AES
This question appears to be off-topic because it is about the meaning of Intel x86 assembly instructions; this site is for questions about cryptography.