Hacker News Reader

Comment by gamache | Hacker News Reader

> Know this: Krypton is more than just a blockchain or another cryptocurrency. We will survive these attacks, even if it means staying on the POS chain, in order to protect KR investments, until we do the complete rewrite of our client platform in a more secure language, like C.

What could possibly go wrong?

View on HN

I was scared by the mention of migrating all code from etherum to bitcoin blockchain in just one night.

Funny, was literally about to post the same thing!

Any chance this was meant as sarcasm? As in, they're suggesting that even C is more secure than what Ethereum has developed?

It has nothing to do with Ethereum. This Krypton chain has a very minuscule hashpower so it's susceptible to attacks. It would happen with any Proof of Work chain. She is moving to a Proof of Stake which requires +- 51% of the ownership total coins to execute an attack like this.

Same thought. But then may be Krypton Dev is wise enough to sort out his stuff.

A great hacker could maybe do it in C -- maybe even in a one-night coding spree -- but a wise hacker in 2016 wouldn't try.

C can be secure if you follow best practices (yes, big if). Are BSD, Linux and Postgres secure?

Maybe

Which BSD? Postgres "maybe", Linux hell no. Constant kernel exploits

Postgres isn't written in standard C. It's written in a derivative of C where signed integer overflow is defined as two's-complement and the strict aliasing rule is removed. Most standard C compilers also support this variant language with the compile options -fwrapv -fno-strict-aliasing.

https://www.postgresql.org/message-id/1689.1134422394@sss.pg...

If you're going to use Postgres as an example of writing secure code in a language, that's fine, but make sure you're advocating for this C variant and not for standard C. Standard C, where signed integer overflow is undefined and the strict aliasing rule exists, is extremely hard to write secure code in.

http://blog.regehr.org/archives/1307

(There's also the separate issue that most of the input paths into Postgres are trusted in some way: you don't expect malformed database files, and you often don't expect hostile queries. It's primarily the auth code that needs to be rock-solid, which is a relatively small piece of the software.)

Yea, postgres certainly assumes a lot more than the standard guarantees. Besides the above, if you look at it formally, it's pretty much impossible to have a multi-process program, connected over shared memory, that's actually fully standard compliant. Especially not when using a pre C11 environment (postgres requires C89).

I think we really should have "official" variants of C that are a bit more predictable. But I guess that's not happening.

Oh, and whoever designed the strict aliasing specs: To me they seem widely impractical. The fact that there's essentially no way to explicitly alias, without memcpy'ing, is just absurd. The standard's language is also so cryptic, that well versed people (like Regehr you linked to) can't agree with each other what the exact requirements are. The union aliasing trick isn't, to my knowledge, actually precisely standards conforming.

No.

https://www.openbsd.org/errata59.html (although of course OpenBSD is pretty decent generally)

https://www.cvedetails.com/vulnerability-list/vendor_id-6/Fr...

https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...

https://www.cvedetails.com/vulnerability-list/vendor_id-336/...

Reply on news.ycombinator.com