DOCSLIB.ORG

Secret Messages

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Secret Messages DM-Crypt SYSADMIN Hard disk encryption with DM-Crypt, LUKS, and cryptsetup SECRET MESSAGES If you’re serious about keeping secrets, try hard disk encryption with DM-Crypt and LUKS. BY CLEMENS FRUHWIRTH AND MARKUS SCHUSTER www.sxc.hu ile encryption is a popular means construct some of your file data – by access this block device to set up and for ensuring the security and pri- snooping through secret files, temporary mount the filesystem. This article exam- Fvacy of file-based data. An in- files, configuration data, and command ines the technology that underlies DM- truder who breaks through your firewall histories. The /var/spool/cups directory, Crypt and the new LUKS (Linux Unified won’t be able to read your private files if for example, could yield a treasure trove Key Setup) management tool. they are encrypted, right? of data about files you might have Actually, selective file encryption pro- printed in the past, and tools such as the En Route to a Crypto Setup vided by utilities such as GnuPG covers Gnome Thumbnail Factory could be DM-Crypt builds on a flexible layer some of your tracks, but it may not cover storing an unencrypted thumbnail of known as the device mapper. Device all of them. An intruder can still learn your encrypted images. mapper modules are configured via so- about your system – and maybe even re- Rather than combing through every called DM Tables – simple text files that action performed on every file to remove specify how the device mapper should Clemens Fruhwirth is the author of any trace of the data, Linux users can handle access to areas of the virtual LUKS and a white paper entitled choose to encrypt data at a deeper level disk. The dmsetup program parses these “New Methods in Hard Disk Encryp- using DM-Crypt. The dm-crypt kernel text files and uses ioctl() calls to pass the tion,” which defines the underlying module works at the block device level, details to the kernel. theories. Clemens is also the inven- tor of ESSIV and the implementor of enabling users to encrypt whole parti- The DM table format for DM-Crypt is LRW-AES and EME for Linux. tions. The process is transparent to the very clumsy for daily use. The software Markus Schuster is a system inte- application, provided the user has been expects the key to be a fixed length hexa- grator with Bits & Bytes (a Bavarian granted access to the data. DM-Crypt en- decimal string. The module uses the key IT service provider); he refers to crypts the so-called backing device (the to encrypt the block device data. How- THEAUTHORS himself as a free software all- physical disk) and uses a virtual block ever, storing the key permanently in a rounder and has been using LUKS device to provide access to the cleartext DM table file is just like leaving your ever since its inception. content below /dev/mapper. Users can door key hanging on the door knob. In- WWW.LINUX - MAGAZINE.COM ISSUE 61 DECEMBER 2005 65 SYSADMIN DM-Crypt stead, the key needs to be entered when- what to do with a set of encrypted infor- password, directly to the kernel. The ever you mount the device. mation from the encrypted information. major drawback to this approach is that Typing up to 32 hex characters from The cryptsetup parameters are mostly the software needs to re-encrypt all data memory may not be easy, but cryptsetup located in scripts or configuration files whenever the password is changed. can help. cryptsetup is a tool that gener- which, obviously, can’t be on the en- cryptsetup-LUKS introduces an addi- ates a cryptographic key from a (more crypted partitions. If you lose these files tional password management layer to re- simple) pass phrase, then passes the key or can’t remember the settings for a por- move this need. The key hierarchy in- to the kernel. Figure 1 shows you the table disk, you will lose access to your serts an extra encryption layer between cryptsetup environment. encrypted data. LUKS (Linux Unified the derived key and the key used by the Two important cryptsetup features can Key Setup) removes this segregation. kernel to protect the data on the parti- be parametrized: key generation and en- LUKS is a formal standard [3], imple- tion. Thus, the derived key only protects cryption. The former specifies how mented by the cryptsetup-LUKS tool [4] the so-called master key. which encrypts cryptsetup will generate a key from a (Figure 2). The latter is a fork of the the data on the partition (Figure 2). password supplied by a user. This de- original cryptsetup. LUKS defines a To change the password, cryptsetup- faults to a hash algorithm, which gives header for DM-Crypt partitions (Figure LUKS decrypts the master key using the the user the freedom of selecting a pass- 3); the header includes all the informa- old password, re-encrypts the key using word of any length. The hash will com- tion for safe key generation. As the the new password, and overwrites the press the information to provide a fixed header is part of the encrypted partition, copy of the old master key with the new number of bytes. Figure 1 shows crypt- the settings are always available right value. As the cleartext master key is not setup using its defaults: the Ripemd-160 where they are needed. affected by this process, the encrypted hash generates a 256-bit key. cryptsetup-LUKS and the original partition data remains valid. This can Two parameters need to be selected cryptsetup also differ with respect to the save you half a day’s work if you need for the encryption process: the algorithm way they generate a key from a pass- to decrypt 120GBytes; the key hierarchy and the mode. cryptsetup passes these phrase (Figure 2). LUKS password man- reduces the time needed to change a parameters and the derived key to the agement is based on three concepts: key password to just a few seconds. kernel, and the DM-Crypt module coor- hierarchies, PBKDF2, and anti-forensic LUKS stores the encrypted master in dinates the procedure, using the Crypto- information storage. the partition header without imposing a API to handle encryption. single copy restriction. To support multi- Secure Password ple passwords for a single partition, Use the Force, LUKS Management LUKS can store multiple, equivalent cop- Unfortunately, there is a downside to The legacy cryptsetup application passes ies of the master key and encrypt each cryptsetup. It separates the details on the key, which is generated from the one of them with a different string. Each Password Hash settings Password Encryption parameters Backing Cryptsetup-LUKS m Bit Cryptsetup Block device (User space) (User space) Partition header Hash m Bit PBKDF2 settings 256 Bit Cipher: AES Hash Modus: Mode: CBC Key Decipher IV Mode: Plain Ripemd 160 256 Bit material master key Encryption DM Table settings DM-Crypt Interface DM Table (Kernel space) DM Crypt Interface /dev/mapper/Virtual_Mapping (Kernelspace) Backing Crypt Engine Block device Backing /dev/mapper/Virtual_Mapping Crypt Engine Blockdevice Crypto API IV Generator Crypto API IV Generator AES-CBC Plain AES-CBC Plain Figure 1: cryptsetup (top) prompts the user for a password and uses a Figure 2: cryptsetup-LUKS stores the parameters for the encrypted hash to create a fixed length key, which it then passes on to the ker- partition in the backing block device partition header (top left). The nel (center). DM-Crypt (bottom) uses the key to encrypt and decrypt derived key protects the master key, which encrypts the data on the data on the hard disk (or backing block device). partition. 66 ISSUE 61 DECEMBER 2005 WWW.LINUX - MAGAZINE.COM DM-Crypt SYSADMIN domain and the the dictionary. In fact, the attacker Partition header key domain. Sim- would need the hashes for each word in LUKS version Encryption algorithm ple padding would the dictionary and for every combination Encryption mode produce a bigger of the appended string. The longer the Size of master key Master key checksum key, but it would salt, the bigger the attacker’s table UUID be no more ran- would need to be. PBKDF2 pushes the dom than the size of the table to an unimaginable password, and scale. The universe has fewer atoms thus it would be than the number of entries the universal Header Slot 1 Slot 2 ... Slot 8 Encrypted data just as easily dictionary would need to contain every guessed. single PBKDF2 combination. Let’s imagine With all hope of using tables dwin- Key Slot 1 that a user entered dling, attackers are forced back to num- Encrypted copy of master key only English ber crunching. The legacy Unix pass- PBKDF2 salt parameter PBKDF2 stretch parameter words; this would word mechanism uses a similar ap- restrict the scope proach, by the way: however, the salt is Figure 3: LUKS adds the parameters needed by cryptsetup-LUKS to of the password a lot shorter in this case (12 bits stored generate the key from a password entered by a user to the header of domain and not in the first two digits.) the encrypted partition. Each key slot contains an encrypted copy of provide enough the master key which DM-Crypt uses for data protection. entropy. An at- Shredding tacker could sim- As we mentioned earlier, data shredding of these passwords gives the user access ply run a dictionary attack instead of on magnetic storage devices is very diffi- to the cleartext content on the disk. This trying the 2128 keys that a 128-bit key cult to perform [2].
Load more

Recommended publications
  • FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 Kernel Crypto
    FIPS 140-2 Non-Proprietary Security Policy Oracle Linux 7 Kernel Crypto API Cryptographic Module FIPS 140-2 Level 1 Validation Software Version: R7-2.0.0 Date: December 7, 2018 Document Version 1.1 ©Oracle Corporation This document may be reproduced whole and intact including the Copyright notice. Title: Oracle Linux 7 Kernel Crypto API Cryptographic Module Security Policy December 07, 2018 Author: Atsec Information Security Contributing Authors: Oracle Linux Engineering Oracle Security Evaluations – Global Product Security Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2018, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may reproduced or distributed whole and intact including this copyright notice. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux 7 Kernel Crypto API Cryptographic
    [Show full text]
  • Namespacing in Selinux
    Namespacing in SELinux Linux.conf.au 2018 Sydney, Australia James Morris [email protected] Introduction ● Who am I? – Linux security subsystem maintainer ● Previously: Crypto API, Netfilter, SELinux, LSM, IPSec, MCS, sVirt ● Recovering manager ● blog.namei.org ● @xjamesmorris ● Overview – Briefly review technologies – Discuss requirements – SELinux namespace prototype – Current work: inode labeling – Future work SELinux ● Label-based mandatory access control (MAC) – Set security labels on: ● Subjects ● Objects – Define permissions – Centrally managed policy – Enforced by kernel ● Generalized ● Separation of policy and mechanism Linux Security Modules (LSM) ● Kernel API for access control ● Hooks – Located at security decision points – All security relevant information available – Race-free ● Kind of like Netfilter but for the whole kernel ● Pluggable: Smack, SELinux, AppArmor etc. Linux Namespaces ● Private views of global resources – mount, network, ipc, pid, user, uts, cgroup ● APIs: clone(2), setns(2), unshare(2) ● See also: pam_namespace(8) ● Uses: – Sandboxes – Containers – Multi-level security (!) ● No namespacing of LSM or other security APIs Containers ● Not a Thing ™ ● Actually namespaces + cgroups + magic – Docker, lxc, lxd etc. ● Very popular ● Kernel security APIs not containerized, e.g. – Limits functionality for OS-like containers – SELinux on Fedora-based distros pretends to be disabled inside container, and yet … ! Use Cases ● Enable SELinux confinement within a container – Currently runs as one global label and appears
    [Show full text]
  • Speeding up Linux Disk Encryption Ignat Korchagin @Ignatkn $ Whoami
    Speeding Up Linux Disk Encryption Ignat Korchagin @ignatkn $ whoami ● Performance and security at Cloudflare ● Passionate about security and crypto ● Enjoy low level programming @ignatkn Encrypting data at rest The storage stack applications @ignatkn The storage stack applications filesystems @ignatkn The storage stack applications filesystems block subsystem @ignatkn The storage stack applications filesystems block subsystem storage hardware @ignatkn Encryption at rest layers applications filesystems block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers applications filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers applications ecryptfs, ext4 encryption or fscrypt filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Encryption at rest layers DBMS, PGP, OpenSSL, Themis applications ecryptfs, ext4 encryption or fscrypt filesystems LUKS/dm-crypt, BitLocker, FileVault block subsystem SED, OPAL storage hardware @ignatkn Storage hardware encryption Pros: ● it’s there ● little configuration needed ● fully transparent to applications ● usually faster than other layers @ignatkn Storage hardware encryption Pros: ● it’s there ● little configuration needed ● fully transparent to applications ● usually faster than other layers Cons: ● no visibility into the implementation ● no auditability ● sometimes poor security https://support.microsoft.com/en-us/help/4516071/windows-10-update-kb4516071 @ignatkn Block
    [Show full text]
  • Red Hat Enterprise Linux Kernel Crypto API Cryptographic Module V4.0
    Red Hat Enterprise Linux Kernel Crypto API Cryptographic Module v4.0 FIPS 140-2 Non-Proprietary Security Policy Version 1.2 Last update: 2016-08-29 Prepared by: atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 www.atsec.co m ©2016 Red Hat Enterprise Linux / atsec information security corporation Page 1 of 24 This document can be reproduced and distributed only whole and intact, including this copyright notice. Red Hat Enterprise Linux Kernel Crypto API Cryptographic Module v4.0 FIPS 140-2 Non-Proprietary Security Policy Table of Contents 1Cryptographic Module Specification........................................................................................4 1.1Module Overview...........................................................................................................4 1.2FIPS 140-2 validation.....................................................................................................6 1.3Modes of Operations......................................................................................................7 2Cryptographic Module Ports and Interfaces.............................................................................8 3Roles, Services and Authentication.........................................................................................9 3.1Roles.............................................................................................................................. 9 3.2Services........................................................................................................................
    [Show full text]
  • Demystifying Internet of Things Security Successful Iot Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M
    Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment — Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Ned Smith David M. Wheeler Demystifying Internet of Things Security: Successful IoT Device/Edge and Platform Security Deployment Sunil Cheruvu Anil Kumar Chandler, AZ, USA Chandler, AZ, USA Ned Smith David M. Wheeler Beaverton, OR, USA Gilbert, AZ, USA ISBN-13 (pbk): 978-1-4842-2895-1 ISBN-13 (electronic): 978-1-4842-2896-8 https://doi.org/10.1007/978-1-4842-2896-8 Copyright © 2020 by The Editor(s) (if applicable) and The Author(s) This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons license, unless indicated otherwise in a credit line to the material.
    [Show full text]
  • I.MX Encrypted Storage Using CAAM Secure Keys Rev
    AN12714 i.MX Encrypted Storage Using CAAM Secure Keys Rev. 1 — 11/2020 Application Note Contents 1 Preface 1 Preface............................................1 Devices often contain highly sensitive information which is consistently at risk 1.1 Intended audience and scope......1 1.2 References...................................1 to get physically lost or stolen. Setting user passwords does not guarantee data 2 Overview......................................... 1 protection against unauthorized access. The attackers can simply bypass the 2.1 DM-Crypt......................................1 software system of a device and access the data storage directly. Only the 2.2 DM-Crypt accelerated by CAAM use of encryption can guarantee data confidentiality in the case where storage .....................................................2 media is directly accessed. 2.3 DM-Crypt using CAAM's Secure Key...............................................3 This document provides steps to run a transparent storage encryption at block 3 Hands-On........................................4 level using DM-Crypt taking advantage of the secure key feature provided 3.1 Installation....................................4 by i.MXs Cryptographic Accelerator and Assurance Module (CAAM). The 3.2 Usage...........................................6 document applies to all i.MX SoCs having CAAM module. The feature is not 3.3 Performance................................ 9 available on i.MX SoCs with DCP. 4 Revision History............................ 10 5 Appendix A. Configuration...........
    [Show full text]
  • Evasive Internet Protocol: End to End Performance
    EVASIVE INTERNET PROTOCOL: END TO END PERFORMANCE By Maaz Khan Submitted in partial fulfillment of the requirements for the Degree of Master of Science Thesis Advisor: Prof. Michael Rabinovich Department of Electrical Engineering and Computer Science CASE WESTERN RESERVE UNIVERSITY August 2011 CASE WESTERN RESERVE UNIVERSITY SCHOOL OF GRADUATE STUDIES We hereby approve the thesis/dissertation of Maaz Khan ______________________________________________________ Masters candidate for the ________________________________degree *. Michael Rabinovich (signed)_______________________________________________ (chair of the committee) Mehmet Koyuturk ________________________________________________ Vincenzo Liberatore ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ 06/09/2011 (date) _______________________ *We also certify that written approval has been obtained for any proprietary material contained therein. Contents Contents i List of Figures iii Abstract iv Chapter 1 Introduction 1 1.1 Basic Approach . 2 1.2 Security and feasibility . 3 Chapter 2 Architecture 6 2.1 Delegation of Authority . 6 2.2 T-Address . .8 2.3 Datagrams . 9 2.4 Obtaining a Destination T-address. 13 Chapter 3 Packet Modification using Netfilter Framework 15 3.1 The Packet Buffer . 15 3.1.1 SKB basic management functiuons . 18 3.2 The Netfilter API . .20 i 3.2.1 Netfilter Hooks . .21 3.2.2 Registering and Unregistering hook functions . .23 Chapter 4 Implementation 27 4.1 Components . 28 4.2 Changing the MSS . 31 Chapter 5 Performance 33 5.1 Experiment Setup . 33 5.2 TCP v/s EIP Performance . ..35 5.3 UDP v/s EIP Performance . .39 Chapter 6 Conclusion 43 References 44 ii List of Figures 1. T-Address . .. .. .. .. 9 2. Type-1 Datagram . .. .. .. 11 3. Type-2 Datagram . 11 4.
    [Show full text]
  • Optimizing Dm-Crypt for XTS-AES: Getting the Best of Atmel Cryptographic Co-Processors
    Optimizing dm-crypt for XTS-AES: Getting the Best of Atmel Cryptographic Co-processors Levent Demir1;2, Mathieu Thiery1;2, Vincent Roca1, Jean-Michel Tenkes2 and Jean-Louis Roch3 1Incas ITSec, France 2Univ. Grenoble Alpes, Inria, France 3Univ. Grenoble Alpes, Grenoble INP, LIG, France Keywords: Full Disk Encryption, XTS-AES, Linux dm-crypt Module, Cryptographic Co-processor, Atmel Board. Abstract: Linux implementation of Full Disk Encryption (FDE) relies on the dm-crypt kernel module, and is based on the XTS-AES encryption mode. However, XTS-AES is complex and can quickly become a performance bot- tleneck. Therefore we explore the use of cryptographic co-processors to efficiently implement the XTS-AES mode in Linux. We consider two Atmel boards that feature different cryptographic co-processors: the XTS- AES mode is completely integrated on the recent SAMA5D2 board but not on the SAMA5D3 board. We first analyze three XTS-AES implementations: a pure software implementation, an implementation that leverages the XTS-AES co-processor, and an intermediate solution. This work leads us to propose an optimization of dm-crypt, the extended request mode, that enables to encrypt/decrypt a full 4kB page at once instead of issu- ing eight consecutive 512 bytes requests as in the current implementation. We show that major performance gains are possible with this optimization, a SAMA5D3 board reaching the performance of a SAMA5D2 board where XTS-AES operations are totally offloaded to the dedicated cryptographic co-processor, while remaining fully compatible with the standard. Finally, we explain why bad design choices prevent this optimization to be applied to the new SAMA5D2 board and derive recommendations for future co-processor designs.
    [Show full text]
  • FIPS 140-2 Non-Proprietary Security Policy Oracle Linux Openssl
    FIPS 140-2 Non-Proprietary Security Policy Oracle Linux OpenSSL Cryptographic Module FIPS 140-2 Level 1 Validation Software Version: R7-3.0.0 and R7-4.0.0 Date: May 23rd, 2019 Document Version 2.0 ©Oracle Corporation This document may be reproduced whole and intact including the Copyright notice. Title: Oracle Linux OpenSSL Cryptographic Module Security Policy Date: May 23rd, 2019 Author: Oracle Security Evaluations – Global Product Security Contributing Authors: Oracle Linux Engineering Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright © 2019, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Oracle specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may reproduced or distributed whole and intact including this copyright notice. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. Oracle Linux OpenSSL Cryptographic Module Security Policy i TABLE OF CONTENTS Section
    [Show full text]
  • Building Secure and Reliable Systems
    Building Secure & Reliable Systems Best Practices for Designing, Implementing and Maintaining Systems Compliments of Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea & Adam Stubblefi eld Praise for Building Secure and Reliable Systems It is very hard to get practical advice on how to build and operate trustworthy infrastructure at the scale of billions of users. This book is the first to really capture the knowledge of some of the best security and reliability teams in the world, and while very few companies will need to operate at Google’s scale many engineers and operators can benefit from some of the hard-earned lessons on securing wide-flung distributed systems. This book is full of useful insights from cover to cover, and each example and anecdote is heavy with authenticity and the wisdom that comes from experimenting, failing and measuring real outcomes at scale. It is a must for anybody looking to build their systems the correct way from day one. —Alex Stamos, Director of the Stanford Internet Observatory and former CISO of Facebook and Yahoo This book is a rare treat for industry veterans and novices alike: instead of teaching information security as a discipline of its own, the authors offer hard-wrought and richly illustrated advice for building software and operations that actually stood the test of time. In doing so, they make a compelling case for reliability, usability, and security going hand-in-hand as the entirely inseparable underpinnings of good system design. —Michał Zalewski, VP of Security Engineering at Snap, Inc. and author of The Tangled Web and Silence on the Wire This is the “real world” that researchers talk about in their papers.
    [Show full text]
  • Linux Kernel Crypto API Manual Release 4.13.0-Rc4+
    Linux Kernel Crypto API manual Release 4.13.0-rc4+ The kernel development community Sep 05, 2017 CONTENTS 1 Kernel Crypto API Interface Specification 3 1.1 Introduction ................................................. 3 1.2 Terminology ................................................. 3 2 Kernel Crypto API Architecture 5 2.1 Cipher algorithm types .......................................... 5 2.2 Ciphers And Templates .......................................... 5 2.3 Synchronous And Asynchronous Operation .............................. 6 2.4 Crypto API Cipher References And Priority ............................... 6 2.5 Key Sizes ................................................... 7 2.6 Cipher Allocation Type And Masks .................................... 7 2.7 Internal Structure of Kernel Crypto API ................................. 8 3 Developing Cipher Algorithms 11 3.1 Registering And Unregistering Transformation ............................. 11 3.2 Single-Block Symmetric Ciphers [CIPHER] ............................... 11 3.3 Multi-Block Ciphers ............................................. 12 3.4 Hashing [HASH] ............................................... 13 4 User Space Interface 15 4.1 Introduction ................................................. 15 4.2 User Space API General Remarks .................................... 15 4.3 In-place Cipher operation ......................................... 16 4.4 Message Digest API ............................................ 16 4.5 Symmetric Cipher API ..........................................
    [Show full text]
  • Documentation and Analysis of the Linux Random Number Generator
    Documentation and Analysis of the Linux Random Number Generator Version: 3.6 Document history Version Date Editor Description 2.0 2018-03-21 Stephan Müller Covering kernel 4.15 Re-running all tests of chapters 6 and following on 4.15 2.1 2018-04-11 Stephan Müller Updating the test results for the reboot tests on bare metal with 50,000 reboot cycles 2.2 2018-04-11 Stephan Müller Covering kernel 4.16 2.3 2018-06-18 Stephan Müller Covering kernel 4.17 2.4 2018-08-24 Stephan Müller Covering kernel 4.18 2.5 2018-11-12 Stephan Müller Covering kernel 4.19 Updated seeding process ChaCha20 DRNG documented 2.6 2019-01-11 Stephan Müller Covering kernel 4.20 3.0 2019-04-05 Stephan Müller Covering kernel 5.0 Re-running all tests of chapters 6 and following on 5.0 3.1 2019-04-12 Stephan Müller Adding results of reboot-tests for 5.0 3.2 2019-05-17 Stephan Müller Addressing comments from BSI Covering kernel 5.1 3.3 2019-08-13 Stephan Müller Covering kernel 5.2 3.4 2019-09-26 Stephan Müller Covering kernel 5.3 3.5 2019-12-13 Stephan Müller Covering kernel 5.4 3.6 2020-04-07 Stephan Müller Covering kernel 5.5 Federal Office for Information Security Post Box 20 03 63 D-53133 Bonn Internet: https://www.bsi.bund.de © Federal Office for Information Security 2020 Document history This analysis was prepared for BSI by atsec information security GmbH.
    [Show full text]