Live data from Hacker News

How I implemented my own crypto

loup-vaillant.fr

21–30 of 409 posts

Re: How I implemented my own crypto

#21
post #14

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?

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.

Re: How I implemented my own crypto

#22

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?

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

The sort of direct control one might look for is, as far as I know, only practically found in your processor's assembly language, and your operating system's collection of syscalls.

I think Rust, Common Lisp, OCaml, D, Haskell, and other languages give you a lot of benefits that are simply not worth giving up in a new crypto library, like safety.

Re: How I implemented my own crypto

#23
The v1.0.0 was published the day a bug was fixed and yet the first sentence of this post is "Monocypher is ready for production". Sure, OpenSSL has bugfixes on regular basis as well, but I believe that further fragmenting the crypto ecosystem with a new library and little commercial support to properly back it and pay for security audits is risky.

Re: How I implemented my own crypto

#24
post #3

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

"Hey y'all, hold my beer and look at this!" There are [1] several non-aviation examples:

- Blood transfusion

- Steam-powered bicycles

- Rotary printing presses

- Submarines

- Luminescent paint

- Hi-speed jet-powered railcars

- Ropes /pulleys to help the user get out of bed

[1] https://en.wikipedia.org/wiki/List_of_inventors_killed_by_th...

Re: How I implemented my own crypto

#25

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?

OCaml was used recently by the MirageOS folks to implement a better TLS than OpenSSL.

Re: How I implemented my own crypto

#26

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?

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.

Re: How I implemented my own crypto

#27
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.

This sounds weird to me, how is a shift (which only apply itself on the bit value, not the number value) triggering a sign extension? I don't think you're talking about integer promotion here unless you had a uint16_t = uint8_t << 24 or something like this.

Re: How I implemented my own crypto

#28
post #7
post #3

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

Parachute?

You don't have to be an expert to make/jump the actual parachute/canopy. As long as the harness, container and reserve are TSO'd you're good to go. It's a lot of work though, at least for a ram-air.

EDIT: Some interesting discussion here: http://www.dropzone.com/cgi-bin/forum/gforum.cgi?post=482241...

Re: How I implemented my own crypto

#29

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?

TLS has been subject to lots of formal verification. The other things, probably not so much.

Verifying some (but not all) properties of crypto is relatively (but not absolutely) easy, because it's essentially just math with pure functions. Operating systems and physical controllers with real-time constraints have different requirements and more interacting state, which means that the desired properties are not easily expressed as a mathematical expression.

Re: How I implemented my own crypto

#30
post #23

The v1.0.0 was published the day a bug was fixed and yet the first sentence of this post is "Monocypher is ready for production". Sure, OpenSSL has bugfixes on regular basis as well, but I believe that further fragmenting the crypto ecosystem with a new library and little commercial support to properly back it and pay for security audits is risky.

It's risky but sometimes it's the only way. To be fair the code size is relatively small so it should be easier to audit than other products. My guess is that his blog post is also some motivation to get new pair of eyes on the library. If there's any fund for that, I'd be happy to look at it ;)
Post reply on HN