This is Omnifarious's Typepad Profile.
Join Typepad and start following Omnifarious's activity
Join Now!
Already a member? Sign In
Recent Activity
I use 256-bit keys to defend against possible future weaknesses discovered in the algorithm that allow better than brute-force attacks. I know full well that given a theoretically ideal computer (in terms of energy use for computation achieved) and extremely optimistic assumptions about the amount of computation required to check a key, it would still take the energy output of a supernova to crack the key if brute force were required. Also, from what I know, quantum computers will have only a very limited effect on symmetric key cryptography. From what I know, the search algorithms possible using a quantum computer effectively halve the key-length of a symmetric key, which makes symmetric keys still pretty darn good, even with quantum computers. Lastly, all known asymmetric algorithms completely fail in the face of a working quantum computer with a sufficient number of gates. These are the algorithms that typically require key lengths of (at the very least) 1024 to be secure. In fact, in order to achieve a level of security equivalent to a 256-bit symmetric block cipher key, you currently need something like an 8192 bit asymmetric key. But, for a 30 year time window, 3072 bits is probably enough. The exponential increase relation does not hold for asymmetric keys. The increase in computation required to break per added bit goes up by more than a polynomial factor, but by less than an exponential one. Of course, once again, with quantum computers with a sufficient number of gates, adding a bit just gets you a linear increase in computational complexity to break, which is exactly the same order of increase as it takes to use. But this is _only_ with asymmetric key cryptography, not with symmetric key.
I don't have a degree, though I have taken a few university courses. When I was 15 someone felt that it would be wise to point me at Knuth, a thing for which I'm very grateful, though I expect I would've stumbled across computer science proper eventually on my own. People who have been working in a particular application area but are not familiar with basic CS concepts are not people I would ever consider hiring unless I was hiring them to do exactly what they were doing before, and even then I would have some misgivings. In my opinion, it is your professional responsibility to educate yourself about stuff like this, not just for interviews, but so you become a better programmer over time. Knowing hexadecimal, for example, aids greatly in the understanding of various things because base 2 and magic numbers (at least seemingly magic in base 10) associated with binary occur all over the place. Being intimately familiar with the numbering system that computers use at base is going to make you better at your job, plain and simple. And I would not ding a candidate for asking me what a prime number was. But if they couldn't code up something involving searching for them after being given the definition, I would question their programming ability. I once did meet a candidate who could program, but who couldn't code during an interview. I realized this was the case because she had some very low-level work with ELF format binaries on her resume and when I asked her detailed questions about it, she knew the answers. I admit that we all likely gave her the benefit of a doubt because we wanted a bit of diversity, but my intuition turned out to be correct, and she was one of the better programmers on our team. So I always ask for code during an interview, but I do not demand it. But if a candidate can't code for me, I am extra-careful to probe the candidate's background and ask detailed questions to make up for the fact. I have not experienced the "hordes of non-programmers applying for programming jobs" problem. But most companies I've worked for have had good recruiters that screened candidates for us. I can easily see how you would fall into using coding questions as a screening tool. But I think that risks some false negatives, false negatives you would be sad to have missed had you realized it.
Toggle Commented Mar 29, 2010 on The Non-Programming Programmer at Coding Horror
Omnifarious is now following The Typepad Team
Mar 29, 2010