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

51–60 of 409 posts

Re: How I implemented my own crypto

#51

Post by simias »

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?

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 different architecture however, which is probably where this argument stems from. Remember when we switched from 32 to 64bits? How many codebases managed to make the jump painlessly?

Re: How I implemented my own crypto

#52

Post by pjmlp »

bandook_raja wrote: post #39
pjmlp wrote: post #31

Earlier quoted context omitted.

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.

That just is quite ironic, because it is even version dependent across releases of the same compiler, which means anything fine tuned for version X can break on version X + 1, due to changes on the optimizer.

And I doubt anyone is regularly reviewing the produced Assembly every single time they change compilers.

Assembly doesn't have more than 200 documented cases that hardly any human is capable of remembering.

Re: How I implemented my own crypto

#53

Post by bananaboy »

TheAceOfHearts wrote: post #45
pjmlp wrote: post #31

Earlier quoted context omitted.

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…

Aren't all undocumented instructions / opcodes actually UB? If you execute an undocumented instruction the processor has to do something.

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.

Re: How I implemented my own crypto

#54

Post by _Codemonkeyism »

vasco wrote: post #40
willtim wrote: post #21

Earlier quoted context omitted.

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.

The difference is: Do I have to write the code to make it portable or does the language developers write that code.

Re: How I implemented my own crypto

#55

Post by bananaboy »

jwl wrote: post #33
rootlocus wrote: post #16

Earlier quoted context omitted.

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.

Yeah and imagine the kind of exciting bugs that exist in new and immature libraries! :)

Re: How I implemented my own crypto

#56

Post by SmallDeadGuy »

reikonomusha wrote: post #17
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?

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…

I would argue the other way. Something which requires a base implementation to be installed on a system which generates different machine code based on a single specification is less portable than a macro processor generating different versions of a program. Sure, people will have had something like python installed since a long time ago, but a new setup requires downloading 2 objects (the base implementation and the program) compared to a single one (a platform-specific copy of a program).

Re: How I implemented my own crypto

#57

Post by cromulent »

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 know a few guys who have manufactured their own canopies and harness/container systems in their garage, and I've jumped them - even though I consider these guys fallible :)

Re: How I implemented my own crypto

#58

Post by majewsky »

reikonomusha wrote: post #17
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?

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…

> Relying on a macro processor [...] isn't really representative of portability of a language and your code.

I would argue that the C preprocessor is, for all intents and purposes, part of the C language. C is not quite practical without its preprocessor, and the preprocessor is not quite practical with any language other than C (or a derivative like C++).

Re: How I implemented my own crypto

#59

Post by reikonomusha »

SmallDeadGuy wrote: post #56
reikonomusha wrote: post #17

Earlier quoted context omitted.

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…

I would argue the other way. Something which requires a base implementation to be installed on a system which generates different machine code based on a single specification is less portable than a macro processor generating different versions of a program. Sure, people will have had something like python installed since a long time ago, but a new setup requires downloading 2 objects (the base implementation and the…

You still need to download two objects: the C code and the C compiler, even if the C code has already been processed.

Edit: Not to mention libc, libm, and the like.

Re: How I implemented my own crypto

#60

Post by jwl »

bananaboy wrote: post #55
jwl wrote: post #33

Earlier quoted context omitted.

But then again, we still got Heartbleed.

Yeah and imagine the kind of exciting bugs that exist in new and immature libraries! :)

Yes, but are hackers going after common used libraries to get more vulnerable systems to attack or are they going to spend time on some unknown homebuilt crypto? In some cases, security through obscurity works well in practice.
Post reply on HN