Capítulo 1 — Pregunta de investigación y método de revisión de la literatura

Capítulo 1 — Pregunta de investigación y método de revisión de la literatura

Mapa de la lección

Lección 01 publicada. Mapa, ejemplo, EX001.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["1.1 De la queja a la pregunta"]
  N2["1.2 Por qué el tamaño es plausible"]
  N3["1.3 FINER"]
  N4["1.4 Una búsqueda documentada"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX001"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["1.1 De la queja a la pregunta"]
  N2["1.2 Por qué el tamaño es plausible"]
  N3["1.3 FINER"]
  N4["1.4 Una búsqueda documentada"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]

[Resultados de aprendizaje y conexión]
    |
    v
[1.1 De la queja a la pregunta]
    |
    v
[1.2 Por qué el tamaño es plausible]
    |
    v
[1.3 FINER]
    |
    v
[1.4 Una búsqueda documentada]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX001]

Resultados de aprendizaje y conexión

Usted podrá (1) convertir una queja operativa en una pregunta investigable; (2) aplicar la prueba FINER (factible, interesante, novedosa, ética y relevante, por sus siglas en inglés); (3) diseñar una búsqueda bibliográfica documentada en fuentes normativas, académicas y profesionales; y (4) construir una tabla de evidencia. El capítulo se apoya en sus conocimientos de entrada y prepara el seminario del capítulo 2.

1.1 De la queja a la pregunta

«Lo poscuántico ha roto internet en el ala del hospital» es una queja. Mezcla una intervención (ofrecer X25519MLKEM768), un resultado (los usuarios no pueden cargar sitios), una población (los usuarios del ala del hospital) y una causa implícita (la criptografía poscuántica). Una pregunta de investigación las separa y convierte la causa en algo que se pone a prueba en lugar de suponerse. Primer borrador: ¿aumentaron los fallos?, que tiene respuesta, pero es descriptivo. Segundo borrador: ¿aumentaron los fallos más en la vía del proxy que en la vía directa?, que es comparativo. Tercer borrador, la pregunta del Estudio Fragment ya citada: ¿qué parte del aumento es atribuible al tratamiento de los ClientHello de varios paquetes, y dónde?, que es explicativo y acotado. El tercer borrador es más difícil, pero es el que debe intentar un trabajo de fin de máster, porque puede orientar una decisión (reparar el proxy o retirar el grupo) y puede resultar erróneo.

1.2 Por qué el tamaño es plausible

Una parte de clave X25519 tradicional ocupa 32 bytes. La clave de encapsulación de ML-KEM-768 ocupa 1.184 bytes (FIPS 203, tabla 3), así que la parte del cliente de X25519MLKEM768 ocupa 1.216 bytes y la parte de respuesta del servidor —un texto cifrado de ML-KEM de 1.088 bytes más 32— ocupa 1.120 bytes (RFC 10024). Un ClientHello que antes cabía en un solo segmento TCP ahora necesita a menudo dos. TLS 1.3 lo admite (RFC 8446: los registros pueden abarcar varios segmentos), pero el software que solo lee el primer paquete para tomar una decisión de encaminamiento o de inspección puede fallar. El mecanismo es concreto, y eso lo hace comprobable.

1.3 FINER

Factible: el proxy y la telemetría de los navegadores de Larkspur ya registran el resultado de los saludos (sintético). Interesante: toda organización que active grupos híbridos se enfrenta a la pregunta. Novedosa: los informes públicos proceden sobre todo de fabricantes o abarcan todo un navegador; pocos estudios atribuyen los fallos dentro de una organización poniendo a prueba explicaciones en competencia. Ética: los registros pueden minimizarse a metadatos (capítulo 3). Relevante: la respuesta decide entre retirar la protección cuántica y reparar la infraestructura. Escriba la comprobación FINER en la propuesta con una frase de evidencia para cada letra, no con una simple marca. Para la factibilidad, nombre las fuentes de registros y confirme con el equipo de red que conservan el resultado de los saludos durante el tiempo suficiente. Para la novedad, remita a la tabla de evidencia, donde se ve la laguna en la atribución dentro de una organización.

1.4 Una búsqueda documentada

Busque por separado en tres familias de fuentes. Normas: RFC Editor y el datatracker del IETF, sobre intercambio de claves híbrido en TLS, ML-KEM en TLS y tamaño del ClientHello. Académicas: IACR ePrint y las bibliotecas digitales de ACM, IEEE y USENIX, con los términos «post-quantum TLS performance», «hybrid key exchange deployment» y «middlebox ossification». Profesionales: blogs de ingeniería de navegadores y CDN, que contienen la mayor parte de la evidencia de despliegue, pero están escritos por partes interesadas. Anote la fecha, la base de datos, la cadena y el número de resultados de cada búsqueda para que un lector pueda repetirla: es el equivalente, en una maestría, de un cuaderno de laboratorio.

1.5 Ejemplo resuelto: la tabla de evidencia

La tabla revela la laguna: existen mecanismos y anécdotas, pero no atribución dentro de una organización.

Añada una fila por cada fuente nueva a medida que avance la búsqueda y mantenga honesta la columna de límites, incluso para las fuentes que apoyan la pregunta. El artículo P-7 que se comenta en el seminario entraría en la tabla con su afirmación del 240 % y un límite que señala la tasa base ausente. Un lector debería poder ver solo con la tabla por qué hace falta el estudio.

1.6 Errores comunes y límites

• Dejar que la causa implícita de la queja se convierta en la hipótesis sin rivales.
• Buscar solo en bases de datos académicas en un campo donde la evidencia de despliegue está en los blogs de ingeniería.
• Tratar una lista seleccionada (tldr.fail) como una muestra aleatoria.
• Búsquedas no registradas que no pueden repetirse.

Cada error tiene una salvaguarda. Escriba los rivales antes de elegir una hipótesis, como hace el capítulo 4 con cinco de ellos. Busque en los blogs de ingeniería como una familia aparte con sus propios límites. Describa tldr.fail como una lista seleccionada, no como una muestra. Lleve un registro de búsqueda con la fecha, la base de datos, la cadena y el número de resultados de cada ejecución, para que un examinador pueda repetirla.

Ejercicios — capítulo 1

• EX001 — Descomponer una queja. Separe «la PQC ha roto el wifi de la biblioteca» en intervención, resultado, población y causa implícita. Rúbrica: 3 = las cuatro más una causa rival.
• EX002 — Tres borradores. Escriba versiones descriptiva, comparativa y explicativa de una pregunta sobre grupos híbridos y VPN. Rúbrica: 3 = versión explicativa acotada y comprobable.
• EX003 — Aritmética de tamaños. Calcule el tamaño de las partes de clave del cliente y del servidor para SecP384r1MLKEM1024 con los tamaños de ML-KEM-1024 de FIPS 203 (clave de encapsulación y texto cifrado de 1.568 bytes) y un punto P-384 sin comprimir de 97 bytes. Rúbrica: 3 = ambos tamaños correctos, con fuentes.
• EX004 — FINER. Aplique FINER a su propia pregunta. Rúbrica: 3 = cada criterio argumentado y al menos una debilidad admitida.
• EX005 — Registro de búsqueda. Escriba un registro de búsqueda con tres bases de datos, cadenas y fechas. Rúbrica: 3 = repetible.
• EX006 — Tabla de evidencia. Añada dos filas a partir de fuentes que verifique usted mismo. Rúbrica: 3 = fuentes primarias o claramente etiquetadas como profesionales, límites declarados.
• EX007 — Enunciado de la laguna. Escriba la laguna en una frase. Rúbrica: 3 = nombra con precisión la evidencia que falta.

Síntesis del capítulo

Una pregunta investigable separa intervención, resultado, población y causa, descansa en un mecanismo concreto y se apoya en una búsqueda repetible en fuentes normativas, académicas y profesionales.

Siga estudiando — capítulo 01 de 08

← Página del curso · Índice de capítulos del curso · Capítulo 02 (borrador) →