Post-quantum readiness
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 12/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- cryptography, security
Direzione di ricerca
The change lives in the Push API spec text: the PushSubscription interface and the "receiving a push message" algorithm, plus references to RFC 8291. Start by reading the linked webpush-pq sketches and the open issue there (martinthomson/webpush-pq#2) to see the proposed keying material. This is cryptographic design work that the IETF DISPATCH process will decide, so a first contribution would be a question or review comment, not a spec edit. Done means the maintainers have agreed on the scope of the spec changes.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
The current cryptographic design loses many of the good properties we might like to have if a cryptographically-relevant quantum computer is created and applied to recovering secrets.
I've started sketches of designs for a replacement cryptographic message protection here: https://github.com/martinthomson/webpush-pq
My goal is to take these to the IETF DISPATCH process, as I think that the cryptographic review there is more likely to be robust. It is also easier to obsolete RFC 8291 with another IETF document.
The work for the Push API is pretty limited. Defining a new member in PushSubscription to carry new secrets or keying material is all that is needed, as well as updates to references and the "receiving a push message" algorithm.
It might make sense to use this opportunity to split out the declarative functions so that it is not necessary to opportunistically parse JSON for every message. The current design spends a lot of bytes on that, plus a bunch of wasted effort to probe for declarative messages. (Tracking that here.)
- Lingua principale
- HTML
- Stelle
- 158
- Fork
- 43
- Merge medio
- 2g 6h
- PR unite (30g)
- 2
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di w3c/push-api
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
-
Do we want to allow a subscription from window.pushManager to fire push event for non-DWP messages?Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 18/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 12/100
Tutte le issue di w3c/push-api
Issue simili
-
sig_hash.from_tx returns a legacy hash for a witness v0 program of a wrong lengthForse già presa @Yudis-bit l’ha presa 1 giorno fa. Apertagood first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
btclib-org/btclib#2997 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
browserify/browserify-des#16 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
digitalbazaar/forge#1170 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
RustCrypto/hashes#941 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement priority: P3
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100