DOCSLIB.ORG

Classification of Cryptographic Libraries

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Classification of Cryptographic Libraries Institute of Software Technology University of Stuttgart Universitätsstraße 38 D–70569 Stuttgart Fachstudie Classification of cryptographic libraries Andreas Poppele, Rebecca Eichler, Roland Jäger Course of Study: Softwaretechnik Examiner: Prof. Dr. rer. nat. Stefan Wagner Supervisor: Kai Mindermann, M.Sc. Commenced: 2017/03/07 Completed: 2017/09/07 CR-Classification: A.1, A.2 Declaration 2/186 Zusammenfassung Bei der Umsetzung von Sicherheitskonzepten stehen Softwareentwickler vor der Heraus- forderung eine passende kryptografische Bibliothek zu finden. Es gibt eine Vielzahl von kryptographischen Bibliotheken für verschiedene Programmiersprachen, ohne dass es eine standardisierte Auffassung von verschiedenen Eigenschaften dieser kryptographischen Bibliotheken gibt. Dieser Bericht liefert eine Klassifizierung von über 700 kryptograph- ischen Bibliotheken. Die Bibliotheken wurden in Bezug auf Aktualität und Beliebtheit ausgewählt. Um einen standardisierten Überblick zu liefern, wurden die wichtigsten Merkmale dieser Bibliotheken gesammelt und definiert. Die Datenerhebung zu diesen Merkmalen wurde sowohl manuell als auch automatisiert durchgeführt. Die Klassifizier- ung enthält Informationen, die erfahrenen und unerfahrenen Entwicklern im kryptografis- chen Bereich helfen, eine Bibliothek zu finden, die ihren Fähigkeiten und Anforderungen entspricht. Darüber hinaus kann sie als Grundlage für Studien über jede Form der Verbesserung dieser Bibliotheken und vieles mehr verwendet werden. Abstract Software developers today are faced with choosing cryptographic libraries in order to implement security concepts. There is a large variety of cryptographic libraries for diverse programming languages, without there being a standardized conception of different properties of these cryptographic libraries. This report provides a classification of over 700 cryptographic libraries. The libraries were chosen pertaining to currentness and popularity. In order to provide a standardized overview the most important traits and characteristics of these libraries were gathered and defined. Data collection on these characteristics was performed in a manual as well as automated fashion. The classification contains information that will help experienced and inexperienced developers in the cryptographic field to choose a library that fits their abilities. Furthermore, it may be used as a basis for studies concerning any form of improvement of these libraries and many more. 3/186 Contents Contents 1. Introduction6 1.1. Context.....................................6 1.2. Purpose.....................................6 1.3. Overview....................................6 2. Literature Review7 3. Method9 3.1. Research Design................................9 3.2. Languages Selection..............................9 3.3. Search Methodology.............................. 13 3.3.1. Code hosting sites........................... 14 3.3.2. Criteria for exclusion.......................... 15 3.3.3. Search constraints........................... 16 3.4. Data Collection................................. 21 3.4.1. Manual data Collection........................ 21 3.4.2. Automated Data Collection...................... 23 4. Classification 26 4.1. Library Types.................................. 26 4.2. Interface-Level................................. 27 4.3. Dependencies.................................. 28 4.4. Related Libraries................................ 28 4.5. Licenses..................................... 29 4.6. Cryptographic Features............................ 29 4.7. Authors and Contributors........................... 31 4.8. Project size................................... 32 4.9. Impact...................................... 32 4.10. Standard Library................................ 36 4.11. Documentation................................. 37 4.12. Ease of Use................................... 37 5. Results 37 5.1. C Libraries................................... 38 5.2. C++ Libraries................................. 42 5.3. JavaScript Libraries.............................. 45 5.4. Ruby Libraries................................. 49 5.5. Rust Libraries.................................. 51 5.6. C# Libraries.................................. 54 5.7. Swift Libraries................................. 56 5.8. Java Libraries.................................. 58 5.9. Objective-C Libraries.............................. 61 5.10. Go Libraries................................... 63 5.11. PHP Libraries.................................. 66 5.12. Python Libraries................................ 68 4/186 Contents 6. Conclusion 70 6.1. Future work................................... 70 6.2. Remarks..................................... 71 7. Acknowledgements 71 References 72 Appendices 74 Appendix A. Detailed Library Table 74 5/186 1. Introduction 1. Introduction 1.1. Context Today’s software developers heavily rely on existent cryptographic libraries to provide features needed to implement security concepts. There is a large variety of cryptographic libraries for diverse programming languages. The libraries differ in terms of size, the range and type of features, the amount of authors and developers still maintaining it. There are libraries which are maintained by companies and some which are developed by individuals as a leisure activity. Some aren’t maintained any more and are deprecated, others still offer great potential. A lot of libraries merely re-implement or use another, offering a different interface through which the functionality can be accessed. Developers are faced with choosing a library which fits their needs in terms of offered functionality and application programmable interface, accessible with their level of ex- perience and knowledge in the cryptographic field. This can be very daunting as there is no standardized conception of different properties of cryptographic libraries. There is no general overview which contrasts these libraries with which developers can choose libraries with properties that fit their needs. 1.2. Purpose This report aims to provide a classification of a large number of cryptographic libraries. A number of selected libraries are examined in respect to defined criteria. The libraries are then systematically grouped according to the result of the examination [8]. This report does not introduce or use a taxonomy as the defined criteria and groupings aren’t ordered in an hierarchical context [13]. To begin with, it is necessary to establish, which library features are relevant, for the purpose of contrasting cryptographic libraries. Additionally, we aim to ascertain, which libraries are relevant in the cryptographic field, pertaining to currentness and popularity and which ones out of the compiled collection have the highest impact. Furthermore, we wish to identify which of the previously selected libraries offer high potential for experienced developers in the cryptographic field and which ones are interesting for inexperienced developers. 1.3. Overview The first section following the introduction is on the conducted literature review, the background and related work. The section 3, Method, contains the Research design, the approach on selecting programming languages and their corresponding cryptographic libraries. Furthermore, it has a section on how the data on the libraries was collected. The investigated properties of the libraries are explicated in section 4, Classification. The data on the collected libraries is contrasted in section 5, Results, and briefly summarised and evaluated in section 6, Conclusion. 6/186 2. Literature Review 2. Literature Review In the field of classification of software related entities several approaches have been developed. Medvidovic and Taylor came up with an approach for classifying architecture descrip- tion languages [10]. The aim of this work was to provide a definition of architecture description languages to make them distinguishable from other types of specifications. In order to classify the architecture description languages, different characteristics were defined. Those include e.g. architecture modeling features like components, connectors or architectural configurations and tool support like multiple views or code generation. Shaw and Clements also concentrated on architecture in their paper [16]. They developed a framework for the classification of architectural styles that should support initial design decisions in software development. Their framework mainly distinguishes between the components and connectors that are used in the different architectural styles and the control issues between those components. As a result, their classification scheme arranges the libraries in a two-dimensional grid. In this report, the use of a two-dimensional grid for the classification would not be feasible, as the cryptographic libraries have more than two main characteristics. Also, the number of libraries is too high to arrange them in a grid. Another classification scheme that concentrates on software security patterns was de- veloped by Alvi and Zulkernine [2]. Their classification makes use of the different phases of the software engineering process. Software security patterns are classified according to their relation to the requirement, design or implementation phase. On the level of individual software security patterns they also developed a template that defines the characteristics of each pattern that have to be collected. Besides their name, these also include, for example, the pattern’s context, its problem as well as its solution and the consequences
Load more

Recommended publications
  • GPU-Based Password Cracking on the Security of Password Hashing Schemes Regarding Advances in Graphics Processing Units
    Radboud University Nijmegen Faculty of Science Kerckhoffs Institute Master of Science Thesis GPU-based Password Cracking On the Security of Password Hashing Schemes regarding Advances in Graphics Processing Units by Martijn Sprengers [email protected] Supervisors: Dr. L. Batina (Radboud University Nijmegen) Ir. S. Hegt (KPMG IT Advisory) Ir. P. Ceelen (KPMG IT Advisory) Thesis number: 646 Final Version Abstract Since users rely on passwords to authenticate themselves to computer systems, ad- versaries attempt to recover those passwords. To prevent such a recovery, various password hashing schemes can be used to store passwords securely. However, recent advances in the graphics processing unit (GPU) hardware challenge the way we have to look at secure password storage. GPU's have proven to be suitable for crypto- graphic operations and provide a significant speedup in performance compared to traditional central processing units (CPU's). This research focuses on the security requirements and properties of prevalent pass- word hashing schemes. Moreover, we present a proof of concept that launches an exhaustive search attack on the MD5-crypt password hashing scheme using modern GPU's. We show that it is possible to achieve a performance of 880 000 hashes per second, using different optimization techniques. Therefore our implementation, executed on a typical GPU, is more than 30 times faster than equally priced CPU hardware. With this performance increase, `complex' passwords with a length of 8 characters are now becoming feasible to crack. In addition, we show that between 50% and 80% of the passwords in a leaked database could be recovered within 2 months of computation time on one Nvidia GeForce 295 GTX.
    [Show full text]
  • The Design of Rijndael: AES - the Advanced Encryption Standard/Joan Daemen, Vincent Rijmen
    Joan Daernen · Vincent Rijrnen Theof Design Rijndael AES - The Advanced Encryption Standard With 48 Figures and 17 Tables Springer Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Springer TnL-1Jn Joan Daemen Foreword Proton World International (PWI) Zweefvliegtuigstraat 10 1130 Brussels, Belgium Vincent Rijmen Cryptomathic NV Lei Sa 3000 Leuven, Belgium Rijndael was the surprise winner of the contest for the new Advanced En­ cryption Standard (AES) for the United States. This contest was organized and run by the National Institute for Standards and Technology (NIST) be­ ginning in January 1997; Rij ndael was announced as the winner in October 2000. It was the "surprise winner" because many observers (and even some participants) expressed scepticism that the U.S. government would adopt as Library of Congress Cataloging-in-Publication Data an encryption standard any algorithm that was not designed by U.S. citizens. Daemen, Joan, 1965- Yet NIST ran an open, international, selection process that should serve The design of Rijndael: AES - The Advanced Encryption Standard/Joan Daemen, Vincent Rijmen. as model for other standards organizations. For example, NIST held their p.cm. Includes bibliographical references and index. 1999 AES meeting in Rome, Italy. The five finalist algorithms were designed ISBN 3540425802 (alk. paper) . .. by teams from all over the world. 1. Computer security - Passwords. 2. Data encryption (Computer sCIence) I. RIJmen, In the end, the elegance, efficiency, security, and principled design of Vincent, 1970- II. Title Rijndael won the day for its two Belgian designers, Joan Daemen and Vincent QA76.9.A25 D32 2001 Rijmen, over the competing finalist designs from RSA, IBl\!I, Counterpane 2001049851 005.8-dc21 Systems, and an English/Israeli/Danish team.
    [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]
  • Argon and Argon2
    Argon and Argon2 Designers: Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich University of Luxembourg, Luxembourg [email protected], [email protected], [email protected] https://www.cryptolux.org/index.php/Password https://github.com/khovratovich/Argon https://github.com/khovratovich/Argon2 Version 1.1 of Argon Version 1.0 of Argon2 31th January, 2015 Contents 1 Introduction 3 2 Argon 5 2.1 Specification . 5 2.1.1 Input . 5 2.1.2 SubGroups . 6 2.1.3 ShuffleSlices . 7 2.2 Recommended parameters . 8 2.3 Security claims . 8 2.4 Features . 9 2.4.1 Main features . 9 2.4.2 Server relief . 10 2.4.3 Client-independent update . 10 2.4.4 Possible future extensions . 10 2.5 Security analysis . 10 2.5.1 Avalanche properties . 10 2.5.2 Invariants . 11 2.5.3 Collision and preimage attacks . 11 2.5.4 Tradeoff attacks . 11 2.6 Design rationale . 14 2.6.1 SubGroups . 14 2.6.2 ShuffleSlices . 16 2.6.3 Permutation ...................................... 16 2.6.4 No weakness,F no patents . 16 2.7 Tweaks . 17 2.8 Efficiency analysis . 17 2.8.1 Modern x86/x64 architecture . 17 2.8.2 Older CPU . 17 2.8.3 Other architectures . 17 3 Argon2 19 3.1 Specification . 19 3.1.1 Inputs . 19 3.1.2 Operation . 20 3.1.3 Indexing . 20 3.1.4 Compression function G ................................. 21 3.2 Features . 22 3.2.1 Available features . 22 3.2.2 Server relief . 23 3.2.3 Client-independent update .
    [Show full text]
  • Detection and Exploitation of Small Correlations in Stream Ciphers
    Detection and Exploitation of Small Correlations in Stream Ciphers Masterthesis conducted under the guidance of Prof. Dr. Joachim Rosenthal and Dr. Gérard Maze Institute of Mathematics, University of Zurich 2008 Urs Wagner Outline This thesis gives an overview of stream ciphers based on linear feedback shift registers (LFSR) and their vulnerability to correlation attacks. In the rst chapter, a short introduction to symmetric key ciphers is given. The main focus hereby is on LFSR based stream ciphers. Further, the principles of LFSR are presented. The chapter is then closed by a stream cipher example, the Gee Generator. The second chapter treats the general approach of correlation attacks. Moreover a correlation attack is mounted on the Gee Generator and the practical results are presented. Boolean functions play an important role in stream cipher designs. The Walsh transform, a tool to analyze the cryptographic properties of Boolean functions, is introduced in chapter 3. Additionally, the cryptographic properties themselves are discussed. In the fourth chapter, an improved kind of correlation attack -the fast correlation attack- is presented. It exploits the same weaknesses in the stream cipher designs as the correlation attack, the mode of operation is however dierent. In the last chapter, the insights gained in the previous chapters are used to suggest an attack on a stream cipher by Philips, named Hitag 2. 1 Acknowledgments This thesis was written in the course of my master's studies at the University of Zurich. I am grateful to Prof. Joachim Rosenthal who gave me the opportunity to write my master thesis in cryptography. Special thanks go to Dr.
    [Show full text]
  • Rhetorical Code Studies Revised Pages
    Revised Pages rhetorical code studies Revised Pages Sweetland Digital rhetoric collaborative Series Editors: Anne Ruggles Gere, University of Michigan Naomi Silver, University of Michigan The Sweetland Digital Rhetoric Collaborative Book Series publishes texts that investigate the multiliteracies of digitally mediated spaces both within academia as well as other contexts. Rhetorical Code Studies: Discovering Arguments in and around Code Kevin Brock Developing Writers in Higher Education: A Longitudinal Study Anne Ruggles Gere, Editor Sites of Translation: What Multilinguals Can Teach Us about Digital Writing and Rhetoric Laura Gonzales Rhizcomics: Rhetoric, Technology, and New Media Composition Jason Helms Making Space: Writing, Instruction, Infrastrucure, and Multiliteracies James P. Purdy and Dànielle Nicole DeVoss, Editors Digital Samaritans: Rhetorical Delivery and Engagement in the Digital Humanities Jim Ridolfo diGitalculturebooks, an imprint of the University of Michigan Press, is dedicated to publishing work in new media studies and the emerging field of digital humanities. Revised Pages Rhetorical Code Studies discovering arguments in and around code Kevin Brock University of Michigan Press ann arbor Revised Pages Copyright © 2019 by Kevin Brock Some rights reserved This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Note to users: A Creative Commons license is only valid when it is applied by the person or entity that holds rights to the licensed work. Works may contain components (e.g., photo- graphs, illustrations, or quotations) to which the rightsholder in the work cannot apply the license. It is ultimately your responsibility to independently evaluate the copyright status of any work or component part of a work you use, in light of your intended use.
    [Show full text]
  • Horizontal PDF Slides
    1 2 The first 10 years of Curve25519 Abstract: “This paper explains the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done. free key compression, free key validation, and state-of-the-art 2005.09.15: Software online. timing-attack protection), 2005.09.20: Invited talk at ECC. more than twice as fast as other authors’ results at the same 2005.11.15: Paper online; conjectured security level (with submitted to PKC 2006. or without the side benefits).” 1 2 3 The first 10 years of Curve25519 Abstract: “This paper explains Elliptic-curve computations the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done. free key compression, free key validation, and state-of-the-art 2005.09.15: Software online. timing-attack protection), 2005.09.20: Invited talk at ECC. more than twice as fast as other authors’ results at the same 2005.11.15: Paper online; conjectured security level (with submitted to PKC 2006. or without the side benefits).” 1 2 3 The first 10 years of Curve25519 Abstract: “This paper explains Elliptic-curve computations the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done.
    [Show full text]
  • PHC: Status Quo
    PHC: status quo JP Aumasson @veorq / http://aumasson.jp academic background principal cryptographer at Kudelski Security, .ch applied crypto research and outreach BLAKE, BLAKE2, SipHash, NORX Crypto Coding Standard Password Hashing Competition Open Crypto Audit Project board member do you use passwords? this talk might interest you! Oct 2013 "hash" = 3DES-ECB( static key, password ) users' hint made the guess game easy... (credit Jeremi Gosney / Stricture Group) May 2014; "encrypted passwords" (?) last week that's only the reported/published cases Lesson if Adobe, eBay, and Avast fail to protect their users' passwords, what about others? users using "weak passwords"? ITsec people using "weak defenses"? developers using "weak hashes"? cryptographers, who never bothered? agenda 1. how (not) to protect passwords 2. the Password Hashing Competition (PHC) 3. the 24-2 PHC candidates 4. next steps, and how to contribute WARNING this is NOT about bikeshed topics as: password policies password managers password-strength meters will-technology-X-replace-passwords? 1. how (not) to protect passwords solution of the 60's store "password" or the modern alternative: obviously a bad idea (assuming the server and its DB are compromised) solution of the early 70's store hash("password") "one-way": can't be efficiently inverted vulnerable to: ● efficient dictionary attacks and bruteforce ● time-memory tradeoffs (rainbow tables, etc.) solution of the late 70's store hash("password", salt) "one-way": can't be efficiently inverted immune to time-memory tradeoffs vulnerable to: ● dictionary attacks and bruteforce (but has to be repeated for different hashes) solution of the 2000's store hash("password", salt, cost) "one-way": can't be efficiently inverted immune to time-memory tradeoffs inefficient dictionary attacks and bruteforce main ideas: ● be "slow" ● especially on attackers' hardware (GPU, FPGA) => exploit fast CPU memory access/writes PBKDF2 (Kaliski, 2000) NIST and PKCS standard in Truecrypt, iOS, etc.
    [Show full text]
  • Key Differentiation Attacks on Stream Ciphers
    Key differentiation attacks on stream ciphers Abstract In this paper the applicability of differential cryptanalytic tool to stream ciphers is elaborated using the algebraic representation similar to early Shannon’s postulates regarding the concept of confusion. In 2007, Biham and Dunkelman [3] have formally introduced the concept of differential cryptanalysis in stream ciphers by addressing the three different scenarios of interest. Here we mainly consider the first scenario where the key difference and/or IV difference influence the internal state of the cipher (∆key, ∆IV ) → ∆S. We then show that under certain circumstances a chosen IV attack may be transformed in the key chosen attack. That is, whenever at some stage of the key/IV setup algorithm (KSA) we may identify linear relations between some subset of key and IV bits, and these key variables only appear through these linear relations, then using the differentiation of internal state variables (through chosen IV scenario of attack) we are able to eliminate the presence of corresponding key variables. The method leads to an attack whose complexity is beyond the exhaustive search, whenever the cipher admits exact algebraic description of internal state variables and the keystream computation is not complex. A successful application is especially noted in the context of stream ciphers whose keystream bits evolve relatively slow as a function of secret state bits. A modification of the attack can be applied to the TRIVIUM stream cipher [8], in this case 12 linear relations could be identified but at the same time the same 12 key variables appear in another part of state register.
    [Show full text]
  • Modern Password Security for System Designers What to Consider When Building a Password-Based Authentication System
    Modern password security for system designers What to consider when building a password-based authentication system By Ian Maddox and Kyle Moschetto, Google Cloud Solutions Architects This whitepaper describes and models modern password guidance and recommendations for the designers and engineers who create secure online applications. A related whitepaper, Password security ​ for users, offers guidance for end users. This whitepaper covers the wide range of options to consider ​ when building a password-based authentication system. It also establishes a set of user-focused recommendations for password policies and storage, including the balance of password strength and usability. The technology world has been trying to improve on the password since the early days of computing. Shared-knowledge authentication is problematic because information can fall into the wrong hands or be forgotten. The problem is magnified by systems that don't support real-world secure use cases and by the frequent decision of users to take shortcuts. According to a 2019 Yubico/Ponemon study, 69 percent of respondents admit to sharing passwords with ​ ​ their colleagues to access accounts. More than half of respondents (51 percent) reuse an average of five passwords across their business and personal accounts. Furthermore, two-factor authentication is not widely used, even though it adds protection beyond a username and password. Of the respondents, 67 percent don’t use any form of two-factor authentication in their personal life, and 55 percent don’t use it at work. Password systems often allow, or even encourage, users to use insecure passwords. Systems that allow only single-factor credentials and that implement ineffective security policies add to the problem.
    [Show full text]
  • Mysql NDB Cluster 7.5.16 (And Later)
    Licensing Information User Manual MySQL NDB Cluster 7.5.16 (and later) Table of Contents Licensing Information .......................................................................................................................... 2 Licenses for Third-Party Components .................................................................................................. 3 ANTLR 3 .................................................................................................................................... 3 argparse .................................................................................................................................... 4 AWS SDK for C++ ..................................................................................................................... 5 Boost Library ............................................................................................................................ 10 Corosync .................................................................................................................................. 11 Cyrus SASL ............................................................................................................................. 11 dtoa.c ....................................................................................................................................... 12 Editline Library (libedit) ............................................................................................................. 12 Facebook Fast Checksum Patch ..............................................................................................
    [Show full text]
  • The Origins of Beowulf Between Anglo-Saxon Tradition and Christian Latin Culture
    The Origins of Beowulf Between Anglo-Saxon Tradition and Christian Latin Culture Autor: Rubén Abellán García Tutor: Agustí Alemany Villamajó Universitat Autònoma de Barcelona 2019-2020 Index 1. Introduction .............................................................................................................. 2 1.1. The structure and transmission of Beowulf. ......................................................... 2 1.2. Literacy context during the creation period of Beowulf ....................................... 3 1.3. Historical Oral-formulaic and literacy research in Old studies ............................. 3 2. Latin Tradition in Beowulf ........................................................................................ 5 2.1. Latin syntax in Beowulf ...................................................................................... 5 2.2. Literary devices .................................................................................................. 6 2.2.1. Alliteration ...................................................................................................... 7 2.2.2. Formulas .......................................................................................................... 7 2.2.3. Compounding and Kennings ............................................................................ 8 2.2.4. Rhymes............................................................................................................ 8 2.2.5. Litotes and irony .............................................................................................
    [Show full text]