Implementação e avaliação da cifra de fluxo Xote em plano de dados de hardware programável Tofino

Implementac¸˜ ao e avaliac¸˜ ao da cifra de fluxo Xote em plano de dados de hardware program´ avel Tofino Rodrigo A. de A. Pierini1, Caio Teixeira1, Christian Esteve Rothenberg1, Marco Amaral Henriques1 1Faculdade de Engenharia El´ etrica e de Computac¸˜ ao Universidade Estadual de Campinas Campinas - SP - Brasil {rpierini,chesteve,maah}@unicamp.br [email protected] Abstract. This work introduces a novel element reordering technique applied to the Intel Tofino architecture’s packet interpreter, enabling the first-time implementation of the Xote algorithm on programmable data planes, and presents a comprehensive comparative performance analysis of the ChaCha, Forr´ o, and Xote algorithms on this architecture. The results demonstrate that the ChaCha algorithm, when implemented with the proposed reordering technique, achieves higher maximum packet throughput and similar resource utilization compared to the other algorithms, surpassing previously reported results in the literature with a 1.65x increase in maximum throughput. Resumo. Este trabalho introduz uma t´ ecnica de reordenac¸ ˜ ao de elementos aplicada no interpretador de pacotes da arquitetura Intel Tofino, viabilizando a implementac¸ ˜ ao in´ edita do algoritmo Xote em plano de dados program´ aveis, e apresenta uma an´ alise comparativa abrangente do desempenho dos algoritmos ChaCha, Forr´ o e Xote nesta arquitetura. Os resultados demonstram que o algoritmo ChaCha, quando implementado com a t´ ecnica de reordenac¸ ˜ ao proposta, alcanc¸a uma maior vaz˜ ao m´ axima de pacotes e uma utilizac¸ ˜ ao de recursos similar em comparac¸ ˜ ao com os demais algoritmos, superando os resultados previamente reportados na literatura com um aumento da vaz˜ ao m´ axima em 1,65 vezes. 1. Introduc¸˜ ao As tecnologias de redes de computadores passaram por diversas mudanc¸as de paradigmas nos ´ ultimos anos, avanc¸ando das redes tradicionais que possuem foco no encaminhamento de pacotes e engenharia de tr´ afego, ` as redes program´ aveis com foco na distribuic¸˜ ao de processamento das aplicac¸ ˜ oes atrav´ es de todo o n´ ucleo da rede. Essas mudanc¸as de paradigmas trazem novas oportunidades e desafios para diversas ´ areas, como a´ area de seguranc¸a da informac¸˜ ao. Garantir a seguranc¸a de uma rede de computadores ´ e uma necessidade crescente em cen´ arios com ataques cibern´ eticos cada vez mais elaborados. Portanto, busca-se prezar por sigilo, integridade e disponibilidade dos dados que est˜ ao em trˆ ansito ou sendo processados pela rede. Com o processamento de pacotes ocorrendo independente de protocolos, novas tecnologias podem ser agilmente criadas para vencer os atuais desafios de seguranc¸a em redes, viabilizando novas abordagens para protec¸˜ ao de dados em trˆ ansito. Pesquisas desenvolvidas no contexto de redes program´ aveis abordam formas de se prover sigilo ` as comunicac¸ ˜ oes atrav´ es da implementac¸˜ ao e avaliac¸˜ ao de algoritmos criptogr´ aficos diretamente no chip de processamento de pacotes em switches program´ aveis. Algoritmos de criptografia como AES [Dworkin et al. 2001], ChaCha [Bernstein et al. 2008] e Forr´ o [Coutinho et al. 2023] j´ a foram implementados e avaliados quanto ` a sua vaz˜ ao e uso de recursos na plataforma “Intel Tofino” com o objetivo de prover sigilo em comunicac¸ ˜ oes e verificar a integridade de dispositivos em uma rede gerenciada. Como demonstrado na literatura, algoritmos de cifra de fluxo implementados em plano de dados program´ avel podem alcanc¸ar vaz˜ oes de dados maiores com menor uso de recursos quando comparadas ` a cifra de bloco AES [Yoshinaka et al. 2022] implementada na mesma arquitetura devido a n˜ ao utilizarem tabelas de substituic¸˜ ao (S-Boxes) e processarem a entrada e a chave conjuntamente, sem o uso de uma key schedule. Este trabalho apresenta a implementac¸˜ ao do algoritmo de cifra de fluxo “Xote” [Coutinho et al. 2023] e conduz uma comparac¸˜ ao com outros algoritmos de criptografia em termos de vaz˜ ao m´ axima e uso de recursos. Portanto, uma pergunta de pesquisa que este artigo permite responder ´ e: “Com o objetivo de prover sigilo de dados que trafegam e s˜ ao processados no n´ ucleo de uma rede program´ avel, como os algoritmos de cifra de fluxo ‘Xote’, ‘Forr´ o’ e ‘ChaCha’ implementados na plataforma Tofino se comparam em vaz˜ ao m´ axima e uso de recursos?” Trˆ es contribuic¸ ˜ oes relevantes s˜ ao apresentadas ao longo deste trabalho: (i) uma nova t´ ecnica de reordenac¸˜ ao de elementos de matriz no interpretador de pacotes (parser) para otimizar uso de recursos; (ii) a primeira implementac¸˜ ao do algoritmo Xote em plano de dados program´ avel na arquitetura Intel Tofino; (iii) uma avaliac¸˜ ao detalhada de desempenho dos algoritmos Chacha, Forr´ o e Xote em trˆ es n´ ıveis diferentes de seguranc¸a. Para melhor contextualizar este trabalho, na Sec¸˜ ao 2 s˜ ao apresentados alguns paradigmas de redes que surgiram nos ´ ultimos anos. J´ a a Sec¸˜ ao 3 apresenta as cifras de fluxo de interesse exploradas na literatura e sua implementac¸˜ ao em plano de dados program´ avel. A Sec¸˜ ao 4 apresenta algumas restric¸ ˜ oes para implementac¸˜ ao de algoritmos na plataforma Tofino. As implementac¸ ˜ oes existentes na literatura s˜ ao introduzidas na Sec¸˜ ao 5 onde descrevemos a t´ ecnica desenvolvida para viabilizar a implementac¸˜ ao da cifra de fluxo “Xote” nessa plataforma. A seguir, a Sec¸˜ ao 7 apresenta e discute os dados coletados nos experimentos conduzidos com as implementac¸ ˜ oes, com o objetivo de comparar seu desempenho em vaz˜ ao e uso de recursos. Por fim, o trabalho ´ e conclu´ ıdo na Sec¸˜ ao 8 com a apresentac¸˜ ao de poss´ ıveis trabalhos futuros. 2. Paradigmas de redes de computadores Nas redes de computadores, os dados s˜ ao transportados entre hospedeiros atrav´ es do n´ ucleo de rede na forma de pacotes de dados. O objetivo da rede ´ e realizar a transmiss˜ ao desses pacotes com a menor latˆ encia e perda poss´ ıvel. Para isso, os equipamentos de n´ ucleo de rede s˜ ao divididos em duas partes: o plano de controle (control plane, CP), respons´ avel por definir como encaminhar pacotes, e o plano de dados (data plane, DP), respons´ avel por realizar o encaminhamento dos pacotes. O DP ´ e constitu´ ıdo por um ASIC (Application-Specific Integrated Circuit) que interpreta, modifica e encaminha os pacotes a partir de parˆ ametros providos por um software executado no CP. Em redes de computadores tradicionais, cada equipamento de comutac¸˜ ao de pacotes (seja um switch ou um roteador) possui o CP e DP embarcados, realizando uma operac¸˜ ao encapsulada e colaborativa com outros equipamentos. J´ a por volta de 2011, um novo paradigma de redes chamado “redes definidas por software” (software-defined networking, SDN) surgiu com o objetivo de facilitar o gerenciamento de redes atrav´ es da centralizac¸˜ ao do CP em um controlador com vis˜ ao de todos os dispositivos da rede. nesse paradigma, o DP nos dispositivos ´ e configurado por softwares em execuc¸˜ ao no controlador utilizando uma API, permitindo a rede operar de forma integrada [Kreutz et al. 2014]. No paradigma SDN, os DPs s˜ ao limitados a operarem de acordo com a arquitetura do ASIC feita pelo fabricante do equipamento e seguindo protocolos de rede existentes. Portanto, por volta de 2014, um novo paradigma chamado de “redes program´ aveis” (Programmable Networks) surgiu com o objetivo de viabilizar a definic¸˜ ao da operac¸˜ ao do ASIC de forma program´ avel, permitindo que desenvolvedores de planos de dados program´ aveis (programmable data plane, PDP) definam a forma que o DP deve interpretar, modificar e encaminhar pacotes sem depender de protocolos pr´ edefinidos. Esta definic¸˜ ao de operac¸˜ ao do PDP ´ e feita atrav´ es de uma linguagem de dom´ ınio espec´ ıfico chamada P4 (Programming Protocol-independent Packet Processors) [Kfoury et al. 2021] [Hauser et al. 2023]. Redes program´ aveis viabilizam que o n´ ucleo da rede realize o processamento de dados diretamente no DP. Com isso, uma nova tendˆ encia chamada “computac¸˜ ao em rede” (In-Network Computing, INC) adota o descarregamento (offloading) do processamento de dados tradicionalmente realizado nos hospedeiros para equipamentos de rede program´ aveis, liberando recursos dos processadores em hospedeiros para realizarem outras operac¸ ˜ oes. Essa abordagem tamb´ em permite que o processamento de dados seja realizado durante a transmiss˜ ao de dados na rede [Gherari et al. 2023]. Portanto, o paradigma de redes program´ aveis tamb´ em viabiliza o processamento de func¸ ˜ oes de seguranc¸a de dados na rede, permitindo abordagens inovadoras para a protec¸˜ ao de redes e dados. Dentre estas abordagens, destaca-se a aplicac¸˜ ao de criptografia diretamente no PDP com algoritmos de cifrac¸˜ ao como AES [Chen 2020], ChaCha [Yoshinaka et al. 2022] e Forr´ o [Pierini et al. 2024], bem como algoritmos de autenticac¸˜ ao de mensagem baseados em resumo criptogr´ afico (hash-based message authentication code, HMAC) como Half SipHash [Yoo and Chen 2021] e Chaskey [Francisco et al. 2024]. Nesse contexto, esse artigo busca expandir o estado da arte com a avaliac¸˜ ao de desempenho de uma nova implementac¸˜ ao de um algoritmo de cifra de fluxo em PDP. A pr´ oxima sec¸˜ ao apresenta conceitos fundamentais dos algoritmos de cifra de fluxo “ChaCha”, “Forr´ o” e “Xote”. 3. Cifras de fluxo Algoritmos de cifra de fluxo s˜ ao utilizados para prover sigilo a dados atrav´ es de uma operac¸˜ ao de ou-exclusivo bit-a-bit (bitwise XOR) com um conjunto de bits (keys- tream) gerado a partir de uma func¸˜ ao pseudoaleat´ oria (Pseudorandom Function, PRF) utilizando uma chave secreta compartilhada. Para a seguranc¸a desse tipo de cifra, o conjunto de bits utilizado para cifrar os dados n˜ ao pode ser repetido, pois essa repetic¸˜ ao facilita a recuperac¸˜ ao da chave utilizada. Para evitar essa repetic¸˜ ao, os algoritmos ChaCha e Forr´ o utilizam um nonce (n´ umero de uso ´ unico) de 64 bits que varia a cada mensagem cifrada e um contador de 64 bits incrementado a cada conjunto de 512 bits gerado, alterando os parˆ ametros de entrada da PRF do algoritmo. Juntamente com uma constante de 128 bits e uma chave secreta de 256 bits, esses parˆ ametros s˜ ao estruturados em uma matriz (chamada “matriz de estado”) com 16 elementos de 32 bits organizados em 4 linhas e 4 colunas. Estes algoritmos s˜ ao chamados de cifras ARX (Add, Rotate, XOR), pois os elementos dessa matriz s˜ ao processados em rodadas utilizando operac¸ ˜ oes de adic¸˜ ao m´ odulo 232, ou-exclusivo e rotac¸˜ ao circular de bits. Quanto maior o n´ umero de rodadas, mais complexa ´ e a revers˜ ao das operac¸ ˜ oes para recuperar a chave utilizada, chegando ` a seguranc¸a de 2256 tentativas, isto ´ e, forc¸a-bruta. O algoritmo ChaCha ´ e uma variac¸˜ ao do algoritmo Salsa20, vencedor da competic¸˜ ao eStream do NIST (National Institute of Standards and Technology) para padronizar um algoritmo de cifra de fluxo [Bernstein 2008]. Atualmente, n˜ ao h´ a um ataque de recuperac¸˜ ao de chave para 8 rodadas de processamento desses algoritmos que seja mais eficiente que forc¸a-bruta. Portanto, recomenda-se que a PRF utilizada no algoritmo ChaCha realize pelo menos 8 rodadas para gerac¸˜ ao do keystream. A quantidade de rodadas ´ e indicada ao final do nome do algoritmo, sendo uma vers˜ ao do ChaCha com 8 rodadas chamado de ChaCha8 e do Salsa20 de Salsa20/8. Assim como o Salsa20, s˜ ao padronizadas as vers˜ oes ChaCha8, ChaCha12 e ChaCha20. [Bernstein et al. 2008] A matriz de 16 elementos utilizada como entrada da PRF do algoritmo ChaCha ´ e processada de forma alternada a cada rodada entre colunas e diagonais da matriz. Na primeira rodada, os elementos das colunas da matriz s˜ ao inseridos em uma func¸˜ ao chamada “Quarter Round Function” (QR), onde o elemento de cada linha representa os buffers A, B, C e D, respectivamente. Esta func¸˜ ao realiza 12 operac¸ ˜ oes ARX nos elementos extra´ ıdos de cada coluna da matriz, conforme ilustrado na Figura 1. Figura 1. Ilustrac¸ ˜ ao da Quarter Round Function da cifra de fluxo ChaCha Visto que as colunas representam elementos independentes, os QRs s˜ ao executados de forma paralelizada. Uma rodada ´ e conclu´ ıda ap´ os aplicar a func¸˜ ao QR em cada coluna. Na pr´ oxima rodada, as mesmas func¸ ˜ oes QR s˜ ao aplicadas nas diagonais da matriz. Os QRs das diagonais tamb´ em s˜ ao calculadas de forma paralelizada. Ao fim do total de rodadas, os elementos da matriz resultante s˜ ao somados com os elementos da matriz inicial, produzindo um conjunto de bits pseudoaleat´ orios para cifrac¸˜ ao dos dados. O mesmo processo ´ e utilizado para a decifrac¸˜ ao, de forma que o mesmo conjunto de bits pseudoaleat´ orios sejam gerados. A Figura 2 ilustra esse processo para os algoritmos ChaCha e Forr´ o. Figura 2. Ilustrac¸ ˜ ao dos algoritmos de cifra de fluxo ChaCha e Forr´ o ´ E importante destacar que esses algoritmos n˜ ao garantem a autenticidade de origem, visto que um atacante pode obter o mesmo keystream realizando uma operac¸˜ ao XOR entre mensagem e texto cifrado, e ent˜ ao gerar um novo texto cifrado v´ alido. Para garantir a autenticidade de origem, um c´ odigo de autenticac¸˜ ao de mensagem (MAC) deve ser utilizado junto ao algoritmo de cifra de fluxo, como o algoritmo “Poly-1305” tamb´ em proposto por Bernstein [Bernstein 2005]. O algoritmo Forr´ o, uma variac¸˜ ao do algoritmo ChaCha, foi proposto por Coutinho de forma a torn´ a-lo mais resistente a ataques de criptoan´ alise diferencial. Este tipo de ataque busca correlac¸ ˜ oes entre os bits dos keystreams gerados a partir de cada chave utilizada, reduzindo a busca de prov´ aveis chaves utilizadas [Coutinho 2023]. O algoritmo Forr´ o alcanc¸a o mesmo n´ ıvel de seguranc¸a a esses ataques utilizando menos rodadas que o algoritmo ChaCha, tendo uma seguranc¸a de 2256 a partir de 6 rodadas. Com isso, s˜ ao recomendadas as vers˜ oes Forr´ o6, Forr´ o10 e Forr´ o14. O algoritmo Forr´ o´ e mais resistente a ataques de criptoan´ alise diferencial com menos rodadas devido a uma t´ ecnica chamada “polinizac¸˜ ao”. Nessa t´ ecnica, o QR atual recebe um parˆ ametro adicional (E) que ´ e obtido do QR anterior (o buffer A), tornando a execuc¸˜ ao de cada QR dependente do resultado do QR anterior. Embora isso aumente a difus˜ ao das modificac¸ ˜ oes atrav´ es da matriz e dificulte ataques de an´ alise diferencial, essa t´ ecnica tamb´ em torna a execuc¸˜ ao do algoritmo sequencial, visto que n˜ ao ´ e poss´ ıvel executar um QR sem o resultado do anterior. a Figura 3 ilustra o QR do algoritmo Forr´ o. Para reduzir o impacto no desempenho do algoritmo em decorrˆ encia da polinizac¸˜ ao, Coutinho propˆ os uma variac¸˜ ao do algoritmo chamada “Xote”. Nessa variac¸˜ ao, dois keystreams s˜ ao calculados paralelamente, de forma a cifrar conjuntos de 1 Kib ao inv´ es de apenas 512 bits [Coutinho et al. 2023]. A pr´ oxima sec¸˜ ao aborda a implementac¸˜ ao destes algoritmos em plano de dados Figura 3. Ilustrac¸ ˜ ao da Quarter Round Function da cifra de fluxo Forr ´ o program´ avel baseado na plataforma Tofino para processamento de pacotes. 4. Restric¸˜ oes de implementac¸˜ ao na plataforma Tofino A linguagem P4, desenvolvida para programac¸˜ ao de processadores de pacotes, possui diferenc¸as em comparac¸˜ ao a linguagens de programac¸˜ ao desenvolvidas para processadores de prop´ osito geral, trazendo novos desafios e novas t´ ecnicas para realizar o processamento de dados em PDP. Para implementar essas cifras de fluxo em plano de dados program´ avel, algumas restric¸ ˜ oes da plataforma devem ser consideradas. A plataforma Intel Tofino utilizada define uma arquitetura de processador de pacotes chamada “Tofino Native Architecture” (TNA), ilustrada na Figura 4. Essa arquitetura conta com 2 pipelines de processamento de pacotes (chamados “Ingress” e “Egress”), onde ´ e realizada a interpretac¸˜ ao (parser), modificac¸˜ ao e reconstruc¸˜ ao (deparser) dos cabec¸alhos dos pacotes para processamento. Cada pipeline possui 12 est´ agios de processamento que utilizam uma estrutura de match/action tables, onde buscas em tabelas (matches) decidem a operac¸˜ ao (action) realizada nos cabec¸alhos interpretados. Nessa estrutura, os registros das tabelas s˜ ao definidos pelo CP. Figura 4. ilustrac¸ ˜ ao da arquitetura TNA utilizada em switches Intel Tofino A linguagem P4, utilizada para programar o PDP da arquitetura TNA, n˜ ao possui suporte a lac¸os de repetic¸˜ ao, devendo os dados serem reinseridos no switch atrav´ es da recirculac¸˜ ao do pacote para continuar seu processamento. No entanto, essa recirculac¸˜ ao reduz a vaz˜ ao m´ axima alcanc¸´ avel pelo pacote. Para recirculac¸˜ ao de pacotes sem necessidade de uso das portas externas, a arquitetura TNA disponibiliza 2 portas internas no switch para recirculac¸˜ ao. Para realizar o parser dos cabec¸alhos, a arquitetura utiliza uma m´ aquina de estados finitos (finite state machine, FSM) que decide o pr´ oximo cabec¸alho a ser interpretado a partir de valores dos cabec¸alhos j´ a coletados. O parser do Ingress pipeline pode extrair at´ e 4 Kib, enquanto o parser do Egress pipeline pode extrair apenas 1280 bits, sendo que 192 bits s˜ ao utilizados em ambos pipelines para extrair metadados da arquitetura. Os dados que s˜ ao interpretados no parser s˜ ao inseridos no circuito de processamento do PDP em Packet Header Vectors (PHVs): registradores de 32, 16 e 8 bits presentes em cada est´ agio de processamento do pipeline. PHVs possuem restric¸ ˜ oes de alocac¸˜ ao de acordo com as poss´ ıveis operac¸ ˜ oes realizadas com eles. Por exemplo, dados podem ser particionados entre PHVs menores para alocac¸˜ ao (por exemplo, um dado de 32 bits pode ser dividido em 2 PHVs de 16 bits) e dados que n˜ ao s˜ ao operados na mesma travessia de um pipeline podem ser alocados no mesmo PHV. No entanto, dados que ser˜ ao rotacionados ou gravados com o resultado de operac¸ ˜ oes aritm´ eticas n˜ ao podem ser particionados entre PHVs, como as operac¸ ˜ oes ARX. 5. Trabalhos relacionados: algoritmos de cifra de fluxo em plano de dados program´ avel Para todas as implementac¸ ˜ oes citadas nessa sec¸˜ ao, um cabec¸alho de controle ´ e inclu´ ıdo ap´ os o cabec¸alho ethernet com seu conte´ udo variando de acordo com a implementac¸˜ ao espec´ ıfica, mas com ao menos um contador de rodadas processadas do algoritmo de cifra de fluxo. O conte´ udo a ser cifrado ´ e adicionado ap´ os o cabec¸alho de controle, devendo o comprimento do payload ser definido em tempo de compilac¸˜ ao pelo desenvolvedor. O algoritmo ChaCha foi implementado em plano de dados program´ avel (PDP) por Yoshinaka et al.. Nessa implementac¸˜ ao, o switch realiza a cifrac¸˜ ao ou decifrac¸˜ ao dos dados enviados em um quadro ethernet sem ethertype espec´ ıfico. Para a cifrac¸˜ ao, o switch gera um nonce aleat´ orio e o adiciona ap´ os o cabec¸alho de controle. J´ a para a decifrac¸˜ ao, ononce deve ser informado pelo emissor do pacote. O switch decide atrav´ es de uma flag no cabec¸alho de controle se o nonce deve ser gerado ou extra´ ıdo [Yoshinaka et al. 2022]. Essa implementac¸˜ ao exige que a chave de cifrac¸˜ ao e a quantidade de rodadas sejam definidas estaticamente no c´ odigo P4 compilado para o switch, n˜ ao sendo poss´ ıvel sua alterac¸˜ ao durante a operac¸˜ ao nem a definic¸˜ ao de uma chave para cada porta ou origem. Al´ em disso, o comprimento de 512 a 3072 bits (em intervalos de 512 bits) de dados a serem cifrados pelo switch tamb´ em ´ e definido em tempo de compilac¸˜ ao, devendo inserir os dados no payload do pacote com o padding realizado. O algoritmo Forr´ o14 foi implementado por Pierini et al. [Pierini et al. 2024]. Esta implementac¸˜ ao ´ e focada na cifrac¸˜ ao de 512 bits e ´ e aplic´ avel para o contexto de atestac¸˜ ao remota de dispositivos em redes de data centers. Portanto, n˜ ao s˜ ao utilizados outros tamanhos de conte´ udo para cifrac¸˜ ao. A implementac¸˜ ao requer que a chave, a quantidade de rodadas e o nonce sejam definidos estaticamente no c´ odigo. Portanto, n˜ ao ´ e feita a gerac¸˜ ao do nonce para cifrac¸˜ ao, mas isso torna a implementac¸˜ ao insegura para um cen´ ario real. 6. Implementac¸˜ ao do algoritmo Xote em PDP Nesse trabalho ´ e apresentada a implementac¸˜ ao do algoritmo “Xote” em PDP1. Para essa implementac¸˜ ao, a chave ´ e inserida em tempo de execuc¸˜ ao no switch, podendo ser definida uma chave por enderec¸o MAC de origem. O nonce a ser utilizado deve ser 1https://github.com/RPierini/p4-forro-regras/tree/xote informado entre o cabec¸alho ethernet e o conte´ udo a ser cifrado/decifrado, ficando a cargo do emissor a gerac¸˜ ao do nonce utilizado. O comprimento dos dados a serem cifrados ´ e fixado em 1 Kib, devendo ser inseridos pelo emissor com o padding realizado. Para a implementac¸˜ ao, o algoritmo foi dividido em 3 etapas: inicializac¸˜ ao, processamento e finalizac¸˜ ao. Na inicializac¸˜ ao, as matrizes de estado iniciais referentes ao primeiro e segundo conjunto de 512 bits s˜ ao carregadas com os parˆ ametros obtidos a partir de uma tabela indexada pelo enderec¸o MAC de origem. No processamento, um QR ´ e executado em cada matriz a cada travessia de pipeline. Considerando que cada rodada (r) do algoritmo ´ e composto de 4 QRs, s˜ ao necess´ arias 4r travessias para realizar o processamento de todas as rodadas, sendo o pacote recirculado a cada execuc¸˜ ao de um QR par (contado de 0 a 7) e ao final do processamento das rodadas. Na finalizac¸˜ ao, cada matriz ´ e somada elemento a elemento com seus respectivos valores iniciais. Ap´ os essa soma, o primeiro conjunto de 512 bits do payload ´ e cifrado utilizando a operac¸˜ ao de XOR com o resultado obtido. Devido ` a limitac¸˜ ao de alocac¸˜ ao de PHVs na arquitetura, a cifrac¸˜ ao do segundo conjunto de 512 bits precisa ser realizada no Ingress pipeline, implicando em outra recirculac¸˜ ao de pacote. Com as recirculac¸ ˜ oes para finalizac¸˜ ao e cifrac¸ ˜ oes, s˜ ao necess´ arias 4r+3 travessias e 2r+2 recirculac¸ ˜ oes de pacotes para toda execuc¸˜ ao do algoritmo, o que impacta a vaz˜ ao m´ axima obtida. A Figura 5 ilustra a disposic¸˜ ao do processamento do algoritmo nos pipelines da arquitetura TNA. Figura 5. Disposic¸ ˜ ao do processamento do algoritmo Xote na arquitetura TNA N˜ ao ´ e poss´ ıvel fazer a finalizac¸˜ ao das matrizes e a primeira cifrac¸˜ ao do payload no Egress pipeline devido ` a limitac¸˜ ao de extrac¸˜ ao de 1280 bits no Egress parser. Al´ em disso, considerando os tamanhos de cabec¸alhos: • 192 bits em metadados da arquitetura TNA; • 112 bits do cabec¸alho Ethernet; • 8 bits do cabec¸alho de controle; e • 64 bits do nonce escolhido pelo emissor do pacote; totalizando 376 bits, restam apenas 904 bits no Egress parser para realizar a extrac¸˜ ao de cabec¸alhos, impedindo que ambas matrizes de 512 bits sejam totalmente interpretadas devido ao deficit de 120 bits para extrac¸˜ ao. Isso impede que a ´ ultima linha da segunda matriz seja processada no Egress pipeline, inviabilizando o processamento de qualquer QR nesse pipeline. Para lidar com essa limitac¸˜ ao, foi desenvolvida uma t´ ecnica de reordenac¸˜ ao dos elementos das matrizes de estado, de forma que o parser sempre realize a interpretac¸˜ ao dos parˆ ametros do QR atual na primeira linha da matriz e os elementos do QR anterior na segunda linha. Esta abordagem traz complexidade ` a estruturac¸˜ ao do parser, mas viabiliza a implementac¸˜ ao do algoritmo e otimiza o uso de PHVs, visto que sempre s˜ ao processadas as mesmas posic¸ ˜ oes de elementos da matriz interpretada. Para clarificar, chamaremos a primeira matriz de estado de matriz “M” e a segunda matriz de estado de matriz “N”. Primeiro, as matrizes s˜ ao transpostas para que as colunas processadas nos QRs 0 a 3 se tornem linhas. As novas linhas ser˜ ao nomeadas de M0 aM3 eN0 aN3. Para possibilitar a extrac¸˜ ao de 3 linhas de ambas matrizes no Egress parser, as matrizes s˜ ao mescladas linha-a-linha. Por fim, as linhas s˜ ao reordenadas de forma que a primeira linha e o primeiro elemento da segunda linha representem os parˆ ametros utilizados como entrada no QR0. A Figura 6 ilustra essa organizac¸˜ ao das matrizes para iniciar o processamento dos QRs. Figura 6. Organizac¸ ˜ ao inicial das matrizes de estado para implementac¸ ˜ ao do algoritmo Xote em P4. Ao fim de cada QR, as linhas s˜ ao reorganizadas para que as mesmas posic¸ ˜ oes de elementos sejam extra´ ıdos no parser da pr´ oxima travessia. No caso do Egress pipeline, a´ ultima linha de cada matriz n˜ ao ´ e extra´ ıda, sendo copiadas na mesma posic¸˜ ao para o pr´ oximo QR e as demais linhas rotacionadas. A exemplo, ao fim do QR0 executado no Egress pipeline, as linhas M02 eN02, s˜ ao mantidas no fim da matriz, enquanto as linhas M0,N0,M3 eN3 s˜ ao movidas para o meio da matriz de forma que as linhas M1 eN1 a serem processadas no QR1 fiquem no in´ ıcio da matriz. No caso dos QRs 1 e 5 no Ingress pipeline,as linhas s˜ ao extra´ ıdas e reordenadas para serem preparadas para a pr´ oxima travessia no Egress pipeline. J´ a no caso dos QRs 3 e 7, os elementos s˜ ao extra´ ıdos individualmente para serem inteiramente reordenados, de forma que as linhas representem as diagonais (no caso do QR7) ou colunas (no caso do QR3) das matrizes originais. Para clarificar, as diagonais das matrizes originais transpostas em linhas s˜ ao nomeadas M4 aM7 eN4 aN7. A Figura 7 ilustra as reordenac¸ ˜ oes realizadas em cada QR para processamento das duas primeiras linhas extra´ ıdas de cada matriz em cada travessia.