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

241–250 of 409 posts

Re: How I implemented my own crypto

#241

Post by loup-vaillant »

arcticbull wrote: post #185
loup-vaillant wrote: post #81

Earlier quoted context omitted.

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

> One of the major Rust design goals is simple C ABI compatibility, and it delivers there.

I was just telling one has to write a wrapper either way. Idiomatic Rust is not idiomatic C, so you would need to have a "C ABI" interface in addition to the clean Rust interface.

> That it's LLVM only appears to me irrelevant […]

Not if it targets less platforms than GCC. Though that will likely matter less and less in the future.

> So long as you get rustc up and running, what does it matter it's architecture?

You have to get it up and running. You have another build step. You have to use a binary library (can't just include the source code). It's not much, but I want to maximise ease of deployment.

Re: How I implemented my own crypto

#242

Post by dsacco »

bascule wrote: post #230
jmulho wrote: post #223

Earlier quoted context omitted.

> "If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot" I've never understood this argument. Encryption algorithms are deterministic. If you implement a known good algorithm on your own, and it gets the same outputs given the same inputs, then you are highly unlikely to shoot yourself in the foot. This is not what p…

Just because an AES implementation matches the test vectors does not make it correct or safe. Here is an excellent visual depiction of several different AES implementations, many of which do not run in constant time: https://cr.yp.to/mac/variability1.html Implementing AES with variable time secret-dependent operations can leak the key. There are much bigger and more terrifying subtleties to implementing crypto correc…

To briefly expand on this (good) comment:

In cryptography, the output of an algorithm is far less important than how that output was generated (with very precise specificity). Crypto code requires far more heavy lifting in the "how" of the output than other software does. This is not intuitive, because ordinarily there are several ways to do things and you can compare on output, and it's probably fine to develop something in a functional but unorthodox way (minus performance consequences, maybe).

As the parent comment here mentions, there are extremely bad consequences to subtle mistakes in how the algorithm and its implementation arrives at the output, even if the output is correct.

If Alice sends Bob an encrypted message and the custom crypto provides an incorrect output, Bob can't decrypt the message. But if Alice sends Bob an encrypted message with the correct output generated in an unsafe way, there are many ways by which the secret key could theoretically be recovered, which is far worse than Bob not being able to read the message in the first place.

Re: How I implemented my own crypto

#243

Post by logfromblammo »

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…

Anyone who can write code can write a crypto library.

The trick is to have a second person helping you, who has all your mathematics notes, a copy of your source code, physical access to your hardware, and the ability to run your program inside a debugger. You don't even get to know whether they put cream in their coffee.

If you can keep a secret from them, you're doing okay. So then you rent a smarter person to do the same thing to make sure all the tricks and shortcuts have been attempted.

If someone manages to break it in the wild after that, you're still doing about as well as some of the highest-paid professionals in the industry.

Defense is difficult.

Re: How I implemented my own crypto

#244

Post by HurrdurrHodor »

Write a crypto library and blog about how great it is.

Apply the tools that other people used to find bugs in it and repeat blogging about how great it is.

...

In the end you get a library that is slower and smaller (because you left out the optimized code, duh). It's still not as small as the smallest.

Is this easier to audit? Dubious but it doesn't matter because if people hadn't wanted the extra speed they wouldn't have added the optimized code anyway.

Plus, that code is already audited and rolled out and works! Who cares about auditing another library that provides nothing new?

The only non obviously-garbage argument here is usability which I am too lazy to look at because it is too fuzzy to refute anyway.

By all means, write your own crypto but DON'T USE IT! And of course don't tell other people to use it either.

Re: How I implemented my own crypto

#245

Post by stcredzero »

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…

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.

Our "field" of programming is so weak in its preservation of institutional knowledge, that we have to occasionally fight the recurrence of bad ideas about very basic things, like using string filtering to avoid SQL injection. Yes, this happens, even in "hip" new parts of the field, like the communities around newer languages. (I have a specific example in mind, but I don't want to deal with the resulting war.)

Re: How I implemented my own crypto

#246

Post by baby »

tptacek wrote: post #236
baby wrote: post #131

Earlier quoted context omitted.

Writing your own crypto is the only way to become good at it, or to understand more about crypto. * DJB wrote NaCl * Frank wrote libsodium / libHydrogen * Brian wrote Ring * Thai Duong and Bleichenbacher wrote Tink * Eric Young wrote OpenSSL * Jason Donenfeld wrote Wireguard * Shoup wrote NTL * Emily Stark, Mike Hamburg and Dan Boneh wrote SJCL * Thomas Pornin wrote 6 SSL libraries and then BearSSL * Adam Langley wro…

This is a deeply misleading list. Daniel Bernstein, Daniel Bleichenbacher, Dan Boneh and Thomas Pornin are professional cryptographers and world-renowned experts. Even I would feel comfortable writing crypto if Bleichenbacher was watching behind my back. Frank "wrote" libsodium, but libsodium is effectively a port of NaCl. Frank had Daniel Bernstein watching behind his back. Eric Young wrote OpenSSL. Look how that tu…

> are professional cryptographers and world-renowned experts

They were not in the beginning. And implementing crypto helped them get there. That's my point.

> Finally: you obviously know that "writing your own crypto" isn't the only way to become good at it. In fact, it's a terrible way to get good at it. The right way to get good at crypto is to learn how to break it.

I strongly disagree with you on this, but I'll add a twist: I'm mostly saying to become good in "applied" crypto you must roll your own. There are too many problems you can't understand until you actually write code and try to make it secure. If you want to become good in theoretical crypto, then don't roll your own obviously.

This works in any field btw. The best web pentesters are the people who have implemented websites on their own as well.

Re: How I implemented my own crypto

#247

Post by simias »

simias wrote: post #51
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?

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…

I can't edit this comment anymore but I'm replying to myself to point out this little bit of C "trivia": the printf function itself, probably the most iconic standard function of all, is not portable.

The problem is that it returns an "int" which contains a negative value on errors and the number of character written on success.

Of course that means that it's possible to write a string whose size doesn't fit in an int.

For instance if you have a 64bit computer (and enough RAM) you can try the following code:

    #include 
    #include 
    #include 
    #include 

    int main(void) {
      size_t len = 0x80000001UL;
      char *str = malloc(len);

      assert(str);

      memset(str, 'a', len);
    
      str[len - 1] = '\0';
    
      fprintf(stderr, "\n%d\n", printf(str));

      return 0;
    }
Don't forget to redirect stdout to /dev/null. You can pipe through `wc -c` if you want to make sure the billion 'a's are printed.

On my computer the "printf" manages to print the whole string successfully but it returns... -1, signaling an error.

The size shouldn't be returned that way, it should be a "size_t" as an output parameter (since you also need a special value for errors). In Rust you'd use "Result" and you'd have a more elegant solution. Of course you can't really do that in C (except by returning a struct, which is a bit cumbersome) so I guess they said "meh, who prints that much text anyway?" and assumed an int would be good enough.

Re: How I implemented my own crypto

#248

Post by [deleted] »

arcticbull wrote: post #185
loup-vaillant wrote: post #81

Earlier quoted context omitted.

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

[deleted]

Re: How I implemented my own crypto

#249

Post by DanBC »

madez wrote: post #180
DanBC wrote: post #164

Earlier quoted context omitted.

> 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.

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

You know who else gets "thought policed"? The people who actually need to rely on cryptography. In their case it isn't grumpy people on Internet message boards telling them not to do something, it's agents of the state killing them or imprisoning them for many years.

Re: How I implemented my own crypto

#250

Post by CocaKoala »

jmulho wrote: post #223
dsacco wrote: post #196

Earlier quoted context omitted.

I'm sorry, I don't understand what you're trying to say. Can you clarify? What I am trying to say is that you gain nothing by, say, implementing your own encryption algorithm, using it on a plaintext, then encrypting the resulting ciphertext with a known good implementation of a known good algorithm like AES. That is how I interpreted your previous comment. So - you don't gain anything from that, if that's what you m…

> "If you mean just implementing a known good algorithm on your own (again, like AES) - why? You are overwhelmingly more likely to shoot yourself in the foot" I've never understood this argument. Encryption algorithms are deterministic. If you implement a known good algorithm on your own, and it gets the same outputs given the same inputs, then you are highly unlikely to shoot yourself in the foot. This is not what p…

But there's more to cryptography than just inputs and outputs.

Like, let's say we have two functions which validate a password.

Function A takes a user-defined parameter, compares it to a stored value byte by byte, and as soon as the strings differ, it exits.

Function B takes a user-defined parameter, compares it to a stored value byte by byte, sets a flag if the strings differ, and exits when all bytes have been compared.

Both of those functions take the same input, and both of them return the same output. Are you prepared to tell me that the two functions are equally secure?

Post reply on HN