Abstract CryptKey public methods to the CryptKeyInterface

[erickskrauch]

The library provides flexible storage for all possible types of entities but strictly adheres to the use of the RSA key written to the file for signing JWT tokens. Using RSA, the size of the signature is almost 3 times larger than the key itself, so I would prefer to use a different key and signature algorithm. But the current implementation of CryptKey sets a strict requirement for RSA.

Of course, I can extend from CryptKey and override the constructor, but this is a way of avoiding the problem rather than solving it.

This solution is BC, so I expect it to be available only in the 9.0.0 release. Anyway, I think we need a lot more abstraction on the keys (see #1007).

[Sephster]

Thanks @erickskrauch. Out of interest, which signing mechanism were you looking to use instead? Can you provide some background as to the issues you are having with the size of the file at the moment? We've chosen this signing mechanism to keep things secure by default but happy to look at changing the library if this is causing real problems for people

[erickskrauch]

@Sephster, ECDSA SHA-256. This algorithm provides a much shorter signature length (compare them on https://jwt.io). You can say that this is a bit saving, but if it can be optimized, I prefer this algorithm over RSA.

[Sephster]

Thanks @erickskrauch. I can see why someone would want this. ECDSA is slower than RSA but does offer some space saving so I guess the implementer would have to weigh up the benefits/drawbacks. Seems like a good idea to include something like this. I will give it a full review soon. Cheers

[Sephster]

Minor changes required around return statements. We will also need to have this merge to the v9 branch (which I haven't created yet). I'm happy to make these changes now to push this through but noting here for feedback.