[throw88888]

Just a small comment/opinion on the inscrutability of crypto:

Crypto relies on number theory and a complexity theoretical assumption that N!=NP (i.e. that there exists one-way/trapdoor functions).

I think it is opaque by the very nature of how it works (math).

Understanding finite fields or elliptic curves (integer groups really) made me able to grok a lot of crypto. It is often a form of the discrete-logarithm problem somehow.

[User23]

That’s not really true. I don’t have a link handy (might try to find later), but I read a rather scathing critique of the state of crypto math by a mathematician. The short summary is that crypto math is overwhelmingly unnecessarily inelegant.

[daelon]

I, for one, would be very interested in reading that.

[skrebbel]

I did not make my point well enough. I don't mind that crypto is inscrutable, that's fine (and unavoidable). Plenty other tech that I use every day is inscrutable (eg TCP, or HyperLogLog, or database query planners, or unicode text rendering, etc). I mind that resources about how to use crypto in software applications are often inscrutable, all the way down to library design, for no good reason. I mean stuff like:

- I learned the other day here on HN that SHA256 is vulnerable to a length extension attack, so if you want 256 bits of SHA goodness, you should use SHA512 and truncate it to 256 bits. This is terrible naming! Name the bad one "SHA-DoNotUse" if it's broken and this is known from the start. Why does it even exist?

- For the first decade or so of JWT library support, many verifiers happily accepted "alg: 'none'" payloads, letting attackers trivially bypass any actual verification. If you wanted JWT safely, you were supposed to know to tell the verifier to only accept the algorithms you were going to use when creating tokens.

- Hash algorithms have names such as "MD5", "SHA1", "bcrypt" and "argon2", ie meaningless character soup. I can't blame novice programmers for just using whatever hash algorithm is the default of their language's hash function, resulting in MD5-hashed passwords being super common until about a decade ago.

Security resources and libraries for programmers should be focused on how a thing should be used, not on how it works. That's what this book gets right (and what its page on elliptic curves gets so wrong).

Or, for another example, my favourite bit of crypto library design is PHP's `password_hash()` function[0]. They added it to the language after the aforementioned decade of MD5-hashed passwords, and that fixed it in one fell swoop. `password_hash()` is great, because it's designed for a purpose, not for some arbitrary set of crypto properties. The purpose is hashing a password. To verify a hashed password, use its brother `password_verify()`. Easy peasy! It's expertly designed, it supports rehashing passwords when necessary, and you don't need to understand any crypto to use it! I don't understand why all other high level programming languages didn't immediately steal this design.

I mean why can't all security libraries be like this? Why do most encryption libs have functions named "crypto_aead_chacha20poly1305" instead of "encrypt_message_symmetrically"? Why do they have defaults that encourage you to use them wrong? Why do they have 5 nearly identically named functions/algorithms for a particular purpose but actually you shouldn't use 4 of them and we won't tell you which ones? Do you want GCM or CCM? Or do you prefer that with AEAD? Do you want that with a MAC, and HMAC, or vanilla? Gaah I just want to send a secret! Tell me how to get it right!

[0] https://www.php.net/manual/en/function.password-hash.php

[throw88888]

I get your point, thanks for clarifying.

I don’t agree with you for various reasons.

I learnt all I know about crypto from online resources. It’s perhaps a question of taste, so let’s just skip that one.

It’s all good that you can easily hash a password in PHP without knowing what happens[0]. If you need to interface with another language/program however, it’s not as convenient anymore.

I am a fan of understanding what you are doing. Also in crypto.

[0]: But not really though. You need to trust that the PHP-team is competent and understand security. They don’t have the best track record there IMHO.

[candiddevmike]

FWIW sha256 isn't broken, it's just you need to be careful when you're using it to generate HMAC. This follows what other comments are saying where you shouldn't use crypto primitives directly and use abstractions that take care of the rough edges.

[GoblinSlayer]

>Why does it even exist?

Who do you think writes these standards? NSA loves footguns, the more footguns the better. Also these things are contextual, length extension is a problem for MAC, but not a problem for a password hash or a secret token.

[vermilingua]

Counterpoint: these crypto APIs are inscrutable for the same reason poisonous mushrooms are brightly coloured; they’re warning you away. It is extremely easy to mishandle crypto primatives, so if you’re reaching for crypto_aead_chacha20poly1305 and are confused it’s probably because you should be using a library that provides encrypt_message_symmetrically.

It just so happens that for PHP that library is the STL.

[neodypsis]

> I mind that resources about how to use crypto in software applications are often inscrutable, all the way down to library design, for no good reason.

I haven't read it, but I plan to, eventually. There's a book titled "Cryptography Engineering: Design Principles and Practical Applications" that could help you.

[immibis]

What would you have called the algorithms?