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

231–240 of 409 posts

Re: How I implemented my own crypto

#231

Post by loup-vaillant »

dsacco wrote: post #199
loup-vaillant wrote: post #193

Earlier quoted context omitted.

> a network protocol is not designed to be error-proof in an intentionally antagonistic environment Err, really? That may be the case sometimes. Also these days many things can be antagonistic: anything online is exposed to adversaries. So is anything that routinely reads untrusted input on everyone's computer (like a video player, or a pdf reader). Thinking of the sheer amount of potentially vulnerable code out ther…

But is the code you're speaking of the security-specific code, or the network-specific code? If you attack a networking protocol, what are you attacking if not the associated cryptography? A networking protocol without any cryptography doesn't really need to be attacked because it's already wide open. You introduce the confidentiality, authentication and integrity (which is really just going to be part of the authent…

I was thinking of attacking the implementation of whatever processes attacker controlled input. If sending 100 pings in a row triggers a stack overflow, this will interest the attacker.

I would say that security specific code would be any code that directly processes the untrusted inputs. Parsers and decoders, mostly. You may want to isolate them from the rest of the program (ideally a separate address space), and make sure the interface between them and the rest of the program is much simpler than the input they are processing.

At least, you want to ensure such code either produces sound output for the rest of the program or fails cleanly. The attacker will have a harder time exploiting a bug deeper in to the program, I think —hope.

Re: How I implemented my own crypto

#232

Post by baby »

pm215 wrote: post #213
baby wrote: post #202

Earlier quoted context omitted.

I just checked that myself, it is not the casting to uint64_t since the sign-extension happens even before that. The problem is that the result from the shift is stored in a register, which is probably 64-bit on your machine, and to do that it is sign extended from a signed int to a signed 64-bit value. Wrote more about that here: https://www.cryptologie.net/article/418/integer-promotion-in...

The size of the cpu registers don't matter here. What matters is that 'int' is a bigger type than uint8_t and smaller than uint64_t: the resulting unexpected behaviour is mandated by the C standard regardless of the register size of the cpu (for instance both 32-bit i386 and 64-bit x86_64 will behave the same, because both typically have 32 bit 'int'). More generally, reasoning about this kind of thing by thinking ab…

Even if the code would still be bad for 32-bit machines, I'm not sure they would suffer from the bug (if they had 32-bit signed int as well).

1. Your uint8_t would get promoted to a 32-bit int

2. Your int would get shifted, getting a 1 in the signing bit

3. The result would get stored in a uint32_t when being casted

Now I don't know how uint64_t works on a 32-bit machine, I'd have to compile the C code with -m32 to see.

EDIT: just tested and you're right, it's still a problem on 32-bit machines.

Re: How I implemented my own crypto

#233

Post by marcosdumay »

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…

The thing that normally nobody says, yet most the people telling you to not roll your own crypto assume you will understand is that you should rely only on well vetted libraries.

Rolling a usable crypto library is not a single person endeavor. Your own crypto won't be peer reviewed, thus you should not trust it.

Re: How I implemented my own crypto

#234

Post by IncRnd »

syrrim wrote: post #220
IncRnd wrote: post #156

Earlier quoted context omitted.

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.

You wouldn't want true random numbers anyways. If you're encrypting it, then you'll want to decrypt it later. That means you'll need the random data you used again. If you had a secure channel over which to send or store the random data, then you could just use that channel to send or store the plaintext itself (note that the random data will be the same length as the plaintext). Such a system could only be useful if…

I think you missed the point of the comment, which wasn't about physical possession of a computer.

You also make assumptions, such as chips being inside the computer, when they can in fact be in an outside environment-based RNG. The hairdryer example is the canonical and prototypical weakness in that particular type of "rng". I'll try to be explicit about that in the future.

Re: How I implemented my own crypto

#235

Post by wuch »

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.

In C++, you can for example:

1. Manage resources with RAII (though, in C you could use non-portable attribute cleanup in similar manner).

2. Use type safe wrappers around builtin types like in [0] and [1].

3. Use containers with more extensive bounds checking and iteration validity checks [1].

This could help detect some of those bugs at runtime, or even possibly prevent them from being written in the first place. Use of uninitialized value could be prevented with types that require explicit initialization or have default one (Bug 1). Left shifting a negative value could have been caught at runtime (Bug 2). Bounds check could prevent uninitialized memory read (Bug 3) Type safe wrappers could prevent an accidental promotion from being written in the first place (Bug 5).

Though, you need to go out of your way to actually do all those things, not to mention that your code would integrate poorly with existing library ecosystem. IMHO choosing C++ alone doesn't improve safety of your programs compared to ones written in C all that much.

[0] https://github.com/foonathan/type_safe

[1] https://github.com/duneroadrunner/SaferCPlusPlus

Re: How I implemented my own crypto

#236

Post by tptacek »

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…

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 turned out! Has there been a class of cryptographic vulnerability that OpenSSL hasn't had?

And yet consider: for all the effort that people like Bernstein and Boneh put into writing strong, safe crypto, the entire world has blundered into vulnerability after vulnerability because the amateurish crypto in OpenSSL is the one every else ended up using.

It's as if you set out to prove 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. But that takes effort, and you can have a blog post crowing about your new crypto library just a few weeks after deciding to write one.

Re: How I implemented my own crypto

#237

Post by CocaKoala »

dankent wrote: post #207
dsacco wrote: post #203

Earlier quoted context omitted.

It's not thought policing. Would you consider us adamantly telling you not to develop and deploy your own rockets or medical software without significant expertise and third party review to be "thought policing"? Furthermore, your argument is fallacious. That expert professionals make mistakes does not tell you anything about the likelihood of an amateur to make a mistake. You can't draw any logical conclusion from t…

If you're telling me I can't develop and deploy my own rockets for fun (providing I don't cause risk to others) then yes, that is thought policing. (btw, I do develop and deploy my own rockets for fun)

If you roll your own crypto and say, "that was a fun learning experience" and write a blog post about what you learned implementing AES in some novel way, nobody is going to show up and tell you not to roll your own crypto. If you roll your own crypto and then deploy it in a production system, then you are putting actual users at risk.

Re: How I implemented my own crypto

#240

Post by tptacek »

I would like to clarify:

The thing that I said was "table stakes" for implementing cryptography was passing the algorithm test vectors, which this author's previous post claimed as a security feature.

If you're unfamiliar with the concept, a test vector is a series of strings and intermediate values used to ensure that your (say) OCB3 is the same as everyone else's OCB3.

Had he asked, I'd further claim that not having dumb C bugs is also table stakes for cryptography, since serious crypto vulnerabilities happen at a higher level of abstraction. The author grazes past (somewhat disconcertingly) one such class of bugs when he discusses carry propagation and limb scheduling in the context of Poly1305. Improper carry propagation is an example of the kind of security vulnerability for which there are no test vectors and no memory safety validation tools.

You just have to know what a carry propagation bug is, where to look for them (not Poly1305), and what the impact of one is.

Hopefully, the author of this library does.

Post reply on HN