Estudio del protocolo BB84 de criptografía cuántica

Universidad de Valladolid ESCUELA DE INGENIERÍA INFORMÁTICA DE SEGOVIA Grado en Ingeniería Informática de Servicios y Aplicaciones Estudio del protocolo BB84 de criptografía cuántica Alumno: Jorge Martín Villafruela Tutor/a/es: Juan José Álvarez Sánchez Estudio del protocolo BB84 de computación cuántica Jorge Martín Villafruela Índice general Lista de figuras v Lista de tablas vii Resumen xiii I Memoria del Proyecto 1 1. Descripción del proyecto 3 1.1. Introducción................................... 3 1.2. Objetivosdeltrabajo.............................. 4 1.3. Entornodelproyecto.............................. 4 1.3.1. Entornogeneral............................. 4 1.3.2. Entorno específico: Xanadu . . . . . . . . . . . . . . . . . . . . . . 5 2. Conceptos teóricos relevantes 7 2.1. La computación cuántica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. El problema de la generación de la clave privada . . . . . . . . . . . . . . . 8 2.3. ElprotocoloBB84 ............................... 11 2.4. Mejoradelprotocolo .............................. 13 3. Metodología 15 3.1. Procesodedesarrollo.............................. 15 3.2. Herramientas de desarrollo utilizadas . . . . . . . . . . . . . . . . . . . . . 17 3.3. Arquitectura................................... 18 3.4. Definición de siglas y abreviaturas . . . . . . . . . . . . . . . . . . . . . . . 19 4. Planificación 21 4.1. Estimación del esfuerzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Planificación temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.1. Roles en el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3. Presupuesto económico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 i Índice general 4.3.1. Hardware y software . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.2. Recursoshumanos ........................... 25 4.3.3. Presupuesto total . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Conclusiones 29 II Documentación técnica 31 6. Lenguajes de programación 33 6.1. Librerías de Python ............................... 33 6.1.1. Crytodome ............................... 33 6.1.2. Matplotlib................................ 34 6.1.3. PennyLane ............................... 35 6.1.4. Numpy.................................. 37 6.1.5. TensorFlow ............................... 37 6.2. Jupyter Notebook ................................ 38 6.2.1. Arquitectura y funcionamiento . . . . . . . . . . . . . . . . . . . . . 38 6.2.2. Entorno de Markdown . . . . . . . . . . . . . . . . . . . . . . . . . 40 7. Análisis 43 7.1. Requisitos.................................... 43 7.1.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.1.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . 49 7.1.3. Atributos de calidad . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.2. Diseño...................................... 50 7.2.1. Cuadernos Jupyter ........................... 50 7.2.2. Scripts de Python ............................ 51 8. Implementación 57 8.1. Person.py .................................... 57 8.2. OperacionesBB84.py .............................. 57 8.3. BB84Basic.py .................................. 62 8.4. BB84Alt.py ................................... 64 8.5. BB84Ruido.py .................................. 66 8.6. BB84Eve.py ................................... 68 8.7. BB84Extra.py .................................. 70 8.8. AES.py ...................................... 72 8.9. Generación de histogramas . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 9. Pruebas 75 ii Jorge Martín Villafruela Índice general III Manuales de la Aplicación 79 10.Manuales 81 10.1. Manual de Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 10.2.ManualdeUso ................................. 83 IV Apéndices 85 A. Anexos 87 A.1. Información complementaria . . . . . . . . . . . . . . . . . . . . . . . . . . 87 A.2.Diagramasytablas............................... 89 A.2.1. Estimaciones temporales del proyecto . . . . . . . . . . . . . . . . . 89 A.2.2. Diagramas de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . 92 B. Contenido del entregable 97 Bibliografía 99 Jorge Martín Villafruela iii Índice general iv Jorge Martín Villafruela Índice de figuras 2.1. Generación de un ambiente cifrado en un canal público. . . . . . . . . . . 9 2.2. Esquema del ataque de eavesdropping . . . . . . . . . . . . . . . . . . . . 10 2.3. Circuito del Protocolo BB84 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Ataque de Eve al protocolo BB84 . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Gráfica de separación de la muestra de ruido e Eve. . . . . . . . . . . . . . 14 3.1. Patróndearquitectura............................. 18 6.1. Visualización de un cuaderno Jupyter como archivo JSON. . . . . . . . . . 39 6.2. Arquitectura de Jupyter Notebook ....................... 40 6.3. Ejemplo de celdas de Markdown . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2. Diagrama del proceso de cribado de bits de los bits transmitidos . . . . . . 52 7.1. Diagrama de actividad del algoritmo BB84 . . . . . . . . . . . . . . . . . . 54 7.3. Diagrama de paquetes del proyecto . . . . . . . . . . . . . . . . . . . . . . 55 9.1. Prueba de caja negra a través de state() .................. 76 9.2. Utilización del Debugger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 10.1. Página de descarga del ejecutable de Python.................. 82 10.2. Abrir Jupyter en Anaconda . . . . . . . . . . . . . . . . . . . . . . . . . . 83 10.3. Barra de herramientas de los cuadernos Jupyter . . . . . . . . . . . . . . . 84 v Resumen La computación cuántica es un paradigma de computación que hasta hace poco solo tenía utilidad práctica. Con la reciente construcción de cada vez más ordenadores cuánticos, este nuevo paradigma está obteniendo una utilidad práctica. Entre las ramas donde encuentra esa utilidad, es en la de la seguridad. El protocolo BB84 solventa una de las grandes debilidad que tiene la seguridad actual: la generación de claves privadas. En este proyecto, se estudiará una implementación de dicho protocolo en python con ayuda de la librería PennyLane, así como el estudio de la fiabilidad (y mejora) del protocolo al trabajar sobre un canal con ruido, donde la detección de un posible atacante es más discreta. Palabras claves: computación cuántica, protocolo BB84, seguridad, estudio teórico, PennyLane, python, Jupyter. xiii Parte I Memoria del Proyecto Capítulo 1 Descripción del proyecto El proyecto consiste en la realización de una serie de cuadernos Jupyter explicando el funcionamiento del protocolo BB84, un protcolo de generación de claves privadas en criptografía cuántica. Por ello, también se realizará una breve introducción a la computación. Además, utilizando la librería PennyLane, se implementará y explicará el protocolo en Phyton. También se analiza la aplicación de dicho protocolo en un canal con ruido, y cómo en este entorno su implementación inicial se vuelve obsoleta. Por último, para completar el proyecto, se sugiere una modificación del protocolo para que puede ser utilizable en este entorno, junto a la generación de varias muestras estadísticas que justifican dicho razonamiento. En esta Memoria se desarrollará tanto los aspectos teóricos del proyecto, donde se explicará tanto la base teórica como la programación del mismo, así como analizar el desarrollo de los cuadernos como proyecto software; explicando la metodología utilizada, así como su planificación temporal y desarrollo de los presupuestos, y la documentación del proyecto realizada a partir del análisis de requisitos y realización de diagramas. Al final de esta Memoria además se encontrarán unos breves manuales de instalación y uso de cuadernos Jupyter. 1.1. Introducción La computación cuántica es todavía una tecnología emergente bastante desconocida y en pleno auge. Por ello, la creación de contenido didáctico que pueda servir como introducción a este paradigma de computación (tanto a nivel personal como general) es necesaria actualmente, sobre todo en español donde toda la bibliografía relacionada es escasa por no decir inexistente. Entre las ramas de la informática donde la computación cuántica parece cobrar más relevancia, se encuentra el campo de la seguridad informática, debido a su naturaleza probabilística. Este Trabajo de Fin de Grado se centra en el estudio del protocolo de cifrado BB84, de manera de que sirva como introducción a este nuevo paradigma, añadiendo para ello simulaciones en Python de circuitos cuánticos. También se analiza cómo afecta 3 Capítulo 1. Descripción del proyecto al protocolo el hecho de que actúe sobre un canal con ruido, donde la detección de un intruso es más costoso al poder camuflarse el atacante con el propio ruido. Para implementar dichas simulaciones, se hace uso de la librería PennyLane, desarrollada por Xanadu(sección 6.1.3). En esta memoria se discutirá cómo se ha planificado y ejecutado el desarrollo de estos cuadernos Jupyter, así como explicar los contenidos teóricos de los cuadernos y el funcionamiento de las librerías de Python utilizadas, con especial atención a la librería de Pennylane. A continuación, aparecerá la documentación del proyecto, compuesta por los requisitos del proyecto y los distintos diagramas que han dictado la elaboración del mismo. En una sección aparte se comentará las librerías utilizadas en el proyecto, así como el razonamiento del desarrollo de las principales funciones que lo componen. Asimismo, se comentarán las pruebas de integridad realizadas sobre el código desarrollado. Finalmente, se incluirá un manual de instalación y uso de los cuadernos Jupyter. 1.2. Objetivos del trabajo Al ser un estudio sobre una nueva tecnología emergente, en el ámbito personal este trabajo ha servido para introducirme al manejo de este nuevo paradigma de computación. Además, he podido asentar mis conocimientos en Python. Más específicamente, la creación de cuadernos Jupyter y el uso de la librería pennylane, utilizada para la simulación en Python de circuitos cuánticos. A nivel teórico, el objetivo principal del proyecto es explicar la mejora que significa la aplicación de la computación cuántica en general y del protocolo BB84 en particular, en el problema de la generación del claves privadas, poniendo énfasis en la efectividad del protocolo en un canal con ruido. En concreto, el objetivo final de los cuadernos es llegar a conseguir una mejora del protocolo para que su rendimiento en un entorno con ruido mejore. Por último, no hay que olvidar el carácter didáctico de los cuadernos que conforman el estudio, puesto que también se quiere que puedan servir como introducción al paradigma de la computación cuántica nivel teórico, usando el protocolo BB84 como guía para ir aprendiendo sobre las características y conceptos únicos de la computación cuántica. De la misma manera, se puede utilizar como ejemplo de implementación de circuitos cuánticos utilizando la librería de PennyLane. 1.3. Entorno del proyecto 1.3.1. Entorno general Dentro del entorno general del proyecto; al ser un estudio teórico, cobran mayor relevancia los factores tecnológicos. En concreto, el estado actual de la computación cuántica. 4Jorge Martín Villafruela 1.3. Entorno del proyecto Hasta antes de la anterior década, todo el avance sobre la computación cuántica era solamente a nivel teórico puesto que no había medios para para la creación de ordenadores cuánticos. Sin embargo, actualmente se están poniendo en funcionamiento los primeros ordenadores cuánticos, teniendo por fin la oportunidad de poner en práctica todos esas resultados anteriormente obtenidos. En España, ya hay un funcionamiento dos ordenadores cuánticos en Barcelona. Uno de ellos es parte de una red de ordenadores cuánticos formada por una red de ordenadores cuánticos situados por toda Europa, principalmente para finalidades de I+D [12]. También es importante considerar los factores económicos que envuelven a la computación cuántica. Pese a que ya haya empresas que han sacado a la venta ordenadores cuánticos para nivel comercial, su coste de fabricación sigue siendo muy elevado para su uso masificado en la población[11]. También es importante comentar los problemas de ser un paradigma de computación completamente diferente al actual. El cambio inmediato a una nueva tecnología nunca es inmediato, más aún en algo tan extendido y generalizado como los ordenadores y demás sistemas informáticos; además de que por comodidad para el usuario siempre se tiene tiene que garantizar cierta retrocompatibilidad del sistema moderno con el anterior. 1.3.2. Entorno específico: Xanadu Xanadu Quatum Tecnologies es una empresa de computación cuántica (tanto a nivel hardware como software). Por la parte hardware, Xanadu desarrolla photonic quatum computers accesibles a través de la nube, fomentando el desarrollo de software para ordenadores cuánticos de otras empresas tecnológicas. Este servicio permite una mayor divulgación y desarrollo de este nuevo paradigma que, pese a lo que se ha comentado, la fabricación de su hardware sigue siendo excesivamente costosa. A nivel software, es la empresa desarrolladora de la librería de PennyLane, no solo utilizada para la implementación de circuitos cuánticos (como es el caso de este proyecto) sino también para poder desarrollar sistemas de Inteligencia Artificial Cuántica (Quantum Machine Learning). Se darán más detalles sobre el uso específico de esta librería en este proyecto en la sección 6.1.3. Jorge Martín Villafruela 5 Capítulo 1. Descripción del proyecto 6Jorge Martín Villafruela Capítulo 2 Conceptos teóricos relevantes La computación cuántica es un nuevo paradigma de computación en pleno desarrollo actualmente, comenzado en estos últimos años. Sin embargo, este nuevo paradigma todavía sigue siendo demasiado desconocido, ya sea por puro desconocimiento, o por lo abrumado que puede ser adentrarse en un nuevo paradigma, sobre todo tan diferente y complejo como es la computación cuántica. Este proyecto quiere servir como punto de inicio para las programadores interesados en aprender sobre este paradigma, tomando como ejemplo y motivación el protocolo BB84, un sistema de generación de claves compartidas que utiliza herramientas básicas de la computación cuántica para resolver una de las mayores vulnerabilidades que tienen los métodos de cifrado actuales. El protocolo BB84 es un protocolo de generación de claves compartidas sobre un canal cuántico público. Para comprender lo que significa ello, hay que explicar primero lo que es la computación cuántica y para qué son necesarias las claves compartidas en la seguridad. 2.1. La computación cuántica La computación cuántica es un paradigma de computación alternativo al tradicional, basado en la modificación y transmisión de bits. En la computación cuántica, el papel de los bits lo cumplen los qubits. A diferencia de los bits, que solo pueden tomar los valores 0 y 1, los qubits pueden tomar cualquier valor de la forma ϕ=a|0⟩+b|1⟩, con a, b ∈C que cumplan a2+b2= 1. Dentro de todos los valores, destacan los valores asociados a 0 y1de la computación tradicional, |0⟩(a= 1 yb= 0) y |1⟩(a= 0 yb= 1), denominados los estados/valores estáticos. Son llamados así ya que, si el qubit es medido, su valor pasa a ser uno de ellos, siendo a2yb2las probabilidades en las que se mida en cada estado estático respectivo. Esto implica que, a no ser el qubit tenga un estado estático, es imposible predecir el valor que tendrá (pero sí intuir en base a los valores de ayb). El hecho de un qubit pueda tener infinitos estados, hace que a la hora de construir circuitos cuánticos haya infinita variedad en las puertas lógicas que existen, además de que, mientras que no se mida el valor, se trabajará en un espacio más grande (se utiliza 7 Capítulo 2. Conceptos teóricos relevantes Figura 2.5: Los valores cercanos a la media de los valores del caso con ruido (punto marrón), serán considerados ruido. El resto, se tratarán como posibles ataques de Eve. 14 Jorge Martín Villafruela Capítulo 3 Metodología Pese a no ser un producto software habitual, la metodología con la que se ha llevado a cabo el proyecto ha sido el Proceso Unificado. El hecho de que el producto no sea una aplicación software no implica que las técnicas de ingeniería aprendidas en la carrera no tengan utilidad en un proyecto de estas características. En esta sección también se comentarán las herramientas software utilizadas, tanto para la realización del proyecto como de la propia memoria, así como un esquema que la arquitectura de trabajo decidida para el proyecto, además de la justificación de la programación estructurada como paradigma de programación empleado. Por último, también se indicará ciertas siglas y expresiones utilizadas en el cuaderno. 3.1. Proceso de desarrollo Siguiendo como referencia las fases del ciclo de vida del Proceso Unificado, el desarrollo del proyecto se puede dividir en tres fases perfectamente diferenciadas (no se considera la fase de Transición): Fase I. Esta primera etapa consiste en el estudio personal sobre el tema que tratará en el proyecto: la computación cuántica y en concreto el funcionamiento del protocolo BB84. No hay mucho más que añadir a esta fase, ya que simplemente toma el papel de la formación del personal. También durante esta fase se comenzará a leer la documentación de la librería PennyLane. Fase II. Esta etapa consiste en la creación de una simulación software del protocolo BB84 (tanto con como sin ruido en el canal) en scripts de Python. El objetivo de esta etapa es que, a partir de los programas en Python creados en esta fase, la creación de los cuadernos Jupyter posteriores resulte más sencilla. Se podría considerar la fase de Elaboración del PU. Esta fase se puede subdividir a su vez en tres iteraciones, donde en cada una se trabajará en la implementación del protocolo en un entorno diferente: •En un canal seguro. 15 Capítulo 3. Metodología •En un canal con ruido. •En un canal vulnerable. Como se verá posteriormente en los apartados de planificación, en un principio iba a existir un cuarto cuaderno donde se analizaba más detenidamente el protocolo desde la situación de Eve. Por problemas de planificación, al final se decanto por no añadir dicho cuaderno, no afectando sustancialmente al los objetivos finales del proyecto. Fase III. Durante esta etapa se creará el producto propiamente dicho: se redactarán los diversos cuadernos que componen el estudio (la fase de implementación del PU). La mayor parte de trabajo a realizar en esta parte se encontrará, en el último cuaderno, donde haya que razonar y justificar (mediante herramientas estadísticas) las mejoras realizadas al protocolo. Como se verá próximamente, la duración de esta etapa acabará siendo más larga de lo esperada. Esto es debido a que también hubo que realizar actividades propias de la fase de Elaboración para la redacción de los cuadernos que no se habían considerado inicialmente. Durante el desarrollo en su conjunto se abogará por un modelo evolutivo, donde se evaluará el progreso en reuniones bisemanales con el tutor para cada versión. Puesto que es un proyecto de investigación, la evaluación de las iteraciones es sencilla y los requisitos del proyecto están más o menos claros, por lo que la parte de desarrollo (no solo en la parte de programación) y el análisis son la más importantes dentro del ciclo de versiones. En cuanto al paradigma de programación utilizado, se trabajará en programación estructurada. La ventaja de utilizar este paradigma de programación frente a uno más relacional como la programación orientada a objetos es debido a que el código deberá estar inscrito dentro de los cuadernos Jupyter, implicando tener que exponer los resultados intermedios de las funciones, que resulta más sencillo en este paradigma. El problema que conlleva el uso de este paradigma de programación es la falta de organización en comparación a otros. Sin embargo, gracias al hecho de que Python sea un lenguaje multiparadigma (como se comentará más adelante), hace que el cambio del código a uno u otro sistema (para, por ejemplo, su mejor utilización como módulo), sea relativamente sencilla. Por otra parte, también tiene coherencia con el hecho de cómo se usará la librería PennyLane, ya que en ella los circuitos cuánticos se simulan como funciones, haciendo que el uso de la librería sea más fluido y natural. Como se verá más adelante, esto no implica que no haya ninguna clase. La clase Person simulará cada una de las personas que entran en acción a la hora de simular el protocolo (Alice, Bob, y, posteriormente, Eve)Sin embargo, su papel es actuar como una estructura de datos, que sirve para saber qué información sabe cada persona en cada momento. Además, se implementará una clase para realizar el cifrado AES, utilizado en los cuadernos (ver sección 8). 16 Jorge Martín Villafruela 3.2. Herramientas de desarrollo utilizadas 3.2. Herramientas de desarrollo utilizadas En cuanto a las herramientas que se han utilizado durante el desarrollo caben destacar: Visual Studio Code. Visual Studio Code es el editor de código fuente que suelo utilizar por sus altos niveles de estilización y adaptación a prácticamente cualquier lenguaje que se vaya a utilizar, gracias a su funcionamiento a base de paquetes. Además, también tiene la posibilidad de vincularlo a un repositorio git, y suele ofrecer herramientas para debuggear y testear. L A T EX. L A TEX es un procesador de textos, que sirve para crear documentos con cierta complejidad tipográfica (en concreto,o está centrado en escribir fórmulas matemáticas, para lo que tiene el math mode ) a la vez de facilitar su estructuración. Aparte de su uso indispensable en la creación de la memoria del proyecto, también cabe mencionar MathJax, que como se comentó anteriormente, es una librería de javascript que implementa el modo matemático de L A TEX, y que Jupyter utiliza. Otra herramienta relacionada con L A TEX es Overleaf, que es el un editor en línea de éste que ofrece bastantes facilidades a la hora de la edición y organización del .tex que genera el documento, con la ventaja (o desventaja, depende de cómo se mire) de que sea una aplicación en línea y que no se trabaje en local. StarUML StarUML es un programa que permite la organización y realización de diagramas UML. Será la utilizada para crear los diagramas destinados al análisis del proyecto. En su mayoría serán diagramas de secuencia o de actividad, debido a que lo más importante del proyecto son los los propios algoritmos. Lucidchart Lucidchart es una aplicación web que permite el diseño de diagramas (y esquemas) de manera fácil y sencilla. A diferencia de StarUML, es menos técnica y avanzada, pero en cambio es más intuitivo. Dependiendo del objetivo del diagrama se utilizará una u otra aplicación. GitHub Para realizar el control de versiones del proyecto, pudiendo saber qué se ha añadido en cada versión y cuándo, se ha utilizado el repositorio web de GitHub. Al ser este proyecto un proyecto individual que además es un estudio teórico, no hace falta llevar un control exhaustivo de versiones ni el proyecto se compondrá de una gran cantidad de archivos, por lo que la actualizaciones (push) al repositorio se han podido realizar de manera “manual”, subiendo los archivos nuevos. Milanote Milanote es una herramienta de organización en línea muy general y sencilla. Básicamente sirve como una pizarra digital donde poder situar desde lista de tareas hasta esquemas de trabajo. Es muy versátil ayuda mucho a la organización de proyectos, en especial a aquellos desarrollados bajo una metodología ágil. OpenProj OpenProj es una herramienta gratuita de gestión que intenta simular a MS Project. Aunque tuviera un diseño bastante similar, su uso resulta muy tosco muy Jorge Martín Villafruela 17 Capítulo 3. Metodología poco pulido, siendo definitivamente MS Project superior en todos los sentidos. Sin embargo, pocas herramientas de gestión gratuitas hay disponibles actualmente, siendo OpenProj una de las mejores dentro de esa categoría (siempre y cuando se desee realiza algún diagrama de Gantt o gestión de recursos, sino cualquier aplicación tipo Excel es mucho más cómoda de utilizar). Microsoft Excel La herramienta para el manejo de hojas de cálculo por excelencia. Toda las tablas (y sus consecuentes operaciones) para por las estimaciones han sido realizadas con ella por la facilidad que ofrece para desplegar datos y operar con ellos. Lenguajes de programación. Se explicarán detenidamente en el capítulo 6. 3.3. Arquitectura Este proyecto no necesita de arquitectura física, ya que la única necesaria es la propia de los cuadernos Jupyter, explicada en la sección 6.2. En cuanto al patrón de arquitectura del proyecto, las propias funciones que conforman el cuaderno se encontrarán definidas en el mismo, puesto que se quiere que el usuario comprenda su construcción. Dicho esto, las funciones definidas en los cuadernos también se encuentran en unos scripts de Python separados, que tiene dos objetivos: Poder usar funciones definidas en un cuaderno o en otro sin tener que volverlas a definir. Poder utilizar las funciones de manera independiente de los cuadernos. Figura 3.1: Patrón de arquitectura 18 Jorge Martín Villafruela 3.4. Definición de siglas y abreviaturas 3.4. Definición de siglas y abreviaturas Además de varias siglas utilizadas a lo largo de la Memoria, aquí también se situarán varias expresiones o palabras que, a lo largo de la Memoria, se utilizarán bajo la jerga de la seguridad informática o de los propios cuadernos, teniendo por tanto que explicar su significado: PU. Proceso unificado. MitM. Man in the Middle. DoS. Denial of Service. NCT. Non-Cloning Theorem. Alice. Nombre con el que se suele denominar a aquel que juega el papel del emisor en los escenarios de distribución de claves. Bob. Nombre con el que se suele denominar a aquel que juega el papel del receptor en los escenarios de distribución de claves. Eve. Nombre con el que se suele denominar a aquel que juega el papel del atacante en los escenarios de distribución de claves. Clave. Bits generados por Alice a partir de los que se sacará la clave privada, y bits de Bob obtenidos a partir del circuito cuántico del protocolo BB84. Polarizaciones. Normalmente se referirá a polaridad/polarizaciones, no la polaridad en sí sino a la cadena de bits por la que Alice/Bob decidirán que polarización utilizar al qubit asociado transmitido. Clave Final. Bits de Alice y/o Bob de la cadena tras haber descartado los bits mal polarizados. Está compuesta por los Bits de integridad y la clave Privada. Bits de integridad. Se refiere a los bits que considerarán Alice y/o Bob para realizar el test de integridad del protocolo. clave Privada. Cadena utilizada en un cifrado que solo debe ser conocida por Alice o Bob. En este caso, es la cadena resultante de aplicar el protocolo BB84, y la de Alice y Bob coincide (es simétrica). Puertas Dentro de las siglas utilizadas durante el cuaderno, cabe destacar la simbología utilizada para referirse a las distintas puestas lógicas cuánticas. H. Puerta Hadamard X,Y,Z. Puertas de Pauli Jorge Martín Villafruela 19 Capítulo 3. Metodología RX(φ),RY(φ),RZ(φ). Puerta rotacional sobre el eje X, Y o Z respectivamente con ángulo φ CP. Puerta controladora sobre la puerta P. 20 Jorge Martín Villafruela Capítulo 4 Planificación En este capítulo se abordarán las cuestiones relativas a la planificación del trabajo, como son el diagrama de Gantt y la creación de los presupuestos, que se comparará con el obtenido. Para ello, se comenzará realizando una estimación temporal del tiempo que consumirán las tareas que componen el proyecto. Si bien es cierto que la mayor parte de las técnicas estudiadas, tales como el método COCOMO II, o los puntos de función son demasiado específicas para una aplicación software como para poder ser eficaces en este caso, técnicas y metodologías más generales como los diagramas de Gantt o el método PERT de estimación resultan sorprendentemente aplicables en este proyecto. Por otra parte, debido a diversas causas que se comentarán más adelante, la estimación realizada del proyecto no ha sido muy acertada, y ha sufrido un severo retraso respecto al plan original, viéndose reflejado en el sobrecoste del presupuesto final, así como en el hecho de tener que descartar cierta parte del proyecto. 4.1. Estimación del esfuerzo La estimación del esfuerzo a partir de los métodos tradicionales, tales como la estimación puntos de Caso de Uso o puntos de función, no tiene sentido para este proyecto, puesto que se basa en las funcionalidad para el usuario y este es un estudio teórico y no una aplicación software. Por tanto, pese haber considerado un proceso de desarrollo, a la hora de las estimaciones de esfuerzo se tendrán que considerar métodos alternativos. Por ello, se va a considerar la estimación PERT (la estimación por tres valores). Para cada tarea que se realizará en el proyecto, se considerarán la duración más optimista, la duración más probable y la duración más pesimista para completarla. De esta manera se puede tratar la duración de la tarea como la variable con distribución βque pasa por eso tres puntos, obteniendo: Tesperado =TOpt + 4 TProb +TP es 6 La estimación obtenida en la tabla A.1 da que el proyecto se terminará en unos 116 días de trabajo (de 4 horas). Es decir, sin considerar días festivos, 5 meses y medio. Si 21 Capítulo 4. Planificación se considera el peor de los casos, tomando la predicción más pesimista siempre, el proyecto terminaría en 171 días de trabajo, lo que equivale a poco más de 8 meses. Como también se muestra en la tabla, el tiempo que se he tardó finalmente en realizar el proyecto fue de 150 días de trabajo (7 meses y una semana aproximadamente). Las mayores diferencias de tiempo han sido mayoritariamente por 3 razones: La implementación de la clase Persona y modelización de los canales no cuánticos, ya que surgieron ciertas dificultades al no haber entendido partes de la documentación correctamente. El retraso mencionado anteriormente además produjo que se decidiese descartar la sección sobre la perspectiva del Eavesdropper. Anaconda comenzó a dar problemas, por lo que se optó por cambiar y utilizar Python de manera independiente de Anaconda. El tiempo que figura en la tabla es el que se tardó en desinstalar Anaconda completamente más la instalación de Python y todas las librerías que se han utilizado (incluidas Jupyter yPennyLane, por ejemplo). Sin embargo, pese a estas dificultades que hicieron que el proyecto durase más de lo estimado, el tiempo obtenido sigue siendo menor que la estimación más pesimista, estando lo obtenido dentro del margen estipulado. 4.2. Planificación temporal En la planificación de tareas del proyecto se mostrará el diagrama de Gantt diseñado al inicio del proyecto, y el obtenido al finalizar el proyecto. Aunque se haya realizado la estimación por el método de tres valores de PERT, no se mostrará el diagrama temporal de PERT, pues carece de importancia al haber sido un trabajo individual. Además, en cambio sí que se realizarán un diagrama de Gantt mucho más ilustrativo y completo (sobre todo teniendo en cuenta que ha sido un proyecto individual y que por tanto es imposible que se trabaje en varias tareas paralelamente). 4.2.1. Roles en el proyecto Recordemos que el proyecto se dividía en tres fases: fase de aprendizaje, fase de elaboración y fase de redacción. La fase de aprendizaje, dedicada al estudio teórico necesario para la realización del proyecto, no se tiene en cuenta en la estimación temporal pese a que siempre es importante tenerla en cuenta, al ser formación necesaria para el proyecto. Esto es debido a que fue realizada anteriormente a estas estimaciones . Pese a que el proyecto a sido realizado por solo una persona, también es de utilidad catalogar qué tareas realizará cada rol (cuando una tarea sea necesaria de varios roles, se considerará que el tiempo se reparte equitativamente por simplificación). Los roles que se considerarán son: 22 Jorge Martín Villafruela 4.2. Planificación temporal Jefe de Proyecto. Rol de la persona encargada de la documentación y organización del proyecto. Programador. Rol de la persona encargada de la creación de los programas necesarios para el estudio. Investigador. Rol de la persona con conocimientos sobre computación cuántica y matemáticas. Es quien redactará los cuadernos. En este caso, los tres roles han sido ejercidos por la misma persona, aunque en un principio no tiene por qué (dicho esto, es bastante recomendable que el rol de Programador y de Investigador lo haga la misma persona, debido a la gran comunicación y entendimiento que debe de haber entre ambas partes). Estos datos servirán principalmente para estimar y calcular los recursos humanos utilizados en el proyecto. En las tablas A.2 y A.3 se vislumbra más claramente cómo han afectado al desarrollo los problemas comentados anteriormente. Haciendo la distinción entre los diferentes roles, se ve que el mayor aumento de horas ha surgido en tareas de programación. También es relevante observar la excesiva escasez de horas empleadas para tareas de “Jefe de proyecto”. El tiempo dedicado a tareas de este rol ha sido insuficiente, teniendo como consecuencia que los percances ocurrido hayan necesitado de tanto tiempo para salvaguardarse (por ejemplo, un retraso de una semana y media de trabajo en terminar la implementación de la clase Person). 4.2.2. Diagrama de Gantt Puesto que el proyecto ha sido realizado por una sola persona, el diagrama de Gantt del proyecto no ofrece mucha información adicional, al no necesitar de una optimización de la ruta crítica del proyecto (no se pueden realizar tareas de forma paralela ni reasignaciones a recursos con el mismo rol). Así, pues, a partir de los tiempos de las tablas A.2 y A.3 se consiguen los siguientes diagramas de Gantt Como se puede observar, varias tareas o se han sustituido por otras o han desaparecido. Eso ha sido producto de cambios intermedios que ha habido, admitiendo que varios de los cuales han sido por un mal planteamiento de los requisitos iniciales. Además, también se puede ver que la implementación de Eve de manera más detallada se desechó, debido a la cierta complejidad que supondría (se detallará más detenidamente en el apartado de implementación), además de ir más relajado a los plazos de entrega. Otra desviación interesante al plan original es el hecho de que finalmente se optó por comenzar la redacción de los cuadernos antes de terminar la simulación de los circuitos. Esto no supone ningún problema, puesto que los cuadernos que necesitaban de esa implementación fueron redactados posteriormente. Jorge Martín Villafruela 23 Capítulo 5. Conclusiones 30 Jorge Martín Villafruela Parte II Documentación técnica Capítulo 6 Lenguajes de programación 6.1. Librerías de Python Python es un lenguaje multiparadigma basado en la implementación por librerías. como su nombre indica, el ser un lenguaje multiparadigma significa que puede utilizarse en varios paradigmas de programación. En el caso específico de Python, éstos son esencialmente la programación estructurada y la orientada a objetos. Para que pueda utilizarse en este último, a nivel interno en Python todo es un objeto incluso las propias clases y las funciones (lo que permite indistintamente programar bajo un paradigma u otro). Como se dijo anteriormente, el principal motivo por el que se eligió Python como lenguaje de programación es por el hecho de utilizar la librería PennyLane para computación cuántica. Además de PennyLane, de la que se hablará detenidamente a continuación, otras librerías utilizadas han sido Cryptodome (para la importación de algoritmos de cifrado) y matplot (para la creación de histogramas y gráficos). 6.1.1. Crytodome Crytodome es una librería de Python que contiene los principales algoritmos de cifrado (y descifrado) utilizados. En el estudio, se quiere poner en práctica la implementación del protocolo BB84 a la hora de generar una clave privada. Como el protocolo de cifrado AES utiliza una clave privada simétrica (que no es lo mismo a que sea un cifrado simétrico). En concreto, el módulo Cipher permite crear un objeto en el que se transmiten varios elementos, para crear la “interfaz de cifrado” en caso del protocolo AES: cipher = new(key, AES.MODE_CBC, iv) donde key es la clave de cifrado y iv es el vector inicial que utilizan en el algoritmo del protocolo. Esta interfaz contiene las funciones encrypt ydecrypt para cifrar y descifrar respectivamente. Puesto que su uso “en bruto” puede resultar pesado, se realizó el script AES.py para realizar su uso en los cuadernos: Listing 6.1: AES.py import base64 33 Capítulo 6. Lenguajes de programación import ha shlib # pycryptodome es un paquete que incorpo from Cryptodome import Random from Cryptodome . Cipher import AES c l a s s AESCipher ( o bj ect ) : def __init__( s e l f , key ) : s e l f . bs = AES. block_size s e l f . key = hashl ib . sha256 ( key . encode ( ) ) . di g e st () def encrypt ( s e l f , raw ) : raw = s e l f . _pad( raw ) iv = Random. new ( ) . read (AES. block_size ) cipher = AES. new( s e l f . key , AES.MODE_CBC, iv ) return base64 . b64encode ( iv + cipher . encrypt ( raw . encode ( ) ) ) def decrypt ( s e l f , enc ) : enc = base64 . b64decode ( enc ) iv = enc [ : AES. block_size ] cipher = AES. new( s e l f . key , AES.MODE_CBC, iv ) return s e l f . _unpad( cipher . decrypt ( enc [AES. block_size : ] ) ) . decode ( ’ utf −8 ’ ) def _pad( s e l f , s ) : return s + ( s e l f . bs −len ( s ) % s e l f . bs ) ∗chr ( s e l f . bs −len ( s ) % s e l f . bs ) @staticmethod def _unpad( s ) : return s [: −ord ( s [ len ( s ) −1:])] 6.1.2. Matplotlib Como su nombre indica, la librería de Matplotlib sirve para mostrar gráficos y animaciones. En el caso específico de este proyecto, será utilizado para mostrar histogramas de las muestras obtenidas. La aparte de esa librería donde se encuentran las funciones para la visualización de gráficas es pyplot. En concreto, la función utilizada para eso es matplotlib.pyplot.hist(x, bins=None, range=None, histtype=’bar’, ..., **kwargs) (puede recibir más parámetros, pero solo se comentarán los más importantes). x. Datos de los que realizar el histograma bins. Puede ser un entero, o una array •Si es un entero, indica el número de columnas equiespaciadas que tendrá el histograma. •Si es un array indica en qué valores se hacen las divisiones para realizar las columnas. 34 Jorge Martín Villafruela 6.1. Librerías de Python range. Dupla de valores (a,b) que indica el mínimo y el máximo considerados para crear el histograma. No tiene efecto en el caso en el que bins sea un array. histtype. Tipo de histograma, puede ser •’bar’ Histograma de barras •’barstacked’ Escalonado •’step’ De línea •’stepfilled’ De línea color. Color del histograma Además, hist devuelve una estructura de datos formada por dos array, que indican los datos obtenidos en cada división, y las divisiones consideradas (el array bins), respectivamente. Esta librería también se utiliza en la elaboración del mapeo utilizado, a partir del cual se realizará el proceso de clustering para dictar si un caso es ruido o de canal vulnerado. En concreto, la función scatter(x,y) dibuja en el gráfico los puntos (x, y) (x,ypueden ser arrays de valores para dibujar varios puntos a la vez), y la función axline([x1,y1],[x2,xy], ...) dibuja la recta que pasa por los puntos (x1, y1) y(x1, y2). 6.1.3. PennyLane PennyLane[3] es la librería que se utilizará para simular los circuitos cuánticos del protocolo BB84 y derivados, siendo parte del cometido del estudio el mostrar la usabilidad básica de esta librería. Dispositivos y circuitos En PennyLane, los circuitos cuánticos son definidos como unas funciones especiales, marcadas a través del decorador qnode. A este decorador ha que pasarle un objeto de la clase device, que indica en qué “dispostivo” se va a correr el circuito (tipo del circuito, cuántos cables va a tener, qué se va a enviar, etc). Por ejemplo, esta sería la definición de un circuito compuesto únicamente por una puerta Hadamard (y en el que el estado inicial del qubit es |0⟩). Listing 6.2: Ejemplo de uso de la librería PennyLane import pennylane as qml from pennylane import numpy as np # Se d ef in e e l ’ d is p os t iv o ’ donde se t ra baja . dev = qml . de vice ( ’ de fa ul t . qubit ’ , wires =1) # Decorador para i n d ic a r que l a s i g u i e n t e funcion # va a s er un c i r c u i t o cuantico sobre e l d i s p o s i t i v o ’ dev ’ . Jorge Martín Villafruela 35 Capítulo 6. Lenguajes de programación @qml . qnode ( dev ) def HadamardGate ( ) : qml . Hadamard (0) # s t at e ( ) devuelve l a s componenetes en la base canonica # del estado f i n a l del c i r c u i t o . En el caso de un s ol o qubit , # son l o s v al o re s de a y b d el estado f i n a l del qubit . return qml . stat e ( ) A lo largo de los distintos cuadernos, se utilizarán dos tipos distintos de dispositivos: ’default.qubit’ y’default.mixed’. La principal diferencia entre ambos que el ’default.mixed’ soporta las funciones que se utilizarán para implementar el ruido, BitFlip() yDepoalirizingQubit(). A cambio, ’default.mixed’ pierde la posibilidad de acceder a información sobre el gradiente el qubit, utilizado en quantum machine learning (pero no importante para el tema tratado en este proyecto). Puertas lógicas PennyLane tiene implementadas además las puertas más comúnmente utilizadas, como las puertas de Pauli (PauliX()) o la de Hadamard (Hadamard()). Además, si sabes la descomposición en rotaciones de la puerta a aplicar, puedes aplicar cualquier puerta gracias a la función Rot(). Todas estas funciones, comparten los mismos parámetros: Los propios argumentos de la puerta (por ejemplo, para la función texttRX), se requiere el ángulo de rotación sobre el eje x. wires. Cable del circuito donde se encuentra situada la puerta. doQeue. Si la puerta quiere aplicarse directamente puede ser True oFalse id. Identificador que se quiera colocar a la puerta. Un caso curioso es el de las puertas controladoras (controlled), en el se pasa como parámetro la función de la puerta a aplicar el controlador. Esto hace que a los propios argumentos de la función haya que enviarles argumentos: Listing 6.3: Ejemplo puerta controladora import pennylane as qml from pennylane import numpy as np dev = qml . de vice ( ’ de fa ul t . qubit ’ , wires =1) @qml . qnode ( dev ) def CNOTGate ( ) : qml . c t r l ( qml . PauliX (1 ) , (0 ) ) return qml . stat e ( ) 36 Jorge Martín Villafruela 6.1. Librerías de Python Respuesta del circuito En los ejemplos mostrados hasta ahora, las funciones de simulación del circuito siempre devuelven state(), que devuelve las componentes (en la base canónica) del estado final del qubit. Otros métodos utilizados en el cuaderno para estructurar la respuesta de las funciones circuitos son probs() ysample(). Como su nombre sugiere, probs() devuelve la probabilidad del resultado al medir el qubit final sea el valor estático asociado (es decir, el cuadrado del módulo de state(). Se puede restringir y solo considerar parte de los cables del circuito mediante el parámetro wires. Por otra parte, el método sample() devuelve la medición de los estados finales (en la polarización pasada por op). Para poder aplicar este método, es necesario que el dispositivo del circuito donde se utiliza tenga el argumento shots, que indica el número de muestras del circuito que se devuelven 1. 6.1.4. Numpy Numpy[8] es la librería de Python por excelencia para trabajar sobre “estructuras matemáticas” complejas, sobre todo para el manejos de arrays numéricos (tiene su propia implementación de array) así como funciones para resolución de matrices, algoritmos de estimación, etcétera. En nuestro caso, no se utiliza directamente esta librería, sino la modificación creada y utilizada en PennyLane. Esta versión ha sido alterada para que sea más cómodo operar con las puertas lógicas y estados cuánticos. Además de utilizarla de manera indirecta a través de PennyLane, también es utilizada en los cuadernos en varias ocasiones de manera directa, desde la generación de números aleatorios (con las funciones de su módulo random), hasta herramientas estadísticas como percentile(v,p), que devuelve el/los percentiles del vector de muestras vo_r() (que permite construir arrays como se haría en R). 6.1.5. TensorFlow TensorFlow es una librería destinada a la construcción de redes neuronales y del aprendizaje automático en general (recordemos que Pennylane es una librería específica para quantum machine learning). Para nuestro proyecto solo es interesante la estructura de datos que utiliza esta librería: los tensores. De manera puntual se ha necesitado la función squeeze(t), que elimina las dimensiones del tensor tde tamaño 1 (es decir, si tes un tensor con array de dimensión [3,1,2]), te devuelve un tensor cuyo array de valores es el mismo que el de t, pero su array de dimensiones es [3,2] (para la preparación de datos a la hora de la creación del histograma). 1Del mismo modo probs() ystate() necesitan de que el dispositivo NO tenga el argumento shots. Jorge Martín Villafruela 37 Capítulo 6. Lenguajes de programación 6.2. Jupyter Notebook Los cuadernos Jupyter (Jupyter Notebook)[13] se definen como una “plataforma de computación interactiva”. Eso significa que es una interfaz web (es decir, que se puede visualizar el archivo creado en formato de página web desde un navegador web), en el que se puede mezclar texto, multimedia y código ejecutable, como si de un “cuaderno de código” se tratase (de ahí el nombre). Los cuadernos están divididos en celdas, que pueden ser de código ejecutable o no (Markdown). El formato que ofrecen los cuadernos Jupyter es perfecto para la creación de informes, estudios u cualquier tipo de documento en el que se haya tenido que programar, puesto que, a diferencia de en un documento tradicional, en un cuaderno Jupyter se puede integrar el código en el documento y ejecutarlo personalmente. 6.2.1. Arquitectura y funcionamiento Los cuadernos Jupyter son una interfaz de visualización de tanto archivos multimedia como de código ejecutado. Esa visualización se hace a través de un navegador web. El lugar donde se ejecutan las celdas que componen los cuadernos (tanto las de “código” como las de Markdown) es el kernel, que compila el código de la celda en el lenguaje indicado (siendo Markdown uno de estos posibles lenguajes). El propio archivo .ipynb (que es un archivo en formato JSON que genera el cuaderno 2), el navegador y el kernel se encuentran conectados entre sí por el servidor Jupyter, de manera de que cada uno funciona de manera independiente del resto: el kernel lo único que hace es ejecutar los comandos transmitidos desde el servidor a partir las celdas contenidas en el archivo .ipynb como si fuesen entradas por la consola de comandos, y el navegador web lo único que hace es mostrar en el navegador la compilación del archivo .ipynb (como JSON) por el servidor enviada, a través de WebSockets. 2Para poder observar un cuaderno Jupyter como JSON, basta con abrirlo como texto plano con cualquier editor de texto (por ejemplo, Notepad), dando como resultado lo mostrado en la figura 6.1. 38 Jorge Martín Villafruela 6.2. Jupyter Notebook Figura 6.1: Visualización de un cuaderno Jupyter como archivo JSON. La comunicación entre el kernel y el servidor de Jupyter se basa en la transmisión de las celdas con y sin compilar por el kernel, y se hace mediante MQ (llamado también ZeroMQ), un middleware de comunicaciones orientado a mensajes[1]. Jorge Martín Villafruela 39 Capítulo 7. Análisis Nombre del Requisito RF-21 Explicación de la implementación del circuito. Descripción El lector debe comprender cómo y por qué se ha simulado el protocolo en PennyLane de la manera realizada. Prioridad Alta Otra info Nombre del Requisito RF-22 Consideraciones de implementación. Descripción Se debe explicar las consideraciones esenciales que se han tenido a la hora de implementar el protocolo, para cada una de sus partes. Prioridad Media Otra info Nombre del Requisito RF-23 Mostrar implementación del circuito del protocolo BB84. Descripción El usuario debe poder visualizar la implementación en Python del circuito del protocolo BB84. Prioridad Media Otra info Nombre del Requisito RF-24 Mostrar ejemplo de ejecución . Descripción Se debe mostrar al lector el funcionamiento de la simulación del protocolo BB84, mediante un ejemplo de ejecución. Prioridad Alta Otra info Implementación del protocolo en un canal con ruido /con Eve. En este cuaderno se harán modificaciones a la implementación anterior del protocolo para simular que se aplica tanto para un canal con ruido como para un canal espiado. Además, se estudiará como modificar el protocolo para que sea más eficaz en diferenciar ambos casos. 46 Jorge Martín Villafruela 7.1. Requisitos Nombre del Requisito RF-31 Implementación del protocolo con ruido. Descripción El lector debe ver el código de la implementación del protocolo en un canal con ruido, así como la justificación de su correcto funcionamiento. Prioridad Alta Otra info Se trabajará considerando que el ruido máximo que admite el canal es del 15 %. Nombre del Requisito RF-32 Implementación del protocolo con Eve. Descripción El lector debe ver el código de la implementación del protocolo en un canal vulnerado, así como la justificación de su correcto funcionamiento. Prioridad Alta Otra info Nombre del Requisito RF-33 Visualización de estadísticas de fallo. Descripción Se debe mostrar al lector estadísticas de fallo en el caso con Ruido y con Eve. Prioridad Alta Otra info Esto puede realizarse a través de la creación de un histograma. Conviene además comparar ambos histogramas. Nombre del Requisito RF-34a Razonamiento de mejora del protocolo. Descripción Se debe explicar cómo mejorar el protocolo para que funcione en un canal con ruido. Prioridad Alta Otra info Esto puede realizarse a través de la creación de un histograma. Conviene además comparar ambos histogramas. Nombre del Requisito RF-34b Implementación de mejora del protocolo. Jorge Martín Villafruela 47 Capítulo 7. Análisis Descripción El lector debe ver el código de la implementación mejorada, así como la justificación de su correcto funcionamiento. Prioridad Media Otra info Nombre del Requisito RF-35 Conclusión final. Descripción El documento debe contener una conclusión final en la que se suma todo lo comentado en los cuadernos y que se comenten las implicaciones de lo estudiado. Prioridad Alta Otra info Además, también existen otros requisitos funcionales de hábito más general, que se deberán de tener en cuenta en el desarrollo de todos los cuadernos: Nombre del Requisito RF-40 Comprobación de la implementación . Descripción Se debe demostrar al lector que los circuitos propios creados son correctos. Prioridad Alta Otra info Nombre del Requisito RF-41 Rigor biblográfico. Descripción En cada cuaderno debe aparecer las fuentes bibliográficas utilizadas, además de estar citadas en formato APA, añadiendo enlace a la cita dentro del texto cuando sea necesario. Prioridad Media Otra info Nombre del Requisito RF-42 Tabla de contenidos. 48 Jorge Martín Villafruela 7.1. Requisitos Descripción En cada cuaderno deben aparecer un esquema que indique los contenidos que se van a tratar en el mismo. Prioridad Baja Otra info Enlazar dicha entrada de la entrada con el contenido en sí daría más completitud y cohesión al documento. 7.1.2. Requisitos no funcionales Además de los requisitos funcionales (que en este caso son prácticamente a los contenidos que se deben elaborar en el cuaderno) también hay que tener en cuenta ciertos requisitos no funcionales. Como material didáctico y de investigación, debe de estar lo suficientemente bien redactado y estructurado. El texto debe tener una buena redacción y cohesión. En cada cuaderno deben aparecer las fuentes bibliográficas utilizadas, además de estar citadas en formato APA. Links entre los cuadernos. Nombre del Requisito RNF-01. Buena redacción Descripción El texto que conforma el estudio debe estar bien redactado y cohesionado Prioridad Alta Otra info Hay que hacer especial hincapié en una buena ortografía y que sea comprensible para cualquier lector. Nombre del Requisito RNF-03 Datos de salida limpios. Descripción Las respuestas que devuelven cada una de las celdas de los cuadernos Jupyter deberá de ser en una estructura de datos legible, y comprensible para el usuario (no simplemente una cifra/array, por ejemplo) Prioridad Baja Otra info En casos excepcionales comola generación de arrays para estadísticas se considerará obviar este requisito. Jorge Martín Villafruela 49 Capítulo 7. Análisis 7.1.3. Atributos de calidad Los atributos de calidad técnicos de los cuadernos como aplicación software (como la robustez) vienen dados por la arquitectura y el funcionamiento de Jupyter como software, por lo que no incumben en la elaboración del proyecto. Sin embargo, esto da lugar a que otros atributos de calidad cobren mayor importancia, a saber: Portabilidad: Los cuadernos deben ser capaces de ser utilizados en cualquier sistema operativo y navegador (esto es inherente al funcionamiento de los cuadernos Jupyter). Fiabilidad: La variables de entorno usadas en los cuadernos y/o archivos .py asociados tendrán que ser limpiadas correctamente de manera de que siempre aparezca en los cuadernos un resultado verídico. En concreto, con las celdas donde el resultado obtenido depende del azar. Usabilidad: El código de los cuadernos debe estar debidamente comentado para su buena comprensión. Además, tendrá que resultar sencilla pasar de un cuaderno a otro cunado se requiera (en relación con el requisito...). Robustez: tiene que ver con el comportamiento, la fiabilidad y la estabilidad de la aplicación ante posibles incidencias en tiempo real. 7.2. Diseño En esta sección se hablará por una parte sobre la estructuración de los cuadernos que componen el estudio, así como las relaciones de los scripts de Python en los que se encuentran alojadas las funciones utilizadas en ellos. 7.2.1. Cuadernos Jupyter Como se ha comentado en la sección de Planificación, el estudio se compone de cuatro cuadernos: Introduccion.ipynb: En este cuaderno se presentan las nociones básicas de computación cuántica. Entre los contenidos del cuaderno, se encuentran: El concepto de qubit La esfera de Bloch. Puertas lógicas uni-qubit Puertas Controlled 50 Jorge Martín Villafruela 7.2. Diseño Este cuaderno contiene una gran carga teórica, así que a penas habrá celdas de código. No obstante, se ilustrará la presentación de las puertas lógicas comentadas con sencillos circuitos utilizando la librería PennyLane, en concreto con las funciones que que implementan dichas puertas y el método state(), para devolver las componentes en la base canónicas del qubit al final del circuito. TeoriaBB84.ipynb: En ese cuaderno se explicará cómo funciona el protocolo BB84 a nivel teórico. Esto implica tener que hablar de los resultados teóricos que utiliza el protocolo, presentar su escenario de aplicación, además explicar el protocolo en sí y su funcionamiento. Igual que el anterior, a penas habrá celdas de código, puesto que el resto de cuadernos se dedican a la implementación de lo comentado en este. Su contenido es similar a lo comentado en la sección 2.3. ImplementacionBB84Basico.ipynb En este cuaderno se dan dos posibles implementaciones del circuito cuántico que utiliza el protocolo BB84. En una de las implementaciones se considera tratar en el circuito con la cadena de bits para generar la clave directamente (el caso perteneciente al script BB84Alternativo.py). Mientras, la otra implementación se decanta porque en el circuito se traten los bits -qubitsde manera individual(BB84Basic.py). Para el siguiente cuaderno, se decantará por continuar por la segunda implementación al ser más sencilla y cómoda. ImplementacionBB84Complejo.ipynb: En el último cuaderno del estudio, se intenta expandir la implementación del circuito comentada en el cuaderno anterior al caso donde hay ruido en el canal, o un atacante en él (lo relacionado con BB84Ruido.py y BB84Eve.py, respectivamente). A partir de ello, se estudia qué posibles herramientas tienen Alice y Bob para diferenciar entre el caso benigno (que haya ruido) y el peligroso (que haya una tercera persona que escuche el canal), para lo cual se realiza un muestreo se hace uso de las librerías Matplotlib yNumpy para calcular las estadísticas de casa caso. Los resultados se darán partiendo de la suposición de que se considera que la saturación del canal se da para un ruido del 15 % (es decir, que el máximo ruido tolerable para la funcionalidad del canal es para p= 0,15). Por último, esta parte da lugar a buscar una variación del protocolo BB84 mejorado, donde se pueda diferenciar entre ambos casos (contenido del script BB84Extra.py). Este cuaderno es el más largo y extenso del conjunto 7.2.2. Scripts de Python Además de los cuadernos que componen el proyecto, el trabajo también contiene una serie de scripts de pyhton que se utilizarán en los cuadernos y/o par preservar las funciones mostradas y explicadas en los mismos. Estos archivos se pueden dividir en tres subgrupos: Útiles En estos scripts Se encuentran las funciones y clases necesarias para la implementaciones de los circuitos cuánticos en sí. Esta formado por dos archivos: Jorge Martín Villafruela 51 Capítulo 7. Análisis Person.py Este script se contiene la implementación de la clase Person, encargada de simular a Alice y a Bob. OperacionesBB84.py. Contiene las funciones que realizan las acciones del protocolo BB84 que no utilizan el circuito cuántico, como el cribado de bits o la realización del test de integridad. En el diagrama de actividad de figura 7.1 se muestra todo lo que es necesario realizar por el protocolo BB84, además de transmitir por el circuito asociado. Dentro de los algoritmos a implementar en este script a nivel de diseño destaca el cribado de bits a partir de las polarizaciones Figura 7.2: Diagrama del proceso de cribado de bits de los bits transmitidos Implementaciones del circuito . En estos scripts se realizan las implementaciones de los circuitos cuánticos para cada uno de los casos a analizar. Para ello, hace uso de la librería PennyLane; y son la parte principal del proyecto. Además de métodos privados que necesitan específicamente cada variante, estos cuadernos contienen la implementación del circuito cuántico, así como funciones que realizan la ejecución entera del protocolo (tanto llegando solo a haber realizado el test de integridad, 52 Jorge Martín Villafruela 7.2. Diseño como hasta haber generado la clave privada1). BB84Basic.py Contiene la implementación del circuito del protocolo BB84 sin ruido y/o atacante. Además, también se encuentran funciones que realizan la ejecución entera del protocolo (tanto llegando solo a haber realizado el test de integridad, como hasta haber generado la clave privada). BB84Alternativo.py Contiene la implementación del circuito del protocolo BB84 sin ruido y/o atacante, realizando la implementación del circuito cuántico para transmitir la cadenas de bits directamente en vez de uno en uno. Además, también se encuentran funciones que realizan la ejecución entera del protocolo. BB84Ruido.py. Contiene la implementación del circuito para el caso en el que el canal tenga cierto porcentaje de ruido de cambio de polarización y/o de bit. Al igual que para el caso básico, también contiene funciones que realizan la ejecución BB84Eve.py Contiene la implementación del circuito para el caso en el que el canal esté siendo espiado (y, por tanto, medido) por un atacante Eve. Al igual que para el caso básico, también contiene funciones que realizan la ejecución entera del protocolo (tanto llegando solo a haber realizado el test de integridad, como hasta haber generado la clave privada). BB84Extra.py. Contiene una función que implementa el circuito BB84 de manera generalizada, que aplicará uno u otro de los circuitos cuánticos implementados en los archivos anteriormente mencionados dependiendo de los parámetros transmitidos, AES . Además, de manera independiente, también se encuentra el script AES.py, donde está implementada una clase con el mismo nombre que, importando métodos de las librerías Cryptodome,hashlib ybase64, una clase cuyo cometido es simplificar el proceso de cifrado y descifrado AES, utilizado en los cuaderno como ejemplo de uso del protocolo BB84. 1la ejecución del protocolo intermedia (la que llega hasta después del test de integridad) es necesaria, puesto que es la que en los cuadernos es utilizada para obtener estadísticas, además de ser la parte que se reutiliza al final para la implementación mejorada sugerida. Jorge Martín Villafruela 53 Capítulo 7. Análisis UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED UNREGISTERED Alice Bob Recibe polarizaciones recibePolarizaciones Envía polarizaciones Envía polarizaciones Obtener la clave Privada Obtener bits de integridad Obtener bits de integridad Obtener la clave Privada Comprobar polarizaciones Enviar Bits de integridadRecibir Bits de Integridad de Bob Comparar bits de integridad Recibir bits de integridad de Alice Enviar bits de integridad Comparar bits de integridad Se acepta la clave privada coinciden difieren Se acepta la clave privadaSe rechaza la clave privada coinciden difieren Esperar respuesta Enviar veredicto Recibir veredictoEsperar respesta Comparar veredictos Ambos respuesta positiva Una respuesta negativa Recibir decisón Notificar decisión BB84 Generación de polarizaciones y claves Realizar cibrado Bits suficientes Realizar cibrado Notificar Bob Bits insuficientes Notificar Alice Bits suficientes Bits insuficientes Comprobar polarizaciones Se rechaza la clave privada Posible intruso Protocolo ejecutado correctamente Figura 7.1: Diagrama de actividad del algoritmo BB84 54 Jorge Martín Villafruela 7.2. Diseño Figura 7.3: Diagrama de paquetes del proyecto Jorge Martín Villafruela 55 Capítulo 8. Implementación return msgFinal except : pr in t ( "ERROR␣EN␣EL␣CIFRADO" ) return False 8.3. BB84Basic.py El primer cuaderno sobre la implementación del protocolo es ImplementacionBB84Basico.ipynb. Como se comentó anteriormente, en este cuaderno se estudia cómo implementar en Python el protocolo BB84. En este archivo, se encontrará una implementación del circuito en la que cada bit de la cadena clave se transmite individualmente. En el script BB84Alt.py se encontrará una implementación del circuito alternativa en la que se transmite la cadena ‘clave‘ por el circuito entera de manera conjunta. En este archivo se encuentra lo relacionado con la primera implementación, mientras que en la siguiente sección se comentará la implementación alternativa. Para los escenarios más avanzados comentados en el último cuaderno del proyecto, se descartará la implementación alternativa y solo se implementará de esta forma, para que su longitud no sea muy elevada. La implementación del circuito en este script se basa en implementar el circuito en PennyLane, utilizando los condicionales para simular las controlled del circuito: CA• PB• PA• |0⟩X H H CB =⇒ Si CA= 1 Si PA= 1 Si PB= 1 |0⟩X H H CB Con esta implementación, los qubits se transmiten por el circuito cuántico individualmente. Esto implica que haya que repetir el circuito 16 ×4 = 64 veces (16 ×2para conseguir la clave compartida, 16 ×2para conseguir suficentes bits para realizar el test de integridad). Sin embargo, a cambio de ello, la implementación del circuito es mucho más simple, puesto que nos podemos apoyar en condicionales para simular la aplicación o no de las puertas en vez de fabricar funciones por parámetros. Además, eso hace que esta implementación sea más natural al circuito cuántico real, siendo más comprensible su funcionamiento: 62 Jorge Martín Villafruela 8.3. BB84Basic.py Listing 8.9: circuitBB84() dev = qml . de vice ( ’ de fa ul t . qubit ’ , wires =1, shots =1) @qml . qnode ( dev ) def circuitBB84 ( b i t : int , AliceP : int , BobP: i n t ) : #Parte de Alice i f ( bi t ) : qml . PauliX (0) i f ( AliceP ) : qml . Hadamard (0) #Parte de Bob i f (BobP ) : qml . Hadamard (0) return qml . sample (None , [ 0 ] ) Añadiendo las funciones creadas en OperacionesBB84.py para implementar el protocolo hasta el test de integridad, se obtiene una función para realizar el protocolo BB84 hasta comprobar que se cumple el test de integridad: Listing 8.10: BB84Test() def BB84Test ( Alice : Person , Bob : Person ) : Alice . set_integr ( [ ] ) # R e i n i c i a r contador de ce ro s testAlice =0 testBob =0 while ( len ( Alice . get_integr ( ) ) < 16): cl av eA li ce = OpBB84. r b i t s (16∗4) pol Al ice = OpBB84. r b i t s (16∗4) polBob = OpBB84. r b i t s (16∗4) claveBob = [ ] Al ice . anadirClave ( cl a v eA l i ce . numpy ( ) ) Al ic e . anadirPol ( po l Al ic e . numpy ( ) ) Bob . anadirPol ( polBob . numpy ( ) ) f o r i in range ( len ( c l a ve A l i ce ) ) : claveBob . append ( circuitBB84 ( c l ave A l ice [ i ] , p olAlice [ i ] , polBob [ i ] ) ) Bob . anadirClave ( t f . squeeze ( claveBob ) . numpy( ) ) polB = Bob . get_pol () polA = Alice . get_pol ( ) OpBB84 . c r i b a r B i t s ( Alice , polB ) Jorge Martín Villafruela 63 Capítulo 8. Implementación OpBB84 . c r i b a r B i t s (Bob , polA ) t e st A l i ce , testBob = OpBB84. t e s t I n t e g r i d a d ( Alice , Bob) return ( t e s t A l ice , testBob ) Finalmente, añadiendo la adjudicación de la clave privada: Listing 8.11: Ciruito básico def BB84( Alice : Person , Bob : Person ) : t es t Al i c e , testBob = BB84Test (Bob , A li ce ) i f ( t e s t A l i c e & testBob ) : i f (OpBB84. genClavePrivada (Bob) and OpBB84. genClavePrivada ( Alice ) ) : return True e l s e : pr in t ( "El␣ canal ␣ es ␣ inseguro " ) return False 8.4. BB84Alt.py Otra posible implementación del circuito del protocolo BB84 es el intentar tratar con toda la cadena de bits a transmitir a la vez en el circuito. Esto supone que no se podrán utilizar los condicionales como en la implementación anterior, sino que habrá que utilizar las propias cadenas de bits para parametrizar las funciones. Recordemos que el circuito a simular consta de cuatro partes: 1. Transmitir el valor de la cadena de bits originales al cable cuántico (al qubit). 2. Polarizar los qubits según el valor de los bits generados por Alice PA. 3. Polarizar los qubits según el valor de los bits generados por Bob PA. 4. Medición de los qubits por parte de Bob para obtener su cadena Para las tres primeras necesitaremos entonces crear dos métodos meterBit ypolarizarQbit. mientras, el método sample(wire:int) de la librería de PennyLane mide el qubit en el cable wire del circuito. Recordemos que en los circuitos implementados con PennyLane el valor inicial de los qubits es siempre |0⟩. Como se observa en el circuito, hay que implementar una puerta CNOT : Si el bit es 0, en la CNOT entra |00⟩y se transforma en |00⟩, luego sale |0⟩. 64 Jorge Martín Villafruela 8.4. BB84Alt.py Si el bit es 1, en la CNOT entra |10⟩y se transforma en |11⟩, luego sale |1⟩. Como se comentó en la sección 6.1.3, en la librería PennyLane se puede encontrar el método CNOT(wires) que implementa dicha puerta. Sin embargo, eso implicaría que el circuito cuántico en el que se simularía el protocolo tuviera que utilizar también canales cuánticos para los bits tradicionales. Aunque sea una solución factible, esta implementación cuadriplicaría los recursos que se necesita para el circuito (el circuito sería de 4 canales cuánticos en vez de solo uno). Una mejor opción a la hora de realizar la implementación es que se aplique una puerta u otra dependiendo de unos parámetros (que simulen a los bits) pasados al circuito. Se tiene entonces que buscar una función para que cuando se envíe el valor 0se aplique la puerta identidad Iy cuando se envíe el valor 1se aplique la puerta Pauli X(cuando el bit vale 1). Como ya hemos dicho anteriormente la identidad equivale al caso donde todos los parámetros son nulos. Es es el caso que asociaremos con que el bit valga 0. Como queremos hacer una rotación en el plano X, equivale a una rotación de πtanto en ycomo en Z:PX=iRy(π)Rz(π)(Más luego la multiplicación por el escalar i, que se puede obviar). Por tanto, como I=Ry(0)Rz(0), podemos considerar la función f:{0,1} −→ C f(x) = eixπ/2RY(πx)RZ(πx) Esto implica que el método meterBit() debe consistir en aplicar primero la puerta RZ(πx)y luego RY(πx)(con las funciones de PennyLnae RY() yRZ()), siendo xel valor del bit a insertar (en ese orden, puesto primero se aplican las puertas “a la derecha”). Listing 8.12: meterBit() def meterBit ( b i t ) : # Para e l l o , hay que t ran sf orm ar |0> a #−|0 >: hay que a p l i c a r l a func ion ide nti dad = RY( 0)∗RZ(0) #−|1 >: hay que a p l i c a r l a puerta PauliX = RY( pi )∗RY( pi ) # luego tenemos que a p l i c a r una puerta u otra , en cada caso qml .RZ( bi t ∗np . pi , ( 0 ) ) qml .RY( b it ∗np . pi , ( 0 ) ) qml . Rot ( b i t ∗np . pi , 0 , 0 , 0 ) De manera similar, se tiene que implementar cómo Alice y Bob polarizan un bit. En el circuito, esto se consigue por las dos Controlled Hadamard (CH) (una en la parte de Alice y otra en la parte de Bob), que son las que cambia la polarización. Por lo mismo que antes, para no tener que representar en el circuito el cable que envía las polarizaciones, tenemos que encontrar una manera de sustituir la puerta CHpor una parametrización que dependa del bit enviado. Jorge Martín Villafruela 65 Capítulo 8. Implementación Ya vimos que la puerta Hadamard se puede descomponer en: H=iRY(π/2)RZ(π) Además, como I=RY(0) RZ(0), podemos considerar la función: f:{0,1} −→ C f(x) = eixπ/2RY(xπ/2)RZ(xπ) Que cumple que f(0) = Iyf(1) = H(luego asocia los 0s de la cadena con la polarización Ay los 1con la B), así que podemos representar las polarizaciones, construyendo así la función polarizarBit(). Con ambos métodos, ya se puede construir el circuito, que tiene como atributos de entrada dos objetos Person que harán el papeles de Alice y Bob respectivamente: Listing 8.13: circuitBB84Alt() dev = qml . de vice ( ’ de fa ul t . qubit ’ , wires =1, shots =1) @qml . qnode ( dev ) def circuitBB84 ( Alice , Bob ) : #Parte de Alice meterBit ( Alice . _clave ) po la riza rQbit ( Alice . _pol ) #Parte de Bob po la rizar Qb it (Bob . _pol ) return ( qml . sample (None , (0) )) 8.5. BB84Ruido.py La principal diferencia en la implementación que se debe considerar respecto al caso básico será, obviamente, la implementación del ruido. En computación cuántica hay dos tipos principales de ruido: el debido al cambio de polarización y el cambio de valor del bit (llamado bitflip). La librería de ‘pennylane‘, contiene ya una implementación de dichos ruidos, mediante los métodos DepolarizingChannel (prob, wires) yBitFlip(prob, wires=0) respectivamente. Esto implica que entre la parte de Alice y la parte de Bob del circuito habrá que añadir ambos métodos. Sin embargo, no es tan sencillo. Estos métodos no son compatibles con el dispositivo básico utilizado para emular el circuito en el caso básico dafult.qubit. En cambio, se tendrá que utilizar el dispositivo default.mixed. Este tipo también se utilizará para el caso de Eve, aunque no sea necesario. 66 Jorge Martín Villafruela 8.5. BB84Ruido.py Listing 8.14: Circuito del protocolo BB84 con ruido en el canal en cadena devMix = qml . de vice ( ’ de fa ul t . mixed ’ , wires =1, shots =1) @qml . qnode ( devMix ) def circuitBB84Ruido ( Alice , Bob , ruido ) : #Parte de Alice BB84 . meterBit ( A lic e . _clave ) BB84 . p ol ariz ar Qb it ( A li ce . _pol ) # Canal qml . DepolarizingChannel ( ruido , wires =0) qml . Bit Flip ( ruido , wires =0) #Parte de Bob BB84 . p ol ariz ar Qb it (Bob . _pol ) return ( qml . sample (None , (0) )) Listing 8.15: circuitBB84Ruido() devMix = qml . de vice ( ’ de fa ul t . mixed ’ , wires =1, shots =1) @qml . qnode ( devMix ) def circuitBB84Ruido ( bit , AliceP , BobP, ruido , ruido2=None ) : ’’’ Ci rcui to c u n t i c o hecho usando la l i b r e r a de pennylane , que ejecu t a e l pr ot oco lo BB84 Alice : Objeto Person que e n v a l a cadena de bi t de la que se sacara la clave Bob : Objeto Person que re ci be l a cadena ruido : probabilidad de que se generere la d i s t o r s i n : fuerza del ruido Retrun : clave de Bob ’’’ i f ( ruido2 i s None ) : ruido2 = ruido #Parte de Alice i f ( bi t ) : qml . PauliX (0) i f ( AliceP ) : qml . Hadamard (0) Jorge Martín Villafruela 67 Capítulo 8. Implementación # Canal qml . DepolarizingChannel ( ruido , wires =0) qml . Bit Flip ( ruido2 , w ires =0) #Parte de Bob i f (BobP ) : qml . Hadamard (0) return ( qml . sample (None , (0) )) A partir de esta función, se puede construir de BB84RuidoTest() yBB84Ruido() de la misma manera que BB84Test() yBB84(). Por ese motivo, no se mostrarán explícitamente aquí. 8.6. BB84Eve.py En esta sección, la función más importante es la que consiste en la implementación del efecto sobre el qubit en la medición de Eve. De las implementaciones consideradas, la que se ha implementado es la básica (donde la polarización elegida por Eve es al azar entre AyB). Para ver cómo implementar esto, analicemos los pasos de cómo Eve interacciona con el qubit: Primero, polariza el qubit (puerta Hadamard condicional) según sus polarizaciones. A continuación, Eve mide el qubit: •En caso de que haya acertado la polarización, el valor del qubit se mide correctamente. •Si no es el caso, como se ha medido mal su valor, se polariza el bit (aplicar una puerta Hadamard). Además, la mitad de estas veces se “invertirá” su valor (una puerta de Pauli X la mitad de estas veces). Finalmente, se envían los qubits con los valores medidos, y con las polarizaciones de Eve (puerta Hadamard condicional). Visualmente, el circuito necesario a implementar en PennyLane es: CA• PE• PA• |0⟩X H H •HA Bob =⇒ 68 Jorge Martín Villafruela 8.6. BB84Eve.py Si CA= 1 Si PA= 1 Si PE= 1Si PE=PA Si PE=PA (la mitad de las veces) Si PE= 1 |0⟩X H H H X H A Bob Simulación de una mala polarización Pasando este circuito a PennyLane, se obtiene esta implementación que simula el efecto de la medición en el canal: Listing 8.16: medirQbit(). def medirQbit ( polEve , polOG ) : cambioBit = BB84. r b i t s (1) i f ( polEve ) : qml . Hadamard (0) i f not (polOG==polEve ) : qml . Hadamard (0) i f ( cambioBit ) : qml . PauliX (0) i f ( polEve ) : qml . Hadamard (0) A partir de esta función, solo falta entonces añadirla al circuito general para obtener el circuito para el caso en el que el canal sea escuchado: Listing 8.17: Circuito para el caso de Eve. @qml . qnode ( devMix ) def circuitBB84Eve ( bit , AliceP , BobP, polEve ) : #Parte de Alice i f ( bi t ) : qml . PauliX (0) i f ( AliceP ) : qml . Hadamard (0) # Canal medirQbit ( polEve , AliceP ) #Parte de Bob i f (BobP ) : qml . Hadamard (0) return ( qml . sample (None , (0) )) De la misma manera que sucedía con BB84Ruido.py, a partir de esta función se puede construir de BB84RuidoEve() yBB84Eve() de la misma manera que se construyeron BB84Test() yBB84() en BB84Basic.py. Jorge Martín Villafruela 69 Capítulo 8. Implementación 8.7. BB84Extra.py En este archivo se encuentra la implementación de la mejora que se sugiere en los cuadernos para mejorar la efectividad del protocolo en un canal con ruido. Durante el cuaderno ImplementacionBB84Complejo.ipynb, se llega a la conclusión de que un factor clave para diferenciar entre cuándo el canal esta siendo atacado a cuándo el canal solamente se ve afectado con cierto nivel de ruido son tanto el número de intentos necesarios para pasar el test de integridad, como veces en las que se ha obtenido más de 5 fallos en el test de integridad a lo largo de todos los intentos. Esto lleva a encontrar una modificación del protocolo a partir de los valores de esa dupla para el caso a analizar. Este proceso consiste en, partiendo de los valores de la muestra obtenida anteriormente en el cuaderno, decidir si tras cada intento de pasar el test de integridad, se ha de comprobar si la dupla (intentos, fallosTotales) del caso a analizar es suficientemente similar a los datos para el ruido en la muestra, siendo: intentos. Nºde intentos (de realización del protocolo) requeridos hasta ese momento para pasar el test (entre todos los intentos). fallosTotales. Veces que se han obtenido más de 5 errores en el test de integridad Puesto que para ambos atributos el ruido suele tener valores menores, se le permite a la muestra volver a intentar pasar el test de integridad siempre y cuando ambos atributos sean suficientemente pequeños. Para ello, se considerará “suficientemente ruido” si está más cercano a la media de los valores obtenidos para el ruido, que a los obtenidos para cuando el canal ha sido atacado. Implementar esto es sencillo, puesto que, ya que para ambos datos los valores para el caso Ruido son menores que para el caso Eve, con solo detectar que los valores del caso a analizar son menores a la media de las medias obtenidas (denotadas en el cuaderno por las variables (tM,fM)), es suficiente para ver si el caso actual se encuentra en la zona de influencia de los valores del ruido o no2. Además, con ayuda de los archivos anteriormente comentados, se aprovechará para que esta función actúe como un polimorfismo, en el que se aplicará uno u otro circuito según los parámetros transmitidos a la función: Listing 8.18: GenericBB84Test() def GenericBB84Test ( Alice : Person , Bob : Person , polEve=None , ruido1=None , ruido2=None ) : ’’’ Dependiendo l o s arguntos enviados , r e a l i z a una v e r s i n d el p r o t o c olo BB84 u otra Parametros : Alice : Persona emisora Bob : Persona receptora polEve : P o l i z a c i n inducida por Eve 2Para el script, los puntos medios que se han considerado son los generados a partir del conjunto de entrenamiento de la figura 2.5. Esto da con los valores tM (media de los tiempos) 45 y fM (media de veces con más de 5 fallos) 7.7, respectivamente. 70 Jorge Martín Villafruela 8.7. BB84Extra.py ruido1 : Porcentaje de ruido de cambio de bi t ( BitFlip ) ruido2 : Porcentaje ded e polar i zacio n return ’’’ i f ( polEve i s None and ruido1 i s None and ruido2 i s None ) : return not ( BB84Test ( Alice , Bob )) # Se i n v i e r t e su resultado , puesto que devulve True cuando se pasa e l t es t a d i f e r e n c i a del r est o e l i f ( ruido1 i s None and ruido2 i s None ) : return BB84EveTest ( Alice , Bob) e l i f ( polEve i s None ) : return BB84RuidoTest ( Alice , Bob , ruido1 , ruido2 ) e l s e : BB84EveRuidoTest ( Alice , Bob , polEve , ruido1 ) Listing 8.19: GenericBB84() def GenericBB84 ( Alice : Person , Bob : Person , polEve=None , ruido1=None , ruido2=None ) : ’’’ Reali za e l pr ot oc lo BB84 ent re Ali ce y Bob para i nt e nt ar generar una cl av e Privada ent re e l l o s , con p o s i b i l i d a d de pueda e x i s t i r Eve espiando , o haya c i e r t o ruido en e l canal Parametros : Alice : Persona emisora Bob : Persona receptora polEve : P o l i z a c i n inducida por Eve ruido1 : Porcentaje de ruido de cambio de bi t ( BitFlip ) ruido2 : Porcentaje ded e polar i zacio n Return : True s i se l o g r generar clave privada ’’’ #Valores empiricos obtenidos de una muestra obtenida tM = 45 fM = 7.7 intentos = 1 f a l l o s T o t a l e s=0 pasaTest = False timeout=False while not ( pasaTest ) : testA l ic e , testBob = GenericBB84Test ( Alice , Bob , polEve , ruido1 , ruido2 ) i f not ( t e s t A l i c e & testBob ) : i f ( genClavePrivada (Bob) & genClavePrivada ( Ali ce ) ) : Jorge Martín Villafruela 71 Capítulo 9. Pruebas 78 Jorge Martín Villafruela Parte III Manuales de la Aplicación Capítulo 10 Manuales 10.1. Manual de Instalación Lo único necesario apara poder visualizar correctamente un cuaderno Jupyter en un dispositivo es tener la librería de Jupyther Notebook instalada -lo que implica tener instalado Python-, y un navegador web. Puesto que, al fin y al cabo, Jupyter es una librería de Python, lo primero será instalar Python en el sistema en el que se vaya a utilizar. En caso de solo querer leer el cuaderno, por lo explicado en 6.2. Sin embargo, en caso de querer poder compilar personalmente las celdas, será necesarias también las librerías y paquetes utilizados en el código. La instalación de Python y de paquetes puede realizarse de dos maneras: Instalación Independiente. Una manera de instalar Python en un dispositivo es simplemente instalando el ejecutable propio de Python para ello, localizado en www. python.org/downloads. Cualquier versión de python3 o superior es suficiente para los cuadernos del proyecto. 81 Capítulo 10. Manuales Figura 10.1: Página de descarga del ejecutable de Python. Tras ejecutarlo (eligiendo ”añadir a la variable PATH” en caso de encontrarse en Windows), se puede comprobar que se ha instalado correctamente viendo que se ejecuta correctamente el comando Python - -version Una vez comprobado que se ha instalado Python correctamente, se tienen que instalar los paquetes. Esto se puede hacer mediente el comando pip en la consola de comandos. En el caso concreto de Jupyter Notebook, es pip install notebook Una vez instalado, para iniciar Jupyter se tiene que escribir en la consola de comandos jupyter notebook Instalación por Anaconda. Una manera alternativa de instalar Python y los paquetes es instalando la distribución de trabajo Anaconda. Anaconda es una distribución de trabajo, centrada en machine learning y en el análisis de datos, para Python y R, que permite instalar y gestionar los paquetes de manera cómoda y sencilla, además de que la instalación del propio Anconda incluye la instalación de Python en su distribución. Pese a la comodidad que ofrece trabjar sobre Anaconda, también tiene sus desventajas. Puesto que Anaconda es una distribución aislada, crea un entorno de desarrollo local, pudiendo no usarse ni Python ni los paquetes instalados fuera de él. Además, suelen surgir problemas si existe una distribución de Python a nivel global en el sistema. Más información sobre este proceso de instalación se puede encontrar en https://docs.anaconda.com. 82 Jorge Martín Villafruela 10.2. Manual de Uso 10.2. Manual de Uso Se recomienda que contenga la información relevante, lo más completa y clara posible, como si fuese el manual de un producto comercial, dirigido a un usuario no avanzado. Esta documentación pudiera coincidir (de hecho, se recomienda) con la AYUDA del programa. Dependiendo de la instalación elegida, se abre la interfaz de jupyter de una manera distinta: Si se ha realizado la instalación por la consola de comandos, basta con ejecutar en cmd (o PowerShell o similares) el comando jupyter notebook Para se abra directamente en un directorio determinado, se debe añadir su ruta (o ruta relativa) al comando: jupyter notebook .\Documents\Cuadernos En Anaconda, basta con abrir el entorno de Jupyter: Figura 10.2: Abrir Jupyter en Anaconda Una vez abierto, hay que ejecutar el cuaderno deseado. En este proyecto, el cuaderno inicial, y por el que se recomienda comenzar, es Introduccion.ipynb, aunque puede seleccionarse cualquiera si así se desea. La barra superior contiene herramientas para la creación y compilación de nuevas celdas: Jorge Martín Villafruela 83 Capítulo 10. Manuales Figura 10.3: Barra de herramientas de los cuadernos Jupyter 1Crea una nueva celda, compilada según lo indicado en 1a. 2Herramientas de copiado y pegado. 3Mueve la ubicación de las celdas. 4Ejecución de la celda seleccionada. 5Parada de la ejecución de la celda 6Reiniciar el kernel. 7Ejecutar todo el cuaderno desde el inicio. Por otra parte, la primera celda de cada cuaderno contiene las importaciones que se necesitan para dicho cuaderno. Si se quiere ejecutar una celda en específica, será necesario primero ejecutar esta celda. 84 Jorge Martín Villafruela Parte IV Apéndices Apéndice A Anexos A.1. Información complementaria Si se quiere profundizar sobre el uso de la librería de PennyLane, se sugiere consultar su documentación en su página web (https://pennylane.ai/qml/documentation), además de varios ejemplos de aplicación, accesibles desde la dirección https://pennylane.ai/ qml/demonstrations. Como ya se ha comentado en la memoria, para profundizar sobre el funcionamiento del protocolo BB84, entre las fuentes bibliográficas se encuentran varias opciones. El libro Quantum Comuptation and Quatum Information[14] sirve para ahondar sobre la computación cuántica en general, siendo su mayor problema el ser demasiado técnico. Un enfoque más práctico es dado en el artículo Quantum cryptography: Public key distribution and coin tossing[2], donde su explicación es mucho más comprensible. 87 30 06 feb 2023 13 20 27 06 mar 2023 13 20 27 03 abr 2023 10 17 24 01 may 2023 08 15 22 29 05 jun 2023 12 19 Investigador[50%];Programador[50%] Investigador[50%];Programador[50%] Programador Investigador[50%];Programador[50%] Programador Programador Investigador[50%];Programador[50%] Programador Programador Programador Investigador Investigador Investigador Investigador Investigador Investigador Investigador Investigador Estimación BB84 Inicial - página2 Apéndice A. Anexos Cuadro A.5: Diagrama de Gantt final 94 Jorge Martín Villafruela 1 Instalación Anaconda 3 days 2 Reunión implementación 1 day 3 Estimaciones del proyecto 38,5 days 4 Preparación Implementación 38,5 days 5 Implementación circuito cuantico para varios qub... 7 days 6 Inserción de bits en el cirucito cuántico 8 days 7 Implementacion cifrado AES en python 3 days 8 Progamación BB84 108 days 9 Clase Persona 15 days 10 Modelización de los parámetros 6 days 11 Modelización del canal 8 days 12 Implementación del circuito 7 days 13 Implementación del test de Integridad 3 days 14 Ejemplo de ejecución 2 days 15 Implementación del ruido 4 days 16 Inserción de ruido en el canal 2 days 17 Estadísticas ruido 5 days 18 implementación Eve 3,625 days 19 Estadísticas Eve 4 days 20 Implementación Eve mejorado 4,75 days 21 Clase Eve 2,125 days 22 Redacción cuadernos 87 days 23 Intrducción a la computación cuántica 11 days 24 Definición de qubit 3 days 25 Esfera de Bolch 4 days 26 Puertas lógicas 2 days 27 Puertas condicionales 2 days 28 Teoría protocolo BB84 23,625 days 29 Non cloning Theorem 2 days 30 Sobre la puerta Hadamard 2 days 31 Aplicación del protocolo BB84 3 days 32 Funcionamiento BB84 2,5 days 33 Método de comprobación 3 days Nombre Duración 19 26 03 oct 2022 10 17 24 31 07 nov 2022 14 21 28 05 dic 2022 12 19 26 02 ene 2023 09 16 23 Programador Jefe de Proyecto Programador Programador Programador Investigador[50%];Programador[50%] Programador Programador Investigador[50%];Programador[50%] Investigador[50%];Programador[50%] Investigador Investigador Investigador Investigador Estimación BB84 Inicial - página1 A.2. Diagramas y tablas Cuadro A.6: Diagrama de Gantt final Jorge Martín Villafruela 95 Apéndice A. Anexos 96 Jorge Martín Villafruela Apéndice B Contenido del entregable El entregable se compondrá de los cuadernos que componen el proyecto, así como de los scripts (guardados en la carpeta pythonBB84) e imágenes (guardados en la carpeta Imagenes) necesarios para compilarles. Para abrir los cuadernos, se hará como cualquier otro cuaderno Jupyter, como se ha indicado en los manuales de uso (sección 10.2). 97 Apéndice B. Contenido del entregable 98 Jorge Martín Villafruela Bibliografía [1] url:https://zeromq.org/get-started/. [2] Charles H. Bennett y Gilles Brassard. “Quantum cryptography: Public key distribution and coin tossing”. En: Theoretical Computer Science 560 (2014). Theoretical Aspects of Quantum Cryptography – celebrating 30 years of BB84, págs. 7-11. issn: 0304-3975. doi:https://doi.org/10.1016/j.tcs.2014.05.025.url: https://www.sciencedirect.com/science/article/pii/S0304397514004241. [3] Ville Bergholm et al. PennyLane: Automatic differentiation of hybrid quantumclassical computations. 2022. arXiv: 1811.04968 [quant-ph]. [4] P. Bourque y R.E. Fairley. Guide to the Software Engineering Body of Knowledge, Version 3.0. ACM-IEEE. 2014. [5] MathJax Consortium. Mathjax.url:https://www.mathjax.org/. [6] Cryptodome documentation. PyCryptodome. Mayo 2023. url:https://www.pycryptodome. org. [7] Bryan Eastin y Steven T. Flammia. Q-circuit Tutorial. 2004. eprint: arXiv:quantph/0406003. [8] Charles R. Harris et al. “Array programming with NumPy”. En: Nature 585 (2020), 357–362. doi:10.1038/s41586-020-2649-2. [9] J. D. Hunter. “Matplotlib: A 2D graphics environment”. En: Computing in Science & Engineering 9.3 (2007), págs. 90-95. doi:10.1109/MCSE.2007.55. [10] Anil K. Jain. “Data clustering: 50 years beyond K-means”. En: Pattern Recognition Letters 31.8 (2010). Award winning papers from the 19th International Conference on Pattern Recognition (ICPR), págs. 651-666. issn: 0167-8655. doi:https:// doi.org/10.1016/j.patrec.2009.09.011.url:https://www.sciencedirect. com/science/article/pii/S0167865509002323. [11] J.M.S. “IBM presenta el primer ordenador cuántico comercial: ¿puedo tener ya un «súper-PC» en casa?” En: ABC (10 de ene. de 2019). url:https://www.abc. es/tecnologia/informatica/hardware/abci-presentaprimer-ordenadorcuanticocomercialpuedotenersuperpccasa201901101757_noticia (visitado 29-10-2019). 99 Bibliografía [12] Sara Sans Josep Corbella. “Barcelona liderará el desarrollo de un ordenador cuántico”. En: La Vanguardia (29 de oct. de 2021). url:https : / / https : / / www . lavanguardia.com/local/barcelona/20211029/7825701/barcelona-lideraradesarrollo-ordenador-cuantico.html (visitado 29-10-2021). [13] Thomas Kluyver et al. “Jupyter Notebooks – a publishing format for reproducible computational workflows”. En: Positioning and Power in Academic Publishing: Players, Agents and Agendas. Ed. por F. Loizides y B. Schmidt. IOS Press. 2016, págs. 87 -90. [14] Michael A. Nielsen e Isaac L. Chang. Quantum Comuptation and Quatum Information. Cambridge, 2010. [15] R. Pressman. Ingeniería del Software. McGraw-Hill, 2014. [16] Adi Shamir. “How to share a secret”. En: Communications of the ACM 22 (1979). 100 Jorge Martín Villafruela