Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2025 Poal.co

393

One example is the NSA requiring many contractors to use an elliptic curve based random number generator for stream ciphers.

So elliptic curves are a funny thing. Not all of the curves are created equal. They are defined by two variables (that define the shape of the curve), and some shapes are considered unsafe and others are considered safe. It's sort of a black magic to know which curves are safe and not, and so users of it are stuck blindly following expert advice. The problem with a stream cipher is that if you can figure out the state of the random number generator behind it usually* you can figure out what the next sequence of random numbers will be and how they will modify the plaintext going forward.

So what mathematicians figured out is that for the particular curve they selected and approach to using it they require, that for this A & B value, if they know some very large number you essentially have a secret backdoor to figure out the state of this random number generator at any time. The worst part is that A & B are calculatable from this theoretical large number. So the question that has everyone scratching their heads is, did the NSA pick the large number first and then calculate an A & B to tell everyone to use?

That is one example of a pushed standard that might have a backdoor by the organization pushing it.

It leaves me wondering if hopping on the bandwagon of using ChaCha (google pushed), is such a good idea. It is a varient of the Salsa cipher.

When you look at a table on Wikipedia for different stream ciphers and their most , you will see that the Salsa cipher has a unique one. "Probabilistic neutral bits method". Maybe google knows more about putting this method into application than others.

I pretty much never hear a suggestion for it but it seems like duel algorithm use could be a good idea. Most of these attacks come from knowing what the plaintext is supposed to look like.

For example. Lets say you make a request to a server over https for a static file. You've only just now opened the socket, so the stream is fresh, and the cipher just initiated. Because you requested it you know exactly what the plain text is supposed to look like. If you also observe the encrypted channel too then you know what the encrypted form looks like. Most stream ciphers use a byte by byte bitwise XOR operation. Doing it once encrypts it. Doing it twice flips all the right bits back again (decrypt). So you can figure out the keystream that this cipher used. Using this to solve a secret key or predict the keystream going forward is the point of an attack.

But if you use two algorithms on top of each other an attacker doesn't know.. what alterations algorithm 1 did to create the intermediate stream since you never saw the intermediate stream, and you don't know what bits algorithm 2 flipped to create the final stream from the intermediate stream because you don't have a copy of the intermediate stream.

Doing this not only would protect you from an attack if either algorithm was compromised, not only because at least one of them would be working, but also because the attacker would fail to see the parts they need for the attack. The practice being adopted broadly would discourage an attacker ever having hopes of successfully using the attack in a practical application and so disincentives development of those attacks, thus securing the base algorithms further. It also removes any possible gain by organizations tempted to make bad suggestions. The hope is that even currently the costs of being found out outweigh the potential benefits. But we can further ensure that by making is so people picking your bad algorithm does nothing for you because everything will be behind an additional layer of encryption that also partially frustrates attacking even the compromised layer. (It's not like block ciphers where you get confirmation that you successfully pulled back a layer. Also stream cipher attacks are more strongly based on knowing both sides).

So yeah. At the very least, don't take the NSA's suggestions for elliptic curves. Their hash functions and block ciphers seem ok.

One example is the NSA requiring many contractors to use an elliptic curve based random number generator for stream ciphers. So elliptic curves are a funny thing. Not all of the curves are created equal. They are defined by two variables (that define the shape of the curve), and some shapes are considered unsafe and others are considered safe. It's sort of a black magic to know which curves are safe and not, and so users of it are stuck blindly following expert advice. The problem with a stream cipher is that if you can figure out the state of the random number generator behind it usually* you can figure out what the next sequence of random numbers will be and how they will modify the plaintext going forward. So what mathematicians figured out is that for the particular curve they selected and approach to using it they require, that for this A & B value, if they know some very large number you essentially have a secret backdoor to figure out the state of this random number generator at any time. The worst part is that A & B are calculatable from this theoretical large number. So the question that has everyone scratching their heads is, did the NSA pick the large number first and then calculate an A & B to tell everyone to use? That is one example of a pushed standard that might have a backdoor by the organization pushing it. It leaves me wondering if hopping on the bandwagon of using ChaCha (google pushed), is such a good idea. It is a varient of the Salsa cipher. When you look at a table on Wikipedia for different stream ciphers and their most [likely attack](https://en.wikipedia.org/wiki/Stream_cipher#Comparison), you will see that the Salsa cipher has a unique one. "Probabilistic neutral bits method". Maybe google knows more about putting this method into application than others. I pretty much never hear a suggestion for it but it seems like duel algorithm use could be a good idea. Most of these attacks come from knowing what the plaintext is supposed to look like. For example. Lets say you make a request to a server over https for a static file. You've only just now opened the socket, so the stream is fresh, and the cipher just initiated. Because you requested it you know exactly what the plain text is supposed to look like. If you also observe the encrypted channel too then you know what the encrypted form looks like. Most stream ciphers use a byte by byte bitwise XOR operation. Doing it once encrypts it. Doing it twice flips all the right bits back again (decrypt). So you can figure out the keystream that this cipher used. Using this to solve a secret key or predict the keystream going forward is the point of an attack. But if you use two algorithms on top of each other an attacker doesn't know.. what alterations algorithm 1 did to create the intermediate stream since you never saw the intermediate stream, and you don't know what bits algorithm 2 flipped to create the final stream from the intermediate stream because you don't have a copy of the intermediate stream. Doing this not only would protect you from an attack if either algorithm was compromised, not only because at least one of them would be working, but also because the attacker would fail to see the parts they need for the attack. The practice being adopted broadly would discourage an attacker ever having hopes of successfully using the attack in a practical application and so disincentives development of those attacks, thus securing the base algorithms further. It also removes any possible gain by organizations tempted to make bad suggestions. The hope is that even currently the costs of being found out outweigh the potential benefits. But we can further ensure that by making is so people picking your bad algorithm does nothing for you because everything will be behind an additional layer of encryption that also partially frustrates attacking even the compromised layer. (It's not like block ciphers where you get confirmation that you successfully pulled back a layer. Also stream cipher attacks are more strongly based on knowing both sides). So yeah. At the very least, don't take the NSA's suggestions for elliptic curves. Their hash functions and block ciphers seem ok.

(post is archived)