It's the exact same critique as a database client library that makes passing data separately harder than putting them right inside the query string (eg PHP's original mysql_query). But the APIs should expose only this intrinsic hardness and design the rest simply so you can't use it wrong. I recognize that some of crypto, especially much other stuff than password hashing, is just intrinsically hard. Correct me if I'm wrong, but why can't they generate those nonces for me? Return a struct with the ciphertext and the nonce? Or have a make_nonce function generate a Nonce struct and only accepting that instead of a string? Do I send the nonce along with the ciphertext? Do I need to authenticate the nonce as well, then? To me it looks like NaCl and libsodium are still very much written by and for cryptographers.Įg, many functions take nonces. For a concrete example, it lacks PHP's password_hash and password_hash_verify functions, essentially being one level of abstraction lower.Īlso the documentation does not mention much in the way of how to _use_ the library. I like the idea of NaCl, but IMO it doesn't go far enough. What about a function like encrypt_symmetric_for_single_user(payload, userid, key) which takes care of picking the right algorithm, doing the right dance with keys and nonces and whatnot? Or maybe functions need to include naming like encrypt_for_sending_once and encrypt_for_storing_long? My understanding is that you want different crypto in such cases, right? I'm sure better cryptographers than me can immediately see what I'm doing wrong here, but you catch the gist right? Why can't this be made easier? Why do we at the same time, collectively, shame everyone who gets security wrong and make it so unnecessarily hard for people to get right? I mean, I don't even know what the different considerations are so I can't design these functions right, so please consider the spirit of the following proposal and not the details. Please make it easy for morons like me to use crypto right. Job safety is nice, but a secure internet is nicer. Cryptographers, please get your act together. We need similar APIs for symmetric and asymmetric encryption, for common use cases, or this madness is simply going to continue. These implement all the best practices, with seeds, the right algorithm parameters, keeping the ability to rehash in the future, etc. Eg PHP doesn't just expose a way to call bcrypt, but also has two functions password_hash and password_hash_verify. Some languages and libraries get it right, here and there. This is shit design and we can blame the cryptographers. The programmer will be none the wiser except if they were lucky enough to post the code somewhere on HN and someone writes a condescending comment. Or else what? Or else the function works perfectly well, produces an encrypted byte array, but with totally broken security. Most standard crypto modules have calls of the formĭepending on the algorithm chosen totally different parameters need to be passed or else. The reason this code is insecure is that the API is a piece of shit. The AES algorithm being invoked, I expect, was written by proper cryptographers. The code quoted does not implement encryption, it invokes encryption. You suggest we hire a cryptographer every time we need something secured? Implementation is best left to cryptographers.
0 Comments
Leave a Reply. |