Qt Cryptographic Architecture - approaching final API

GPG support only provides OpenPGP ops - signing, verification, encryption and decryption. It doesn't give you the raw primitives. So Cast5 isn't supported as a cipher primitive. It might not be too hard to provide though, if you can explain what you need it for. Can you elaborate?

MD2, MD4 and SHA0 are provided because they are still potentially valuable (just like MD5). Even though there are potential collision attacks for some algorithms, collision-resistance isn't the only useful property for a hash. For example, MD4 is used for its non-reverse characteristic in NTLM, and is a reasonable choice.

Whirlpool might not be too hard either. Do you know if OpenSSL supports it? Would you like to propose a patch?

The random function is a product of the plugin that provides it. We do have an internal provider for random (also MD5 and SHA-1), and it just calls the qrand() function. What algorithm is used to implement that depends on the platform. However other plugins also provide random functions.

QCA doesn't do compression separate to the encryption ops (e.g. in TLS). Can you tell me what led you to think that it might? I probably need to reword it.

Ascii85 isn't a common crypto operation, and I don't see how it could be shared with PDF (since I think that is built into poppler, rather than okular).

Cast 5 is needed for reading Gnupg keyrings (private keys).

For the hashing functions, they must be only provided if there is a real need, you cited NTLM for md4 which is a good reason.

For whirlpool i see it has been implemented already (awesome!) which makes the library now really interesting. Whirlpool is different from the md5 and sha hashing functions, and is suitable as a (hot) replacement for sha if that one is found broken too fast.

The random functions and the compression functions (gzip, bzip2 ..) do matter. It is easier to break data with lots of redundancies, just like the passwords in /etc/password are hashed with a salt and not hashed directly. An incorrect compression or random function however can also make the data much more suitable for cryptanalysis.

As for Ascii85, it is no more a crypto operation than base64, but its use in pdf and its encoding ratio (25% loss instead of 33%) make it a rather relevant feature.

Rich,

Can you explain what you plan to do with this list? I'm trying to make sure we actually provide something useful.

Do you want to show it to the user? If so, do you want a pretty name ("SHA256"), or do you want the name of the provider feature ("sha256")? Or do we need to provide a pair?

Brad

Yes, I'm thinking in terms of providing a list to users. I think the type of users to whom this information would make sense would be able to handle sha256 or SHA256 so I doubt you'd need a 'friendly name'.

...has been implemented.

We could always give you a list of hashes - it just wasn't only the hashes - you got every feature.

Now you can get a list of available hashes. This is from qca_basic.h, as part of the Hash class:
/**
Returns a list of all of the hash types available
*/
static QStringList supportedTypes(const QString &provider = QString());

[The reason why it is static is so you can get the list without creating a Hash first].

By default, you get all the hashes for all the providers, but the provider argument allows you to choose a particular provider.

We also extended this to ciphers and MAC algorithms too.

Sounds great.