We recently had the following question: Timing vulnerability of byte array equality test?

quote:

Would the following code to test MAC equality leak timing information ?

bool equal(unsigned char *a, unsigned char *b, int len) {
    unsigned char c = 0;
    for (int i = 0; i < len; i++) {
        c |= a[i] ^ b[i];
    }
    return c == 0;
}

More precisely, does the last expression c == 0leak timing information ?

I don't think so, because it doesn't allow to know where would be the mismatch.

Why are then some crypto libraries using complex expression to convert c into a 1 or 0 value than later simply compare that value with a simple == with 1 (or 0) ?

Would a timing difference between MAC mismatch and identical MAC condition be relevant ?

Stripping the chit-chat and ignoring the code snippet, this contains 3 questions:

  1. More precisely, does the last expression 'c == 0' leak timing information ?

  2. Why are then some crypto libraries using complex expression to convert c into a 1 or 0 value than later simply compare that value with a simple == with 1 (or 0) ?

  3. Would a timing difference between MAC mismatch and identical MAC condition be relevant ?

The resulting answers all dive into things with coding examples and explanations about how compilers may (but are not guaranteed to) compile the code in a timing-attack safe way.

Weirdly enough, none of the answers seems to answer number 3 which would (from my personal, non-moderator point of view) have been the easiest and most crypt-related question contained.

Anyway, the question was close-voted with

"Programming questions are off-topic even if you are writing or debugging cryptographic code. Unless your question is specifically about how the cryptographic algorithm or protocol works, you should look into asking on Stack Overflow instead."

Reasons to adapt

Looking at the 3 reopen votes as well as the 8 upvotes Ilmari's comment received (at the time of writing this), it shows several Crypto.SE users seem to object and say that "some coding related questions" should be handled as on-topic.

Now… I'm open to this, but something tells me we should potentially adapt our close-reasons and help center texts accordingly, because two of 3 contained questions clash into what the system says.

  1. More precisely, does the last expression 'c == 0' leak timing information ?

    Is clearly about cryptographic coding (I'm guessing C, based on the Q's code snippet and the answers which agree by talking about C). Also, the compiler-related talk in all answers underline the fact the question is about cryptographic coding.

    So, it contradicts our on-hold reason stating

    "Programming questions are off-topic even if you are writing or debugging cryptographic code. Unless your question is specifically about how the cryptographic algorithm or protocol works, you should look into asking on Stack Overflow instead."

    How can/should we modify this on-hold reason so that is shows questions like the above are OK?

    And where exactly do we draw the clear line so that new users don't disrupt our system by pointing to such questions and claiming their question is alike?

  2. Why are then some crypto libraries using complex expression to convert c into a 1 or 0 value than later simply compare that value with a simple == with 1 (or 0) ?

    Ignoring the fact "some crypto libraries" is rather broad and unclear since we don't know which ones OP is thinking about, this at its core again is a coding-related question, because it asks why "some crypto libraries" adher to a specific coding practice.

    If not already covered by the on-hold reason mentioned in the previous point, this also somewhat contradicts our help center text going

    If your question is about using a cryptographic library (e.g. Crypto++, OpenSSL etc) and using it in your application, you probably need Stack Overflow. (A good indicator is the existence of source code in your question or most good answers).

    Actually, this is exactly what happened in the Q&A. So the help center describes a situation we now have, but users obviously prefer to handle the Q&A on-topic. So we should think about clearing up the contradiction which arises by modifying/adapting this text to make clear when Crypto.SE is a valid target for crypto-coding questions and when it should be asked at SO (using the crypto tag at SO).

    How can/should we modify this help center text so that is shows questions like the above are OK?

    And where exactly do we draw the clear line so that new users don't disrupt our system by pointing to such questions and claiming their question is alike?

Last but not least:

Why should we even think about modifying those texts at all?

In the end, the main reason why we most probably will have to adapt both texts (the on-hold reason and our help center text about coding-related Qs) is to avoid attracting questions which are not considered good, on-topic questions for this site.

Also, we have to draw a clear line here so that users know what goes and what doesn't. We have to avoid that users start using questions as evidence that they can ask similar, but off-topic questions here… which would (among other things) practically void the need for all questions at StackOverflow which were tagged cryptography.

The other option, of course, is that we keep things as-is and handle the above question as off-topic. Yet, the community feedback indicates this might not be a general consensus… which is why I've posted this META Q, so we can talk and (hopefully) agree upon things in a constructive way.


My point of view from both a personal and from a moderator perspective:

Crypto.SE has seen a lot of change during the past years, and on several occasions it showed that change can be a good thing. We just have to keep an eye on the importance of safe-keeping the quality of our site. The use of clear texts (in the help center and in our close reasons), which describe the rules of our community, are one tool to guard that quality. We merely have to make sure that tool isn't used against our community one day. Ensuring the system texts fit the Q&As we handle and regard to be on-topic is one way to do that. So, if change is needed, let's do our best at clarifying what crypto-coding related questions we accept as on-topic and where we draw the line.

As for the linked Q itself, I've dropped a 4th vote to reopen the Q&A which has an accepted answer. Yet, that does not mean the problems and reasons described in this META Q&A are voided. Reopening the question actually enforces the problem that users might start using this and other questions as evidence that they can ask similar, but off-topic questions. That's why we definitely need to clarify things so we stay clear of turning into a StackOverflow duplicate.

  • "Is clearly about C coding." How do you know? C is mentioned nowhere in the question. – fkraiem Sep 11 '17 at 11:56
  • @fkraiem By bluntly looking at the code. The Q's function snippet seems to be an obvious example of either C (or maybe C++). The As also talk about “C”, so I'm not the only one interpreting things like that. Nevertheless, I'll edit this META Q to handle your How do you know? C is mentioned nowhere in the question. objection. Now… please note this nit-pick doesn't really matter in relation to this META Q&A, because even if it were a snippet in another coding language, it doesn't change the problem. Our system texts generalize it saying Programming questions… and cryptographic code. – e-sushi Sep 11 '17 at 12:02
  • Personally I feel like the line should be the same as it always has been(?): Questions about side-channels and their mitigations are on-topic (after all only cryptographers care about this property and are experts on it). – SEJPM Sep 11 '17 at 12:26
  • 6
    Compare ‘What code does GCC compile c == 0 into on powerpc64 systems with AIX ABI?’ and ‘Is there a danger that this isolated string comparison routine in C might leak secrets via a timing side channel?’. The first one is obviously just a programming question. The second one, although clearly a C-related question, is something that essentially only crypto people are likely to have a good handle on, and is clearly about cryptography. – Squeamish Ossifrage Sep 11 '17 at 13:10
up vote 12 down vote accepted

Side-Channel attacks and their mitigations are on-topic.

The above is the line I would draw. If answers to questions on the above require digging into code / how compilers (likely) do some things, so be it.

The above guide-line also covers the specific question because in the first discussed sub-question it is explicitely asked "(how) does this 'atomic instruction' lead to a side-channel attack" and the second one being "(how / why) does this snippet prevent side-channel attacks" (with the OP suspecting it does clearly being in the statement).

As to the why we should accept side-channel-code-related questions:

  1. We already cover side-channels attacks (see the name of our chat room and the corresponding tag)
  2. We are the best place to judge this particular aspect of code because it's specifically cryptographers who care about side-channels and as such they tend to have the most experience with them.
  3. (Rhetorical question): Should we really welcome the offensive part of a crypographic attack but reject the defensive part?
  4. We have precedents to questions asking about side-channel mitigations (1 2 3 4 5). I have to admit, these aren't quite on this level of actual code but they hint in the vey same direction.

Now for my proposal for the adopted close-reason:

Programming questions are off-topic even if you are writing or debugging cryptographic code. Unless your question is specifically about how the cryptographic algorithm, protocol or side-channel (mitigation) works, you should look into asking on Stack Overflow instead.


Actually, this is exactly what happened in the Q&A.

Actually no. The help-center talks about using libraries. The asker is not interested on how to do things with the libraries while not caring about how they do things.

The question at hand is why certain things directly related to side-channel mitigations are done.

If it makes you feel better, we could amend the help-center snippet along the follow lines:

If your question is about using a cryptographic library (e.g. Crypto++, OpenSSL etc) and using it in your application, you probably need Stack Overflow. (A good indicator is the existence of source code in your question or most good answers).
However, questions on why libraries do certain things (internally) which you strongly suspect are directly related to preventing side-channel attacks are on-topic.

(the emphasis is intentionally and probably will clear things up for the reader and thus should be added)

  • 1
    As usual: Don't forget that voting on meta means "disagreement" and "agreement" as opposed to "good answer" and "bad answer". So no offence should and will be taken for down-votes out of disagreement! – SEJPM Sep 11 '17 at 13:33
  • 2
    Thanks for you extended contribution. [+1] Even in case we end up not modifying texts, this Q&A will surely help whenever we need a place to point to (meaning: in cases where related uncertainty and/or disagreement comes up somewhere in the future). Honestly, I'm currently thinking the help center text could remain unchanged… but your suggested modification to the close-vote reason reads like it might indeed be perfect to serve its purpose, as it would generally stop people from close-voting allowed side-channel attack mitigation Qs just because they might include coding-related sub-questions. – e-sushi Sep 11 '17 at 14:25
  • After a week and based on the fact your suggestion received 9 upvotes, I've accepted this answer and adapted the on-hold reason accordingly. The change is now (since I modified the on-hold reason with an edit) waiting for another moderator's approval before going live on the site. Since CodesInChaos is enjoying his holiday, I've pinged mikeazo asking him if he could add his approval. Due to his timezone, it might take a bit for the change to go live. – e-sushi Sep 18 '17 at 8:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .