PFC ULPGC – Aplicaciones Criptográficas Java ___________________________________________________________________ 4.El proyecto Desde el punto de vista de la seguridad, el conjunto de clases de seguridad distribuidas con el Java 2 SDK pueden dividirse en dos subconjuntos: clases relacionadas con el control de acceso, la gestión de permisos y las clases relacionadas con la criptografía. Java proporciona funciones criptográficas de propósito general, conocidas colectivamente como la Arquitectura Criptográfica de Java (JCA) y la Extension Criptográfica de Java (JCE). El JCA está formado por las clases básicas relacionadas con la criptografía y el soporte para la protección lo proporciona el paquete de extensión JCE. La librería JCA es un marco de trabajo para acceder y desarrollar funciones criptográficas en la plataforma Java. Se diseñó alrededor de dos principios básicos, la independencia e interoperabilidad de las implementaciones y la independencia y extensibilidad de los algoritmos. Las principales funciones criptográficas implementadas son: encriptar datos, desencriptar datos, encriptar claves, desencriptar claves, generar claves, generar otros parámetros, realizar conversiones entre distintas representaciones de los parámetros y de las claves, generar y verificar resúmenes de mensajes, códigos de autentificación de mensajes y firmas digitales. Sin embargo, utilizar la arquitectura criptográfica de Java (JCA) y su extensión (JCE) resulta demasiado complicado. Es por ello por lo que se ha decidido desarrollar una nueva librería criptográfica llamada JCEF (Java Cryptographic Extension Framework), en lugar de mostrar un conjunto de aplicaciones concretas de la criptografía. JCEF se soporta sobre JCA y JCE facilitando enormemente su uso. Esta nueva librería sería mayormente una fachada de las librerías JCA y JCE. El cliente de esta nueva librería sería el desarrollador de software que necesita usar sistemas criptográficos de seguridad con suma facilidad sin las complejidades inherentes a JCA y JCE. Ilustración 14: JCEF acerca la criptografía al usuario 45 PFC ULPGC – Aplicaciones Criptográficas Java A continuación se describirán las deficiencias encontradas y mejoradas en JCE (y JCA) y las mejoras realizadas por JCEF al mundo de la criptografía mediante Java. Y finalmente se muestran las mejoras que están pendientes de realizarse en futuras versiones de este proyecto. De esta forma, un usuario podrá decidir convenientemente cuál de las dos librerías debería usar. JCEF mejora enormemente a JCE. Las deficiencias de JCE que han sido mejoradas son: • JCE deja mucho que desear, puesto que la calidad de su código y diseño es baja. • Dificulta su uso y aprendizaje al utilizar términos poco comprensibles. • No proporciona al usuario un uso sencillo de sus funciones. • Generar autentificadores es complicado al igual que su verificación, principalmente de huellas y sellos digitales al exigir que el usuario conozca cómo se verifican autentificadores como las huellas, sellos o firmas digitales. • La protección y desprotección es muy complicada de utilizar. • Los algoritmos hay que inicializarlos de una forma anticuada y engorrosa. • Los parámetros se generan y gestionan de una forma nada sencilla. • JCE no permite construir objetos seguros para cualquier algoritmo criptográfico. • No reconstruye automáticamente las operaciones tras un cambio. • Proporciona un modo de operación muy particular para cada algoritmo criptográfico. • Finalmente, para terminar con la paciencia de cualquier usuario, la gestión de los proveedores es complicada y desgraciadamente necesaria. • Los algoritmos JCE no se pueden configurar en tiempo de ejecución ni tampoco se puede probar su funcionamiento con facilidad. • Para definir algoritmos se utilizan clases diferentes a las que se usan en la utilización de los algoritmos. En definitiva, utilizar JCE requiere un gran esfuerzo en tiempo y dedicación al usuario del mismo. Sin embargo, JCEF proporciona los siguientes valores añadidos: • Proporciona una serie de mejoras muy significativas. • Vale la pena usarlo, es amigable y fácil de utilizar. • Se aprende de forma intuitiva y no requiere demasiado tiempo de aprendizaje. • No se cometen errores fácilmente y no requiere grandes conocimientos técnicos. • Evita el uso de conceptos técnicos, y además, su diseño y código son de mayor calidad. • Simplifica enormemente la autentificación, haciéndola sencilla y homogénea, tanto la generación como verificación de huellas, sellos y firmas digitales; por lo que la autentificación se aprende de forma más sencilla y rápida. • Proporciona un uso sencillo de los algoritmos, además de hacer que éstos sean reutilizables. 46 PFC ULPGC – Aplicaciones Criptográficas Java • Suministra una jerarquía de objetos muy completa. • Permite seleccionar los algoritmos de una forma muy sencilla. • La inicialización de los algoritmos es infinitamente más sencilla. • Proporciona adaptaciones de proveedores criptográficos ya existentes que cumplen con la especificación JCE o no. Incluso permite definir fácilmente nuevos algoritmos con especificación JCEF. • Permite de forma sencilla obtener información completa de inicialización y de configuración. • Proporciona gestión adeacuada de los parámetros de inicialización y configuración. • Permite cambiar fácilmente de algoritmo y de implementación. • Para reducir la dificultad, las operaciones de bajo nivel son automáticas, transparentes y sencillas, de esta forma es innecesario realizar un sinfín de operaciones como por ejemplo la encapsulación y desencapsulación de claves. • Los algoritmos aceptan los parámetros en cualquiera de sus formas con el objetivo de mejorar la usabilidad. • Aún hay más, JCEF potencia la creación de proveedores criptográficos personalizados. • Se generan de forma automática todos los parámetros de los algoritmos. • Para continuar simplificando, es posible evitar la realización de ciertas operaciones. • Es innecesario conocer los algoritmos secundarios de los algoritmos criptográficos. • Con JCEF, no hace falta tener conocimientos importantes. • Proporciona mecanismos para la definición de algoritmos criptográficos compuestos. • Permite construir objetos seguros de forma sencilla. • La implementación y el algoritmo poseen la misma especificación. • Proporciona un marco sencillo para pruebas de funcionalidad e implementación. • Recopila una gran cantidad de algoritmos criptográficos y proveedores. Por desgracia, JCEF no es perfecto y todavía puede y debe seguir creciendo. Algunas de las posibles mejoras que se le pueden hacer son: • Proporcionar todas aquellas características que JCE proporciona y JCEF no, tales como los flujos de entrada/salida seguros, gestión de certificados digitales, almacenes seguros, protocolos de intercambio de claves, etc... • Implementar flujos de entrada/salida seguros de forma sencilla para cualquier algoritmo criptográfico. • Proporcionar algunos aspectos avanzados, tales como almacenes seguros para cualquier tipo de objetos incluyendo claves y certificados. • Permitir gestionar certificados de una manera muy sencilla. 47 PFC ULPGC – Aplicaciones Criptográficas Java • Proporcionar sencillos mecanismos para los protocolos de intercambio de claves. • Mejorar la gestión de los modos de operación y los esquemas de relleno en los algoritmos criptográficos de protección ya existentes. • Verificar el correcto funcionamiento de todos los algoritmos criptográficos a través del uso de vectores de tests y corregir aquellos incorrectos. • Comprobar el correcto funcionamiento de las pruebas de implementación. • Terminar de implementar los algoritmos compuestos, probarlos y añadir a todos los proveedores JCEF existentes nuevos algoritmos compuestos reutilizando sus algoritmos criptográficos. • Comprobar el correcto funcionamiento de algunos detalles de las implementaciones JCEF. • Reducir la dependencia con otros proyectos. • Aumentar el nivel de confianza de este proyecto. • Implementar algoritmos nuevos no implementados hasta ahora en Java. Como un ejemplo del valor añadido de este proyecto, observe el código siguiente donde se muestra cómo se asegura un objeto e inmediatamente después se recupera el mismo; y todo ello de una forma super sencilla: Object object = new String("my object"); CryptoAlgorithm secureAlgorithm = new AES_BlockSymmetricProtectionRREXKY(); SecureObject secureObject = new SecureObject(object, secureAlgorithm); object = (String)secureObject.getObject(secureAlgorithm); Tabla 35: Pequeño ejemplo de uno de los valores añadidos de JCEF En las próximas secciones podrán encontrarse más detalles sobre las deficiencias, mejoras realizadas y pendientes y otros detalles del proyecto como parte de su valor añadido, comparativa con lo que había antes (JCA-JCE), detalles de implementación, presentación, distribuciones, etc... Si lo desea, también puede consultar la página web oficial del proyecto http://jcef.sourceforge.net y los recursos utilizados http://jcef.sourceforge.net/doc/resources.pdf. 48 PFC ULPGC – Aplicaciones Criptográficas Java 1 Deficiencias mejoradas JCE deja mucho que desear puesto que: • La calidad de su código es baja. • Dificulta su uso y aprendizaje. • Se utilizan términos poco comprensibles. • Su uso es muy complejo. • La generación y verificación de autentificadores es complicada. La calidad del código es baja, ya que: • Complica el mantenimiento del código. • Dificulta su reutilización. • Complica el código volviéndolo incomprensible. • Complica la accesibilidad del código volviéndolo cerrado. • Se desconoce si su funcionamiento
Serpent: a Proposal for the Advanced Encryption Standard
Serpent: A Proposal for the Advanced Encryption Standard Ross Anderson1 Eli Biham2 Lars Knudsen3 1 Cambridge University, England; email rja14@cl.cam.ac.uk 2 Technion, Haifa, Israel; email biham@cs.technion.ac.il 3 University of Bergen, Norway; email lars.knudsen@ii.uib.no Abstract. We propose a new block cipher as a candidate for the Ad- vanced Encryption Standard. Its design is highly conservative, yet still allows a very efficient implementation. It uses S-boxes similar to those of DES in a new structure that simultaneously allows a more rapid avalanche, a more efficient bitslice implementation, and an easy anal- ysis that enables us to demonstrate its security against all known types of attack. With a 128-bit block size and a 256-bit key, it is as fast as DES on the market leading Intel Pentium/MMX platforms (and at least as fast on many others); yet we believe it to be more secure than three-key triple-DES. 1 Introduction For many applications, the Data Encryption Standard algorithm is nearing the end of its useful life. Its 56-bit key is too small, as shown by a recent distributed key search exercise [28]. Although triple-DES can solve the key length problem, the DES algorithm was also designed primarily for hardware encryption, yet the great majority of applications that use it today implement it in software, where it is relatively inefficient. For these reasons, the US National Institute of Standards and Technology has issued a call for a successor algorithm, to be called the Advanced Encryption Standard or AES.
Data Encryption Standard The Data Encryption Standard (DES /ˌdiːˌiːˈɛs, dɛz/) is a Data Encryption Standard symmetric-key algorithm for the encryption of electronic data. Although insecure, it was highly influential in the advancement of modern cryptography. Developed in the early 1970s atIBM and based on an earlier design by Horst Feistel, the algorithm was submitted to the National Bureau of Standards (NBS) following the agency's invitation to propose a candidate for the protection of sensitive, unclassified electronic government data. In 1976, after consultation with theNational Security Agency (NSA), the NBS eventually selected a slightly modified version (strengthened against differential cryptanalysis, but weakened against brute-force attacks), which was published as an official Federal Information Processing Standard (FIPS) for the United States in 1977. The publication of an NSA-approved encryption standard simultaneously resulted in its quick international adoption and widespread academic scrutiny. Controversies arose out of classified The Feistel function (F function) of DES design elements, a relatively short key length of the symmetric-key General block cipher design, and the involvement of the NSA, nourishing Designers IBM suspicions about a backdoor. Today it is known that the S-boxes that had raised those suspicions were in fact designed by the NSA to First 1975 (Federal Register) actually remove a backdoor they secretly knew (differential published (standardized in January 1977) cryptanalysis). However, the NSA also ensured that the key size was Derived Lucifer drastically reduced such that they could break it by brute force from [2] attack. The intense academic scrutiny the algorithm received over Successors Triple DES, G-DES, DES-X, time led to the modern understanding of block ciphers and their LOKI89, ICE cryptanalysis.
An Efficient VHDL Description and Hardware Implementation of The
An Efficient VHDL Description and Hardware Implementation of the Triple DES Algorithm A thesis submitted to the Graduate School of the University of Cincinnati In partial fulfillment of the requirements for the degree of Master of Science In the Department of Electrical and Computer Engineering Of the College of Engineering and Applied Sciences June 2014 By Lathika SriDatha Namburi B.Tech, Electronics and Communications Engineering, Jawaharlal Nehru Technological University, Hyderabad, India, 2011 Thesis Advisor and Committee Chair: Dr. Carla Purdy ABSTRACT Data transfer is becoming more and more essential these days with applications ranging from everyday social networking to important banking transactions. The data that is being sent or received shouldn’t be in its original form but must be coded to avoid the risk of eavesdropping. A number of algorithms to encrypt and decrypt the data are available depending on the level of security to be achieved. Many of these algorithms require special hardware which makes them expensive for applications which require a low to medium level of data security. FPGAs are a cost effective way to implement such algorithms. We briefly survey several encryption/decryption algorithms and then focus on one of these, the Triple DES. This algorithm is currently used in the electronic payment industry as well as in applications such as Microsoft OneNote, Microsoft Outlook and Microsoft system center configuration manager to password protect user content and data. We implement the algorithm in a Hardware Description Language, specifically VHDL and deploy it on an Altera DE1 board which uses a NIOS II soft core processor. The algorithm takes input encoded using a software based Huffman encoding to reduce its redundancy and compress the data.
Differential Cryptanalysis of the Data Encryption Standard
Differential Cryptanalysis of the Data Encryption Standard Eli Biham1 Adi Shamir2 December 7, 2009 1Computer Science Department, Technion – Israel Institute of Technology, Haifa 32000, Israel. Email: biham@cs.technion.ac.il, WWW: http://www.cs.technion.ac.il/˜biham/. 2Department of Applied Mathematics and Computer Science, The Weizmann Institute of Science, Rehovot 76100, Israel. Email: shamir@wisdom.weizmann.ac.il. This versionofthebookisprocessedfromtheauthor’soriginalLaTeXfiles,andmaybe differentlypaginatedthantheprintedbookbySpringer(1993). Copyright:EliBihamandAdiShamir. Preface The security of iterated cryptosystems and hash functions has been an active research area for many years. The best known and most widely used function of this type is the Data Encryption Standard (DES). It was developed at IBM and adopted by the National Bureau of Standards in the mid 70’s, and has successfully withstood all the attacks published so far in the open literature. Since the introduction of DES, many other iterated cryptosystems were developed, but their design and analysis were based on ad-hoc heuristic arguments, with no theoretical justification. In this book, we develop a new type of cryptanalytic attack which can be successfully applied to many iterated cryptosystems and hash functions. It is primarily a chosen plaintext attack but under certain circumstances, it can also be applied as a known plaintext attack. We call it “differen- tial cryptanalysis”, since it analyzes the evolution of differences when two related plaintexts are encrypted under the same key. Differential cryptanalysis is the first published attack which is capable of breaking the full 16-round DES in less than 255 complexity. The data analysis phase computes the key by analyzing about 236 ciphertexts in 237 time.
Obsah - horní část dokumentu Obsah Shannonův model kryptosystému ..................................................................................... 6 Kerchhoffův princip .......................................................................................................... 6 Kategorie útoků na kryptosystém ..................................................................................... 7 Kryptoanalýza ................................................................................................................... 7 Základní rozdělení šifer ..................................................................................................... 8 Vernamova šifra ............................................................................................................... 9 Teorie informace .............................................................................................................. 9 - entropie jazyka, krytptosystému ................................................................................ 10 - redundance ............................................................................................................... 10 - jednotkový odstup .................................................................................................... 11 Teorie složitosti .............................................................................................................. 11 - klasifikace problémů, třídy složitosti .......................................................................... 11 - vztah mezi třídami
Differential Cryptanalysis C¸etin Kaya Ko¸c Oregon State University 1 Differential cryptanalysis is a method for breaking certain classes of cryptosystems It was invented in 1990 by Israeli researchers Eli Biham and Adi Shamir However, apparently the IBM researchers who designed DES knew about differential crypt- analysis, as was indicated by Don Copper- smith of TJ Watson Research Center 2 Differential cryptanalysis is efficient when the cryptanalyst can choose plaintexts and obtain ciphertexts (chosen plaintext cryptanalysis) The known plaintext differential cryptanalysis is also possible, however, often the size of the known text pairs is very large The method searches for plaintext, ciphertext pairs whose difference is constant, and inves- tigates the differential behavior of the cryp- tosystem The difference of two elements P1 and P2 is defined as P1 ⊕ P2 (bit-wise XOR operation) for DES The difference may be defined differently if the method is applied to some other cryptosystem 3 Differential cryptanalysis is applicable to the iterated ciphers with a weak round function (so-called Feistel ciphers) The summary of the technique: • Observe the difference between the two ci- phertexts as a function of the difference between the corresponding plaintexts • Find the highest probability differential in- put (called characteristic) which can be traced through several rounds • Assign probabilities to the keys and locate the most probable key 4 Notation • P denotes plaintext, T denotes ciphertext • (P, P ∗)isapair of plaintexts which XOR to a specific value P , i.e., P = P ⊕ P ∗ • (T,T∗)isapair of ciphertexts which XOR to a specific value T , i.e., T = T ⊕ T ∗ • Primed values are always differential: P , T , a, A, etc.
A Related Key Attack on the Feistel Type Block Ciphers
International Journal of Network Security, Vol.8, No.3, PP.221{226, May 2009 221 A Related Key Attack on the Feistel Type Block Ciphers Ali Bagherzandi1;2, Mahmoud Salmasizadeh2, and Javad Mohajeri2 (Corresponding author: Ali Bagherzandi) Computer Engineering Department, Sharif University of Technology1 Electronic Research Center, Sharif University of Technology2 P. O. Box 11155-8639 Azadi Avenue 14588 Tehran, Iran (Email: bagherzandi@ce.sharif.edu) (Received Jan. 3, 2006; revised and accepted Mar. 3, 2006) Abstract related-key attacks. In order to strengthen DES, several extensions have In this paper we show that Biham's chosen key attack can been developed including Triple-DES, DES-X, Biham- be generalized to include any block cipher and we give a DES, DES-X and NewDES. These extensions improved low complexity chosen key attack on any Feistel type ci- the resistance of DES against exhaustive search, linear pher. Then we show that the irregularities in the shift cryptanalysis and di®erential cryptanalysis; but not any pattern of DES key schedule algorithm is not su±cient signi¯cant improvement has been gained against related- for the cryptosystem to resist against related key attacks. key attacks and several related-key cryptanalysis have We have realized our proposition by a counter example been developed against these extensions [8, 9]. Even in in which the E-box of DES is slightly modi¯ed whiles the case of DES-X there has been introduced some novel other components and among those, the shift pattern in key related attacks [9]. It is believed that the irregularities key schedule algorithm is kept unchanged.
Joan Daemen Vincent Rijmen Note on naming Rijndael Note on naming 1. Introduction After the selection of Rijndael as the AES, it was decided to change the names of some of its component functions in order to improve the readability of the standard. However, we see that many recent publications on Rijndael and the AES still use the old names, mainly because the original submission documents using the old names, are still available on the Internet. In this note we repeat quickly the new names for the component functions. Additionally, we remind the reader on the difference between AES and Rijndael and present an overview of the most important references for Rijndael and the AES. 2. References [1] Joan Daemen and Vincent Rijmen, AES submission document on Rijndael, June 1998. [2] Joan Daemen and Vincent Rijmen, AES submission document on Rijndael, Version 2, September 1999. http://csrc.nist.gov/CryptoToolkit/aes/rijndael/Rijndael.pdf [3] FIPS PUB 197, Advanced Encryption Standard (AES), National Institute of Standards and Technology, U.S. Department of Commerce, November 2001. http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf [4] Joan Daemen and Vincent Rijmen, The Design of Rijndael, AES - The Advanced Encryption Standard, Springer-Verlag 2002 (238 pp.) 3. Naming The names of the component functions of Rijndael have been modified between the publication of [2] and that of [3]. Table 1 lists the two versions of names. We recommend using the new names. Old naming New naming ByteSub SubBytes ShiftRow ShiftRows MixColumn MixColumns AddRoundKey AddRoundKey Table 1: Old and new names of the Rijndael component functions 4.
Iterative Characteristics of DES and 2 s -DES Lars Ramkilde Knudsen Aarhus University Computer Science Department Ny Munkegade DK-8000 Aarhus C. Abstract. In this pap er we show that we are close at the pro of that the typ e of characteristics used by Biham and Shamir in their di erential attack on DES [3] are in fact the b est characteristics we can nd for DES. Furthermore we show that the criteria for the construction of DES-like S-b oxes prop osed by Kim [6] are insucient to assure resistance against di erential attacks. We show several go o d iterativecharacteristics for these S-b oxes to b e used in di erential attacks. Finally we examine the probabiliti es of the twocharacteristics used by Biham and Shamir in [3]. We found that for some keys we do not get the probabiliti es used in the attack. We suggest the use of 5 characteristics instead of two in the attack on DES. 1 Intro duction In 1990 Eli Biham and Adi Shamir intro duced di erential cryptanalysis,achosen plaintext attack on blo ck ciphers that are based on iterating a cryptographically weak function r times e.g. the 16-round Data Encryption Standard DES. The metho d proved strong enough to break several cryptosystems, Lucifer, GDES, Feal-4, Feal-8, Snefru a.o. and DES with a reduced numb er of rounds, i.e. less than 16 rounds [1, 2, 4]. In decemb er 1991 Biham and Shamir published an improved di erential attack 47 that is capable of breaking the full 16-round DES [3].