On a regular base, we receive questions related to the usage and/or inner workings of cryptography-related software and/or libraries.

Seven randomly picked examples of many:

I’ve only picked seven random Q&As, but if you look around you’ll notice there is a whole range of them.

These kind of questions tend to border the “programming” on-hold 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.

and if they don’t crash into that, such questions collide with our help center which states

If your question is about usage of a specific cryptographic software (not its cryptographic internals), Super User is the right site.

Fact is, answers often indeed tend to contain sourcecode or end up quoting part of the related software manual. Others explain how the software works, which commandline parameters to use, and/or how to interpret it’s output.

This makes me ask how we want to handle this. Currently, the line we draw seems to be pretty blurry. So, let’s discuss this to clarify things:

  1. Are such questions indeed programming and/or software usage questions and should accordingly be put on hold (or locked for historical reasons) like it has been done on several occasions?

  2. Or should we rethink our position related to questions about cryptographic software and libraries, and allow them? In that case we should probably adapt our help center texts and close-voting behaviour accordingly.

  • I edited the "libsodium (ArgonHashString function)?" question because the title was incredibly generic. It seems quite on topic to me, the fact that a particular library was used is more of a background detail. For the record, I would close the pgpdump one. The rest seem at least ok-ish, if not all clearly on topic. – otus Dec 10 '17 at 20:02
  • Here's an example of a question that is obviously currently off-topic because it's a programming question, but for which I can't imagine that stackoverflow will actually give a sensible meaningful useful answer without real crypto engineering expertise: crypto.stackexchange.com/q/54125/49826 Suppose this actually affected real user data (in this case, it's not clear there is a remotely sensible security model, but suppose there were). What would the responsible thing to do be? Send the questioner to somewhere they'll get bad crypto engineering advice but working code? – Squeamish Ossifrage Dec 21 '17 at 9:37
  • @SqueamishOssifrage Crypto expertise won’t prevent this newbie coder to fail coding correctly (hint: java.lang.IllegalStateException). In the end, it’s SO material because the problem lies in Java code, not cryptography. Besides that, note that SO has an encryption tag for a reason. – e-sushi Dec 21 '17 at 13:28
  • @e-sushi: I agree that there is plenty of Java coding crap that we don't want to deal with (and the question morphed substantially since I cited it, apparently a few seconds after I cited it), but there remains a nugget of a question about crypto engineering in there. I'm not saying we should have addressed that particular question—just that I have a nagging doubt in my head about sending novice coders to fix the code for a protocol that is obviously broken. Once the code compiles/runs/passes tests, there's no more feedback for the novice about the brokenness of the protocol. – Squeamish Ossifrage Dec 21 '17 at 15:20
  • Another one that's partly in the domain of ‘how do I use library X in PHP?’ but partly in the domain of ‘how do I do the crypto that satisfies my applications needs and where do I even start understanding this?’: crypto.stackexchange.com/q/54330/49826 It's especially bad because while there is programming documentation for OpenSSL, it's terrible and full of bad advice. So I tried to give some pointers on the latter question. – Squeamish Ossifrage Dec 30 '17 at 16:41
up vote 6 down vote accepted

I think we should at least re-consider our position.

Why sending users elsewhere might be bad

Other stackexchange sites don't necessarily have users that are knowledgeable about crypto. In fact, we could probably operate under the assumption that users who aren't on crypto don't know much (if anything) about crypto. I have seen heavily upvoted answers on other SE sites that were blatantly wrong, and obviously so to anyone who does know what they're doing.

If we want to make sure that users receive accurate advice that will ensure things are done safely, I think that we should think twice before simply sending them elsewhere.

Of course, it's a fine line between a programming question and a crypto question sometimes. If people just have bugs or can't figure out how to get their unit test to pass, I agree that that seems like a better fit for stackoverflow.

I can think of certain kinds of programming related questions that users would be less likely to find adequate advice for on other sites. For example, suppose someone needs to write side-channel resistant code. If they go to codereview or stackoverflow, it seems not unreasonable that the folks there simply won't be able to help much; Writing side-channel resistant code is not a standard programming exercise, and the average programmer is likely to have no experience doing so. Some things need to be done in less than obvious manner, and users there may not know how to properly advise someone in such a position.


Defining exactly what falls on either side of the line might be challenging and somewhat nebulous - sometimes it's already unclear whether or not Qs should be on security.se or crypto.se. If we allow software related Qs, then users may end up even more unsure of where they are supposed to post. Unfortunately I don't have an answer to that problem, there will probably always exist Qs that are on the fence and require a judgement call either way...

  • 1
    As for side channels, we have already allowed them here. – SEJPM Dec 9 '17 at 19:18

Seems to me there should be a pretty clear distinction between

  1. How do I do specific crypto operation X in library Y?

  2. Can you help me use the crypto available in libraries P, Q, or R to provide security property S for my application?

(1) is clearly in the domain of the library authors. But (2) requires some crypto expertise that many library authors are incompetent to provide. (Sometimes the answer might be, ‘Don't—use W instead!’.)

Even ‘How do I use crypto operation X in library Y?’, like how to pick initialization vectors to season a TLA soup, may need crypto expertise that the library authors don't understand.

  • If (2) is stated as: How do I achieve cryptographic property X using the primitives in library Y? Then it seems on topic. Your formulation would be "too broad" IMO, even if not off topic per se. – otus Dec 10 '17 at 20:04
  • 1
    Regarding (2), a user who knows what they are doing should be able to reword the question in a general way that does not mention specific libraries. And a user who doesn't shouldn't be writing crypto code. – fkraiem Dec 10 '17 at 23:40
  • How do we expect that the user who doesn't know, but who is trying to accomplish something and who has a gnawing sense of responsibility for security, will learn? – Squeamish Ossifrage Dec 12 '17 at 2:30

It is impossible to draw a firm line in sand.

Are such questions indeed programming and/or software usage questions and should accordingly be put on hold (or locked for historical reasons) like it has been done on several occasions?

There will always be ambiguous cases no matter what the rules are. But most of the ones listed in the question do not run afoul of the current consensus or else they probably would have been closed. They seem to fall on the side of being about the algorithms or standards instead of just the programming part.

Or should we rethink our position related to questions about cryptographic software and libraries, and allow them? In that case we should probably adapt our help center texts and close-voting behaviour accordingly.

I do not think so. That would only move the blurry line to whether the software is really cryptographic or whether the problem is really with the cryptographic part of using the library. (E.g. if someone is trying to use libsodium, but the question is actually a generic C-library one.)

So I do not think there is a reason to change the position.

In theory there should be no distinction between theory and practice, but in practice there is. Implementations are necessarily always leaky abstractions.

I care not if the purity of the ivory tower is somehow tarnished by grubby practicalities. I vote for including discussions about cryptographic software and libraries.

You must log in to answer this question.

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