<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/23/22 1:05 AM, Jeremy Karlson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:03FDE88A-E56C-4B39-8172-4C60AF9A9EC8@gmail.com">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-freetext" href="https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html">https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html</a>:
"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."</pre>
</blockquote>
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>
</p>
<blockquote type="cite"
cite="mid:03FDE88A-E56C-4B39-8172-4C60AF9A9EC8@gmail.com">
<pre class="moz-quote-pre" wrap="">
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.”</pre>
</blockquote>
<p><br>
</p>
<p>Yes, that list of weak/bad curves is what we'd need.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:03FDE88A-E56C-4B39-8172-4C60AF9A9EC8@gmail.com">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.</blockquote>
<p><br>
</p>
<p>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.</p>
<p>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:</p>
<p>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.</p>
<p>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.<br>
</p>
</body>
</html>