DOCSLIB.ORG

Analysing and Improving the Crypto Ecosystem of Rust

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Institute of Software Technology University of Stuttgart Universitätsstraße 38 D–70569 Stuttgart Masterarbeit Analysing and improving the crypto ecosystem of Rust Philipp Keck Course of Study: Softwaretechnik Examiner: Prof. Dr. Stefan Wagner Supervisor: Kai Mindermann M.Sc. Commenced: 2016-10-13 Completed: 2017-04-14 CR-Classification: D.2.2, D.2.11, D.2.13, E.3 Abstract Context: Rust is an emerging systems programming language that suits security-critical applications because it guarantees memory safety without a garbage collector. Its grow- ing ecosystem already encompasses several crypto libraries, though the competition is still open. Previous cryptography research found that vulnerabilities are often due to misunderstandings and misuse of cryptographic APIs rather than bugs in the libraries themselves. Aim: This thesis presents a holistic analysis of Rust’s current crypto ecosys- tem and aims to improve its further development. A particular focus is on API design because all libraries are still open to change their APIs and it will become increasingly difficult to change them later. Method: All parts of the ecosystem are systematically analysed, guided by the general structure of a crypto ecosystem. Research methods include a systematic search for libraries, a survey among contributors, GitHub analyses as well as a self-experiment and a controlled experiment to test the usability. Results: The contributors are typical open source developers and they collaborate in typical ways on GitHub. Most libraries have a clear main developer and there is a general lack of contributors. While two of the major libraries focus on usability and are consequently easier to use and more resistant to misuse, the two most widespread libraries consciously neglect these topics and exhibit flaws known from crypto libraries in other languages. Conclusion: The misuse resistant Rust crypto libraries should be advertised more actively. In the medium term, an officially endorsed API could improve interoperability and foster competition. For such an API and for the improvement of existing APIs, the thesis discusses a number of design decisions and their usability implications. 3 Kurzfassung Kontext: Rust ist eine junge Systemprogrammiersprache, die sich für sicherheitskritische Anwendungen eignet, weil sie Speichersicherheit ohne einen Garbage Collector garan- tiert. Das wachsende Ökosystem umfasst bereits einige Krypto-Bibliotheken, wobei der Wettbewerb noch offen ist. Die bisherige Forschung hat gezeigt, dass Schwachstellen oft durch Missverständnisse und Missbrauch der kryptographischen APIs verursacht werden anstatt durch Fehler in den Bibliotheken selbst. Ziel: Diese Thesis enthält eine ganzheit- liche Analyse des Krypto-Ökosystems von Rust mit dem Ziel, die zukünftige Entwicklung zu verbessern. Ein besonderer Fokus liegt auf dem API-Design, weil alle Bibliotheken noch offen für API-Änderungen sind und solche Änderungen später schwieriger werden. Vorgehen: Alle Bestandteile des Ökosystems werden anhand der allgemeinen Struktur eines Krypto-Ökosystems systematisch analysiert. Zu den eingesetzten Forschungsme- thoden gehören eine systematische Suche nach Bibliotheken, eine Entwicklerumfrage, GitHub-Analysen sowie ein Selbstversuch und ein kontrolliertes Experiment um die Be- nutzbarkeit zu testen. Ergebnisse: Die Entwickler sind typische Open-Source-Entwickler und sie arbeiten auf typische Weise auf GitHub zusammen. Die meisten Bibliotheken haben einen eindeutigen Hauptentwickler und es gibt einen generellen Mangel an wei- teren Entwicklern. Während zwei der größeren Bibliotheken sich auf Benutzbarkeit konzentrieren und dementsprechend einfacher zu verwenden und missbrauchsresis- tenter sind, vernachlässigen die beiden am weitesten verbreiteten Bibliotheken diese Themen bewusst und weisen Schwächen auf, die von Krypto-Bibliotheken anderer Spra- chen her bekannt sind. Fazit: Die missbrauchsresistenten Krypto-Bibliotheken in Rust sollten aktiver beworben werden. Mittelfristig könnte eine offiziell unterstützte API die Interoperabilität und den Wettbewerb fördern. Für eine solche API und für die Verbesserung der existierenden APIs werden in der Thesis diverse Designentscheidungen und ihre Auswirkungen auf die Benutzbarkeit erörtert. 4 Acknowledgements I would like to thank my supervisor Kai Mindermann for coming up with this exciting topic and for his guidance, advice and collaboration. Without his support, this thesis would not have been possible. I would also like to thank all survey participants for their time and input as well as the active community members on the #rust-crypto IRC channel and @briansmith for their help, tips and for interesting discussions. Publication Parts of this thesis have been submitted as a paper at the Thirteenth Symposium on Usable Privacy and Security (SOUPS ’17), in collaboration with Kai Mindermann M.Sc. and Prof. Dr. Stefan Wagner. A separate paper has been submitted for the controlled experiment that is only briefly reported on in this thesis. Note on links Many of the sources referenced in this thesis are rather volatile. Where necessary, links are annotated with the date on which they were stored in the Internet Archive (https://web.archive.org/), where the respective version can be retrieved. License This thesis and all supplementary material (see appendix A) are licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. Suggested citation: “Philipp Keck, master’s thesis ‘Analysing and improving the crypto ecosystem of Rust’, 2017” 5 Contents List of Figures9 List of Tables 10 1 Introduction 11 2 Foundations 13 2.1 The Rust programming language..................... 13 2.2 Cryptographic foundations......................... 20 3 Related work 27 3.1 Open-source projects............................ 27 3.2 API design and usability.......................... 28 3.3 Crypto usability............................... 30 4 Ecosystems 35 4.1 Deriving a definition............................ 35 4.2 Definition.................................. 36 4.3 C and C++................................. 40 4.4 Java..................................... 40 4.5 .NET..................................... 42 4.6 Python.................................... 43 4.7 Conclusion................................. 43 5 The Rust crypto ecosystem 45 5.1 Research questions............................. 45 5.2 Library search and categorization..................... 46 5.3 Libraries providing primitives....................... 50 5.4 Contributors survey............................. 55 5.5 GitHub analysis............................... 63 5.6 Crypto in the standard library....................... 72 5.7 Areas for improvement........................... 73 5.8 Conclusion................................. 79 7 6 Usage analysis 81 6.1 Approach.................................. 82 6.2 High-level results.............................. 84 6.3 Hashing................................... 85 6.4 HMAC.................................... 90 6.5 Symmetric encryption........................... 92 6.6 Threats to validity............................. 94 6.7 Conclusion................................. 96 7 Usability analysis 97 7.1 Self-experiment............................... 97 7.2 Controlled experiment........................... 105 7.3 Conclusion................................. 108 8 Improving usability and misuse resistance 109 8.1 Documentation............................... 110 8.2 Scope of included algorithms....................... 113 8.3 Level of abstraction............................. 115 8.4 Organization of included algorithms................... 118 8.5 Split into multiple crates.......................... 126 8.6 Defaults and future security........................ 128 8.7 Strong types................................. 130 8.8 Keys, nonces and seeds........................... 131 8.9 Constant-time comparisons........................ 133 8.10 &mut parameters.............................. 134 8.11 Conclusion................................. 136 9 Conclusion 137 9.1 Future of crypto in Rust.......................... 137 9.2 Future work................................. 138 9.3 Summary.................................. 139 A Supplementary material 141 B Rust contributors survey questionnaire 142 Acronyms 147 References 149 8 List of Figures 2.1 Data flows for symmetric encryption................... 23 2.2 Data flows for authenticated symmetric encryption........... 25 4.1 Populations and interactions in a programming ecosystem....... 38 5.1 Rust crypto libraries and their dependencies............... 49 5.2 Timeline of the major Rust primitive libraries’ start dates and ancestors 50 5.3 Self-ratings for cryptography and Rust skills............... 58 5.4 Years of experience with programming and cryptography........ 59 5.5 Time commitment in hours per week................... 60 5.6 GitHub issue and pull request (PR) topics................ 69 5.7 Importance of API design to the contributors............... 70 6.1 Number of considered search results per library............. 84 6.2 Filtering the crates found in the previous step.............. 84 6.3 High-level usages per category and library................ 85 6.4 Hash function usage............................ 88 6.5 HMAC usage................................ 91 6.6 Symmetric encryption usage........................ 93 6.7 Hash function usage: output
Recommended publications
  • Course 5 Lesson 2

    Course 5 Lesson 2

    This material is based on work supported by the National Science Foundation under Grant No. 0802551 Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author (s) and do not necessarily reflect the views of the National Science Foundation C5L3S1 With the advent of the Internet, social networking, and open communication, a vast amount of information is readily available on the Internet for anyone to access. Despite this trend, computer users need to ensure private or personal communications remain confidential and are viewed only by the intended party. Private information such as a social security numbers, school transcripts, medical histories, tax records, banking, and legal documents should be secure when transmitted online or stored locally. One way to keep data confidential is to encrypt it. Militaries,U the governments, industries, and any organization having a desire to maintain privacy have used encryption techniques to secure information. Encryption helps to boost confidence in the security of online commerce and is necessary for secure transactions. In this lesson, you will review encryption and examine several tools used to encrypt data. You will also learn to encrypt and decrypt data. Anyone who desires to administer computer networks and work with private data must have some familiarity with basic encryption protocols and techniques. C5L3S2 You should know what will be expected of you when you complete this lesson. These expectations are presented as objectives. Objectives are short statements of expectations that tell you what you must be able to do, perform, learn, or adjust after reviewing the lesson.
  • Chapter 12 Pretty Good Privacy (PGP)

    Chapter 12 Pretty Good Privacy (PGP)

    Chapter 12 Pretty Good Privacy (PGP) With the explosively growing reliance on electronic mail for every conceivable pur- pose, there grows a demand for authentication and confidentiality services. Two schemes stand out as approaches that enjoy widespread use: Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extension (S/MIME). The latter is a security en- hancement to the MIME Internet e-mail format standard, based on technology from RSA Data Security. Although both PGP and S/MIME are on an IETF standards track, it appears likely that S/MIME will emerge as the industry standard for commercial and organisational use, while PGP will remain the choice for personal e-mail security for many users. In this course we will only be looking at PGP. S/MIME is discussed in detail in the recommended text. 12.1 Background PGP is a remarkable phenomenon. Largely the effort of a single person, Phil Zimmer- mann, PGP provides a confidentiality and authentication service that can be used for electronic mail and file storage applications. In essence what Zimmermann has done is the following: 1. Selected the best cryptographic mechanisms (algorithms) as building blocks. 2. Integrated these algorithms into a general purpose application that is independent of operating system and processor and that is based on a small set of easy to use commands. 3. Made the package and its source code freely available via the Internet, bulletin boards, and commercial networks such as America On Line (AOL). 4. Entered into an agreement with a company (Viacrypt, now Network Associates) to provide a fully compatible low cost commercial version of PGP.
  • Using Frankencerts for Automated Adversarial Testing of Certificate

    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.
  • Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard V1.2.3

    Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard V1.2.3

    Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard v1.2.3 Phong Q. Nguyen CNRS/Ecole´ normale sup´erieure D´epartement d’informatique 45 rue d’Ulm, 75230 Paris Cedex 05, France. [email protected] http://www.di.ens.fr/˜pnguyen Abstract. More and more software use cryptography. But how can one know if what is implemented is good cryptography? For proprietary soft- ware, one cannot say much unless one proceeds to reverse-engineering, and history tends to show that bad cryptography is much more frequent than good cryptography there. Open source software thus sounds like a good solution, but the fact that a source code can be read does not imply that it is actually read, especially by cryptography experts. In this paper, we illustrate this point by examining the case of a basic In- ternet application of cryptography: secure email. We analyze parts of thesourcecodeofthelatestversionofGNUPrivacyGuard(GnuPGor GPG), a free open source alternative to the famous PGP software, com- pliant with the OpenPGP standard, and included in most GNU/Linux distributions such as Debian, MandrakeSoft, Red Hat and SuSE. We ob- serve several cryptographic flaws in GPG v1.2.3. The most serious flaw has been present in GPG for almost four years: we show that as soon as one (GPG-generated) ElGamal signature of an arbitrary message is released, one can recover the signer’s private key in less than a second on a PC. As a consequence, ElGamal signatures and the so-called ElGamal sign+encrypt keys have recently been removed from GPG.
  • A History of End-To-End Encryption and the Death of PGP

    A History of End-To-End Encryption and the Death of PGP

    25/05/2020 A history of end-to-end encryption and the death of PGP Hey! I'm David, a security engineer at the Blockchain team of Facebook (https://facebook.com/), previously a security consultant for the Cryptography Services of NCC Group (https://www.nccgroup.com). I'm also the author of the Real World Cryptography book (https://www.manning.com/books/real-world- cryptography?a_aid=Realworldcrypto&a_bid=ad500e09). This is my blog about cryptography and security and other related topics that I Ûnd interesting. A history of end-to-end encryption and If you don't know where to start, you might want to check these popular the death of PGP articles: posted January 2020 - How did length extension attacks made it 1981 - RFC 788 - Simple Mail Transfer Protocol into SHA-2? (/article/417/how-did-length- extension-attacks-made-it-into-sha-2/) (https://tools.ietf.org/html/rfc788) (SMTP) is published, - Speed and Cryptography the standard for email is born. (/article/468/speed-and-cryptography/) - What is the BLS signature scheme? (/article/472/what-is-the-bls-signature- This is were everything starts, we now have an open peer-to-peer scheme/) protocol that everyone on the internet can use to communicate. - Zero'ing memory, compiler optimizations and memset_s (/article/419/zeroing-memory- compiler-optimizations-and-memset_s/) 1991 - The 9 Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementations The US government introduces the 1991 Senate Bill 266, (/article/461/the-9-lives-of-bleichenbachers- which attempts to allow "the Government to obtain the cat-new-cache-attacks-on-tls- plain text contents of voice, data, and other implementations/) - How to Backdoor Di¸e-Hellman: quick communications when appropriately authorized by law" explanation (/article/360/how-to-backdoor- from "providers of electronic communications services di¸e-hellman-quick-explanation/) and manufacturers of electronic communications - Tamarin Prover Introduction (/article/404/tamarin-prover-introduction/) service equipment".
  • Self-Encrypting Deception: Weaknesses in the Encryption of Solid State Drives

    Self-Encrypting Deception: Weaknesses in the Encryption of Solid State Drives

    Self-encrypting deception: weaknesses in the encryption of solid state drives Carlo Meijer Bernard van Gastel Institute for Computing and Information Sciences School of Computer Science Radboud University Nijmegen Open University of the Netherlands [email protected] and Institute for Computing and Information Sciences Radboud University Nijmegen Bernard.vanGastel@{ou.nl,ru.nl} Abstract—We have analyzed the hardware full-disk encryption full-disk encryption. Full-disk encryption software, especially of several solid state drives (SSDs) by reverse engineering their those integrated in modern operating systems, may decide to firmware. These drives were produced by three manufacturers rely solely on hardware encryption in case it detects support between 2014 and 2018, and are both internal models using the SATA and NVMe interfaces (in a M.2 or 2.5" traditional form by the storage device. In case the decision is made to rely on factor) and external models using the USB interface. hardware encryption, typically software encryption is disabled. In theory, the security guarantees offered by hardware encryp- As a primary example, BitLocker, the full-disk encryption tion are similar to or better than software implementations. In software built into Microsoft Windows, switches off software reality, we found that many models using hardware encryption encryption and completely relies on hardware encryption by have critical security weaknesses due to specification, design, and implementation issues. For many models, these security default if the drive advertises support. weaknesses allow for complete recovery of the data without Contribution. This paper evaluates both internal and external knowledge of any secret (such as the password).
  • Analysis of an Encrypted HDD

    Analysis of an Encrypted HDD

    Analysis of an encrypted HDD J. Czarny, R. Rigo May 11, 2015 Abstract The idea of this presentation is to debunk the myth that analyzing the security of hardware is difficult. From the perspective of a software reverse engineer we present the process of studying a hardware-encrypted, PIN secured, external hard drive: the Zalman VE-400. While the end result of the analysis and attack is not a full success as it was not possible to recover an encrypted drive, it shows that the drive is nevertheless vulnerable by design. 1 Introduction 1.1 The target Analysing the security of hardware products seems to scare software reversers and hackers. It used to scare us. But, fortunately, today there is no need to know much about electronics, as most products are just System on Chip (SoC), a single integrated circuit with IO and a CPU or microcontroller. All that is needed is a bit of soldering ability, a multimeter, some useful pieces of hardware and a brain. The subject here is not embedded systems in the now common sense of “small hardware running Linux” but smaller systems using one or two chips. Most interesting for software hackers are encrypted HDD/USB keys: their functionnality is conceptually simple and they provide an interesting target. We will focus on the Zalman VE-400 encrypted drive, a consumer enclosure for 2.5" SATA hard drives which supports hardware encryption. It also supports advanced features like mounting ISO files as virtual optical drives. To do so, the user must choose between the ExFAT and NTFS filesystem support, by reflashing the correct firmware.
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

    Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
  • Nouveau Mode Opératoire Pour La Cryptographie *

    Nouveau Mode Opératoire Pour La Cryptographie *

    Nouveau Mode Opératoire pour la Cryptographie * Naima Hadj-Said*, Adda Ali-Pacha, Mohamed Sadek Ali-Pacha – Aek Haouas *Laboratoire SIMPA (Signal-Image-Parole) Université des Sciences et de la Technologie d’Oran USTO , BP 1505 El M’Naouer Oran 31036 Algerie [email protected] Résumé : Un mode opératoire consiste en la description détaillée des actions nécessaires à l'obtention d'un résultat. Il décrit généralement le déroulement détaillé des opérations effectuées sur un poste fixe, mais il peut également décrire l'enchaînement des opérations de poste à poste. Un mode opératoire décrivant les enchaînements opératoires de poste à poste permet de définir : -l'ensemble des postes de travail concernés par la réalisation d'un produit, d'une pièce élémentaire, - les temps de passage prévus (alloués) à chaque poste, -l'ordre logique d'intervention de chaque poste (machine, ou poste manuel), -les conditions d'enchaînement, de déclenchement, des opérations successives, -les moyens de transfert de poste à poste. En cryptographie, un mode d'opération est la manière de traiter les blocs de texte clairs et chiffrés au sein d'un algorithme de chiffrement par bloc ou bien c’est la présentation d’une méthode de chaînage des blocs dans un chiffrement par blocs. Plusieurs modes existent possédant leur propre atout, certains sont plus vulnérables que d'autres et certains modes combinent les concepts d'authentification et sécurité. Dans ce travail on essaie de faire la synthèse des modes opératoires des systèmes cryptographique et de proposer une bonne alternative pour faire le bon choix du vecteur d'initialisation de ces modes, avec la suggestion d’un nouveau mode opératoire qu’on a appelé : mode Autonome Secure blocK (ASK).
  • Secure Industrial Device Connectivity with Low-Overhead TLS

    Secure Industrial Device Connectivity with Low-Overhead TLS

    Secure Industrial Device Connectivity with Low-Overhead TLS Tuesday, October 3, 2017 1:10PM-2:10PM Chris Conlon - Engineering Manager, wolfSSL - B.S. from Montana State University (Bozeman, MT) - Software engineer at wolfSSL (7 years) Contact Info: - Email: [email protected] - Twitter: @c_conlon A. – B. – C. – D. – E. F. ● ● ● ○ ● ○ ● ○ ● Original Image Encrypted using ECB mode Modes other than ECB ● ○ ● ○ ● ● ● ● ○ ● ● ● ● ○ ● ○ ○ ○ ○ ● ○ ● ● ● ● ○ ● ● ○ By Original schema: A.J. Han Vinck, University of Duisburg-EssenSVG version: Flugaal - A.J. Han Vinck, Introduction to public key cryptography, p. 16, Public Domain, https://commons.wikimedia.org/w/index.php?curid=17063048 ● ○ ● ○ ■ ■ ■ ● ○ ■ ● ● ● ● ● ○ ● ● ● ● ● ● ● ○ ○ ○ ○ ● “Progressive” is a subjective term ● These slides talk about crypto algorithms that are: ○ New, modern ○ Becoming widely accepted ○ Have been integrated into SSL/TLS with cipher suites ● ChaCha20 ● Poly1305 ● Curve25519 ● Ed25519 Created by Daniel Bernstein a research professor at the University of Illinois, Chicago Chacha20-Poly1305 AEAD used in Google over HTTPS Ed25519 and ChaCha20-Poly1305 AEAD used in Apple’s HomeKit (iOS Security) ● Fast stream cipher ● Based from Salsa20 stream cipher using a different quarter-round process giving it more diffusion ● Can be used for AEAD encryption with Poly1305 ● Was published by Bernstein in 2008 Used by ● Google Chrome ● TinySSH ● Apple HomeKit ● wolfSSL ● To provide authenticity of messages (MAC) ● Extremely fast in comparison to others ● Introduced by a presentation given from Bernstein in 2002 ● Naming scheme from using polynomial-evaluation MAC (Message Authentication Code) over a prime field Z/(2^130 - 5) Used by ● Tor ● Google Chrome ● Apple iOS ● wolfSSL Generic Montgomery curve. Reference 5 Used by ● Tera Term ● GnuPG ● wolfSSL Generic Twisted Edwards Curve.
  • Pgpfone Pretty Good Privacy Phone Owner’S Manual Version 1.0 Beta 7 -- 8 July 1996

    Pgpfone Pretty Good Privacy Phone Owner’S Manual Version 1.0 Beta 7 -- 8 July 1996

    Phil’s Pretty Good Software Presents... PGPfone Pretty Good Privacy Phone Owner’s Manual Version 1.0 beta 7 -- 8 July 1996 Philip R. Zimmermann PGPfone Owner’s Manual PGPfone Owner’s Manual is written by Philip R. Zimmermann, and is (c) Copyright 1995-1996 Pretty Good Privacy Inc. All rights reserved. Pretty Good Privacy™, PGP®, Pretty Good Privacy Phone™, and PGPfone™ are all trademarks of Pretty Good Privacy Inc. Export of this software may be restricted by the U.S. government. PGPfone software is (c) Copyright 1995-1996 Pretty Good Privacy Inc. All rights reserved. Phil’s Pretty Good engineering team: PGPfone for the Apple Macintosh and Windows written mainly by Will Price. Phil Zimmermann: Overall application design, cryptographic and key management protocols, call setup negotiation, and, of course, the manual. Will Price: Overall application design. He persuaded the rest of the team to abandon the original DOS command-line approach and designed a multithreaded event-driven GUI architecture. Also greatly improved call setup protocols. Chris Hall: Did early work on call setup protocols and cryptographic and key management protocols, and did the first port to Windows. Colin Plumb: Cryptographic and key management protocols, call setup negotiation, and the fast multiprecision integer math package. Jeff Sorensen: Speech compression. Will Kinney: Optimization of GSM speech compression code. Kelly MacInnis: Early debugging of the Win95 version. Patrick Juola: Computational linguistic research for biometric word list. -2- PGPfone Owner’s
  • Enclave Security and Address-Based Side Channels

    Enclave Security and Address-Based Side Channels

    Graz University of Technology Faculty of Computer Science Institute of Applied Information Processing and Communications IAIK Enclave Security and Address-based Side Channels Assessors: A PhD Thesis Presented to the Prof. Stefan Mangard Faculty of Computer Science in Prof. Thomas Eisenbarth Fulfillment of the Requirements for the PhD Degree by June 2020 Samuel Weiser Samuel Weiser Enclave Security and Address-based Side Channels DOCTORAL THESIS to achieve the university degree of Doctor of Technical Sciences; Dr. techn. submitted to Graz University of Technology Assessors Prof. Stefan Mangard Institute of Applied Information Processing and Communications Graz University of Technology Prof. Thomas Eisenbarth Institute for IT Security Universit¨atzu L¨ubeck Graz, June 2020 SSS AFFIDAVIT I declare that I have authored this thesis independently, that I have not used other than the declared sources/resources, and that I have explicitly indicated all material which has been quoted either literally or by content from the sources used. The text document uploaded to TUGRAZonline is identical to the present doctoral thesis. Date, Signature SSS Prologue Everyone has the right to life, liberty and security of person. Universal Declaration of Human Rights, Article 3 Our life turned digital, and so did we. Not long ago, the globalized commu- nication that we enjoy today on an everyday basis was the privilege of a few. Nowadays, artificial intelligence in the cloud, smartified handhelds, low-power Internet-of-Things gadgets, and self-maneuvering objects in the physical world are promising us unthinkable freedom in shaping our personal lives as well as society as a whole. Sadly, our collective excitement about the \new", the \better", the \more", the \instant", has overruled our sense of security and privacy.