Live data from Hacker News

How I implemented my own crypto

loup-vaillant.fr

141–150 of 409 posts

Re: How I implemented my own crypto

#141
post #84

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.

Could you link that article? I searched and couldn't find it on hN.

Re: How I implemented my own crypto

#142

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…

> 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

#143
post #135
post #120

Earlier 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.

We can agree on that. But now I am completely lost as to what your original point was...

Re: How I implemented my own crypto

#144
post #107

Earlier 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).

I didn't deny messing up crypto code is a thing. I'm saying messing up code is a separate problem from messing up how one architects projects using crypto.

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

#145
post #73

I 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…

Reducing the linking footprint wasn't my only goal. Reducing the source code is also important, if only to facilitate tests and audits —thus increasing confidence. That huge table for instance would need to be tested. Every single value would need to be checked for correctness, or I would have to demonstrate they came from a sound generator.

---

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

#146
post #75

I 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…

I apologize if that sounds dismissive (it's not intended to) but your post is not more than the usual vague FUD. Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used crypto library that wasn't essentially compromised in one of its functions at one time or another. Not only that, professionals from the closed-source department have a long history of coming up with compromised or bogus, sometimes even ridiculous cryptographic algorithms and implementations. Two typical examples: CMEA cell phone encryption, and the Crypto AG backdoor debacle.

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

#147

Earlier 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…

Pretty sure 'char' in this case would be 32 bits.

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

#148
post #142

Earlier 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.

It's easier to write safer code in C++ but there's still many pitfalls and it's still a lot of effort. There's really nothing even remotely close to being practical?

Re: How I implemented my own crypto

#149

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.)

Proving correctness isn't enough. You have to test it too. It's perfectly possible for the proof to have errors (bugs). It's also possible for the proof to be incomplete: you can prove the algorithm is correct and implemented correctly to spec and still have vulnerabilities.

Re: How I implemented my own crypto

#150

Earlier 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

Woah that's pretty neat! Thanks!
Post reply on HN