<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Jeremy,</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/14/22 8:55 PM, Jeremy Karlson via
users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1197ADB2-9712-4035-98A0-A66479E23D32@gmail.com">
<pre class="moz-quote-pre" wrap="">Hi everyone. I’m new here, so I apologize if this has been discussed ad nauseam before. (I did try searching for answers, but didn’t fine clarity for this specific file.)</pre>
</blockquote>
<p><br>
</p>
<p>Nope, this is the first time it's been brought up AFAIK.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:1197ADB2-9712-4035-98A0-A66479E23D32@gmail.com">
<pre class="moz-quote-pre" wrap="">
Veracode (a code scanning tool my employer has recently started using) is reporting CWE ID 27 (Use of a Broken or Risky Cryptographic Algorithm) specifically in opensaml-security-api, </pre>
</blockquote>
<p><br>
</p>
<p>I have no familiarity with Veracode. I found this table with CWE
IDs:</p>
<p><a class="moz-txt-link-freetext" href="https://docs.veracode.com/r/c_review_cwe">https://docs.veracode.com/r/c_review_cwe</a><br>
</p>
<p>but 27 is a different thing, about path traversal. The one with
that name/label is actually 327 - can you confirm that that is a
typo etc, and 327 is the one in question?<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:1197ADB2-9712-4035-98A0-A66479E23D32@gmail.com">
<pre class="moz-quote-pre" wrap="">org.opensaml.security.crypto.ec.curves.AbstractNamedCurve.java, line 94. This method is:
@Nullable protected ECParameterSpec buildParameterSpec()
And the line in question is:
jcaSpec = ECPublicKey.class.cast(
KeySupport.generateKeyPair(JCAConstants.KEY_ALGO_EC, new ECGenParameterSpec(getName()), null)
.getPublic()).getParams();
I looked at the code but I am certainly out of my depth here, as I know very little about how this operates internally.</pre>
</blockquote>
<p><br>
</p>
<p>That's sort of weird. The only cryptographic algorithm mentioned
there is (general) use of Elliptic Curve (EC) keys, and that
certainly isn't broken or risky. I mean, it's considered more
secure and future-proof than RSA. I was expecting this to
possibly point at a weak signing or encryption algorithm, but all
that code is doing is generating an EC keypair so if that is truly
the code in question, this really doesn't make any sense.</p>
<p>Unless... it's possibly actually flagging on a *particular* named
curve. But in that case, we'd need to know which named curve. The
code above is just code in an abstract base class that resolves an
ECParameterSpec based on a curve name. So we'd need to know the
actual curve name from the surrounding context.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:1197ADB2-9712-4035-98A0-A66479E23D32@gmail.com">
<pre class="moz-quote-pre" wrap=""> I am certain this has been brought up and considered before, so if someone wants to let me know this isn’t a problem, I can put a checkmark in this box and we can all get on with out days. :-)</pre>
</blockquote>
<p><br>
</p>
<p>It actually never has, to my knowledge. It's certainly possible
that we are by default including support for a named curve that is
considered weak at this point.</p>
<p>But the code reference above doesn't tell us anything useful.
We'd need to know the value of the getName() there - the named
curve ID - which is going to be in the concrete class impl. (Every
named curve will have a concrete NamedCurve impl, which has
AbstractNamedCurve as a super class.)<br>
</p>
<p>--Brent<br>
</p>
</body>
</html>