Anytime someone wants to rewrite a C library in a language less prone
to buffer overflows, I'm totally for it.  Some say that "it's not the
library, it's the programmer", but I think that denies human factors. 
C simply requires too much machinery on top of it to use it securely.

It is possible to write secure C code, much as it is possible to write
portable C code, but it requires discipline, and C makes it marginally
harder to use new constructs than native ones.  C's string libraries
in particular are so complex to use securely that OpenBSD rewrote
them.  And unlike portability, one cannot create a test that assures
that you have coded securely.

And yet cryptographers continue to write in C.

HHLs have their problems; in an interpreted language with immutable
strings, it may be hard to overwrite a crypto key.  However, these
kinds of problems do not account for 50% of the current
vulnerabilities the way buffer overflows do.
--  -><- P=NP if (P=0 or N=1)
"My love for mathematics is like 1/x as x approaches 0."
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to