Re: Updating SafeCurves for 2022...

I have worked with Ceramic and did-JWT and
https://github.com/sparkfun/SparkFun_ATECCX08a_Arduino_Library (p256 (NIST
FIPS) cryptographic co-processor that works with ESP32 mcu) due to ease of
learning.

Along the way I wondered if BBS+ signatures could be supported, but it was
something that seemed a long way off. The se050 seemed like an obvious next
step for more curves (maybe not Blake..but I found Tobias comment useful).

I am excited to hear about where this goes with my background knowledge
from  working on a prototype. I’ve had to play catch up reading your
documents. I’m sure you’ve seen me around.

-Brent

On Thursday, May 26, 2022, John, Anil <anil.john@hq.dhs.gov> wrote:

> Regardless of the speed (or lack thereof) of both standardization and
> infrastructure support it feels as though cryptographic agility is still
> something that needs to be fully explored and baked into the VC/DID
> standards more than it has been, and on a parallel track socialized,
> accepted and utilized by the broader ecosystem.
>
>
>
> However, based on out-of-band conversations I have had with some of you, I
> am not clear what exactly the term “cryptographic agility” encompasses
> here, so would appreciate some clarification.
>
>
>
> Is it:
>
>    1. The ability for me deploy a solution that supports a particular
>    cryptographic proof format and in the future upgrade it something else e.g.
>    I choose some manner of a **pre-quantum** cryptographic scheme now and
>    in the future have the ability to update my solution to something that uses
>    a **post-quantum** cryptographic scheme?
>    2. The ability to deploy a solution that simultaneously supports
>    multiple cryptographic schemes so that based on verifier policy regarding
>    the features it can support, it can accept one, or the other, or both; OR a
>    separate case being that one of the cryptographic schemes gets broken and
>    there is a  way to signal that such that the verifier is sure to use the
>    other non-broken scheme  e.g. I simultaneously deploy support for both FIPS
>    compliant cryptography and for BBS+ signatures with the choice of what
>    should be used at a verifier to be negotiated between the holder and the
>    verifier.
>
>
>
> If the (2) scenario is valid, does it automatically include (1)? And what
> are the trade-offs and considerations that are involved in deploying
> something like (2) into the ecosystem?
>
>
>
> Best Regards,
>
>
>
> Anil
>
>
>
> Anil John
>
> Technical Director, Silicon Valley Innovation Program
>
> Science and Technology Directorate
>
> US Department of Homeland Security
>
> Washington, DC, USA
>
>
>
> Email Response Time – 24 Hours
>
>
>
> [image: A picture containing graphical user interface Description
> automatically generated] <https://www.dhs.gov/science-and-technology>[image:
> /Users/holly.johnson/Library/Containers/com.microsoft.Outlook/Data/Library/Caches/Signatures/signature_1972159395]
>


-- 
-Brent Shambaugh

GitHub: https://github.com/bshambaugh
Website: http://bshambaugh.org/
LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh
WebID: http://bshambaugh.org/foaf.rdf#me