Live data from Hacker News

How I implemented my own crypto

loup-vaillant.fr

261–270 of 409 posts

Re: How I implemented my own crypto

#261
post #258

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

> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…

Being able to Google unfamiliar terms is table stakes for participating in HN :)

http://www.urbandictionary.com/define.php?term=table%20stake...

Re: How I implemented my own crypto

#262
post #138
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…

> but I feel like it's a discussion that needs to be had with governments around the world wanting to backdoor everything.

On the contrary, this is -exactly- why you don't want to roll your own crypto. Because they can and will break it. Good crypto takes serious thought and effort from people who put a lot of thought and effort into it.

Re: How I implemented my own crypto

#263
post #212

Earlier quoted context omitted.

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…

> I would happily bet $10,000 that AES will not be broken in the next ten years. What are you talking about: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf You'd lose the bet so hard. Don't take anything for granted. Even the most supposedly secure and widely used primitives should be scrutinized and are subjects to constant attacks.

> What are you talking about: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

Read that paper again. Cache timing attacks (and more generally timing attacks) are a subset of side channel attacks, which are not a break in the fundamental design of a cryptographic algorithm. When Bernstein mentions that he considers it a design flaw, that's a misnomer in the mathematical sense: he means that AES is antagonistic to a software implementation that can resist a timing attack, not that the design of the algorithm is fundamentally unsound. This is essentially true for all encryption schemes that utilize lookup tables and S-boxes, which he even mentions in the paper.

This is similar to using acoustic analysis or fault injection for key retrieval - yes, you've done it, but it's not really fair to say you've broken AES whatsoever. That remains a pipe dream. You've merely broken an AES implementation on a particular platform that was not hardened for this threat. Just a few months ago a team came up with a way to retrieve an AES key through acoustic analysis in a paper that was published here on HN. That's not actually the same as a cryptanalysis, the best of which is this: https://eprint.iacr.org/2009/317

There are effective CPU mitigations that allow you to safely implement algorithms in order to avoid this issue - for example, AES-NI theoretically mitigates cache timing attacks. See: http://cseweb.ucsd.edu/~hovav/dist/aes_cache.pdf

So: no, I wouldn't "lose that bet so hard."

Re: How I implemented my own crypto

#264
post #258

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

> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…

"Table stakes" in competetive Poker means that all you can bet is what's on the table, in front of you.

So this old movie cliché where the protagonist has lost almost all his chips and needs a huge win, so he casually throws in his car keys and the title to his house in the middle of play is not allowed. Neither is grabbing your wallet and throwing cash in.

The idea is that (a) rich people cannot bully others around at will with their huge wealth "in the background" and also (b) players are protected from losing possessions extraneous to the game.

Re: How I implemented my own crypto

#265
post #212

Earlier quoted context omitted.

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…

> I would happily bet $10,000 that AES will not be broken in the next ten years. What are you talking about: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf You'd lose the bet so hard. Don't take anything for granted. Even the most supposedly secure and widely used primitives should be scrutinized and are subjects to constant attacks.

That's not an (algorithmic) break, but a (side-channel) attack on some implementation. "Break" is precise jargon here; you're right that a particular real-world implementation of a strong algorithm may be weak, but that doesn't contradict anything dsacco said.

Also, please be nice.

Re: How I implemented my own crypto

#266
post #264
post #258

Earlier quoted context omitted.

> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…

"Table stakes" in competetive Poker means that all you can bet is what's on the table, in front of you. So this old movie cliché where the protagonist has lost almost all his chips and needs a huge win, so he casually throws in his car keys and the title to his house in the middle of play is not allowed. Neither is grabbing your wallet and throwing cash in. The idea is that (a) rich people cannot bully others around…

In this context, though, it means the minimum you need to play the game.

Re: How I implemented my own crypto

#267
post #212

Earlier quoted context omitted.

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…

I wouldn't take that bet either as I agree that is a very unlikely thing to happen.

Note, though, that you are using the specific word 'algorithm', where as I am talking about 'methods'. Most cryptographic failures are in how the algorithms are implemented or applied, not a problem in the underlying maths.

I would not be nearly so confident about a similar bet that applied to the actual code being widely used for encryption.

Re: How I implemented my own crypto

#268
post #211

Earlier quoted context omitted.

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.

> I do wonder whether the hypothesis could be tested

Data point: everyone who evaluates crypto constructions says not to roll your own.

Re: How I implemented my own crypto

#269
post #171

Earlier quoted context omitted.

I agree with what you're saying in general, that people should not write a crypto library unless they have a strong need to and are going to have it thoroughly audited. > Simply put, the rule is there to remind people that rolling your own crypto libraries is dangerous. It's not meant to be taken literally to the daft extremes that yourself and a few others on here have. My problem is that this nuance is not present…

I think it's a bit of a stretch to say nobody implemented Argon2 because of the aforementioned rule when it's also been pointed out in this thread the vast number of times that people have rolled their own crypto libraries. That would suggest to me that there are other factors at play with your example. Possibly due to the relatively young age of that specific KDF, or perhaps it's lesser known compared to many of the…

I used Argon2 as an example because it was mentioned in TFA, as the author discovered that the test vectors were wrong because the reference implementation was wrong. That author noted that if someone else had implemented it from scratch they would've noticed this immediately when testing the test vectors.

Re: How I implemented my own crypto

#270
post #258

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

> You just have to know what a carry propagation bug is This is one of the things that drives me nuts about the crypto community. The natural response upon reading, "You just have to know X" if you don't already know is to go search for X. Well, if you go search for "carry propagation bug" you will find lots of examples of carry propagation bugs being found and fixed, but no explanation of what one is. The thing that…

> And while we're at it, what are "table stakes"?

(business) minimum entry requirement for a market or business arrangement OR (poker) limit on the amount a player can win or lose in the play of a single hand [1]

[1] https://en.wikipedia.org/wiki/Table_stakes

Post reply on HN