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

211–220 of 409 posts

Re: How I implemented my own crypto

#211

Post by dsacco »

dankent wrote: post #201
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.

Have any studies been done on relative security of crypto algorithms that are either: a) Well known, well studied but also attractive targets for attackers to study b) Unknown (aside from the developer) until an attacker encounters a specific piece of encrypted data It is a common assumption that well-known methods are better (and it is the assumption I work under) but does empirical data on security breaches back th…

I'm not aware of academic studies on the subject (I think that would be hard to do, because it's virtually impossible to know how many proprietary algorithms exist, how many are trivially breakable and how many have been broken).

However, this point is featured as 101 material in basically every cryptographic textbook. To put it very succinctly: there are conditions in which it can be beneficial to use proprietary cryptography, especially when you require very unique interoperability constraints. However it is almost never a benefit for the safety of the algorithm.

I've come across a proprietary algorithm and successfully broken it, in a black box setting, with differential cryptanalysis. This algorithm was deployed to disguise the sequential order numbers for a very large delivery company. It took me about a month, but it was done. The challenge in proprietary algorithms is shifted to figuring out what's going on because it's unrecognizable. That is a significantly easier challenge that identifying a vulnerability in an algorithm like AES, which has never had a meaningful vulnerability in a decade and a half of cryptanalysis.

If you use a proprietary algorithm it might be safer than a known unsafe open algorithm, but it's virtually guaranteed to be worse than widely studied algorithms, and most likely in a trivially breakable way. They can be safe, but that still means you're going to be working with professional cryptographers at a company like Riscure to assure it's safe.

Re: How I implemented my own crypto

#212

Post by dsacco »

dankent wrote: post #206
dsacco wrote: post #197

Earlier quoted context omitted.

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

You find it fantastically unrealistic that a vulnerability could be found for a well known and widely used encryption method?

Depending on the algorithm: yes. I'm not saying all algorihms that are widely used and well known are extremely unlikely to be broken.

I would happily bet $10,000 that AES will not be broken in the next ten years. I'd make the same bet for several hash functions.

And as a corollary to this point: I think it's incredibly foolish to try and combat the threat of an encryption algorithm being broken by double encrypting a plaintext, including with that algorithm.

Re: How I implemented my own crypto

#213

Post by pm215 »

baby wrote: post #202
masklinn wrote: post #96

Earlier quoted context omitted.

It's probably the latter part (conversion to "whatever the expression's type ends up being) doing the sign-extension, see moefh's sibling comment with a uint64_t final destination, the int -> uint64_t is sign-extending. I should have quoted the proper part I was replying to ("I don't think you're talking about integer promotion here")

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 about the CPU leads you down the wrong path -- modern C as implemented by compilers today is an implementation of a standardized language, and they behave as that standard says, which is not always as you might expect from the hardware behaviour. (Simple example: left shifting of negative numbers does a simple straightforward thing on practically all hardware, but the C spec says it's UB and if you write code that assumes the h/w behaviour you'll get bitten.)

Re: How I implemented my own crypto

#214

Post by dsacco »

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)

That's great, but that's not what I'm telling you. I'm telling you not to develop and deploy them with human passengers, in a production environment, on a trip to orbit. If you get collaboration from professionals with significant expertise and audit the design and development extensively, then sure, go for it.

Even were that as accessible as developing and deploying your own cryptography, I'd still advise against it.

Re: How I implemented my own crypto

#215

Post by beckler »

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've found some helpful guidelines, but I know it is by no means an exhaustive list.

https://cryptocoding.net/index.php/Coding_rules

Re: How I implemented my own crypto

#216

Post by dankent »

dsacco wrote: post #211
dankent wrote: post #201

Earlier quoted context omitted.

Have any studies been done on relative security of crypto algorithms that are either: a) Well known, well studied but also attractive targets for attackers to study b) Unknown (aside from the developer) until an attacker encounters a specific piece of encrypted data It is a common assumption that well-known methods are better (and it is the assumption I work under) but does empirical data on security breaches back th…

I'm not aware of academic studies on the subject (I think that would be hard to do, because it's virtually impossible to know how many proprietary algorithms exist, how many are trivially breakable and how many have been broken). However, this point is featured as 101 material in basically every cryptographic textbook. To put it very succinctly: there are conditions in which it can be beneficial to use proprietary cr…

I am aware of the usual (and strong in my opinion) argument.

Every time this discussion does the rounds, though, I do wonder whether the hypothesis could be tested.

Most vulnerabilities do not come from breaking the core algorithm but rather from a flaw in how they are implemented or applied. Standardisation can lead to monocultures that become tempting targets for those with plenty of resources to throw at them.

Re: How I implemented my own crypto

#217

Post by xyzzy4 »

viraptor wrote: post #72
ktta wrote: post #46

I've always seen 'rolling your own crypto' as not being recommendation against writing your own library, but creating your own primitive. Sure, writing your own library is very difficult, but you have a simpler set of problems, which proper testing, another set of eyes and enough tools will take care of the big problems. Now, implementing your own primitive and recommending to use it is bad . For a primitive to be de…

Even just using crypto primitives is dangerous unless you've got experience. There's an old post from matasano about it https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

I disagree. The way you get experience is by trying things. If everyone followed that advice then nobody would learn anything.

Re: How I implemented my own crypto

#218

Post by monsieurbanana »

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…

That's far from what I'd call "doing crypto as a side-hobby".

Re: How I implemented my own crypto

#219

Post by fundabulousrIII »

adwn wrote: post #134
fundabulousrIII wrote: post #124

Earlier quoted context omitted.

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

Selection and context are _so_ important, don't you think?

Re: How I implemented my own crypto

#220

Post by syrrim »

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.

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 the cryptographic key was shorter than the plaintext. So it would have to be a deterministic RNG, and you would only need the seed and the ciphertext in order to decrypt.

Also, if someone has acccess to the hardware, then you're screwed. No one would bother wasting time with a hairdryer. If the plaintext was on your harddrive, they would just grab that and run.

Post reply on HN