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 == 0
leak 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:
More precisely, does the last expression 'c == 0' leak timing information ?
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 ?
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.
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?
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.
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 sayingProgramming questions…
andcryptographic code
. $\endgroup$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. $\endgroup$