Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I implemented my own crypto

loup-vaillant.fr

Post reply on HN
Print view View original

31–40 of 409 posts

Re: How I implemented my own crypto

#31

Post by pjmlp »

thinkMOAR wrote: post #18
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?

Most programming languages with compilers to native code (JIT/AOT), the myth of high level Assembler for C only applies if your computer is a PDP-11 or a basic 8-bit CPU like a 6502 or Z80.

The ANSI C and C++ standards define the concept of abstract machine for the language semantics, just like in most languages.

Additionally you have the concepts of sequence points, the new memory model semantics for multi-threaded code and the beloved UB.

UB which doesn't exist in most languages, because their rather leave it implementation defined or lose the opportunity to target some strange CPU not able to support the language semantics.

Also Assembly doesn't has UB, making it ironic that it is safer to write straight Assembly at the expense of portability than C or C derived languages.

Re: How I implemented my own crypto

#32

Post by bandook_raja »

reikonomusha wrote: post #22
thinkMOAR wrote: post #18

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…

Rust doesn't even exist on a plethora of platforms which C targets. I have high hopes with D and give or take ~2 years, it'll be able to progress forward in lots of domains. Not sure about other languages.

Re: How I implemented my own crypto

#33

Post by jwl »

rootlocus wrote: post #16
timclark wrote: post #12

Earlier quoted context omitted.

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.

But then again, we still got Heartbleed.

Re: How I implemented my own crypto

#34

Post by kabouseng »

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?

Actually you do roll your own parachute once you have done enough jumps. But your reserve chute is always rolled by a certified professional specifically certified to roll reserve chutes, and not by yourself. (if I remember correctly, my memory is a bit fuzzy from when I jumped a couple of years back)

Re: How I implemented my own crypto

#35

Post by pjmlp »

adwn wrote: post #26
reikonomusha wrote: post #22

Earlier quoted context omitted.

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.

Writing unidiomatic code would still be compliant with the Haskell Language Report, compiled by an Haskell compiler and safer than plain C code.

Re: How I implemented my own crypto

#36

Post by ktta »

I'm amazed that the reference implementation of Argon2 had a bug. So that means anyone who deployed Argon2 today didn't really use Argon2 (I'm being pedantic), but something else?

libsodium also got it wrong, so that brought down my opinion of it being a trusted and well-reviewed library.

Now the question is, will they continue to use the same implementation or move to the fixed code?

Re: How I implemented my own crypto

#37

Post by diegoperini »

adwn wrote: post #26
reikonomusha wrote: post #22

Earlier quoted context omitted.

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.

Honest question: What makes you think you can't mitigate? A̶ ̶t̶y̶p̶e̶s̶a̶f̶e̶ ̶c̶r̶y̶p̶t̶o̶ ̶t̶h̶a̶t̶ ̶m̶e̶a̶s̶u̶r̶e̶s̶ ̶i̶t̶s̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶ ̶t̶i̶m̶e̶ ̶a̶p̶p̶e̶n̶d̶e̶d̶ ̶w̶i̶t̶h̶ ̶a̶ ̶f̶i̶n̶a̶l̶ ̶d̶e̶l̶a̶y̶ ̶t̶i̶m̶e̶ ̶r̶e̶a̶d̶ ̶f̶r̶o̶m̶ ̶/̶d̶e̶v̶/̶u̶r̶a̶n̶d̶o̶m̶ ̶c̶a̶n̶ ̶s̶t̶i̶l̶l̶ ̶b̶e̶ ̶i̶d̶i̶o̶m̶a̶t̶i̶c̶.̶ It has to be monadic, that is for sure but abstracting a crypto algorithm as IO is actually treating it as a device which sounds like a safe metaphor.

Edit: Whoah, why the hate? :(

Re: How I implemented my own crypto

#38

Post by pjmlp »

bandook_raja wrote: post #32
reikonomusha wrote: post #22

Earlier quoted context omitted.

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…

Rust doesn't even exist on a plethora of platforms which C targets. I have high hopes with D and give or take ~2 years, it'll be able to progress forward in lots of domains. Not sure about other languages.

That is a matter of tooling, though.

Until the early 90's C had hardly any meaning outside big expensive UNIX boxes.

And it was already on its way out on Windows and OS/2, if it wasn't for the rise of FOSS software and its dependency on C.

Re: How I implemented my own crypto

#39

Post by bandook_raja »

pjmlp wrote: post #31
thinkMOAR wrote: post #18

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?

Most programming languages with compilers to native code (JIT/AOT), the myth of high level Assembler for C only applies if your computer is a PDP-11 or a basic 8-bit CPU like a 6502 or Z80. The ANSI C and C++ standards define the concept of abstract machine for the language semantics, just like in most languages. Additionally you have the concepts of sequence points, the new memory model semantics for multi-threaded…

> Also Assembly doesn't has UB, making it ironic that it is safer to write straight Assembly at the expense of portability than C or C derived languages.

You just need to know your compiler flags/configuration to produce exact assembly output (if you want that). And about assembly not having UB, BSF and BSR are pretty good examples for that.

Re: How I implemented my own crypto

#40

Post by vasco »

willtim wrote: post #21
taneq wrote: post #14

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?

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.

Just because you don't see those ugly macros to make your pure high level language portable, doesn't mean they're not there, somewhere.
Post reply on HN