Post-quantum readiness
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 12/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Área
- cryptography, security
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.)
- Lenguaje dominante
- HTML
- Estrellas
- 158
- Forks
- 43
- Merge medio
- 2 d 6 h
- PR fusionados (30 d)
- 2
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de w3c/push-api
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
-
Do we want to allow a subscription from window.pushManager to fire push event for non-DWP messages?Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 18/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 12/100
Todos los issues de w3c/push-api
Issues similares
-
sig_hash.from_tx returns a legacy hash for a witness v0 program of a wrong lengthPosiblemente ocupada @Yudis-bit la tomó hace 1 día. Abiertogood first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
btclib-org/btclib#2997 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
browserify/browserify-des#16 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
digitalbazaar/forge#1170 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
RustCrypto/hashes#941 ·
Los mantenedores suelen responder en 1 día
-
enhancement priority: P3
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100