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

131–140 of 409 posts

Re: How I implemented my own crypto

#131

Post by baby »

rijoja wrote: post #94

Whenever I feel the need for a tin foil hat I start to wonder if there is a FUD campaign powered by the "establishment" to encourage people not to investigate this area of computer science so that security holes will remain unnoticed. But, yes I wouldn't start out on writing a crypto library, then again I wouldn't attempt to build an OS or a 3D stack or even an web server either. All cases where a security breach cou…

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 wrote everything else

* ...

Re: How I implemented my own crypto

#132

Post by loup-vaillant »

flanfly wrote: post #93

I only had a brief look at it but it seems that crypto_check doesn't verify whenever the signers public key is on the curve.

I'm not sure. If there is such a test, you should find it on `ge_frombytes_neg`. I bet it returns -1 in line 1315 if that happens. (It triggers a rejection when that happens.)

If I'm right about this, it would explain why this code path is never hit: it would only trigger with invalid public keys. I'll test that as soon as I can.

Re: How I implemented my own crypto

#133

Post by Piskvorrr »

pkolaczk wrote: post #128
Piskvorrr wrote: post #121

Earlier quoted context omitted.

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?"

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.

Thank you, that's my point exactly.

Nothing wrong with what you wrote - but note the subtle difference between "XORing a stream of random numbers" (potentially viable, even unbreakable when using a OTP) and "XORing a random number" (essentially a Caesar cipher, kid-sister encryption).

Re: How I implemented my own crypto

#134

Post by adwn »

fundabulousrIII wrote: post #124
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…

It's even more tiresome hearing a new generation of programmers constantly lamenting the fact that C requires a great deal of skill to develop in and that X or Y new language completely avoids C pitfalls. Not only is it dishonest but it seems to be marketing 70% of the time. Portability does not equal 'without blemishes'. It simply means that when compiled across platforms it will perform as expected.

> that X or Y new language completely avoids C pitfalls

Yeah, you don't even need a new, hip language to avoid C's pitfalls.

> Portability does not equal 'without blemishes'. It simply means that when compiled across platforms it will perform as expected.

By that measure, C is not portable, since it will behave differently across multiple platforms – or multiple compilers, multiple compiler versions, even multiple optimization settings.

Re: How I implemented my own crypto

#135

Post by baby »

pbsd wrote: post #120
baby wrote: post #114

Earlier quoted context omitted.

right, but he only used unsigned types. I think there is another problem here: u64 = u8 Here the integer promotion might transform u8 into a 16-bit or 32-bit int (depending on the arch). Which will then be converted to a u64 AFTER the shift. Which might have you lose half or more of the bits. His code is not that though, it's u32 = u8 which should work only if ints are 32-bit on the system you compile on.

u8 gets promoted to signed int before the shift. That he only used unsigned types is irrelevant.

> That he only used unsigned types is irrelevant

If he had used a signed type, it would have got sign extended and the result would have been different.

Re: How I implemented my own crypto

#136

Post by raverbashing »

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…

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 making C worry about 8-bit microcontrolers when we're doing big application with it, it's trying too hard

Re: How I implemented my own crypto

#137

Post by x91823wu791 »

reikonomusha wrote: post #22
thinkMOAR wrote: post #18

Earlier quoted context omitted.

Curious about the other language. What other language that doesn't add another layer between the code and system instructions were you thinking about?

C adds a layer between your code and the system. It abstracts away memory layout, locations, as well as function call semantics, and a many other things. For example, given a C program, you will not be able to tell me with certainty that a variable will occupy memory on the stack, any of your particular processor registers, etc. Formally, C is a language to control the C Abstract Machine , as described in the standar…

This is an idiotic statement and typical meaningless HN lecturing. OCaml does not even have the basic integer types required for published algorithms.

Re: How I implemented my own crypto

#138

Post by Sylos »

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 generally also think that it's a bad idea to do, but I feel like it's a discussion that needs to be had with governments around the world wanting to backdoor everything.

It means that normal citizens won't be completely helpless against tyrannic governments and it helps to educate that writing crypto from scratch is most definitely something that criminals can do. The government making it illegal or backdooring it will only help against lowest-effort criminals, not against organized terrorist groups. Sure, those probably won't write unbreakable encryption, but it'll be enough to bypass a government that's expecting everything to be in plain text.

Re: How I implemented my own crypto

#139

Post by raesene6 »

baby wrote: post #131
rijoja wrote: post #94

Whenever I feel the need for a tin foil hat I start to wonder if there is a FUD campaign powered by the "establishment" to encourage people not to investigate this area of computer science so that security holes will remain unnoticed. But, yes I wouldn't start out on writing a crypto library, then again I wouldn't attempt to build an OS or a 3D stack or even an web server either. All cases where a security breach cou…

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…

oh man, making that list and leaving out the bear....

Re: How I implemented my own crypto

#140

Post by loup-vaillant »

mathieubordere wrote: post #4

I still believe it's a bad idea to roll your own crypto, interesting as an exercise, but I would never use it in a production environment.

I would probably have the same perspective if our roles were reversed. I assume I'm a random dude on the internet to you, and trusting crypto code from a random dude is… unwise to say the least.

Nevertheless, Monocypher is pretty thoroughly tested by now. I wouldn't be surprised if Monocypher starts getting serious vetting a few months from now.

Post reply on HN