DOCSLIB.ORG

Comparison of SSL/TLS Libraries Based on Algorithms/Languages Supported, Platform, Protocols and Performance

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Comparison of SSL/TLS Libraries Based on Algorithms/Languages Supported, Platform, Protocols and Performance Comparison of SSL/TLS libraries based on Algorithms/languages supported, Platform, Protocols and Performance By Akshay Thorat Table of Contents TLS - Why is it needed ? Introduction- SSL/TLS evolution Libraries Studied Comparison Library to Implementation Supported Features Algorithm/Ciphers Supported Performance for libraries Conclusion Transport Layer Security(TLS), why is it needed ? Communication security on internet Secure - Email, VOIP, Web browsing, Bank transactions Provides Privacy and Integrity of data Prevent Eavesdropping and Tampering Introduction Application protocol independent TLS versions (Implementations) evolved as SSL1.0->SSL2.0->SSL3.0 ->TLS1.0->TLS1.1->TLS1.2->TLS1.3 (draft) Less Secure Each suite contains authentication, message authentication code (MAC), key exchange and encryption algorithms Datagram TLS (DTLS) – TLS with packet lost and reordering implementation DTLS1.0 and DTLS 1.2 Libraries Under Consideration Primary OpenSSL - Robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) GnuTLS – Portable ANSI C based library with Lesser General Public license (GPL) Other Network Security Services (NSS) - Library designed to support cross- platform development of security-enabled client and server applications Cryptlib - Open source cross-platform software security toolkit library for SSL/TLS and SSH secure sessions, CA services Library to Implementation comparison Library SSL3.0 TLS1.0 TLS1.1 TLS1.2 TLS1.3 DTLS1.0 DTLS1.2 OpenSSL Yes Yes Yes Yes Yes Yes Yes GnuTLS Yes Yes Yes Yes No Yes Yes NSS Yes Yes Yes Yes Yes Yes Yes Cryptlib Yes Yes Yes Yes No No No General Comparison OpenSSL GnuTLS NSS Languages C C C or C++ Cryptographic Token Not Present natively * Present Present Interface- PKCS #11 Thread safety Two callback function Use POSIX or Yes with POSIX or Win Win Thread Threads CPU Assisted Crypt. Yes Yes (+VIA Yes With AES-NI Padlocks) Languages Cryptographic Token Interface - Hardware security module Platform independent API for Hardware Security Modules (HSM) and smart cards Thread Safety – Safe shared data manipulation CPU assisted Cryptography – Use of hardware acceleration for cryptographic functions with supported instruction set *engine needs to be added externally through patch Performance Comparisons Criteria Literature survey of Speedtest and Comparison of Open-Source Cryptography Libraries by Timo Bingmann Public key performance results for NSS Installing OpenSSL and running hashing algorithms Installing GnuTLS and running benchmarking for hashes/ciphers OpenSSL and GnuTLS Comparison Each speed test consists of one encryption pass directly followed by a decryption pass Ciphers Tested OpenSSL - AES, Blowfish,CAST5,3DES, XTEA GnuTLS – AES, Blowfish, CAST5,3DES, Serpent, Twofish Average of KB of data processed per unit time with different distributions Throughput KB/s 35,000 30,000 25,000 20,000 15,000 10,000 5,000 0 Ubuntu-hardy Debian-lenny Ubuntu-Gutsy Fedora8 Debian-etch GnuTLS OpenSSL Problems Ciphers compared are not same – average values could have been shifted Varying Buffer size values were calculated and only ran once – should have ran multiple times until results avg. out Only Symmetric ciphers are tested NSS The SSL_RSA_WITH_RC4_128_MD5 (SSL3) cipher is used Restart runs utilize cache which results in higher throughput Full runs handshake every connection which introduce overhead Type Ops/sec CPU-usage(%) Full 156.23 95 Full-zones 216.55 100 Restart 220.76 90 Restart-zones 569.82 86 Throughput and CPU usage 600 500 400 300 200 100 0 Full Full-zones Restart Restart-zones Throughput (Ops/sec) CPU-usage(%) CPU utilization is near about same for each run So varying throughput is a function of Memory access speed Depending the use of cache, throughput can be vastly increased Performance Tests Comparison based OS running natively vs in Virtual machine Libraries compared – OpenSSL and GnuTLS Native machine and VM both are running equal environments Ubuntu 16.04 CPU – Intel core i5 – 2.20GHz RAM – 4GB Disk – 25GB OpenSSL Throughput (KB/s) Comparison 350000 300000 250000 200000 150000 100000 50000 0 1 10 100 1000 10000 Buffer Size (Bytes) Native VM SHA256 with varying buffer size (16,64,256,1024,8192 Bytes) Buffer size above 1000 bytes, starts to saturate throughput – 330MB/s In VM, low throughput is observed because of overhead of running inside VM After increasing buffer value by certain value bottleneck can occur GnuTLS Throughput KB/s 700000 600000 500000 400000 300000 200000 100000 0 SHA1 SHA256 SHA512 Native VM Hashing algorithms checked for fixed payload size (16384 bytes) MACs - SHA1, SHA256,SHA512 Throughput around 300MB/s In VM low throughput Conclusion Best library ? Depends on criteria Higher Throughput and simple – OpenSSL (32MB/s) Portable and lightweight - GnuTLS Cross Platform support – NSS License compatibility - Apache License (used by OpenSSL) are incompatible with the GPL, GnuTLS or NSS Novice TLS developer – OpenSSL Wide Support Simple to use Single platform and no compatibility required Thank You ! References [1] Timo Bingmann,(14th July 2008), Speedtest and Comparison of Open-Source Cryptography Libraries and Compiler Flags, [online]. Available: https://panthema.net/2008/0714-cryptography-speedtest-comparison/ [2] OpenWrt Oraganisation (n.d). OpenSSL Benchmarks tool. [online]. Availble: https://wiki.openwrt.org/doc/howto/benchmark.openssl [3] GNU TLS, Transport Layer Security Library for the GNU system, for version 2.0.2, 17 October 2007. Available: http://ports.gnu-darwin.org/security/gnutls/work/gnutls- 2.0.2/doc/gnutls.pdf [4] Mozilla Developer Network. Network Security Services. Available: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS#Documentation . Accessed: Sep. 8,2017. .
Load more

Recommended publications
  • Effective Cryptography What’S Wrong with All These Crypto Apis?
    Effective Cryptography What’s Wrong With All These Crypto APIs? Thorsten Groetker, CTO Utimaco, Inc. Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 1 Outline § What I mean by Effective Cryptography § Crypto APIs § Security § Ease of Use § Runtime Performance § Predictions § CryptoScript in a Nutshell § Outlook Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 2 Effective Cryptography Definition in a Nutshell Cryptography is effective if it is Li lingues es membres del sam familie. Lor separat existentie es 1. Secure unJCE/JCA myth. Por scientie, musica , sport etc, litot li sam vocabular. Li lingues differe solmen in li grammaticaOpenSSL, li pronunciation e li pluEVP commun vocabules. Omnicos directe al desirabilite de un nov lingua franca: On refusa continuar payar custosi traductores. At solmen va esser necessi 2. Efficient far uniform grammaticaPKCS#11, pronunciation e plu sommun paroles. Ma quande lingues coalesce, li grammatica del resultant lingue es plu CAPIsimplic e regulari quam ti del coalescent lingues. Li nov lingua CNG a. Time to Result franca va esser plu simplic e regulari quam li existent Bouncy linguesCastle. I b. Performance What’s wrong with all these crypto APIs? (Focused on Hardware Security Modules) Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 3 Problem #1: Security PKCS#11 § Numerous key extraction attacks known § Jolyon Clulow “On the Security of PKCS#11” § Tookan project (e.g., “Attacking and Fixing PKCS#11 Security Tokens”) § CVE entries (not necessarily sporting “PKCS#11” in the text)
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Libressl Presentatie2
    Birth of LibreSSL and its current status Frank Timmers Consutant, Snow B.V. Background What is LibreSSL • A fork of OpenSSL 1.0.1g • Being worked on extensively by a number of OpenBSD developers What is OpenSSL • OpenSSL is an open source SSL/TLS crypto library • Currently the de facto standard for many servers and clients • Used for securing http, smtp, imap and many others Alternatives • Netscape Security Services (NSS) • BoringSSL • GnuTLS What is Heartbleed • Heartbleed was a bug leaking of private data (keys) from both client and server • At this moment known as “the worst bug ever” • Heartbeat code for DTLS over UDP • So why was this also included in the TCP code? • Not the reason to create a fork Why did this happen • Nobody looked • Or at least didn’t admit they looked Why did nobody look • The code is horrible • Those who did look, quickly looked away and hoped upstream could deal with it Why was the code so horrible • Buggy re-implementations of standard libc functions like random() and malloc() • Forces all platforms to use these buggy implementations • Nested #ifdef, #ifndefs (up to 17 layers deep) through out the code • Written in “OpenSSL C”, basically their own dialect • Everything on by default Why was it so horrible? crypto_malloc • Never frees memory (Tools like Valgrind, Coverity can’t spot bugs) • Used LIFO recycling (Use after free?) • Included debug malloc by default, logging private data • Included the ability to replace malloc/free at runtime #ifdef trees • #ifdef, #elif, #else trees up to 17 layers deep • Throughout the complete source • Some of which could never be reached • Hard to see what is or not compiled in 1.
    [Show full text]
  • Hannes Tschofenig
    Securing IoT applications with Mbed TLS Hannes Tschofenig Part#2: Public Key-based authentication March 2018 © 2018 Arm Limited Munich Agenda • For Part #2 of the webinar we are moving from Pre-Shared Secrets (PSKs) to certificated-based authentication. • TLS-PSK ciphersuites have • great performance, • low overhead, • small code size. • Drawback is the shared key concept. • Public key cryptography was invented to deal with this drawback (but itself has drawbacks). 2 © 2018 Arm Limited Public Key Infrastructure and certificate configuration © 2018 Arm Limited Public Key Infrastructure Various PKI deployments in existence Structure of our PKI The client has to store: self-signed • Client certificate plus corresponding private key. CA cert • CA certificate, which serves as the trust anchor. The server has to store: Signed by CA Signed by CA • Server certificate plus corresponding private key. Client cert Server cert (Some information for authenticating the client) 4 © 2018 Arm Limited Generating certificates (using OpenSSL tools) • When generating certificates you will be prompted to enter info. You are about to be asked to enter information that will be • The CA cert will end up in the trust incorporated into your certificate request. What you are about to enter is what is called a Distinguished anchor store of the client. Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, • The Common Name used in the server If you enter '.', the field will be left blank. ----- cert needs to be resolvable via DNS Country Name (2 letter code) [AU]:.
    [Show full text]
  • Notices Openssl/Open SSL Project
    Notices The following notices pertain to this software license. OpenSSL/Open SSL Project This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young ([email protected]). This product includes software written by Tim Hudson ([email protected]). License Issues The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact [email protected]. OpenSSL License: Copyright © 1998-2007 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)”. 4. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].
    [Show full text]
  • Black-Box Security Analysis of State Machine Implementations Joeri De Ruiter
    Black-box security analysis of state machine implementations Joeri de Ruiter 18-03-2019 Agenda 1. Why are state machines interesting? 2. How do we know that the state machine is implemented correctly? 3. What can go wrong if the implementation is incorrect? What are state machines? • Almost every protocol includes some kind of state • State machine is a model of the different states and the transitions between them • When receiving a messages, given the current state: • Decide what action to perform • Which message to respond with • Which state to go the next Why are state machines interesting? • State machines play a very important role in security protocols • For example: • Is the user authenticated? • Did we agree on keys? And if so, which keys? • Are we encrypting our traffic? • Every implementation of a protocol has to include the corresponding state machine • Mistakes can lead to serious security issues! State machine example Confirm transaction Verify PIN 0000 Failed Init Failed Verify PIN 1234 OK Verified Confirm transaction OK State machines in specifications • Often specifications do not explicitly contain a state machine • Mainly explained in lots of prose • Focus usually on happy flow • What to do if protocol flow deviates from this? Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
    [Show full text]
  • Securing Mysql with a Focus on SSL
    Securing MySQL! With a Focus on SSL http://www.yassl.com (206) 369-4800 About Me Chris Conlon So#ware Developer at yaSSL Bozeman, MT © Copyright 2011 FishEyeGuyPhotography © Copyright 2011 yaSSL SSL Statistics Ivan Ristic: Internet SSL Survey 2010 http://www.ssllabs.com SSL Survey 2010 Valid SSL – 0.42% •" Sample of 119 Million Domain Names 0.60%, Certificate Name Matches 0.42%, Counting only valid ones Alexa Top 1M •" Alexa Top 1M Sites Use SSL – 12% 120,000 Use SSL (12%) © Copyright 2011 yaSSL Presentation Outline Part I: MySQL Security 1." Common Attacks & Vulnerabilities 2." Good Security Practices for MySQL Part II: SSL/TLS 1." Overview of SSL and TLS 2." Configuring and Building MySQL with SSL 3." MySQL SSL Command Options 4." SSL Certificate Creation 5." Performance Comparison Part III: Additional Security Concerns 1." Data Storage and Encryption Part IV: Wrap-Up 1." Licensing 2." yaSSL 3." Conclusion © Copyright 2011 yaSSL MySQL Updates Part I Account Passwords Test Databases mysqld MySQL Security Privileges © Copyright 2011 yaSSL Common Attacks and Vulnerabilities Do we really need to secure our MySQL database? YES! MySQL is Susceptible to Many Attacks: - Basic Attacks (empty password, etc.) - SQL Injection Attacks - Known MySQL Bugs and Vulnerabilities - Trojanning MySQL © Copyright 2011 yaSSL Good Security Practices for MySQL A. Keeping MySQL Version Up to Date An easy way to stay better protected: - New MySQL Patches, Bug Fixes, etc. - You should take advantage of updates © Copyright 2011 yaSSL Good Security Practices for MySQL 'MySQL' Vulnerabili1es By Year cvedetails.com (nvd.nist.gov) 16 2000 14 2001 2002 11 2003 10 2004 9 2005 8 2006 7 2007 6 6 6 2008 5 2009 3 2010 2011 © Copyright 2011 yaSSL Good Security Practices for MySQL •" yaSSL Vulnerabilities affecting MySQL in the past: CVE-2005-3731 Certificate Chain Processing CVE-2008-0227 Denial of Service (crash) CVE-2008-0226 Allowed Execution of Arbitrary Code CVE-2009-4484 Allowed Execution of Arbitrary Code, Denial of Service Possible © Copyright 2011 yaSSL Good Security Practices for MySQL B.
    [Show full text]
  • Vetting SSL Usage in Applications with SSLINT
    2015 IEEE Symposium on Security and Privacy Vetting SSL Usage in Applications with SSLINT Boyuan He1, Vaibhav Rastogi2, Yinzhi Cao3, Yan Chen2, V.N. Venkatakrishnan4, Runqing Yang1, and Zhenrui Zhang1 1Zhejiang University 2Northwestern University 3Columbia University 4University of Illinois, Chicago [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Abstract—Secure Sockets Layer (SSL) and Transport Layer In particular, we ask the following research question: Is it Security (TLS) protocols have become the security backbone of possible to design scalable techniques that detect incorrect use the Web and Internet today. Many systems including mobile of APIs in applications using SSL/TLS libraries? This question and desktop applications are protected by SSL/TLS protocols against network attacks. However, many vulnerabilities caused poses the following challenges: by incorrect use of SSL/TLS APIs have been uncovered in recent • Defining and representing correct use. Given an SSL years. Such vulnerabilities, many of which are caused due to poor library, how do we model correct use of the API to API design and inexperience of application developers, often lead to confidential data leakage or man-in-the-middle attacks. In this facilitate detection? paper, to guarantee code quality and logic correctness of SSL/TLS • Analysis techniques for incorrect usage in software. applications, we design and implement SSLINT, a scalable, Given a representation of correct usage, how do we de- automated, static analysis system for detecting incorrect use sign techniques for analyzing programs to detect incorrect of SSL/TLS APIs.
    [Show full text]
  • How Secure Is Textsecure?
    How Secure is TextSecure? Tilman Frosch∗y, Christian Mainkay, Christoph Badery, Florian Bergsmay,Jorg¨ Schwenky, Thorsten Holzy ∗G DATA Advanced Analytics GmbH firstname.lastname @gdata.de f g yHorst Gortz¨ Institute for IT-Security Ruhr University Bochum firstname.lastname @rub.de f g Abstract—Instant Messaging has gained popularity by users without providing any kind of authentication. Today, many for both private and business communication as low-cost clients implement only client-to-server encryption via TLS, short message replacement on mobile devices. However, until although security mechanisms like Off the Record (OTR) recently, most mobile messaging apps did not protect confi- communication [3] or SCIMP [4] providing end-to-end con- dentiality or integrity of the messages. fidentiality and integrity are available. Press releases about mass surveillance performed by intelli- With the advent of smartphones, low-cost short-message gence services such as NSA and GCHQ motivated many people alternatives that use the data channel to communicate, to use alternative messaging solutions to preserve the security gained popularity. However, in the context of mobile ap- and privacy of their communication on the Internet. Initially plications, the assumption of classical instant messaging, fueled by Facebook’s acquisition of the hugely popular mobile for instance, that both parties are online at the time the messaging app WHATSAPP, alternatives claiming to provide conversation takes place, is no longer necessarily valid. secure communication experienced a significant increase of new Instead, the mobile context requires solutions that allow for users. asynchronous communication, where a party may be offline A messaging app that claims to provide secure instant for a prolonged time.
    [Show full text]
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries
    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
    [Show full text]
  • Xerox® Igen™ 150 Press 3 Party Software License Disclosure
    Xerox® iGen™ 150 Press 3rd Party Software License Disclosure October 2013 The following software packages are copyrighted for use in this product according to the license stated. Full terms and conditions of all 3rd party software licenses are available from the About screen under the Help menu on the Press Interface or by accessing the Support & Drivers page located on the http://www.xerox.com website. Adobe Icons and Web Logos, license: Adobe Icons and Web Logos License Apache log4j 1.2.8, Apache log4j 1.2.9, Apache Web Services XML-RPC 1.2.b1, Apache Lucene Java 1.3, Apache Tomcat 4.1.27, license: Apache License 1.1 Apache Axis 1.x 1.4, Apache Jakarta Commons HttpClient 3.0.alpha1, Apache Jakarta Commons Logging 1.0.4, Apache Jakarta Lucene 1.9.1, Apache XML Security Java 1.3.0, saxpath 1.0 FCS, Skin Look And Feel (skinlf) 1.2.8, Spring Framework Utilities 0.7, Apache Web Services Axis 1.2rc3, Apache Xerces Java XML Parser 2.7.1, Apache XML Xalan-Java 2.7.0, Jetty - Java HTTP Servlet Server 4.0.D0, Lucene Snowball, Streaming API for XML (StAX) - JSR-173 20040819, license: Apache License 2.0 Perl 5.8.5, Perl 5.10.0, AppConfig-1.66, Archive-Tar-1.58, Compress::Zlib-2.020, Expect.pm- 1.21, File-NCopy-0.36, File-NFSLock-1.20, Filesys-Df-0.92, Filesys-DiskFree-0.06, HTML- Parser-3.69, HTML-Tagset-3.20, HTML-Template-2.9, IO-Stty-0.02, IO-Tty-1.08, IO-Zlib- 1.09, libxml-perl-0.08, Net-Netmask-1.9015, Net-Telnet-3.03, perl-5.8.3, perlindex-1.605, Pod- Escapes-1.04, Pod-POM-0.25, Pod-Simple-3.13, Proc-ProcessTable-0.45, Socket6-0.23, Stat-
    [Show full text]
  • Security Issues in the Diffie-Hellman Key Agreement Protocol
    Security Issues in the Diffie-Hellman Key Agreement Protocol Jean-Franc¸ois Raymond and Anton Stiglic Zero-Knowledge Systems Inc. jfr, anton ¡ @zeroknowledge.com Abstract Diffie-Hellman key agreement protocol [20] implementations have been plagued by serious security flaws. The attacks can be very subtle and, more often than not, have not been taken into account by protocol designers. In this summary we discuss both theoretical attacks against the Diffie-Hellman key agreement pro- tocol and attacks based on implementation details . It is hoped that computer se- curity practitioners will obtain enough information to build and design secure and efficient versions of this classic key agreement protocol. 1 Introduction In their landmark 1976 paper “New Directions in Cryptography”[20], Diffie and Hell- man present a secure key agreement protocol that can be carried out over public com- munication channels. Their protocol is still widely used to this day. Even though the protocol seems quite simple, it can be vulnerable to certain attacks. As with many cryptographic protocols, the Diffie-Hellman key agreement protocol (DH protocol) has subtle problems that cryptographers have taken many years to discover. This vulnerability is compounded by the fact that programmers often do not have a proper understanding of the security issues. In fact, bad implementations of crypto- graphic protocols are, unfortunately, common [2]. In this work, we attempt to give a comprehensive listing of attacks on the DH proto- col. This listing will, in turn, allow us to motivate protocol design decisions. Note that throughout this presentation emphasis is placed on practice. After reading this paper, one might not have an extremely detailed understanding of previous work and theoret- ical problems, but should have a very good idea about how to securely implement the DH protocol in different settings.
    [Show full text]