How I implemented my own crypto • Hacker News Board

Re: How I implemented my own crypto

#11

Post by reikonomusha » Thu, Aug 03, 2017, 7:34 AM UTC

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 not surprise me when more show themselves.

The author's lack of practical familiarity with the memory hierarchy, caching, and pipelining—evidenced by his surprise by the speed gained by fetching more than a byte at a time—also makes me suspicious of his understanding of the semantics of his program. (I understand that this is a form of ad hominem as it relates to arguing the correctness of software, but it's a consideration worth noting in a broader context of trust.)

It would be great if this was written in another language.

[0] Most "portable" code written in C is not portable. Look at any mature C project and see the layers and layers of macros and hacks to make things portable.

Re: How I implemented my own crypto

#12

Post by timclark » Thu, Aug 03, 2017, 7:34 AM UTC

mathieubordere wrote: post #4

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?

Re: How I implemented my own crypto

#13

Post by cyphar » Thu, Aug 03, 2017, 7:36 AM UTC

mathieubordere wrote: post #4

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.

Interestingly it looks like there was a bug in every Argon2 implementation specifically because everyone just used the reference implementation.

Personally, I think the intention of the phrase "don't roll your own crypto" was lost over time. It was advice to companies to use standard cryptographic algorithms rather than everyone coming up with their own thing for no good reason. It doesn't mean that only some blessed individuals should be allowed to write cryptographic software. I think OpenSSL has taught us that not rolling your own crypto results in a monoculture of self-professed experts that didn't follow that advice.

Re: How I implemented my own crypto

#14

Post by taneq » Thu, Aug 03, 2017, 7:41 AM UTC

reikonomusha wrote: post #11

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…

> 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?

Re: How I implemented my own crypto

#15

Post by karrotwaltz » Thu, Aug 03, 2017, 7:43 AM UTC

dlgeek wrote: post #7

sigjuice wrote: post #3

Are there other fields where the slogan "don't roll your own XXX unless you are an infallible expert" is applicable?

Parachute?

I'm not sure about "don't roll your own parachute" as it should be common sense, but well, in 1912 a parachute inventor died while testing his creation.

https://en.wikipedia.org/wiki/Franz_Reichelt

Re: How I implemented my own crypto

#16

Post by rootlocus » Thu, Aug 03, 2017, 7:45 AM UTC

timclark wrote: post #12

mathieubordere wrote: post #4

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?

Through sweat and blood. Don't expect crypto libraries to be secure the first few years after their release. That's why people favor the mature, battle-tested libraries.

Re: How I implemented my own crypto

#17

Post by reikonomusha » Thu, Aug 03, 2017, 7:49 AM UTC

taneq wrote: post #14

reikonomusha wrote: post #11

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…

> 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?

Relying on a macro processor to patch and bandage your program at compile time depending on a collection of symbolic features isn't really representative of portability of a language and your code. To me, that is brute forcing portability, and is a web of conditional inclusions/exclusions that needs to be maintained and added to per-architecture and per-OS.

Something that is, in some sense, truly portable is one that has a single specification that runs on all platforms the base implementation supports. Virtual machines and certain styles of language standard are often able to accomplish portability for a vast number of applications.

Re: How I implemented my own crypto

#18

Post by thinkMOAR » Thu, Aug 03, 2017, 7:49 AM UTC

reikonomusha wrote: post #11

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?

Re: How I implemented my own crypto

#19

Post by 2bitencryption » Thu, Aug 03, 2017, 7:55 AM UTC

AstralStorm wrote: post #9

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'm sure you encounter "high assurance code" like this every day -- your operating system, the secure protocol used to post your comment, the controls for your Anti-Lock Breaking System in your car.

How much of those were formally proven?

Re: How I implemented my own crypto

#20

Post by laumars » Thu, Aug 03, 2017, 7:55 AM UTC

cyphar wrote: post #13

mathieubordere wrote: post #4

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.

Interestingly it looks like there was a bug in every Argon2 implementation specifically because everyone just used the reference implementation. Personally, I think the intention of the phrase "don't roll your own crypto" was lost over time. It was advice to companies to use standard cryptographic algorithms rather than everyone coming up with their own thing for no good reason. It doesn't mean that only some blessed…

Those are two separate arguments. Of course there should be competition in crypto libraries. However the "don't roll your own" advice is to prevent people who don't have sufficient experience, education nor resources to write their own library that can compete - effectively leaving their systems vulnerable.

The thing about the "don't roll your own" advice is it's aimed at people who don't competently know what they're doing rather than those who do.