Live data from Hacker News

How I implemented my own crypto

loup-vaillant.fr

221–230 of 409 posts

Re: How I implemented my own crypto

#221
post #151

Earlier quoted context omitted.

This is the point people miss. Same as wordpress vs creating your own blog. The more popular the software the larger the interest and the bigger exploit if successful.

It is less likely, though, and more likely to get fixed everywhere fast. 100,000 easy to crack implementations with obvious errors isn't really more secure than 1 super difficult, super well optimized/secured implementation, is it?

It is more difficult to crack 100,000 different interfaces because the time required to learn each one is a fixed cost. Having one central implementation makes it much easier to expliot because if an issue is discovered it can be immediately used everywhere. Don't put all your eggs in one basket.

Re: How I implemented my own crypto

#223
post #196
post #190

Earlier quoted context omitted.

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 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 people are talking about when they warn not to roll your own crypto.

Re: How I implemented my own crypto

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

Could you list the main pitfalls you are thinking about? Also, I may have mentioned some of them in this earlier article: http://loup-vaillant.fr/articles/rolling-your-own-crypto

And instead of saying nothing those who harp on "C's pitfalls" could politely enumerate those relevant to the issue at hand, that way we actually have something discrete to discuss.

Re: How I implemented my own crypto

#225
Have the library functions been tested (or proved) to be constant time ? This is a critical property of libsodium.

Another question is what make the difference in number of line of codes with libsodium ? I mean what do these lines of of libsodium that your lib doesn't have contain ?

Also, is this a fair metric ? You know we can have 1000 char long lines in C. ;)

Re: How I implemented my own crypto

#226
Have the library functions been tested (or proved) to be constant time ? This is a critical property of libsodium.

Another question is what make the difference in number of line of codes with libsodium ? Is this a fair metric ? You know we van have 1000 cha long lines in C. ;)

Re: How I implemented my own crypto

#227
Have the library functions been tested (or proved) to be constant time ? This is a critical property of libsodium.

Another question is what make the difference in number of line of codes with libsodium ? Is this a fair metric ? You know we van have 1000 cha long lines in C. ;)

Re: How I implemented my own crypto

#228
post #179
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.

Game companies are a great example because: 1) they invest 6 or 7 figures in this (piracy prevention is big money) 2) they still get it wrong 3) they not only get it wrong, they get in wrong in ways that teenagers still in high school can break, let alone the NSA

The fact that piracy prevention can not be solved does not help them.

Re: How I implemented my own crypto

#229
post #186
post #109

Earlier quoted context omitted.

You got to consider your most likely risk for attack. Targeted or at random by a botnet? For example, you are most likely more secure in practice by writing your own website than using Wordpress, simply because you are more likely to get hit by a botnet targeting every Wordpress site than someone going directly for you.

This is off-topic. We are talking about security vs obscurity in the context of cryptography libraries.

Replace WordPress with OpenSSL and website with crypto.

Re: How I implemented my own crypto

#230
post #223
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…

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 correctly than simply matching the test vectors.

Post reply on HN