On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote:
On Wednesday, 1 July 2020 at 07:19:11 UTC, Cym13 wrote:
Here's what you should know if you are a user:
RSA, as implemented in the library, is still very much broken.
I do not recommend using it. The confidentiality and integrity
of all messages exchanged using this library must be
questionned: if you exchanged sensitive information such as
passwords using it I recommend to change them since their
security is not guaranteed.
[snip]
Thanks for the article. IMO it was as clear for
non-professionals as crypto can be: Even I (non-crypographer)
understood what's the problem with padding with only one byte.
Thank you for that feedback.
It also illustrates what's the prolem with cryptography: it's
like coding without ability to test. Who could even dream to
get that right the first or even the second time? I think there
a shortcoming in the "don't roll your own crypto" - advice: One
could think it only applies to the algorithms, not the
implementation. That's what I did when I first heard it.
There's one more element missing here: the protocol. Cryptography
isn't about encrypting stuff, it's about protecting secrets from
start to finish and that includes the protocol used. To take an
example, many people can think "Hey, I need encryption between my
two servers, I'll use AES" and stop there. But use AES how? What
mode (CBC,GCM,...)? Let's say CBC is used, what about message
authentication? Can I just modify your stream? How is the key
exchanged? How is the key generated? Etc.
People tend to focus on encryption, be it algorithm or
implementation, but once you've got bricks it's still a pain to
put them together in a solid way. Things like TLS or SSH actually
combine at least 3 completely different sets of bricks to
establish the communication, authenticate it, secure it once
established etc.
So, in a way, "don't roll your own crypto" means "use TLS as much
as possible" :)
If one needs to use cryptography, would redundancy help? I
mean, encode and decode the message with say three different
algorithms from different libraries, so that the attacker would
need to find a weakness in all of them?
That's a good question. The general answer is: no.
The more detail answer is: in some cases it can help (I know of
one client for example that doesn't trust national standards and
has layered US technology with Russian technology to make sure
that at least one layer stands).
However in the general case we can prove that the security of the
combination is less than or equal to the security of the better
of the elements of that combination. In some cases badly choosen
algorithm actually counteract each other leading to easier
attacks.
My general advice is to stay true to well audited implementations
of good standards. I like opiniated libraries in that context so
I'd say "whatever libsodium implements".
