4 ms·
> It's simply a matter of observable fact. If you write in C/C++, you are far more likely to introduce security vulnerabilities than in other languages; therefo
by runeks 13y ago
> It's simply a matter of observable fact. If you write in C/C++, you are far more likely to introduce security vulnerabilities than in other languages; therefore, unless there's a pressing reason to use these languages, don't.
And in the case of crypto code, one could argue that there is a very good reason to use C/C++: to prevent timing attacks.
- stcredzero 13y agoHow hard would it be to develop a fast memory safe language that eliminates timing attacks?
- runeks 13y agoThat's a very good question. I think it's possible that the recent revelations will at least spur some interest in researching this. It seems like we need it badly.
- arh68 13y agoThat seems like a great idea. Timing attacks work when code tries to be fast, taking shortcuts where possible. There's a reason we talk big-O instead of big-Theta: we gladly accept when an algorithm finishes early. This is, in this case, highly undesirable. Shortcuts are great, everywhere but crypto; not unlike recursion being great, unless it's embedded. A language where every expression takes constant-time to compute seems like a solution. No short-circuiting, no variable runtimes. Don't use sorting algorithms like insertion/quicksort where best-case & worst-case are very different; use selection/merge where best-case = worst-case = average-case. Use constant-time hash functions. Caching is a very prevalent (and somewhat invisible) shortcut that needs to be solved (how can a language disable caching?). Obviously this isn't fast but you can't have both.
- stcredzero 13y agoObviously this isn't fast but you can't have both. Merge sort is still pretty fast. It isn't the fastest. But safe > fast when it comes to reliability and security.