How I implemented my own crypto • Hacker News Board

Re: How I implemented my own crypto

#191

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

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.

> Pretty sure 'char' in this case would be 32 bits.

On ARM it is 8 bit + manipulation of value

> Arguing that C shouldn't support microcontrollers seems a bit unfair

No, I'm saying the opposite

What I want to say is that because it supports a big variety of processors it tries to do too much AND that our focus should be in more expressive languages in more powerful machines

C is great for a microcontroller with limited resources and inputs

Re: How I implemented my own crypto

#192

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

jancsika wrote: post #184

dsacco wrote: post #169

Earlier quoted context omitted.

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

Okay, what exactly is the claim you'd like me to argue with? That Bruce Schneier was a hobbyist when he developed any of his cryptographic algorithms? He wasn't, and more importantly that misses the point since those algorithms were widely reviewed in competition settings.

I'm not sure what you're getting at here. Yes, someone has to develop cryptography, just like someone has to work on designing rockets. Theoretically everyone begins an aspiration as a hobby, but that's pedantic. A cryptographic design or implementation is not going to survive as a side hobby regardless of how it begins.

Re: How I implemented my own crypto

#193

Post by loup-vaillant » Thu, Aug 03, 2017, 1:20 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…

> 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 there makes me a little scared.

Re: How I implemented my own crypto

#194

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

SAI_Peregrinus wrote: post #149

AstralStorm wrote: post #9

Main lesson not learned: instead of testing, prove correctness in high assurance code like this. Rigorously and formally. Preferably even refine the proof to executable code. (Yes, it would take somewhere on the order of 10k LOC to prove correctness of this 1k.)

Proving correctness isn't enough. You have to test it too. It's perfectly possible for the proof to have errors (bugs). It's also possible for the proof to be incomplete: you can prove the algorithm is correct and implemented correctly to spec and still have vulnerabilities.

"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth

Re: How I implemented my own crypto

#195

Post by dankent » Thu, Aug 03, 2017, 1:21 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…

If a vulnerability is found for the outer encryption method, additional encryption of the inner message by a different method may provide some defence.

If that is the goal, though, it would be better to use two well studied encryption methods rather than something homemade.

Re: How I implemented my own crypto

#196

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

madez wrote: post #190

dsacco wrote: post #189

Earlier quoted context omitted.

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…

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 meant. 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, and there are plenty of open source implementations that you can inspect if you don't trust the code.

Finally, if you distrust the design of a known good algorithm, you're out of luck, because (again) you're almost certainly not going to come up with something better. If you do, by all means use it, but it's simply not likely whatsoever.

And again: you're not increasing the safety margin by double encrypting, unless you know both algorithms and implementations are solid. And even if they both are, the safety margin improvement will be negligible compared to the decrease in performance.

Re: How I implemented my own crypto

#197

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

dankent wrote: post #195

dsacco wrote: post #189

Earlier quoted context omitted.

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…

If a vulnerability is found for the outer encryption method, additional encryption of the inner message by a different method may provide some defence. If that is the goal, though, it would be better to use two well studied encryption methods rather than something homemade.

Right, that observation is correct on the surface. But the reason why that's almost never done is because the goal of a cryptographic algorithm is to contribute enough safety margin on its own. Instead of encrypting twice, it's better to encrypt with a greater number of rounds, or to come up with a superior algorithm. In practice you sacrifice an unreasonable amount of performance double encrypting in a production environment for a threat model that is fantastically unrealistic.

Re: How I implemented my own crypto

#198

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

ramphastidae wrote: post #188

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.

> How do you handle biased entropy input from that hairdryer someone is blowing on your chips? Sounds fascinating. Can you please tell us more?

If you had a RNG that sampled some hardware noise but then you altered the environment by introducing extreme temperatures, maybe the RNG would end up with biased output. A simple example: you can use a camera as a good source of randomness, even taking a picture of a wall indoors. But if an attacker was able to flood that room with light and overwhelm your sensor, he could predict the image would be 100% white pixels or near to it and guess the random output.

But the comment is exaggerating. Encryption algorithms do not handle the case of your entropy source being compromised. Good RNG algorithms like Yarrow try to mitigate this somewhat.

Re: How I implemented my own crypto

#199

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

loup-vaillant wrote: post #193

dsacco wrote: post #169

Earlier quoted context omitted.

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…

> 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 authentication) through cryptography and security-specific code.

I'm not saying people don't attack networking protocols, or that there is no incentive for doing so. I'm saying that the portion that plays the defensive role is in the security software, not the overlying networking protocol.

Re: How I implemented my own crypto

#200

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

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.

I like to think that I'm rather neutral, since I'm neither pro-C or against-C.

But from a rather philosophical point of view, C is basically Portability 1.0, it was one of the first truly portable "fast" languages. I'd like to think that we could do better than C with 40 years or CS research and industry experience.

Of course, there's the whole second-system syndrome so it's a wicked problem :)