Reputation
21,561
Next tag badge:
97/100 score
23/20 answers
Badges
4 29 79
Impact
~448k people reached

Feb
7
answered Noisiest RF band for random number generation
Feb
7
comment Misunderstanding Broadcast Encryption
Check out non-committing encryption. Is it what you are looking for?
Feb
4
awarded  Good Answer
Feb
1
comment How hard is it to find plaintexts whose hashes satisfy $h(a)\oplus h(b)=h(c)$?
@JohnMeacham, I'm not familiar with SWIFFT, but if it satisfies $f(a+b)=f(a)+f(b)$, I would not call it a cryptographic hash function. The question specifically asks about cryptographic hash functions (and mentions SHA256 as an example); the term "cryptographic hash function" is often understand to require that the hash is effectively pseudorandom. So I think your criticism is debateable. If you have questions about what the OP meant by "cryptographic hash function", I suggest posting a comment underneath the question to ask the original poster to clarify.
Jan
31
comment Merkle hash tree updates
@user3150164, You can have a Merkle tree that has data values in internal nodes, if you want -- it's straightforward to extend all the ideas to that case. Alternatively, it's also possible to build a balanced binary tree data structure with values only in the leaves (and not in any internal nodes); the details of that are out of scope for this site (they're more appropriate for CS.SE than Crypto.SE). This is not a discussion forum, and not a place for extended back-and-forth or an interactive tutorial. I encourage you to formulate the original question more precisely in the future.
Jan
30
comment Merkle hash tree updates
@user3150164, inserting a new leaf at the leftmost edge can be done with $O(\lg n)$ operations. For instance, if $\ell$ is the leftmost leaf, you turn it into an internal node, with two children: $\ell$, and the new value. Then, you update the hashes of the nodes on the path to the root from these two new leaves. This takes $O(\lg n)$ time and hash updates. The general answer is: look at how any standard balanced binary tree data structure (e.g., AVL trees, red-black trees, etc.) handles this case -- they all handle this case, and achieve $O(\lg n)$ time. See paragraphs 2-4 of my answer.
Jan
30
comment Merkle hash tree updates
@user3150164, I've updated my answer with further explanation of these points.
Jan
30
revised Merkle hash tree updates
added 3474 characters in body; added 815 characters in body
Jan
30
comment Merkle hash tree updates
So, my advice is (1) take a closer look at the literature on balanced binary trees, (2) recognize that for most practical applications, the exact structure of the tree is not essential; all that matters is the set of values at the leaves, or possibly the order they are in. (If you have an application where you need something more, such as some special requirements on the shape of the tree, then the problem becomes different -- but that's an unusual requirement whose motivation is unclear, so don't be surprised if there haven't been many, or any, published papers on it.)
Jan
30
comment Merkle hash tree updates
Instead, the way that balanced binary tree data structures achieve $O(\lg n)$ running time is by weakening the requirement slightly: they insist that the height be $\le 2 \lg n$ (or some other slight weakening). That condition is perfectly sufficient for all needs. In practical applications there's no reason why we need the Merkle tree to have height exactly $\lg n$; height $2 \lg n$ is just as good. This relaxation is what allows balanced binary tree data structures to be efficient (including to handle the insert-at-front operation you mentioned efficiently). (cont.)
Jan
30
comment Merkle hash tree updates
@user3150164, I think I understand why you are finding this tricky -- I think the problem is that you are imposing a requirement that is stronger than it needs to be. The source of your confusion is the difference between requiring the height of the tree to be $\lg n$ vs requiring it to be $O(\lg n)$. If you insist that the height of the tree be exactly $\lg n$ (plus or minus one), then you are absolutely right that some operations can take $\Theta(n)$ time. (cont.)
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