4 ms·

A long list of supported hashes/algorithms is imo an antipattern for crypto libraries. They should focus on being very obviously correct for a small set of sup

A long list of supported hashes/algorithms is imo an antipattern for crypto libraries. They should focus on being very obviously correct for a small set of supported algorithms. Crypto's hard and this just increases the surface area.

mcraiha 2y ago
It would be easier, if there would be one standard combo that would be enough (e.g. something similar to the WireGuard). Currently there are many IoT devices that mention TLS-support, but they don't specify e.g. supported ciphers and hash functions.
- deleted 2y ago
  [deleted]
- ekr____ 2y ago
  In the case of TLS, at least, there is a set of mandatory to implement algorithms, so in principle two conformant implementations should be able to interoperate using those. Currently, they are: - ECDSA with P-256 for signature - ECDH with P-256 for key establishment - AES_128_GCM for data encryption with SHA-256 for hashing and KDF
capitol_ 2y ago
I would say that this is true for protocols, tls have been significantly improved by dropping support for many different algorithms. But its not obvious that the same is true for a library. The RustCrypto project breaks each algorithm into its own crate, while botan implrments everything. Its not obvious to me that one approach is clearly superior to the other.
- cryptonector 2y ago
  Each alg in its own crate means lower footprint when you need just a few.
  - randombit 2y ago
    It's not really a significant factor here - the Botan build system allows you to select what features you want to include. For example if you wanted a binary that just supports AES, GCM, SHA-256, and ECDSA, with nothing else, that's easily done.
nickelpro 2y ago
This only makes sense if you're doing greenfield development. The second you need to support existing protocols and devices where those decisions were chiseled in stone years or decades before, you'll be happy for a long list of hashes and algorithms all contained inside a single package with a single API to learn.
cryptonector 2y ago
And then you have to deal with some case where you have to interop with something that uses a secure ciphersuite that your library doesn't support, and you block hard on that. Yes, if you want a cryptography library for a greenfield project, then you want something tiny and simple and secure (e.g., libsodium). For other things you'll want a more complete library.

mcraiha 2y ago

It would be easier, if there would be one standard combo that would be enough (e.g. something similar to the WireGuard). Currently there are many IoT devices that mention TLS-support, but they don't specify e.g. supported ciphers and hash functions.

deleted 2y ago
[deleted]
ekr____ 2y ago
In the case of TLS, at least, there is a set of mandatory to implement algorithms, so in principle two conformant implementations should be able to interoperate using those. Currently, they are: - ECDSA with P-256 for signature - ECDH with P-256 for key establishment - AES_128_GCM for data encryption with SHA-256 for hashing and KDF

capitol_ 2y ago

I would say that this is true for protocols, tls have been significantly improved by dropping support for many different algorithms. But its not obvious that the same is true for a library. The RustCrypto project breaks each algorithm into its own crate, while botan implrments everything. Its not obvious to me that one approach is clearly superior to the other.

cryptonector 2y ago
Each alg in its own crate means lower footprint when you need just a few.
- randombit 2y ago
  It's not really a significant factor here - the Botan build system allows you to select what features you want to include. For example if you wanted a binary that just supports AES, GCM, SHA-256, and ECDSA, with nothing else, that's easily done.

nickelpro 2y ago

This only makes sense if you're doing greenfield development. The second you need to support existing protocols and devices where those decisions were chiseled in stone years or decades before, you'll be happy for a long list of hashes and algorithms all contained inside a single package with a single API to learn.

cryptonector 2y ago

And then you have to deal with some case where you have to interop with something that uses a secure ciphersuite that your library doesn't support, and you block hard on that. Yes, if you want a cryptography library for a greenfield project, then you want something tiny and simple and secure (e.g., libsodium). For other things you'll want a more complete library.