Hacker News Reader

Comment by dsacco | Hacker News Reader

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, and you lose performance.

What you're doing is tantamount to a weird sort of encoding that doesn't offer any benefit.

View on HN

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.

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.

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.

> 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."

I know this is a side channel attack. I know people have used acoustic analysis to retrieve 4096 bit RSA keys, but the attack outlined in the paper is more feasible in real life situations, and systems do get compromised due to implementation details. AES might not be broken as a whole but that doesn't mean you can't attack specific usages.

AES isn't proven to be secure. I don't know about $10k, but I would not bet my life on any hash function not being broken.

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.

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 know it is safe?

My idea above is a way to increase the safety margin in a way that is orthogonal to the increase of the key space of the recommended tool. That sounds like a very good thing to me.

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.

> "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.

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.

To briefly expand on this (good) comment:

In cryptography, the output of an algorithm is far less important than how that output was generated (with very precise specificity). Crypto code requires far more heavy lifting in the "how" of the output than other software does. This is not intuitive, because ordinarily there are several ways to do things and you can compare on output, and it's probably fine to develop something in a functional but unorthodox way (minus performance consequences, maybe).

As the parent comment here mentions, there are extremely bad consequences to subtle mistakes in how the algorithm and its implementation arrives at the output, even if the output is correct.

If Alice sends Bob an encrypted message and the custom crypto provides an incorrect output, Bob can't decrypt the message. But if Alice sends Bob an encrypted message with the correct output generated in an unsafe way, there are many ways by which the secret key could theoretically be recovered, which is far worse than Bob not being able to read the message in the first place.

> "Just because an AES implementation matches the test vectors does not make it correct or safe."

Actually, this does make it correct. Whether or not it is safe depends on the application. For example, I sent my friend Bob some cyphertext that I calculated by hand with a pencil and paper using the AES algorithm. I sent it via my trusted courier Eve. It took four hours for me to do the calculation. At the last minute I started to second guess my math so I double checked it against a respected crypto library. It was fine, so I handed it off to Eve. I am pretty sure that in this application my choice to calculate the answer by hand was exactly as safe as if I had just used the library. In fact, I am so sure (given that the answers were identical), that just as Eve was walking out the door, enroute to Bob, I pulled her close and whispered in her ear: "Eve, be very careful with this cyphertext, it took me four hours to create it."

I'll just leave this here: https://underhandedcrypto.com/2017/07/31/2017-runner-up-nevi...

...what? Yes, if you compute by hand and compare with a known implementation, than it's likely you computation is correct. But this has nothing to do with test vectors. You could match all test vectors while still giving incorrect results for values not in the test vectors.

And how do matching test vectors ensure there are no timing attacks? Or memory leaks that disclose private keys?

But there's more to cryptography than just inputs and outputs.

Like, let's say we have two functions which validate a password.

Function A takes a user-defined parameter, compares it to a stored value byte by byte, and as soon as the strings differ, it exits.

Function B takes a user-defined parameter, compares it to a stored value byte by byte, sets a flag if the strings differ, and exits when all bytes have been compared.

Both of those functions take the same input, and both of them return the same output. Are you prepared to tell me that the two functions are equally secure?

> 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.

That is exactly what people mean by "don't roll your own crypto." If your belief is that you only need to match the same output per input, then your implementation might be an oracle that leaks information.

Crypto people don't say this for job security or to feel important. They say it, because they, themselves, have made mistakes, and they constantly see examples of programs that trivialize both security and cryptography while simultaneously introducing foreseeable bugs and obviously weak crypto.

They are deterministic, but timing attacks are a big deal. There were lots of practical key extraction attacks on RSA with nothing but timing, even on a network.

You can also do things like forget input validation in ways that reveal key material, or reuse a nonce or IV in a way that breaks the whole system.

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

Reply on news.ycombinator.com