Skip to content

Instantly share code, notes, and snippets.

@ChristopherA

ChristopherA/Cryptographic_Watch.md

Last active January 3, 2024 03:14
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ChristopherA/bdcf416486bcd21998494d065f58b24f to your computer and use it in GitHub Desktop.
Save ChristopherA/bdcf416486bcd21998494d065f58b24f to your computer and use it in GitHub Desktop.
Download ZIP
Opinionated notes on cryptographic technologies
Raw
Cryptographic_Watch.md

STATUS: RAW DRAFT

Goal is an opinionated version of something like Cryptographic Right Answers but focused on the needs of the decentralized identity and cryptocurrency ecosystes, and the needs of the Patrons of Blockchain Commons.

See also my replies to:

Encrypting Data

In the [Cryptography Review of W3C Verifiable Credentials Data Model (VCDM) and Decentralized Identifiers (DIDs) Standards and Cryptography Implementation Recommendations] funded by US Department of Homeland Security: http://www.csl.sri.com/papers/vcdm-did-crypto-recs/

RECOMMENDATION: Transition all block ciphers to AES.

I don't agree with most of this document, in particular that the recommendations here 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.

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.

PAKE - Password-Authenticated Key Exchange

A long-time challege for internet security are low-entropy passwords used to authenticate a user with a server, in particular when the server may be compromized or honeypot to collect passwords from many users. The oldest techniques are to use a KDF (Key Derivation Function) to hash the password, and typically leveraged a MD5 or PKDF2. These are vulnerable to approaches like Rainbow Tables, and the oldest KDFs are now trivially breakable (see Hive Report 2022. Even more advanced techniques that do salting & 1000s of iterations like bcrypt & scrypt are beginning to show weaken against brute-force attacks.

With PAKE(Password-Authenticated Key Exchange), the two entities, who only share a password and may be communicating over an insecure channel, can authenticate each other and agree on a large session key for protecting their subsequent communication. These techniques typically leverage public key cryptography such as DH(Diffie-Helman Key Exchange).

OPAQUE

The most interesting new approach to PAKE is OPAQUE, which improves significantly on many other PAKE schemes. It offers the ability to hide the password from the server, even during password registration, does not need to leverage PKI (Public Key Infrastructure), offers security against pre-computation attacks upon server compromise, provides forward secrecy, supports user-side hash iterations, and allows a user-transparent server-side threshold implementation. All powerful features. OPAQUE is reasonably well-reviewed, and is in the process of becoming and IETF Draft, however, many security architects worry that it is too new (2018). IMHO it should be the current best practice, and I also feel the general approach may have broader applicability to be used in future protocols.

Puncturable Encryption

privacy preserving measurements / statistics / data

Distributed Key Generation

Pairing based DKG

Saved at 2022-05-24 20:20

post-quantum

slide on key & signature sizes

zk

kxg committments https://twitter.com/bkiepuszewski/status/1518163771788824576?s=12&t=o4n8bUgfotR0DiWdLNiJ4A

VSS, Distributed Key Generation & Threshold Signing

zk-snark

zk-snark aggregation

zk vulnerabilities

Plonk, Halo & JubJub (zcash) [2022-05-24]

hardware

Partially annotated

  • Comments of the American Civil Liberties Union, Center for Democracy & Technology, Electronic Privacy Information Center, and Electronic Frontier Foundation to the Transportation Security Administration Dept. of Homeland Security on Minimum Standards for Driver's Licenses and Identification Cards Acceptable by Federal Agencies for Official Purposes; Waiver for Mobile Driver's Licenses (2023-10-16). [PDF document]. Retrieved 2024-01-02 from Electronic Frontier Foundation: https://www.eff.org/document/10-16-2023-aclu-eff-epic-comments-re-tsa-nprm-mdls.

    TAGS: #DigitalIdentity #PrivacyRights #MobileDriversLicenses #FederalRegulations #CivilLiberties #RealIDAct #TSA #PrivacyPreservation #GovernmentStandards #IdentificationSecurity #PublicPolicy

    SHORT ABSTRACT: "This document presents a collective response from the ACLU, CDT, EPIC, and EFF to the TSA's proposed standards for mobile driver's licenses. It critically assesses the privacy implications and the sufficiency of proposed security measures, urging caution against premature implementation without adequate privacy safeguards and interoperability standards. The comments emphasize the need for a comprehensive, privacy-preserving digital identity system and caution against vendor lock-in, underscoring the broader impacts on civil liberties and effective identity management."

    KEY QUOTES:

    1. "The use of mobile driver's licenses (mDLs) in federal identification and screening processes, such as at TSA checkpoints, raises substantial privacy and civil liberties concerns that are not adequately addressed in the NPRM."
    2. "It is crucial that privacy and security considerations, particularly the minimization of data collection and sharing, be central to the development of mDL standards."
    3. "We are concerned that the proposed standards do not prevent unnecessary collection or retention of personal information by entities verifying an mDL."
    4. "The implementation of mDLs must include robust security measures to prevent unauthorized access to sensitive personal information."
    5. "The deployment of mDLs should not lead to mandatory use or become a de facto requirement for citizens, thereby infringing on individual choice and privacy."

Undersorted

Offline Crypto [2022-05-11]

AKE Authenticated Key Exchange: CPACE OPAQUE, etc. [2022-05-11]

Peer DIDs: did:peer, git, github, keri (Key Event Receipt Infrastructure) [2022-05-11]

Schnorr [2022-05-24]

Proof of * [2022-05-26]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment