41–50 of 409 posts
I still believe it's a bad idea to roll your own crypto, interesting as an exercise, but I would never use it in a production environment.
Main lesson not learned: instead of testing, prove correctness in high assurance code like this. Rigorously and formally. Preferably even refine the proof to executable code. (Yes, it would take somewhere on the order of 10k LOC to prove correctness of this 1k.)
I still believe it's a bad idea to roll your own crypto, interesting as an exercise, but I would never use it in a production environment.
How will cryptography libraries ever develop if someone doesn't roll their own?
Earlier quoted context omitted.
C adds a layer between your code and the system. It abstracts away memory layout, locations, as well as function call semantics, and a many other things. For example, given a C program, you will not be able to tell me with certainty that a variable will occupy memory on the stack, any of your particular processor registers, etc. Formally, C is a language to control the C Abstract Machine , as described in the standar…
> Haskell I think writing timing-attack resistant code in Haskell would be very hard to impossible, at least without writing very unidiomatic code (basically "C in Haskell"). I'm happy to be proven wrong, though.
In fact, I believe something along the lines of this has already been done: https://cryptol.net
Earlier quoted context omitted.
Curious about the other language. What other language that doesn't add another layer between the code and system instructions were you thinking about?
Most programming languages with compilers to native code (JIT/AOT), the myth of high level Assembler for C only applies if your computer is a PDP-11 or a basic 8-bit CPU like a 6502 or Z80. The ANSI C and C++ standards define the concept of abstract machine for the language semantics, just like in most languages. Additionally you have the concepts of sequence points, the new memory model semantics for multi-threaded…
Sure, writing your own library is very difficult, but you have a simpler set of problems, which proper testing, another set of eyes and enough tools will take care of the big problems.
Now, implementing your own primitive and recommending to use it is bad. For a primitive to be deemed secure, it has to undergo years of review and testing by seasoned cryptographers.
This isn't a recommendation to write your own library, but my opinion that it is okay to do so if you want something that none of the major libraries offer.
Earlier quoted context omitted.
Portability is not black or white. Macros are essentially selecting different code depending on the platform. A good high-level language would not need to do this.
Just because you don't see those ugly macros to make your pure high level language portable, doesn't mean they're not there, somewhere.
Writing code in Common Lisp means you're writing something with semantics promised by the Common Lisp specification. Vendors implement the spec (perhaps using nasty #ifdefs), and developers write code against the spec. The spec is a contract, and from the point of view of the programmer, it's indifferent to platform change and so on (up to what the spec says is platform-dependent, like machine integer size or maximum array length).
Just because a particular implementation may not be considered portable, doesn't mean my program (which I may choose to run on that implementation) isn't portable.
It was a fun read, except when all the C bugs were listed. It's getting tiresome to hear about folks writing nominally Important software in a language where it is extraordinarily difficult to get things absolutely correct, with paltry excuses such as "it needs to be fast" or "it needs to be portable [0] to a VAX-11/750." It doesn't give me confidence that these completely usual bugs popped up early on, and it will n…
Curious about the other language. What other language that doesn't add another layer between the code and system instructions were you thinking about?
Edit: Sorry, wrote this too hastily and want to put it in perspective. While Ada is well-suited for cryptography and has some good implementations, it is probably not as secure as C crypto libraries in practice. The reason is that the implementations I know don't do OS-specific things like locking memory or preventing core dumps, and doing this in Ada is a bit harder than in C.
Earlier quoted context omitted.
Portability is not black or white. Macros are essentially selecting different code depending on the platform. A good high-level language would not need to do this.
Just because you don't see those ugly macros to make your pure high level language portable, doesn't mean they're not there, somewhere.
Earlier quoted context omitted.
Portability is not black or white. Macros are essentially selecting different code depending on the platform. A good high-level language would not need to do this.
Just because you don't see those ugly macros to make your pure high level language portable, doesn't mean they're not there, somewhere.
My "ugly macros" are tested against my own implementation only. Compiler's are tested against thousands.