DOCSLIB.ORG

Vmware Java JCE (Java Cryptographic Extension) Module Software Version: 2.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

VMware, Inc. 3401 Hillview Ave Palo Alto, CA 94304, USA Tel: 877-486-9273 Email: [email protected] http://www. vmware.com VMware Java JCE (Java Cryptographic Extension) Module Software Version: 2.0 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 0.5 Security Policy, Version 0.5 VMware Java JCE (Java Cryptographic Extension) Module TABLE OF CONTENTS 1 Introduction .................................................................................................................................................. 4 1.1 Purpose......................................................................................................................................................... 4 1.2 Reference ..................................................................................................................................................... 4 2 VMware Java JCE (Java Cryptographic Extension) Module ............................................................................ 5 2.1 Introduction .................................................................................................................................................. 5 2.1.1 VMware Java JCE (Java Cryptographic Extension) Module ...................................................................... 5 2.2 Module Specification .................................................................................................................................... 5 2.2.1 Physical Cryptographic Boundary ............................................................................................................ 6 2.2.2 Logical Cryptographic Boundary .............................................................................................................. 6 2.2.3 Modes of Operation ................................................................................................................................. 8 2.2.4 Module Configuration .............................................................................................................................. 8 2.3 Module Interfaces ........................................................................................................................................ 9 2.4 Roles, Authentication and Services ............................................................................................................ 10 2.4.1 Assumption of Roles .............................................................................................................................. 10 2.4.2 Services .................................................................................................................................................. 10 2.5 Physical Security ......................................................................................................................................... 13 2.6 Operational Environment ........................................................................................................................... 14 2.6.1 Use of External RNG ............................................................................................................................... 15 2.7 Cryptographic Key Management ............................................................................................................... 15 2.7.1 Critical Security Parameters ................................................................................................................... 19 2.7.2 Public Keys ............................................................................................................................................. 21 2.8 Self-Tests .................................................................................................................................................... 22 3 Secure Operation ........................................................................................................................................ 24 3.1 Mitigation of Other Attacks Policy ............................................................................................................. 24 3.2 Basic Enforcement ...................................................................................................................................... 24 3.3 Additional Enforcement with a Java SecurityManager .............................................................................. 25 3.4 Basic Guidance ........................................................................................................................................... 25 3.5 Enforcement and Guidance for GCM IVs .................................................................................................... 25 3.6 Enforcement and Guidance for use of the Approved PBKDF ...................................................................... 26 4 References and Acronyms ........................................................................................................................... 27 March 15, 2017 Page 2 of 31 © 2017 VMware, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 VMware Java JCE (Java Cryptographic Extension) Module LIST OF FIGURES Figure 1 – Hardware Block Diagram ......................................................................................................... 6 Figure 2 – Module’s Logical Cryptographic Boundary ........................................................................... 7 LIST OF TABLES Table 1 – Security Level Per FIPS 140-2 Section ........................................................................................ 5 Table 2 – FIPS 140-2 Logical Interfaces ....................................................................................................... 7 Table 3 – Available Java Permissions .......................................................................................................... 8 Table 4 – FIPS 140-2 Logical Interface Mapping ......................................................................................... 9 Table 5 – Roles Description ........................................................................................................................ 10 Table 6 – Services ...................................................................................................................................... 10 Table 7 – CSP Access Rights within Services ............................................................................................ 12 Table 8 – Tested Configuration ................................................................................................................... 14 Table 9 – Approved and CAVP Validated Cryptographic Functions .......................................................... 15 Table 10 – Approved Cryptographic Functions Tested with Vendor Affirmation ........................................ 18 Table 11 – Non-Approved but Allowed Cryptographic Functions ............................................................... 18 Table 12 – Non-Approved Cryptographic Functions for use in non-FIPS mode only ................................. 18 Table 13 – Critical Security Parameters (CSPs) ......................................................................................... 20 Table 14 – Public Keys ............................................................................................................................... 21 Table 15 – Power Up Self-tests .................................................................................................................. 22 Table 16 – Conditional Self-tests ................................................................................................................ 23 Table 17 – References ................................................................................................................................ 27 Table 18 – Acronyms .................................................................................................................................. 28 March 15, 2017 Page 3 of 31 © 2017 VMware, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.5 VMware Java JCE (Java Cryptographic Extension) Module 1 INTRODUCTION 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the VMware Java JCE (Java Cryptographic Extension) Module from VMware, Inc. This Security Policy describes how the VMware Java JCE (Java Cryptographic Extension) Module meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-2, which details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp. This document also describes how to run the module in a secure FIPS-Approved mode of operation. The VMware Java JCE (Java Cryptographic Extension) Module is also referred to in this document as “the module”. 1.2 Reference This document deals only with operations and capabilities of the composite module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: The VMware website (http://www.vmware.com) contains
Recommended publications
  • IBM® Z/OS® Version 1 Release 12 System SSL Cryptographic Module

    IBM® Z/OS® Version 1 Release 12 System SSL Cryptographic Module

    z/OS Version 1 Release 12 System SSL Security Policy IBM® z/OS® Version 1 Release 12 System SSL Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Policy Version 1.01 IBM Systems & Technology Group System z Development Poughkeepsie, New York IBM Research Zurich Research Laboratory August 24, 2011 © Copyright International Business Machines Corporation 2011 This document may be reproduced only in its original entirety without revision. © Copyright IBM Corp. 2011 Page 1 of 31 z/OS Version 1 Release 12 System SSL Security Policy Table of Contents 1 SCOPE OF DOCUMENT .............................................................................................................................................................3 2 CRYPTOGRAPHIC MODULE SPECIFICATION...................................................................................................................4 3 CRYPTOGRAPHIC MODULE SECURITY LEVEL ...............................................................................................................5 4 PORTS AND INTERFACES ........................................................................................................................................................6 5 ROLES, SERVICES AND AUTHENTICATION.......................................................................................................................6 5.1 ROLES ......................................................................................................................................................................................6
  • Security + Encryption Standards

    Security + Encryption Standards

    Security + Encryption Standards Author: Joseph Lee Email: joseph@ ripplesoftware.ca Mobile: 778-725-3206 General Concepts Forward secrecy / perfect forward secrecy • Using a key exchange to provide a new key for each session provides improved forward secrecy because if keys are found out by an attacker, past data cannot be compromised with the keys Confusion • Cipher-text is significantly different than the original plaintext data • The property of confusion hides the relationship between the cipher-text and the key Diffusion • Is the principle that small changes in message plaintext results in large changes in the cipher-text • The idea of diffusion is to hide the relationship between the cipher-text and the plaintext Secret-algorithm • A proprietary algorithm that is not publicly disclosed • This is discouraged because it cannot be reviewed Weak / depreciated algorithms • An algorithm that can be easily "cracked" or defeated by an attacker High-resiliency • Refers to the strength of the encryption key if an attacker discovers part of the key Data-in-transit • Data sent over a network Data-at-rest • Data stored on a medium Data-in-use • Data being used by an application / computer system Out-of-band KEX • Using a medium / channel for key-exchange other than the medium the data transfer is taking place (phone, email, snail mail) In-band KEX • Using the same medium / channel for key-exchange that the data transfer is taking place Integrity • Ability to determine the message has not been altered • Hashing algorithms manage Authenticity
  • ONVIF™ Advanced Security Test Specification

    ONVIF™ Advanced Security Test Specification

    ONVIF Advanced Security Test Specification Version 17.06 ONVIF™ Advanced Security Test Specification Version 17.06 June 2017 www.onvif.org ONVIF Advanced Security Test Specification Version 17.06 © 2017 ONVIF, Inc. All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so long as this copyright notice, license and disclaimer are retained with all copies of the document. No license is granted to modify this document. THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT. THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION. 2 www.onvif.org ONVIF Advanced Security Test Specification Version 17.06 REVISION HISTORY Vers.
  • Cs 255 (Introduction to Cryptography)

    Cs 255 (Introduction to Cryptography)

    CS 255 (INTRODUCTION TO CRYPTOGRAPHY) DAVID WU Abstract. Notes taken in Professor Boneh’s Introduction to Cryptography course (CS 255) in Winter, 2012. There may be errors! Be warned! Contents 1. 1/11: Introduction and Stream Ciphers 2 1.1. Introduction 2 1.2. History of Cryptography 3 1.3. Stream Ciphers 4 1.4. Pseudorandom Generators (PRGs) 5 1.5. Attacks on Stream Ciphers and OTP 6 1.6. Stream Ciphers in Practice 6 2. 1/18: PRGs and Semantic Security 7 2.1. Secure PRGs 7 2.2. Semantic Security 8 2.3. Generating Random Bits in Practice 9 2.4. Block Ciphers 9 3. 1/23: Block Ciphers 9 3.1. Pseudorandom Functions (PRF) 9 3.2. Data Encryption Standard (DES) 10 3.3. Advanced Encryption Standard (AES) 12 3.4. Exhaustive Search Attacks 12 3.5. More Attacks on Block Ciphers 13 3.6. Block Cipher Modes of Operation 13 4. 1/25: Message Integrity 15 4.1. Message Integrity 15 5. 1/27: Proofs in Cryptography 17 5.1. Time/Space Tradeoff 17 5.2. Proofs in Cryptography 17 6. 1/30: MAC Functions 18 6.1. Message Integrity 18 6.2. MAC Padding 18 6.3. Parallel MAC (PMAC) 19 6.4. One-time MAC 20 6.5. Collision Resistance 21 7. 2/1: Collision Resistance 21 7.1. Collision Resistant Hash Functions 21 7.2. Construction of Collision Resistant Hash Functions 22 7.3. Provably Secure Compression Functions 23 8. 2/6: HMAC And Timing Attacks 23 8.1. HMAC 23 8.2.
  • Troubleshoot PKCS#12 File Installation Failure with Non-FIPS Compliant PBE Algorithms

    Troubleshoot PKCS#12 File Installation Failure with Non-FIPS Compliant PBE Algorithms

    Troubleshoot PKCS#12 File Installation Failure with Non-FIPS Compliant PBE Algorithms Contents Introduction Background Information Prerequisites Requirements Components Used Problem Solution Verification Introduction This document describes how to troubleshoot the installation failure of a Public Key Cryptography Standards (PKCS)#12 file with non-Federal Information Processing Standard (FIPS) compliant Password-Based Encryption (PBE) algorithms via Cisco Firepower Management Center (FMC). It explains a procedure to identify it and to create a new compliant bundle with OpenSSL. Background Information The Cisco Firepower Threat Defense (FTD) supports compliance with FIPS 140 when you enable Common Criteria (CC) or Unified Capabilities Approved Products List (UCAP) mode on a managed device. This configuration is part of a FMC Platform Settings policy. After applied, the fips enable command appears in the show running-config output of FTD. PKCS#12 defines a file format used to bundle a private key and the respective identity certificate. There is the option to include any root or intermediate certificate that belongs to the validation chain as well. PBE algorithms protect the certificates and private key portions of the PKCS#12 file. As a result of the combination of the Message Authentication Scheme (MD2/MD5/SHA1) and the Encryption scheme (RC2/RC4/DES), there are multiple PBE algorithms but the only one that is FIPS compliant is PBE-SHA1-3DES. Note: To learn more about FIPS in Cisco products navigate to FIPS 140. Note: To learn more about the security certifications standards available for FTD and FMC navigate to the Security Certifications Compliance chapter of the FMC Configuration Guide.
  • SSL Certificates Avi Networks — Technical Reference (18.1)

    SSL Certificates Avi Networks — Technical Reference (18.1)

    Page 1 of 6 SSL Certificates Avi Networks — Technical Reference (18.1) SSL Certificates view online Avi Vantage supports terminating client SSL and TLS connections at the virtual service. This requires Avi Vantage to send a certificate to clients that authenticates the site and establishes secure communications. A virtual service that handles secure connections will require both of the following: SSL/TLS profile: Determines the supported ciphers and versions. See SSL Profile. SSL certificate: A certificate is presented to clients connecting to the site. SSL certificates may also be used to present to administrators connecting to the Avi Vantage web interface or API, and also for Avi Service Engines to present to servers when SE-to-server encryption is required with client (the SE) authentication. The SSL Certifications tab on the Templates > Security page shown below supports import, export, and generation of SSL certificates or certificate requests. From this page different kinds of certificates may be created: Newly-created certificates may be either self-signed by Avi Vantage or created as a certificate signing request (CSR) that must be sent to a trusted certificate authority (CA), which then generates a trusted certificate. Creating a self-signed certificate generates both the certificate and a corresponding private key. Imported existing certificates are not valid until a matching key has been supplied. Avi Vantage supports PEM and PKCS #12 formatted certificates. Copyright © 2018 Avi Networks, Inc. Page 2 of 6 SSL Certificates Avi Networks — Technical Reference (18.1) SSL/TLS Certificates Page Select Templates > SSL/TLS Certificates to open the SSL/TLS Certificates page.
  • HP Laserjet Pro Devices – Installing 2048 Bit SSL Certificates

    HP Laserjet Pro Devices – Installing 2048 Bit SSL Certificates

    Technical white paper HP LaserJet Pro Devices – Installing 2048 bit SSL certificates Table of Contents Disclaimer 2 Introduction 2 Generating a Certificate Signing Request 2 The normal process 2 HP LaserJet Pro devices that support generating a 2048 bit certificate request 4 When the printer cannot generate a Certificate Request for 2048 bit certificates 5 Method 1 – Software supplied by the CA 5 Method 2 – OpenSSL 10 Obtaining a certificate from the CA 12 Installing the Certificate into the Printer 14 Converting the Certificate to the Personal Information Exchange (.PFX) format 15 Method 1 – Software supplied by the CA 15 Method 2 - OpenSSL 20 Installing the new certificate 21 Applicable Products 25 For more information 26 Call to action 26 Disclaimer This document makes reference to certain products and/or services provided by third parties. These references are provided for example and demonstration purposes only and are not intended as an endorsement of any products, services, or companies. Introduction A recent publication of the National Institute of Standards and Technology (NIST Special Publication 800-131A) announced that the use of 1024 bit SSL/TLS certificates is no longer recommended and will be “disallowed” after December 31, 2013. The publication recommends the use of 2048 bit certificates to maintain network security and integrity. As a result, most Certificate Authorities (CAs) will no longer issue 1024 bit certificates. And, most Web browsers will no longer honor such certificates as safe and secure. In order to avoid error messages and the risk of a security breach, systems and devices that rely on the SSL/TLS protocols will need to have 2048 bit Certificates installed.
  • FIPS 140-2 Non-Proprietary Security Policy Forcepoint Java Crypto Module

    FIPS 140-2 Non-Proprietary Security Policy Forcepoint Java Crypto Module

    FIPS 140-2 Non-Proprietary Security Policy: Forcepoint Java Crypto Module FIPS 140-2 Non-Proprietary Security Policy Forcepoint Java Crypto Module Software Version 3.0.1 Document Version 1.2 December 21, 2017 Prepared For: Prepared By: Forcepoint SafeLogic Inc. 10900-A Stonelake Blvd. 530 Lytton Ave Quarry Oaks 1 Suite 200 Ste. 350 Palo Alto, CA 94301 Austin, TX 78759 www.safelogic.com www.forcepoint.com Document Version 1.2 © Forcepoint Page 1 of 35 FIPS 140-2 Non-Proprietary Security Policy: Forcepoint Java Crypto Module Abstract This document provides a non-proprietary FIPS 140-2 Security Policy for the Forcepoint Java Crypto Module. Document Version 1.2 © Forcepoint Page 2 of 35 FIPS 140-2 Non-Proprietary Security Policy: Forcepoint Java Crypto Module Table of Contents 1 Introduction .............................................................................................................................................. 5 1.1 About FIPS 140 ............................................................................................................................................. 5 1.2 About this Document .................................................................................................................................... 5 1.3 External Resources ....................................................................................................................................... 5 1.4 Notices .........................................................................................................................................................
  • Cryptanalysis of Selected Block Ciphers

    Cryptanalysis of Selected Block Ciphers

    Downloaded from orbit.dtu.dk on: Sep 24, 2021 Cryptanalysis of Selected Block Ciphers Alkhzaimi, Hoda A. Publication date: 2016 Document Version Publisher's PDF, also known as Version of record Link back to DTU Orbit Citation (APA): Alkhzaimi, H. A. (2016). Cryptanalysis of Selected Block Ciphers. Technical University of Denmark. DTU Compute PHD-2015 No. 360 General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. Cryptanalysis of Selected Block Ciphers Dissertation Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy at the Department of Mathematics and Computer Science-COMPUTE in The Technical University of Denmark by Hoda A.Alkhzaimi December 2014 To my Sanctuary in life Bladi, Baba Zayed and My family with love Title of Thesis Cryptanalysis of Selected Block Ciphers PhD Project Supervisor Professor Lars R. Knudsen(DTU Compute, Denmark) PhD Student Hoda A.Alkhzaimi Assessment Committee Associate Professor Christian Rechberger (DTU Compute, Denmark) Professor Thomas Johansson (Lund University, Sweden) Professor Bart Preneel (Katholieke Universiteit Leuven, Belgium) Abstract The focus of this dissertation is to present cryptanalytic results on selected block ci- phers.
  • Cryptanalysis of Block Ciphers

    Cryptanalysis of Block Ciphers

    Cryptanalysis of Block Ciphers Jiqiang Lu Technical Report RHUL–MA–2008–19 30 July 2008 Royal Holloway University of London Department of Mathematics Royal Holloway, University of London Egham, Surrey TW20 0EX, England http://www.rhul.ac.uk/mathematics/techreports CRYPTANALYSIS OF BLOCK CIPHERS JIQIANG LU Thesis submitted to the University of London for the degree of Doctor of Philosophy Information Security Group Department of Mathematics Royal Holloway, University of London 2008 Declaration These doctoral studies were conducted under the supervision of Prof. Chris Mitchell. The work presented in this thesis is the result of original research carried out by myself, in collaboration with others, whilst enrolled in the Information Security Group of Royal Holloway, University of London as a candidate for the degree of Doctor of Philosophy. This work has not been submitted for any other degree or award in any other university or educational establishment. Jiqiang Lu July 2008 2 Acknowledgements First of all, I thank my supervisor Prof. Chris Mitchell for suggesting block cipher cryptanalysis as my research topic when I began my Ph.D. studies in September 2005. I had never done research in this challenging ¯eld before, but I soon found it to be really interesting. Every time I ¯nished a manuscript, Chris would give me detailed comments on it, both editorial and technical, which not only bene¯tted my research, but also improved my written English. Chris' comments are fantastic, and it is straightforward to follow them to make revisions. I thank my advisor Dr. Alex Dent for his constructive suggestions, although we work in very di®erent ¯elds.
  • The Retracing Boomerang Attack

    The Retracing Boomerang Attack

    The Retracing Boomerang Attack Orr Dunkelman1, Nathan Keller2, Eyal Ronen3;4, and Adi Shamir5 1 Computer Science Department, University of Haifa, Israel [email protected] 2 Department of Mathematics, Bar-Ilan University, Israel [email protected] 3 School of Computer Science, Tel Aviv University, Tel Aviv, Israel [email protected] 4 COSIC, KU Leuven, Heverlee, Belgium 5 Faculty of Mathematics and Computer Science, Weizmann Institute of Science, Israel [email protected] Abstract. Boomerang attacks are extensions of differential attacks, that make it possible to combine two unrelated differential properties of the first and second part of a cryptosystem with probabilities p and q into a new differential-like property of the whole cryptosystem with probability p2q2 (since each one of the properties has to be satisfied twice). In this paper we describe a new version of boomerang attacks which uses the counterintuitive idea of throwing out most of the data (including poten- tially good cases) in order to force equalities between certain values on the ciphertext side. This creates a correlation between the four proba- bilistic events, which increases the probability of the combined property to p2q and increases the signal to noise ratio of the resultant distin- guisher. We call this variant a retracing boomerang attack since we make sure that the boomerang we throw follows the same path on its forward and backward directions. To demonstrate the power of the new technique, we apply it to the case of 5-round AES. This version of AES was repeatedly attacked by a large variety of techniques, but for twenty years its complexity had remained stuck at 232.
  • Statistical Cryptanalysis of Block Ciphers

    Statistical Cryptanalysis of Block Ciphers

    STATISTICAL CRYPTANALYSIS OF BLOCK CIPHERS THÈSE NO 3179 (2005) PRÉSENTÉE À LA FACULTÉ INFORMATIQUE ET COMMUNICATIONS Institut de systèmes de communication SECTION DES SYSTÈMES DE COMMUNICATION ÉCOLE POLYTECHNIQUE FÉDÉRALE DE LAUSANNE POUR L'OBTENTION DU GRADE DE DOCTEUR ÈS SCIENCES PAR Pascal JUNOD ingénieur informaticien dilpômé EPF de nationalité suisse et originaire de Sainte-Croix (VD) acceptée sur proposition du jury: Prof. S. Vaudenay, directeur de thèse Prof. J. Massey, rapporteur Prof. W. Meier, rapporteur Prof. S. Morgenthaler, rapporteur Prof. J. Stern, rapporteur Lausanne, EPFL 2005 to Mimi and Chlo´e Acknowledgments First of all, I would like to warmly thank my supervisor, Prof. Serge Vaude- nay, for having given to me such a wonderful opportunity to perform research in a friendly environment, and for having been the perfect supervisor that every PhD would dream of. I am also very grateful to the president of the jury, Prof. Emre Telatar, and to the reviewers Prof. em. James L. Massey, Prof. Jacques Stern, Prof. Willi Meier, and Prof. Stephan Morgenthaler for having accepted to be part of the jury and for having invested such a lot of time for reviewing this thesis. I would like to express my gratitude to all my (former and current) col- leagues at LASEC for their support and for their friendship: Gildas Avoine, Thomas Baign`eres, Nenad Buncic, Brice Canvel, Martine Corval, Matthieu Finiasz, Yi Lu, Jean Monnerat, Philippe Oechslin, and John Pliam. With- out them, the EPFL (and the crypto) would not be so fun! Without their support, trust and encouragement, the last part of this thesis, FOX, would certainly not be born: I owe to MediaCrypt AG, espe- cially to Ralf Kastmann and Richard Straub many, many, many hours of interesting work.