The OP suggests a weirdly specific Shibboleth, and half the comments are people saying he picked the wrong one - like "public key encryption isn't the right thing to test - you should be testing knowledge of computer architecture or regexes, or how to set up a web page with a specific stack" or whatever.
For developers, we usually test whether they're good at programming. We let them choose whatever language they want (because in the end they're all mostly the same, and a good programmer will be able to use any of them) and have them work through some simple but realistic programming exercises (eg. from this data structure, figure out whether person X manages person Y). Most fail in a way that demonstrates they won't be able to do the job, or will take too long to get going at it. It also usually identifies people who have weird religious attachments to certain tools, languages or methodologies (Many times I've heard crap like "Oh, I can't type this simple answer into a regular text editor, I need XYYXYXZZYX with autocomplete on" or whatever).
Anyway, back to the OP, yes I would expect that most developers should have some idea how they would encrypt a file, even if they haven't used the tools themselves personally (this isn't a core job in most development jobs I know of). But I wouldn't think they're dumb or unqualified if they don't. Why use a weak correlation like "a good developer probably knows how to encrypt stuff" when you could just test whether they can do development stuff directly?
And we do the same stuff for other jobs. When we were interviewing a graphic designer to work integrated with the programmers, we had them do some graphic design in the interview, fixing up pages we had purposefully borked in a real project. Again, most disqualified themselves pretty quickly when faced with realistic job tasks.