Use ciphersuite strings to select ciphers?

[tarcieri]

The test vectors presently use the following ciphersuite strings:

• XSTREAM_X25519_HKDF_SHA256_AES128_SIV
  • Key Agreement: X25519
  • KDF: HMAC-SHA-256
  • Symmetric Cipher: AES-128-SIV
• XSTREAM_X25519_HKDF_SHA256_AES128_PMAC_SIV
  • Key Agreement: X25519
  • KDF: HMAC-SHA-256
  • Symmetric Cipher: AES-128-PMAC-SIV

However, none of the existing XSTREAM implementations accept these as arguments, but instead take an AES-SIV versus AES-PMAC-SIV string which is passed directly to Miscreant (where applicable).

For the Rust implementation in particular, it would be nice to have object safe traits for STREAM which allow us to use either STREAM or XSTREAM via a trait object, and in particular to select the stream encryptor type to use based on a string.

[xorxornop]

In particular, these constructions could very well be made through a series of Decorator-pattern traits/impls. Stringly-typed parameters in Rust is just.... wrong!

[tarcieri]

Selection of which cipher to use can often come from a string parameter, such as a command-line option or data read from a file.

I love types too, but there's a point where you have to interface with a user...

[eternaleye]

I'd argue that handling strings and converting them to a strongly-typed interface belongs in the frontend - in the commandline parser stage for handling CLI args; in the config file loading stage for handling configurations, etc.

There will certainly be cases where people know they only want one of these, or they have a system based on numeric or UUID identifiers, or other reasons why the particular strings miscreant and/or xstream expect are irrelevant. In those situations, they will have lost static validation of what they're passing for zero gain.