CWE ID 327: AbstractNamedCurve.java:94

[Brent Putman]

On 9/23/22 1:05 AM, Jeremy Karlson wrote:
> Sorry for the delay in responding. I’ve spent the last couple of days doing other things, as well as thinking about this. There is no list of algorithms that Veracode considers weak that I know of; they seem to rely heavily on OWASP, and OWASP says:
>
>> https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html:
>> "For asymmetric encryption, use elliptical curve cryptography (ECC) with a secure curve such as Curve25519 as a preferred algorithm. If ECC is not available and RSA must be used, then ensure that the key is at least 2048 bits."


Ok.  Well, if that's all they are willing to say, then I don't think we 
can really do anything here.  Other than maybe find out in general what 
curves the crypto community consensus believes to be weak, or something 
like that.


> Since the file it refers to is very specifically an ECC file, and it doesn’t specify exactly which curve it has complaints about, I don’t see any way to know. I assume that some curves are better than others, but it doesn’t list any specifically as “don’t do this.”


Yes, that list of weak/bad curves is what we'd need.


> For my own education… If it’s one-sided, in this exchange, who is the 
> specifier of which encryption mechanisms are used? In my case, my 
> employer is the Service Provider, and we are not an Identity 
> Provider. If it’s the Service Provider, then maybe I have a hope of 
> disabling the offending curve (if I ever find it). If it’s the 
> Identity Provider, then I think I’d have fewer options because we are 
> limited by what all of the IdPs would be willing / able to do.


Well, in general both parties might express preferences for different 
kinds of algorithms, via different mechanisms, so it's not an easy 
answer for all algorithms.

However, here we are talking about the named curve of an EC key, not 
say a signing or encryption algorithm. So the answer is actually easier:

For encryption, as an SP, the IdP will encrypt with a key that you 
previously gave them, either via SAML metadata or out-of-band.  So if 
you don't want a "weak" curve used - just don't give the IdP(s) an EC 
public key generated with a weak curve (or too short key length, etc).  
It's really that simple. You are in complete control of the key(s) the 
IdPs use to encrypt to you.

For signing, as an SP, you are validating messages signed with the 
IdP's key.  They are in control of that, so it could be a weak curve 
(or too-short key).  The SP could enforce a policy on IdP keys at 
runtime.  I don't recall if you said if you are using the Shibboleth 
SP, or another implementation.  Off-hand I don't know if the Shib SP 
supports such a key policy eval. We just discussed briefly on our dev 
call, but I can't remember if Scott said the SP already has this or 
just would like to have. Hopefully he'll comment. If the SP is 
something else, including something that your employer has coded 
themselves, then you'll have to look to the developers of that SP 
software for the answer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220923/1a64727c/attachment.htm>