# Choosing UWP encryption algorithms

I've just come across the large variety of encryption ciphers available in the UWP WinRT API, both symmetric and asymmetric. I'm trying to figure out which are commonly seen as the most favourable from the choices available for UWT (obviously this is very context specific, but surprisingly many seem to be outdated or clearly just "worse").

With symmetric, I've seen that AES is usually a good go-to algorithm of choice (this post for example), and this site says AES_GCM is pretty much the best variant.

With asymmetric the two main options presented in UWP's API are ECDSA and RSA. I was sceptical if ECDSA was actually an encryption algorithm, but this answer certainly made it seem so, even if the name says "digital signature". Now all of these names include a hash, and their descriptions state that there is signing involved with this hash, which confused me. Why is this explicit encryption algorithm signing this stuff too?

Anyway, this post, and this article both suggest that OAEP is better than PKCS#1, which then leaves us with the following options for asymmetric encryption:

ECDSA_P256_SHA256
ECDSA_P384_SHA384
ECDSA_P521_SHA512
ECDSA_SHA256
ECDSA_SHA384
ECDSA_SHA512
RSA_OAEP_SHA1
RSA_OAEP_SHA256
RSA_OAEP_SHA384
RSA_OAEP_SHA512

Given that P256, P384 and P521 are the public key size for ECDSA, then that raises the question of what the difference is with the ECDSA without P256, P384 or P521? What applicable difference do these differences make?

Okay, cheers for reading so far! I've summarised my questions below:

1. Is the assumption that AES is "best" a valid one, alongside the assumption for AES_GCM?
2. Is ECDSA actually an encryption algorithm, given the name?
3. Why do the UWP API asymmetric encryption algorithms all reference signing with hashes in their descriptions? Is this really the case, and if so why? Surely if they wanted authentication through signing it would be a separate process?
4. Is OAEP generally considered better than PKCS#1?
5. What is the difference between the ECDSA algorithms which do and don't specify public key size (eg ECDSA_SHA256 vs ECDSA_P256_SHA256)?
6. What difference do the hash sizes (and public key sizes for ECDSA if relevant) make, and what about if authentication isn't needed (which I guess would be why they're hashing and signing in the first place)

Any and all help is greatly appreciated, thank you for your time! :D

## 1 Answer

1. Is the assumption that AES is "best" a valid one, alongside the assumption for AES_GCM?

Opinionated, but Microsoft doesn't implement a lot of modern ciphers, so AES is the tried and true one. If GCM mode is best depends on the use case really, but as it is an authenticated mode - it includes a MAC - it is generally better than e.g. ECB / CBC which aren't.

1. Is ECDSA actually an encryption algorithm, given the name?

Asking the question is answering it: no it is not. However, using ECIES, you can use the keys both for ECDSA and ECDH, and ECDH enables ECIES, which is an encryption scheme.

1. Why do the UWP API asymmetric encryption algorithms all reference signing with hashes in their descriptions? Is this really the case, and if so why? Surely if they wanted authentication through signing it would be a separate process?

I don't know, Microsoft webpages are down, I get a 403. Oh, they are up again, and they are as helpful as ever. Off topic here though.

1. Is OAEP generally considered better than PKCS#1?

PKCS#1 v2.0 is the standard that defines OAEP, so that's a nonsensical question if you take it literally. Yes, generally it is considered more secure than PKCS#1 v1.5, which is what "PKCS#1" usually refers to. Although you could say that this is opinionated as well, at least OAEP has got a proof that it is secure given that RSA is secure.

What is the difference between the ECDSA algorithms which do and don't specify public key size (eg ECDSA_SHA256 vs ECDSA_P256_SHA256)?

That's more of an issue with the API, maybe the P256 one assumes the Certicom named curve with the NIST standardized name. Again, not specified.

What difference do the hash sizes (and public key sizes for ECDSA if relevant) make, and what about if authentication isn't needed (which I guess would be why they're hashing and signing in the first place).

Hashes are used for a lot of things, e.g. OAEP uses them internally as well, but not to authenticate the message. In ECDSA they are used to hash the message, which is then used in signature generation and verification. Generally a larger hash output size / key size means more secure.

• Sorry about the fact that I cannot comment on the Microsoft API. I'm really trying to get these guys to properly document their API's, but there is a lot of historical dept. At the moment I'm still seeing them as one of the worst documented crypto API's. Note that such API documentation questions are officially off topic here. These should be asked at StackOverflow. I've answered the other questions though. Jul 28 '20 at 18:16