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

171–180 of 409 posts

Re: How I implemented my own crypto

#171

Post by cyphar »

laumars wrote: post #168
cyphar wrote: post #123

Earlier quoted context omitted.

How do you expect people to become competent if you constantly tell them to not do something? All that will happen is that people who don't listen to warnings will write crypto libraries and everyone will be forced to use them because nobody else wrote one. The fact that there was no independent implementation of Argon2 that found there was a bug in the reference implementation shows that the " don't roll your own "…

Again I feel the need to reiterate that the rule only needs to apply to those it needs explaining to. Ie nobody who is smart enough to roll their library would not do so for a production system without it having undergone rigorous testing first. Sure we might write hobby projects (I've written my own encryption ciphers for fun) but that's very different from actually using said cipher on live and/or business critical…

I agree with what you're saying in general, that people should not write a crypto library unless they have a strong need to and are going to have it thoroughly audited.

> Simply put, the rule is there to remind people that rolling your own crypto libraries is dangerous. It's not meant to be taken literally to the daft extremes that yourself and a few others on here have.

My problem is that this nuance is not present in the statement "don't roll your own crypto". And that lack of nuance leads to no competing Argon2 implementation, and having OpenSSL control the future of TLS.

It's not just a few people who have taken it "literally to the daft extremes". Nobody in the entire crypto community re-implemented Argon2, not even as a hobby project. The message "don't roll your own crypto" is too strong because it results in nobody implementing their own crypto for any reason (which should not be surprising given the mantra).

Re: How I implemented my own crypto

#172

Post by simias »

int_19h wrote: post #100
simias wrote: post #51

Earlier quoted context omitted.

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 diffe…

> We've had to wait till C99 to get stdint.h, clearly portability is kind of an afterthought in C. C provided "at least N bits" guarantees for its integer types since its first standard (for the curious: char at least 8-bit, short at least 16-bit, long at least 32-bit; in C99, long long as least 64-bit). This is the most that you can get if you want absolute portability, because there are architectures out there wher…

Sure but as as said in an other comment in this thread those "at least N bits" guarantees are not very practical.

Suppose you want to give a unique id to users of your application. Clearly 16bit is a bit small, you might get more than 65535 users. You'll probably want 32bits to be comfortable (unless you're google or facebook I guess).

So what type do you use? On any modern 32 or 64bit computer "unsigned int" would do the trick but if you want to be portable then you can't assume that "unsigned int" is more than 16 bits. So you have to use long instead.

But then that makes your type 64bits on modern computers. Completely overkill. If this id is used all over the place it will significantly increase the memory footprint and could hurt performance as well.

In truth when you write an application you never really care about the size of the CPU registers outside of device drivers. What you want to say is "I have this value that I estimate will max out at N, find me the fastest type where that fits".

So in the end, pre-stdint everybody would use machine-specific typedefs to do just that, portability be damned. In particular any big C library ended up doing that (glib has "gint8", "gint16", Qt has "qint8", "qint16, etc, libpng has "png_uint_16", "png_uint_32", etc...). Clearly people were not fine just using the minimum requirements of the standard.

>Types like int32_least_t and int32_fast_t are unconditionally supported, but they don't give you anything that you didn't have before.

But they do! Pre-C99 there's no way to say "I want a type that's at least 32bits and as fast as possible" or "I want a type that's at least 32bits but as small as possible". "int" could potentially be 16bits and "long" could be unnecessarily large, wasting RAM and cache. The only way to have this functionality was to use architecture-specific definitions.

Re: How I implemented my own crypto

#173

Post by mathieubordere »

cyphar wrote: post #123
laumars wrote: post #20

Earlier quoted context omitted.

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 th…

How do you expect people to become competent if you constantly tell them to not do something? All that will happen is that people who don't listen to warnings will write crypto libraries and everyone will be forced to use them because nobody else wrote one. The fact that there was no independent implementation of Argon2 that found there was a bug in the reference implementation shows that the " don't roll your own "…

I believe it should read "Don't roll your own crypto for use in a production environment", but that doesn't sound very catchy.

Re: How I implemented my own crypto

#174

Post by dsacco »

w8rbt wrote: post #142
seanwilson wrote: post #116

Earlier quoted context omitted.

> 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." Are there any practical alternatives when that kind of portability is needed? What about trans…

Yes, C++. It's the only practical, safe alternative to C.

Can you clarify what you mean by "practical"?

Re: How I implemented my own crypto

#175

Post by madez »

dsacco wrote: post #159
madez wrote: post #152

Earlier quoted context omitted.

You can do crypto as a side-hobby and safely put it into production. Of course, you can also do it wrong, but it is with little work possible to do it correctly. Normally I wouldn't speak against what you said because the critique is only very minor, but I heard this too often. Your warning is too strong. People should try their own crypto and with little care it is not unsafer. Maybe giving a list of do's for that w…

> You can do crypto as a side-hobby and safely put it into production. No, you really can't, unless you stretch the definition of "side-hobby" to the point of breaking at the seams. I'd be shocked if a single person who professionally works in security or cryptography is going to agree with you in this thread. You need far more than a "little care" to assure that a new cryptographic library is safe. It's an endeavor…

We are talking in vague terms, but assume you want to encrypt some offline data.

- You can just use any recommended (by whom?) tool.

- Or you encrypt it with recommended tool with it's own dedicated key. Then you encrypt it again by whatever way you made up in five minutes, and you need only to ensure you didn't use the key material of the recommended tool. Then there you go, you just rolled your own not-unsafer crypto.

Re: How I implemented my own crypto

#176

Post by simias »

taneq wrote: post #147
raverbashing wrote: post #136

Earlier quoted context omitted.

Good explanation And to me this shows clearly that we shouldn't be using C then. If an arch can't address an 8 bit sized element there are two choices for what happens if you write: char *a = "test"; char x = a[1]; Either char takes 32bytes or the a[1] read will shuffle the bytes to get a 32bit value whose least significant digits are a[1] And saying that int32_t are "conditionally supported" is really proof we're ma…

Pretty sure 'char' in this case would be 32 bits. Arguing that C shouldn't support microcontrollers seems a bit unfair. What should embedded software engineers use, if not "high level assembler"? There are plenty of modern languages that sacrifice performance in order to be fully hardware agnostic.

I agree that the jab at microcontrollers is unwarranted (after all, I do want to be able to program microcontrollers in Rust!)

But you could still have any-bit integers even on an 8 bit processor, you'd just have to emulate them.

Clearly that's not really in the spirit of C which is probably why the standard doesn't force the compiler to implement those, instead relying on the coder to make a decision.

But that just proves my original point: C is not about portability. It's about writing fast code on any architecture. If portability was the concern the standard would make fixed-width integers mandatory and would define things like signed overflow, forcing the compilers to emulate the behavior when the hardware doesn't behave in the same way.

That's what portable languages do, that's what Rust does.

Re: How I implemented my own crypto

#177

Post by loup-vaillant »

Piskvorrr wrote: post #121
msl09 wrote: post #104

Earlier quoted context omitted.

Hey, like you I decided to dive into cryptography coming from a different background. Although this quote is not directly related to your problem it can be safely applied to it: "Almost certainly you will get the urge to invent new cryptographic algorithms, and will believe that they are unbreakable. Don't resist the urge; this is one of the fun parts. But resist the belief; almost certainly your creations will be br…

Note that the author is not inventing crypto algorithms, rather implementing them (although the part about XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line). Still a risky business, and tricky to get right, but several orders of magnitude safer than "hey, what if we just XORed everything with a random number? Unbreakable, eh?"

> the part about XChaCha20 being a mix of ChaCha20 and XSalsa20 is IMHO dancing on the line

It was a few months ago. Then Libsodium danced on the same line, and I was able to compare the results (they behave the same, phew).

It's not inventing crypto either: it's a straightforward application of what was done to Salsa20. The security reduction that worked for XSalsa20 (guaranteed secure if Salsa20 is secure) applies to XChacha20 as well.

Re: How I implemented my own crypto

#178

Post by BlackFingolfin »

dsacco wrote: post #169
JohnStrange wrote: post #146

Earlier quoted context omitted.

I apologize if that sounds dismissive (it's not intended to) but your post is not more than the usual vague FUD. Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used…

So I have two points for you: > Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used crypto library that wasn't essentially compromised in one of its functions at one…

While I actually mostly agree with you, I feel I need to point this out... You write: > I will point out that a network protocol is not designed to be error-proof in an intentionally antagonistic environment, which is a difficulty unique to cryptographic software.

But that's actually not true, at least not anymore. People attack protocols on the internet all the time, and it's a difficult task to harden them against that.

That said, it doesn't really take aware from your point, I think; but rather confirms it: Think twice before rolling your own network protocols (at least if they are meant to be used in large scale on the open internet), be aware of all the complicated pitfalls.

Re: How I implemented my own crypto

#179

Post by ZoFreX »

DanBC wrote: post #164
madez wrote: post #152

Earlier quoted context omitted.

You can do crypto as a side-hobby and safely put it into production. Of course, you can also do it wrong, but it is with little work possible to do it correctly. Normally I wouldn't speak against what you said because the critique is only very minor, but I heard this too often. Your warning is too strong. People should try their own crypto and with little care it is not unsafer. Maybe giving a list of do's for that w…

> Of course, you can also do it wrong, but it is with little work possible to do it correctly. GCHQ loves people who think this. Have a look at some of the game console cryptography. These are companies with strong financial incentive to get it right. They're large well funded multinational organisations. They still get it wrong.

Game companies are a great example because:

1) they invest 6 or 7 figures in this (piracy prevention is big money)

2) they still get it wrong

3) they not only get it wrong, they get in wrong in ways that teenagers still in high school can break, let alone the NSA

Re: How I implemented my own crypto

#180

Post by madez »

DanBC wrote: post #164
madez wrote: post #152

Earlier quoted context omitted.

You can do crypto as a side-hobby and safely put it into production. Of course, you can also do it wrong, but it is with little work possible to do it correctly. Normally I wouldn't speak against what you said because the critique is only very minor, but I heard this too often. Your warning is too strong. People should try their own crypto and with little care it is not unsafer. Maybe giving a list of do's for that w…

> Of course, you can also do it wrong, but it is with little work possible to do it correctly. GCHQ loves people who think this. Have a look at some of the game console cryptography. These are companies with strong financial incentive to get it right. They're large well funded multinational organisations. They still get it wrong.

Just look at the major used crypto libraries and their CVE's. Everybody gets it wrong. I consider that a sane and sound assumption.

But then you can combine stuff as I've for example written in another comment to roll your own crypto in five minutes, which is not-unsafer.

There is cult around "Don't roll your own crypto" that is thought-policing.

Post reply on HN