Is it OK to make large changes in an off-topic question one did not ask, in an attempt to salvage it?

Question

Is it OK to make large changes in an off-topic question one did not ask, in an attempt to salvage it?

Motivating context: this recent question asked for the preimage resistance of a custom hash function, exposed as a piece of C code (with link to source of a full test program and some test vectors). It was understandably closed as off-topic on the grounds that

Requests for analyzing ciphertext or reviewing full cryptographic designs are off-topic, as the results are rarely useful to anyone else and/or would be too long for this site.

I would like to fix the question, because I find that

• The design has the virtue of being extremely simple, close to minimalist for a cryptographic hash function with arbitrary input and output size and a state of 128 trits. That makes discussion possible.
• The design can be described in an existing academic framework (iterated hash function with message block reduced to a single bit; at least Merkle–Damgård sans length strengthening and alternate output production, perhaps even better as a sponge with 1-bit input/output per iteration).
• The only immediately clear flaw (biased output) is non-devastating, easily fixable, and a non-issue w.r.t. preimage resistance or collision-resistance.
• Another unusual characteristic (some state entropy loss at each message bit, also easily fixable) seems worth a discussion about if this in an exploitable weakness.

My fixes would incorporate into the question the description part of my answer. I would ask about the security of some generic hash construct restricted to 1 bit input/output processed by hash round, w.r.t. standard hash security criteria (RO security, collision resistance, first/second preimage resistance); and how the entropy loss in the message injection is affecting that.

I also wonder what to do about the code:

1. remove it
2. improve it for unbiased output
3. change it for no entropy loss at each input bit (not exclusive from 2)
4. make it simpler only where that can be done without changing the result
5. separate message processing and output production (not exclusive from 2..4)
6. leave it as is.

Answer 1

Is it OK to make large changes in an off-topic question one did not ask, in an attempt to salvage it?

Personal opinion

From my personal opinion (not speaking as a moderator): “Yes, as long as the core of the question remains in focus.”

What I do as a Moderator

As a moderator, I mostly try to motivate the asker to edit his/her question via the comments – which is probably the more polite way to handle things, as it doesn’t surprise the asker that his/her question suddenly has been changed.

Yet, it frequently happens that the asker leaves it up to me to pull things on-topic after some back-and-forth via the comments. (Some might have noticed me talking about “saving a Q” in the past… which is nothing else than what I just described and what @fgrieu is asking about.)

From my experience, it’s not unusual for an asker to leave it up to someone else to do the edits needed to pull things on-topic, since new users are happy to rely on someone who somewhat knows the nuts and bolts of a specific SE site. After all, their Q gets reopened – which not only makes them happy, but also is something everyone benefits from on the long run.

Taking a look at the mentioned question

Now, related to that specific question:

I also wonder what to do about the code:

1. remove it

This would somewhat kill the core of the question.

2. improve it for unbiased output

No, as this would change the question core. Improvements could be incorporated into the answer though…

3. change it for no entropy loss at each input bit (not exclusive from 2)

Same as #2.

4. make it simpler only where that can be done without changing the result

Would be a nice option if this can be done without changing the actual output of the function. Yet, this is walking a fine line… with the risk of stumbling into #2.

5. separate message processing and output production (not exclusive from 2..4)

Same as #4.

6. leave it as is.

That’s what I would do. It’s just a single function representing only part of a complete program sourcecode. If the question would have shown the full program sourcecode, I would have shortened things, stripping it down to that single function. But the asker already did that, so there’s not much reason to fiddle with it.

I hope diving into these 6 points helps getting a “feel” of what can be done and what to avoid.

Reopening the Q

The fact that the asker accepted the answer and even commented…

I'm not sure what to comment but this answer nailed it in all senses, thanks for dissecting what I did in such a precise way, for pointing the relevant resources and for suggesting improvements such as having less biased bits and avoiding losing entropy on the injection. I can't overstate how insightful that was.

… shows that the Q may have been asking to review a full cryptographic design, but that it hasn’t been that big of a problem to wrap up an answer in a few paragraphs.

Based on the fact the answer got an accept and the question has obviously been answered to the fullest satisfaction of the person asking, I have reopened the question.

As for the close-reason, I disagree… as a “full cryptographic design” tends to be more lengthly than what was asked. Also, sourcecode related to a full cryptographic design rarely restricts itself to a single C function. We have been accepting pseudo-code and short code-snippets like that for as long as I can remember, even after the latest changes to our close-reasons. I see no reason why we should treat this one different. The question we’re talking about here isn’t low quality, it shows more than just a code-snippet, it was answerable in a few paragraphs, and it doesn’t provide any reason that could be abused to circumvent our established close reasons. This made me reopen it.