How I implemented my own crypto • Hacker News Board

Re: How I implemented my own crypto

#181

Post by user5994461 » Thu, Aug 03, 2017, 1:03 PM UTC

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.

Who says they are trying to make it right?

They just need to make it hard enough to delay pirated games.

Re: How I implemented my own crypto

#182

Post by user5994461 » Thu, Aug 03, 2017, 1:05 PM UTC

ktta wrote: post #105

loup-vaillant wrote: post #98

Earlier quoted context omitted.

Maybe the authors will fix the code in subsequent versions of Argon2. Right now, backward compatibility is deemed more important. The effects of this bug are practically negligible anyway. I bet a single bit of additional entropy in a password would compensate that a hundred fold. I'm a bit disappointed however at their not updating the specs. I signalled the bug in January, and the latest version of the appear to ha…

I'm also referring to the orgs who used Argon2 in production. If they move to the fixed version of Argon2 in libsodium, they'll have to make a plan to securely move to the correct implementation by hashing the passwords again. It can be done, but I'm wondering if they'll even bother.

There is hardly anyone using Argon in production.

The few hipsters who jumped on the new hashing algorithm bandwagon can't have much users.

Re: How I implemented my own crypto

#183

Post by ZoFreX » Thu, Aug 03, 2017, 1:06 PM UTC

JohnStrange wrote: post #146

ZoFreX wrote: post #75

I am terrified that I do not consider myself competent enough to write a crypto library, and yet there isn't a single mention - in this article, nor at the time of writing the comments here on Hacker News - of many of the pitfalls I know to avoid when undertaking such an endeavour. There is even a list of "you have to do A, B, C, and that's about it" that is missing some major - well known, even! - items. I know "don…

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…

As I said I'm not a fan of the phrase "don't roll your own crypto". I don't disagree that that (obviously!) prevents new crypto libraries being written. But if you're going to do it, you damn well do it right, and these days that means an amount of work that would likely total millions of dollars. If you aren't going to do it right, don't cut a 1.0 and use it in production.

Sidenote: how we started these things historically is not relevant anymore. We have learned a lot since then. Failing to "stand on the shoulders of giants" and learn from history is one the biggest factors that makes home-rolled crypto so easy to break - they are doomed to repeat the mistakes of history. Mistakes that are nowadays well documented and well known.

Re: How I implemented my own crypto

#184

Post by jancsika » Thu, Aug 03, 2017, 1:07 PM UTC

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…

> This doesn't diminish the claim that the modal individual should not attempt to "roll their own crypto."

Just wanted to point out that "individual-should-not-attempt-to-roll-their-own-crypto" is ambiguous and unnecessarily antagonistic while the paragraph quoted above from Schneier is clear and difficult to argue with.

"As simple as possible but no simpler" applies quite well to summaries, esp. when they regard cryptography.

Re: How I implemented my own crypto

#185

Post by arcticbull » Thu, Aug 03, 2017, 1:08 PM UTC

loup-vaillant wrote: post #81

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…

> The author's lack of practical familiarity with the memory hierarchy, caching, and pipelining Maybe I didn't express myself clearly. I knew loading stuff word by word would be much faster, thanks to my knowledge of the memory hierarchy, caching, and pipelining. What I didn't expect was the magnitude of the overall impact. The core round functions are much, much faster that I had anticipated. I didn't think the load…

One of the major Rust design goals is simple C ABI compatibility, and it delivers there. That it's LLVM only appears to me irrelevant, as the generated libraries can be linked anywhere, and the specifics of how the Rust compiler are built are out of scope. So long as you get rustc up and running, what does it matter it's architecture?

If you're curious, check this out: https://doc.rust-lang.org/1.5.0/book/ffi.html

> I would totally recommend to rewrite the whole thing in Rust for Rust projects, though.

Any time you rewrite anything, you run the risk of introducing new and unexpected bugs, and you're just doing unnecessary, complex work fraught with pitfalls (doubly so here) -- generally a Rust project would create a wrapper around the C code, invoke the methods and expose idiomatic APIs on top to avoid just that.

This is my go-to article on re-writing things and why not to: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

To be clear I'm not saying you made a mis-step, just that your arguments for it don't seem at first glance to support your decision.

Re: How I implemented my own crypto

#186

Post by ZoFreX » Thu, Aug 03, 2017, 1:08 PM UTC

jwl wrote: post #109

ZoFreX wrote: post #87

Earlier quoted context omitted.

> In some cases, security through obscurity works well in practice. This is not one of those cases. Absolutely not. I'm moderately competent at finding security bugs in things, but I doubt I could find any in OpenSSL. I am confident I could find some in your average hand-rolled code. The thing is people make the same mistakes. There's a set of well-known mistakes that are very easy to make, especially if you're not v…

You got to consider your most likely risk for attack. Targeted or at random by a botnet? For example, you are most likely more secure in practice by writing your own website than using Wordpress, simply because you are more likely to get hit by a botnet targeting every Wordpress site than someone going directly for you.

This is off-topic. We are talking about security vs obscurity in the context of cryptography libraries.

Re: How I implemented my own crypto

#187

Post by pzduniak » Thu, Aug 03, 2017, 1:09 PM UTC

inopinatus wrote: post #71

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?

- Terms & conditions of use - Chocolate soufflé - Distributed lock manager - Autonomous war robot - init(1) replacement I am personally guilty of attempting four of these things without adequate preparation or expertise.

I seriously hope that you didn't try to write an init(1) replacement!

Re: How I implemented my own crypto

#188

Post by ramphastidae » Thu, Aug 03, 2017, 1:09 PM UTC

IncRnd wrote: post #156

pkolaczk wrote: post #128

Earlier quoted context omitted.

What's wrong with xoring with a stream of random numbers? Isn't it how stream ciphers work? Get a good cryptographic RNG, initialize it properly with a long enough key and you should be fine.

You're right about the theory, but you're also wrong about how to implement - which is the point of telling people not to roll their own crypto. What about reseeding or prediction resistance? How do you handle biased entropy input from that hairdryer someone is blowing on your chips? Oops, the quantum random number generator card doesn't work anymore after adding that extra GPGPU to the system.

> How do you handle biased entropy input from that hairdryer someone is blowing on your chips?

Sounds fascinating. Can you please tell us more?

Re: How I implemented my own crypto

#189

Post by dsacco » Thu, Aug 03, 2017, 1:10 PM UTC

madez wrote: post #175

dsacco wrote: post #159

Earlier quoted context omitted.

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

That is not rolling your own crypto. Rolling your own would be relying on your custom construction, not double encrypting and relying on the known construction for safety.

...Furthermore I'm confused as to why someone would do that. If you already have a safe way to encrypt your plaintext and you're the only one with both keys, why would you bother double encrypting? You gain absolutely nothing because it's redundant, and you lose performance.

What you're doing is tantamount to a weird sort of encoding that doesn't offer any benefit.

Re: How I implemented my own crypto

#190

Post by madez » Thu, Aug 03, 2017, 1:15 PM UTC

dsacco wrote: post #189

madez wrote: post #175

Earlier quoted context omitted.

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

That is not rolling your own crypto. Rolling your own would be relying on your custom construction, not double encrypting and relying on the known construction for safety. ...Furthermore I'm confused as to why someone would do that. If you already have a safe way to encrypt your plaintext and you're the only one with both keys, why would you bother double encrypting? You gain absolutely nothing because it's redundant…

Doing your own encryption does clearly not exclude also using other encryption. Or is implementing AES already not anymore doing your own encryption, because AES wasn't invented by you? You _always_ use work of others.

Doing your own crypto can be used as way to safeguard against unknown vulnerabilities in the tools you would use otherwise. If the recommended library is safe, then fine, you are good to go. How do we know it is safe?

My idea above is a way to increase the safety margin in a way that is orthogonal to the increase of the key space of the recommended tool. That sounds like a very good thing to me.