71–80 of 409 posts
Are there other fields where the slogan "don't roll your own XXX unless you are an infallible expert" is applicable?
- Chocolate soufflé
- Distributed lock manager
- Autonomous war robot
- init(1) replacement
I am personally guilty of attempting four of these things without adequate preparation or expertise.
I've always seen 'rolling your own crypto' as not being recommendation against writing your own library, but creating your own primitive. 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 de…
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 libsodium instead of rolling your own library. Maybe turn the "I want the smaller version without the huge lookup table please" in a compile time option or so. That way more people could have used it without having to commit to "I'll use this little known experimental library instead of libsodium". Commit in the sense of "people will ask why and I will have to defend my decision", not in the sense of "oh no we are locked in!!"
First let me say that I've followed your work a bit and I'm really impressed with the library. I'm currently planning on rolling my own crypto as well and your library is on my list of the things to look at. One question: > I was shifting a uint8_t, 24 bits to the left. I failed to realise that integer promotion means this unsigned byte would be converted to a signed integer, and overflow if the byte exceeded 127. Th…
> Each of the operands shall have integer type.
> The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand.
6.3.1.1 § 2
> If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions.
So if you shift a uint8_t, it is first converted to a (machine-dependent) signed int, then shifted, then converted to whatever the expression type ends up being.
I know "don't roll your own crypto" comes across as dismissive or patronising. I'm not a huge fan of the phrasing. But as a first-order approximation, it is correct. If you want to roll your own crypto, that needs to be your _thing_. It's very unlikely you're going to be a fantastic full-stack web developer _and_ be able to do that. If it's really what you want to do then awesome! Go study it, learn it, practice it. But if you're doing it as a side-hobby, never put it into production.
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.)
First let me say that I've followed your work a bit and I'm really impressed with the library. I'm currently planning on rolling my own crypto as well and your library is on my list of the things to look at. One question: > I was shifting a uint8_t, 24 bits to the left. I failed to realise that integer promotion means this unsigned byte would be converted to a signed integer, and overflow if the byte exceeded 127. Th…
If you say "foo + 3", and foo is a uint8_t, then 3 is technically an int, so the addition will do an integer promotion. If you say "foo + bar" and both are uint8_t, then both will be promoted to integer. That's how C works. Assigning the result to another uint8_t will truncate it. Please do not write your own crypto library until you really understand how C works, especially including this kind of detail.
Your example is different, this is because you're doing an addition. I can see how this could be a problem if you want to do a rotation (a > 60) and hence why you should use a ^ instead of a + here (example: https://github.com/gvanas/KeccakCodePackage/blob/master/SnP/... )
Earlier quoted context omitted.
> Look at any mature C project and see the layers and layers of macros and hacks to make things portable. So.. it's portable, then?
We've had to wait till C99 to get stdint.h, clearly portability is kind of an afterthought in C. C is meant to map easily to a wide range of hardware without overhead, conceptually it's almost the opposite of portability since it precludes creating standard abstractions that would hold true across architectures as those could not map to native functionality across the board. It's easy to compile C programs on a diffe…
Also, portability isn't a binary attribute. For every way two platforms vary, there are often a subset of states and transitions that are identical, and two disjoint subsets that are different.
As long as your inputs start out in the identical subset and don't wander too far, you're good to go. For example, if you never put a value above 32767 into an int, you don't really care whether your int is 16 or 32 bits in size. If that int is e.g. line number in a file, it may mean that your program works fine on most files, but only the 32-bit version works correctly on large files. And of course the cleverer you are the closer you're likely to skate to the edge of the common intersection.
First let me say that I've followed your work a bit and I'm really impressed with the library. I'm currently planning on rolling my own crypto as well and your library is on my list of the things to look at. One question: > I was shifting a uint8_t, 24 bits to the left. I failed to realise that integer promotion means this unsigned byte would be converted to a signed integer, and overflow if the byte exceeded 127. Th…
6.5.7 Bitwise shift operators > Each of the operands shall have integer type. > The integer promotions are performed on each of the operands. The type of the result is that of the promoted left operand. 6.3.1.1 § 2 > If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called th…
First let me say that I've followed your work a bit and I'm really impressed with the library. I'm currently planning on rolling my own crypto as well and your library is on my list of the things to look at. One question: > I was shifting a uint8_t, 24 bits to the left. I failed to realise that integer promotion means this unsigned byte would be converted to a signed integer, and overflow if the byte exceeded 127. Th…
I believe this[1] is the patch that fixes this bug. I tried to reproduce the behavior but couldn't succeed. Maybe I was doing something wrong. Would really appreciate it if someone here could show a test case where this matters. [1] https://github.com/LoupVaillant/Monocypher/commit/347189c50c...
[1]: https://github.com/LoupVaillant/Monocypher/blob/master/src/m...