Reintroduce GetAsymmetricAlgorithm/GetSymmetricAlgorithm

The base AsymmetricSecurityKey and SymmetricSecurityKey classes should expose GetAsymmetricAlgorithm/GetSymmetricAlgorithm to allow retrieving the underlying algorithm without having to cast the security key to known types.

@brentschmaltz any chance we could bring back these APIs for RTM?

[kevinchalet]

@tushargupta51 for RC2, it’s of course too late, that’s why I suggested keeping the API as-is (no rollback) and adding the necessary stuff in the next milestone 👍

Your approach seems fine, and it’s pretty close to what CryptoConfig offers:

public override bool IsSupportedAlgorithm(string algorithm)
{
    if (string.IsNullOrEmpty(algorithm))
    {
        throw DiagnosticUtility.ExceptionUtility.ThrowHelperArgument(algorithm, SR.GetString(SR.EmptyOrNullArgumentString, "algorithm"));
    }

    object algorithmObject = null;

    try
    {
        algorithmObject = CryptoHelper.GetAlgorithmFromConfig(algorithm);
    }
    catch (InvalidOperationException)
    {
        algorithmObject = null;
    }

    if (algorithmObject != null)
    {
        SignatureDescription signatureDescription = algorithmObject as SignatureDescription;
        if (signatureDescription != null)
            return true;
        AsymmetricAlgorithm asymmetricAlgorithm = algorithmObject as AsymmetricAlgorithm;
        if (asymmetricAlgorithm != null)
            return true;
        return false;
    }

    switch (algorithm)
    {
        case SecurityAlgorithms.RsaV15KeyWrap:
        case SecurityAlgorithms.RsaOaepKeyWrap:
        case SecurityAlgorithms.RsaSha1Signature:
        case SecurityAlgorithms.RsaSha256Signature:
            return true;
        default:
            return false;
    }
}

[kevinchalet]

A key has only data. A provider knows how to interact with the underlying layers to produce the correct crypto operations.

Care to share more information or better, write a sample about how to achieve the desired result without the suggested APIs?