3 ms·
My question is, why does the library even support AES-CBC? I know that it's OpenSSL here but why can't we have an additional library then that ships only the re
by sureglymop 2y ago
My question is, why does the library even support AES-CBC? I know that it's OpenSSL here but why can't we have an additional library then that ships only the recommended encryption schemes, safe curves, etc. and deprecates obsolete practices in an understandable process?
Something that is aimed at developers and also comes with good documentation on why it supports what it does.
- Ekaros 2y agoLegacy. You rarely only touch new stuff or secure stuff. And instead end up at least with one scenario that requires you do something with old stuff. And this is not just crypto.
- sureglymop 2y agoI get that. But then, keeping that legacy stuff running is just as problematic as rolling your own crypto. We can leave OpenSSL as it is but it shouldn't be the popular recommendation for developers. They should have another library which, like I said, actively deprecates obsolete and insecure practices but in a way that makes the update process digestible for people depending on it.
- chupasaurus 2y ago> I get that. But then, keeping that legacy stuff running is just as problematic as rolling your own crypto. Both problems are from the lack of knowledge, but latter one is orders of magnitude harder to fix.
- maqp 2y ago>We can leave OpenSSL as it is but it shouldn't be the popular recommendation for developers. OpenSSL isn't a recommendation for developers. For TLS, LibreSSL and BoringSSL are. For other stuff, libsodium is. The only reason I've picked OpenSSL, is it has a higher level library (pyca/cryptography) that gives bindings to X448.
- izacus 2y agoBecause such library is pretty useless in the real world where your system needs to interact with other systems using "legacy" encryption schemes. Usability and practicality is critical for successful security approach.