[Cryptography] "NSA-linked Cisco exploit poses bigger threat than previously thought"

Kent Borg kentborg at borg.org
Wed Aug 24 17:48:28 EDT 2016


It was quite clever of C to make pointers and arrays and strings all the 
same, it was efficient and elegant, but it brought dangers. Critics have 
always been dismissed, with the implication that they are not Real 
Programmers.

   "We are adults, we program carefully, this won't be a problem."

Except it has not worked. That clever unity of pointers and arrays and 
strings is still burning us, both in very old code and in new.

Arguing that any reaction is pointless, that it will always be possible 
to write bugs, is kind of like arguing that it will always be possible 
to crash an airplane. Okay, what's the point? All efforts are futile?

   "Lecture the programmers harder. Don't make mistakes!"

Hmmm.

Disclaimer: The following might contain mistakes.

 From what I understand Rust manages to be as small and fast as C,  yet 
as safe as Python/Java, even suitable for systems programming.

   "Wait, safe *and* I can write device drivers?"

Not quite. If you have to do unsafe things (directly manipulate a 
pointer, touch hardware, etc), you have to do that in a block of code 
that is marked "unsafe". Be really careful in there, be ready to defend 
to your colleagues both the details of your unsafe code, and that the 
unsafe block need be there at all.

Where every line of a C program is dangerous, in Rust you can grep for 
them all.

Yes, Rust has an odd syntax for a C programmer.

The compiler is also very picky, figuring out how to make it happy can 
apparently be frustrating, but once you do there are whole classes of 
bugs that won't be there.

Possibly the most onerous thing about Rust is it obligates the 
programmer to specify ownership of all allocated data. Passing data to a 
function? Okay, but are you passing ownership of that data or are you 
just lending it? This has to be explicit. The benefits, however, are 
great: use after free or before allocation is no longer a problem, and a 
bunch of bugs endemic to multithreaded code also go away. So though Rust 
requires programs to be explicit about ownership, the programmer then no 
longer has to implement all that error-prone data-locking by hand.

To make array bounds checking fast Rust offers higher level access 
mechanisms, similar to Python's slices: If the programmer doesn't manage 
array indexes by hand, then Rust doesn't need to runtime check them! 
(Rust compiler trusts its own code generation.) What if you have an 
access pattern that you can't efficiently express in Rust? Okay, maybe 
just pay the bounds-checking cost, or maybe you need a small block of 
unsafe code: Be careful in that handful of lines. Be as careful as you 
should always be in C. Examine your unsafe block, have it reviewed, test 
it. Be skeptical.

Most of Rust's safety comes from compile-time static analysis (that's 
why the compiler is annoying). This means Rust is fast, and its runtime 
code can be (depending on what libraries you use) very nearly as small 
as that of C. Far smaller than Java, and I think even smaller than C++. 
Oh, and there is no garbage collector, seems the compile time approach 
works and there is no need. And though Rust might be a little bizarre, 
is it not as bizarre as something like Erlang!

We have a crisis. Our software is riddled with low-level bugs and it is 
only getting worse. I don't know whether Rust will be successful, but it 
seems quite clear that programmers are not capable of handling C's 
clever pointer/array/string-unity. What other languages are suitable for 
"I need every drop of performance and control", yet are this safe? 
Serious question. A question we should be asking.

Forgive me for going on so long with something that is not strictly 
crypto-related, but Rust is new technical ground for most of us, and 
crypto code also has these low-level bugs. Rust might help.

-kb



More information about the cryptography mailing list