Earlier quoted context omitted.
Yes but this is a separation of concerns. This is precisely the point of an abstraction, especially at the level of a language and its implementations. 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 vie…
Unfortunately the architectural details of the machine will leak through to the program you are writing, and you will need to twist your code in order to get correct behaviour and fast execution. Case in point is the recent article posted on HN about the platform specific details of getTimeMilliseconds() in Java.
How I implemented my own crypto
141–150 of 409 posts
Re: How I implemented my own crypto
#142It 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…
> 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." Are there any practical alternatives when that kind of portability is needed? What about trans…
Re: How I implemented my own crypto
#143Earlier quoted context omitted.
u8 gets promoted to signed int before the shift. That he only used unsigned types is irrelevant.
> That he only used unsigned types is irrelevant If he had used a signed type, it would have got sign extended and the result would have been different.
Re: How I implemented my own crypto
#144Earlier quoted context omitted.
Every line of code written can be a severe vulnerability, not just code dealing with crypto. In case of crypto, being well-informed is good enough to not mess up those kind of implementations (on a theoretical level). The problems mentioned can be pointed out and verified on paper. But you can't say the same thing for code.
No, you can write crypto code, even when knowing stuff about the crypto, and still mess up. Crypto is problematic because you often cannot easily check whether you're wrong (it could be a tiny edge case that isn't tested because your input space is huge).
What you say as messing up with edge cases, etc. is a programming problem. The errors talked about in the link he posted is about using faulty crypto. Today it is common knowledge to never use ECB.
What cipher mode you use is a problem you think about before you even start writing a single line of code. But you are talking about programming errors, which one can make in all areas, not only ones involving crypto. Those errors can break security similar to messing up crypto implementation.
Re: How I implemented my own crypto
#145I really liked that read, good writing style and the author was coming from the same place that I'm usually coming from (can we redo this ourselves and shave off some bloat in the process). However, as it stands now, it looks more like a cautionary tale on why he should have listened when people told him not to do it :-) I suspect a worthier goal would have been to look for ways to improve the linking footprint of li…
---
I've been careful not to lock people in. If people want to upgrade to faster primitives, they can. I don't think they will ever need to, though.
Re: How I implemented my own crypto
#146I am terrified that I do not consider myself competent enough to write a crypto library, and yet there isn't a single mention - in this article, nor at the time of writing the comments here on Hacker News - of many of the pitfalls I know to avoid when undertaking such an endeavour. There is even a list of "you have to do A, B, C, and that's about it" that is missing some major - well known, even! - items. I know "don…
Surely people who invent and implement cryptographic algorithms for a living can be expected to be better than your run-off-the-mill programmer, but as I've said elsewhere implementing crypto is also not a black art. It requires about the same level of skill as e.g. implementing a production-ready low-level network protocol or a file system. That rules out many programmers but not all. That concerns implementations. As for algorithms, their development requires extensive experience in cryptanalysis (not just applied cryptography!). Some pros have that, others don't.
Last but not least, many popular and widely used crypto libraries started as a side hobby. For example, libtomcrypt started that way. In fact, many widely respected cryptographers started as hobbyists. For example, Bruce Schneier. Of course, the ones who are widely accepted as peers are also those who are in the 'hire me as a consultant, not the other guy' business, and they will naturally advise everyone to not roll their own crypto but to rely on their expertise...
Re: How I implemented my own crypto
#147Earlier quoted context omitted.
> We've had to wait till C99 to get stdint.h, clearly portability is kind of an afterthought in C. C provided "at least N bits" guarantees for its integer types since its first standard (for the curious: char at least 8-bit, short at least 16-bit, long at least 32-bit; in C99, long long as least 64-bit). This is the most that you can get if you want absolute portability, because there are architectures out there wher…
Good explanation And to me this shows clearly that we shouldn't be using C then. If an arch can't address an 8 bit sized element there are two choices for what happens if you write: char *a = "test"; char x = a[1]; Either char takes 32bytes or the a[1] read will shuffle the bytes to get a 32bit value whose least significant digits are a[1] And saying that int32_t are "conditionally supported" is really proof we're ma…
Arguing that C shouldn't support microcontrollers seems a bit unfair. What should embedded software engineers use, if not "high level assembler"? There are plenty of modern languages that sacrifice performance in order to be fully hardware agnostic.
Re: How I implemented my own crypto
#148Earlier quoted context omitted.
> 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." Are there any practical alternatives when that kind of portability is needed? What about trans…
Yes, C++. It's the only practical, safe alternative to C.
Re: How I implemented my own crypto
#149Main 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.)
Re: How I implemented my own crypto
#150Earlier quoted context omitted.
You can't really accidentally or unintentionally arrive at undefined behaviour in assembly language though. You would have to explicitly use an undocumented instruction or opcode and the result would probably be a hardware interrupt or exception every time.
Not quite every time though: https://github.com/xoreaxeaxeax/sandsifter