Re: Use of cryptography with W3C VCs and DIDs released

On Fri, Apr 22, 2022 at 8:12 AM bengoering@gmail.com <bengoering@gmail.com>
wrote:

> Christopher, originally I read your message as being against all of the
> recommendations.
>

To be clear I said "recommendations are largely bad long-term" — many are
clearly better than current practices for incremental improvements for the
short term. My concern is that they continue an old-style of thinking and
lock you into architectural choices that are too limiting for the longer
term.

Personally, I find at least the first couple recommendations fairly
> reasonable. Would you be willing to be more explicit about which
> recommendations, if any, you don’t find to be largely bad long-term
> decisions? Is there any common ground?
>

Thanks for the question, and it is on our (Blockchain Commons) roadmap to
be able to explain more about these "strong opinions" and issues of
"short-term" vs "long-term" more clearly.

Let's just take one example - AES.

http://www.csl.sri.com/papers/vcdm-did-crypto-recs/:
> RECOMMENDATION: Transition all block ciphers to AES.

AES certainly is a minimum viable block cipher, and older ones were long
overdue to be deprecated. However, AES has been broken with demonstrated
key-recovery attacks from side-channels in many practical settings, and
there is a large group of cryptographers who don't consider it safe. I'll
crib from last week's #RealWorldCrypto conference slides
https://iacr.org/submit/files/slides/2022/rwc/rwc2022/105/slides.pdf —
"there is more that we want from our block ciphers today":
  * Format preserving encryption
  * searchable encryption
  * order-preserving encryption
  * white-box cryptography
  * full-disk encryption
  * ciphers suitable for protocols like multi-party computation,
zero-knowledge proofs, etc.
  * Nonce-misuse resistance
  * related-key security
  * combined functionality
  * inherent side channel resistance
  * key commitment
  * suitable for constrained environments etc.

Though there are a number of candidates in these areas, many practical
implementations today are variants of, or leverage the ChaCha stream
cipher, and the Poly1305 message authentication code (MAC), in particular
ChaCha20-Poly1035 which is recommended for use by TLS 1.3. (we shortly will
be supporting this directly as a CBOR object in Blockchain Commons specs).
These two primitives also support a wide variety of other solutions,
including in particular full-disk media encryption on all Android devices
which doesn't require the overhead storage of nonces for their use case,
and punctuated perfect forward secrecy in Signal. There is no mention of
ChaCha or Poly1305 in the entire NIST document!

In my opinion, AES should be considered *Legacy -> Deprecated*. It should
only be used if you are locked into using legacy because of NIST-certified
low-performance chips that only have hardware support for AES and SHA256.
And if you do, you need to deeply understand the differences and
limitations of AEAD-AES-GCM-SHA & AES-CTR with HMAC. As we are beginning to
see chip support for other block and stream ciphers in hardware, and many
of those that don't have new primitives often can do ChaCha20-Poly1305 a
reasonable amount of time using JavaCard code or other C libraries.  If you
can do ChaCha20-Poly1035, use it.

I do feel ChaCha20-Poly1305 isn't perfect. For one thing, it is overkill. I
think a ChaCha8 would probably have been sufficient for the next
decade(Google's Adiatum
https://security.googleblog.com/2019/02/introducing-adiantum-encryption-for.html
does ChaCha12). But it is now an IETF standard (RFC7539) and there is
quality reviewed code available out there to implement it. Thus it rates
*Best-Practice* in my book.

I hope you found this useful — I regularly have discussions about these
kind of questions among our Blockchain Commons patrons, and hope that if
you'd like to see more of this that you might become one.
https://github.com/sponsors/BlockchainCommons. Even $20 a month helps and
offers social proof for others to see that our past and future
contributions to this field are useful. Our sustaining sponsors at $1000 to
$10,000 a month get substantially more as they guide our priorities for our
open source specs, libraries, and reference code.

-- Christopher Allen