Security Terminology
Total Page:16
File Type:pdf, Size:1020Kb

Load more
Recommended publications
-
RSA: Encryption, Decryption
Data Communications & Networks Session 11 – Main Theme Network Security Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences Adapted from course textbook resources Computer Networking: A Top-Down Approach, 5/E Copyright 1996-2009 J.F. Kurose and K.W. Ross, All Rights Reserved 1 Agenda 1 Session Overview 2 Network Security 3 Summary and Conclusion 2 What is the class about? .Course description and syllabus: »http://www.nyu.edu/classes/jcf/CSCI-GA.2262-001/ »http://www.cs.nyu.edu/courses/spring15/CSCI- GA.2262-001/index.html .Textbooks: » Computer Networking: A Top-Down Approach (5th Edition) James F. Kurose, Keith W. Ross Addison Wesley ISBN-10: 0136079679, ISBN-13: 978-0136079675, 5th Edition (03/09) 3 Course Overview . Computer Networks and the Internet . Application Layer . Fundamental Data Structures: queues, ring buffers, finite state machines . Data Encoding and Transmission . Local Area Networks and Data Link Control . Wireless Communications . Packet Switching . OSI and Internet Protocol Architecture . Congestion Control and Flow Control Methods . Internet Protocols (IP, ARP, UDP, TCP) . Network (packet) Routing Algorithms (OSPF, Distance Vector) . IP Multicast . Sockets 4 Course Approach . Introduction to Basic Networking Concepts (Network Stack) . Origins of Naming, Addressing, and Routing (TCP, IP, DNS) . Physical Communication Layer . MAC Layer (Ethernet, Bridging) . Routing Protocols (Link State, Distance Vector) . Internet Routing (BGP, OSPF, Programmable Routers) . TCP Basics (Reliable/Unreliable) . Congestion Control . QoS, Fair Queuing, and Queuing Theory . Network Services – Multicast and Unicast . Extensions to Internet Architecture (NATs, IPv6, Proxies) . Network Hardware and Software (How to Build Networks, Routers) . Overlay Networks and Services (How to Implement Network Services) . -
Semi-Quantum Communication: Protocols for Key Agreement, Controlled Secure Direct Communication and Dialogue Arxiv:1702.07861V1
Semi-quantum communication: Protocols for key agreement, controlled secure direct communication and dialogue Chitra Shuklaa;,∗ Kishore Thapliyalb;,y Anirban Pathakb;z aGraduate School of Information Science, Nagoya University, Furo-cho 1, Chikusa-ku, Nagoya, 464-8601, Japan bJaypee Institute of Information Technology, A-10, Sector-62, Noida, UP-201307, India February 28, 2017 Abstract Semi-quantum protocols that allow some of the users to remain classical are proposed for a large class of problems associated with secure communication and secure multiparty computation. Specif- ically, first time semi-quantum protocols are proposed for key agreement, controlled deterministic secure communication and dialogue, and it is shown that the semi-quantum protocols for controlled deterministic secure communication and dialogue can be reduced to semi-quantum protocols for e- commerce and private comparison (socialist millionaire problem), respectively. Complementing with the earlier proposed semi-quantum schemes for key distribution, secret sharing and deterministic secure communication, set of schemes proposed here and subsequent discussions have established that almost every secure communication and computation tasks that can be performed using fully quantum protocols can also be performed in semi-quantum manner. Further, it addresses a funda- mental question in context of a large number problems- how much quantumness is (how many quan- tum parties are) required to perform a specific secure communication task? Some of the proposed schemes are completely orthogonal-state-based, and thus, fundamentally different from the existing semi-quantum schemes that are conjugate-coding-based. Security, efficiency and applicability of the proposed schemes have been discussed with appropriate importance. arXiv:1702.07861v1 [quant-ph] 25 Feb 2017 Keywords: Semi-quantum protocol, quantum communication, key agreement, quantum dialogue, deter- ministic secure quantum communication, secure direct quantum communication. -
Openpgp Card Application User Guide
OpenPGP Card Application User Guide Cédric Mesnil ([email protected]) May 30, 2018 Contents 1 License 3 2 Introduction 4 3 How to install GPG Application 5 3.1 Nano S / Blue . 5 3.1.1 From Binary . 5 3.1.2 From source . 6 3.2 System Configuration . 6 3.2.1 Linux . 6 3.2.2 MAC . 6 3.2.3 Windows . 7 4 Nano S OpenPGP Card application explained 8 4.1 Menu Overview . 8 4.2 Device Info . 9 4.3 Select Slot . 9 4.4 Settings . 10 4.4.1 Key Template . 10 4.4.2 Seed mode . 11 4.4.3 PIN mode . 11 4.4.4 UIF mode . 13 4.4.5 Reset . 13 5 Nano S OpenPGP Card application usage 14 5.1 GPG . 14 5.1.1 Configuration . 14 5.1.2 Get/Set basic information . 15 5.1.3 Generate new key pair . 16 5.1.4 Moving existing key pair . 21 5.1.5 Decrypting and Signing . 23 5.2 SSH . 23 5.2.1 Overview . 23 5.2.2 Generate new key on device . 23 1 5.2.3 Add sub-key . 23 5.2.4 Configure SSH and GPG . 26 5.3 Trouble/FAQ . 28 6 Annexes 29 6.1 References . 29 2 Chapter 1 License Author: Cedric Mesnil <[email protected]> License: Copyright 2017 Cedric Mesnil <[email protected]>, Ledger SAS Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -
An Architecture for Cryptography with Smart Cards and NFC Rings on Android
OpenKeychain: An Architecture for Cryptography with Smart Cards and NFC Rings on Android DOMINIK SCHÜRMANN, TU Braunschweig, Germany SERGEJ DECHAND, University of Bonn, Germany LARS WOLF, TU Braunschweig, Germany While many Android apps provide end-to-end encryption, the cryptographic keys are still stored on the device itself and can thus be stolen by exploiting vulnerabilities. External cryptographic hardware solves this issue, but is currently only used for two-factor authentication and not for communication encryption. In this paper, we design, implement, and evaluate an architecture for NFC-based cryptography on Android. Our high-level API provides cryptographic operations without requiring knowledge of public-key cryptography. By developing OpenKeychain, we were able to roll out this architecture for more than 100,000 users. It provides encryption for emails, messaging, and a password manager. We provide a threat model, NFC performance measurements, and discuss their impact on our architecture design. As an alternative form factor to smart cards, we created the prototype of an NFC signet ring. To evaluate the UI components and form factors, a lab study with 40 participants at a large company has been conducted. We measured the time required by the participants to set up the system and reply to encrypted emails. These measurements and a subsequent interview indicate that our NFC-based solutions are more user friendly in comparison to traditional password-protected keys. CCS Concepts: • Security and privacy → Usability in security and privacy; Key management; Hardware-based security protocols; • Human-centered computing → Mobile devices; Additional Key Words and Phrases: NFC, near-field communication, smart card, ring ACM Reference Format: Dominik Schürmann, Sergej Dechand, and Lars Wolf. -
Applying Mix Nets to Email Document
Ref. Ares(2016)2647269 - 08/06/2016 Harry Halpin (Greenhost/LEAP)) Kali Kaneko (Greenhost/LEAP) Ruben Pollan (Greenhost/LEAP) Elijah Sparrow (Greenhost/LEAP)) Mooness Davarian (Greenhost/LEAP) Raf Degens (Medialaan/Mobile Vikings) Tariq Elahi (KUL) George Danezis (UCL) Applying Mix Nets to Email Document Deliverable D 7.1 June 8, 2016 Panoramix Project, # 653497, Horizon 2020 http://www.panoramix-project.eu Contents 1 Introduction 3 2 Use-cases 4 2.1 Companies and Government Use-case . 4 2.2 Journalist Use-case . 5 2.3 Activists . 5 3 Email Systems 7 4 Threat Models and Requirements 9 4.1 Threat Models . 9 4.2 Requirements . 10 4.2.1 Security Requirements . 11 4.2.2 Privacy Requirements . 11 4.3 Problems and Meditations . 12 4.3.1 Security Requirement Problem: StartTLS downgrade . 12 4.3.2 Security Requirement Problem: DNS hijacking . 12 4.3.3 Security Requirement Problem: MX impersonation . 13 4.3.4 Privacy Requirement Problem: Abusive Users . 13 4.3.5 Privacy Requirement Problem: Spam . 14 4.3.6 Privacy and Abuse Prevention Mediations . 15 5 LEAP Software 17 5.1 The LEAP Architecture . 18 5.1.1 LEAP Platform . 19 5.1.2 Soledad . 20 5.1.3 LEAP Client . 21 5.1.4 Nicknym Key-Management . 22 5.2 LEAP for Email Encryption Example . 22 1 5.2.1 Setting up a new device . 22 5.2.2 Receiving Mail . 23 5.2.3 Mailbox Sync . 23 5.2.4 Sending Mail . 23 5.3 Current State and Future Work . 23 6 End-user Usability 25 7 System Administration Usability 27 8 Empirical Mix-net Parameters 30 8.1 Empirical Data . -
Lecture 12: Quantum Key Distribution. Secret Key. BB84, E91 and B92 Protocols. Continuous-Variable Protocols. 1. Secret Key. A
Lecture 12: Quantum key distribution. Secret key. BB84, E91 and B92 protocols. Continuous-variable protocols. 1. Secret key. According to the Vernam theorem, any message (for instance, consisting of binary symbols, 01010101010101), can be encoded in an absolutely secret way if the one uses a secret key of the same length. A key is also a sequence, for instance, 01110001010001. The encoding is done by adding the message and the key modulo 2: 00100100000100. The one who knows the key can decode the encoded message by adding the key to the message modulo 2. The important thing is that the key should be used only once. It is exactly this way that classical cryptography works. Therefore the only task of quantum cryptography is to distribute the secret key between just two users (conventionally called Alice and Bob). This is Quantum Key Distribution (QKD). 2. BB84 protocol, proposed in 1984 by Bennett and Brassard – that’s where the name comes from. The idea is to encode every bit of the secret key into the polarization state of a single photon. Because the polarization state of a single photon cannot be measured without destroying this photon, this information will be ‘fragile’ and not available to the eavesdropper. Any eavesdropper (called Eve) will have to detect the photon, and then she will either reveal herself or will have to re-send this photon. But then she will inevitably send a photon with a wrong polarization state. This will lead to errors, and again the eavesdropper will reveal herself. The protocol then runs as follows. -
Gnuk — a Free Software USB Token Implementation Niibe Yutaka
Gnuk — A Free Software USB Token Implementation Niibe Yutaka <[email protected]> What’s Gnuk? Free Software implementation of Cryptographic Token For GNU Privacy Guard Supports OpenPGP card protocol version 2 Runs on STM32 processor Named after NUK® My son used to be with his NUK®, always, everywhere I wish Gnuk Token can be a soother for GnuPG user NUK® is a registered trademark owend by MAPA GmbH, Germany. Cryptographic Token? Stores your Secret Keys Performs security operations on the device Digital signature Authentication Decryption No direct access of Secret Keys How useful? Can bring secret keys securely On the go, you can do: Make digital signature Authenticate yourself Read encrypted mail GNU Privacy Guard (GnuPG) Tool for Privacy by Cryptography Conforms to OpenPGP standard Usage: Digital Signature Encryption/Decryption Authentication Supports "OpenPGP card" OpenPGP card Smartcard to put GnuPG keys Follows OpenPGP protocol standard Features of v2.0: RSA 1024-bit, 2048-bit, 3072-bit Three keys: Sign, Decrypt, Auth Key generation on the card RSA accelerator OpenPGP card Applications GnuPG OpenSSH → gpg-agent TLS/SSL Client authentication Scute (Network Security Service) PAM Poldi Problem to solve Where and how we put our secret keys? On the disk of our PC Encrypted by passphrase Not Secure Enough OpenPGP card Good (portable, secure) Not easily deployed (reader is not common) FSIJ USB Token v1 (2008) Hardware: Built a PCB CPU: Atmel AVR ATmega 328 @20MHz Software: RSA computation routine for AVR RSA 1024-bit About 5sec Data objects -
Device-Independent Quantum Cryptography for Continuous Variables
Device-Independent Quantum Cryptography for Continuous Variables Kevin Marshall1, ∗ and Christian Weedbrook1, 2, y 1Department of Physics, University of Toronto, Toronto, M5S 3G4, Canada 2QKD Corp., 60 St. George St., Toronto, M5S 3G4, Canada (Dated: October 8, 2018) We present the first device-independent quantum cryptography protocol for continuous variables. Our scheme is based on the Gottesman-Kitaev-Preskill encoding scheme whereby a qubit is embedded in the infinite-dimensional space of a quantum harmonic oscillator. The novel application of discrete-variable device- independent quantum key distribution to this encoding enables a continuous-variable analogue. Since the se- curity of this protocol is based on discrete-variables we inherit by default security against collective attacks and, under certain memoryless assumptions, coherent attacks. We find that our protocol is valid over the same distances as its discrete-variable counterpart, except that we are able to take advantage of high efficiency com- mercially available detectors where, for the most part, only homodyne detection is required. This offers the potential of removing the difficulty in closing the loopholes associated with Bell inequalities. PACS numbers: 03.67.Dd, 03.67.Hk, 42.50.-p, 89.70.Cf I. INTRODUCTION parties may share a private key despite having no knowledge of the inner workings of their respective devices. Conversely, Quantum key distribution (QKD) [1,2] is a method by in conventional QKD protocols it is regularly assumed that which two parties, Alice and Bob, may generate a shared both parties have a high degree of control over both state secret key over an insecure quantum channel monitored by preparation as well as measurement. -
Analysing and Patching SPEKE in ISO/IEC
1 Analysing and Patching SPEKE in ISO/IEC Feng Hao, Roberto Metere, Siamak F. Shahandashti and Changyu Dong Abstract—Simple Password Exponential Key Exchange reported. Over the years, SPEKE has been used in several (SPEKE) is a well-known Password Authenticated Key Ex- commercial applications: for example, the secure messaging change (PAKE) protocol that has been used in Blackberry on Blackberry phones [11] and Entrust’s TruePass end-to- phones for secure messaging and Entrust’s TruePass end-to- end web products. It has also been included into international end web products [16]. SPEKE has also been included into standards such as ISO/IEC 11770-4 and IEEE P1363.2. In the international standards such as IEEE P1363.2 [22] and this paper, we analyse the SPEKE protocol as specified in the ISO/IEC 11770-4 [24]. ISO/IEC and IEEE standards. We identify that the protocol is Given the wide usage of SPEKE in practical applications vulnerable to two new attacks: an impersonation attack that and its inclusion in standards, we believe a thorough allows an attacker to impersonate a user without knowing the password by launching two parallel sessions with the victim, analysis of SPEKE is both necessary and important. In and a key-malleability attack that allows a man-in-the-middle this paper, we revisit SPEKE and its variants specified in (MITM) to manipulate the session key without being detected the original paper [25], the IEEE 1363.2 [22] and ISO/IEC by the end users. Both attacks have been acknowledged by 11770-4 [23] standards. -
Quantum Error Correcting Codes and the Security Proof of the BB84 Protocol
Quantum Error Correcting Codes and the Security Proof of the BB84 Protocol Ramesh Bhandari Laboratory for Telecommunication Sciences 8080 Greenmead Drive, College Park, Maryland 20740, USA [email protected] (Dated: December 2011) We describe the popular BB84 protocol and critically examine its security proof as presented by Shor and Preskill. The proof requires the use of quantum error-correcting codes called the Calderbank-Shor- Steanne (CSS) quantum codes. These quantum codes are constructed in the quantum domain from two suitable classical linear codes, one used to correct for bit-flip errors and the other for phase-flip errors. Consequently, as a prelude to the security proof, the report reviews the essential properties of linear codes, especially the concept of cosets, before building the quantum codes that are utilized in the proof. The proof considers a security entanglement-based protocol, which is subsequently reduced to a “Prepare and Measure” protocol similar in structure to the BB84 protocol, thus establishing the security of the BB84 protocol. The proof, however, is not without assumptions, which are also enumerated. The treatment throughout is pedagogical, and this report, therefore, serves as a useful tutorial for researchers, practitioners and students, new to the field of quantum information science, in particular quantum cryptography, as it develops the proof in a systematic manner, starting from the properties of linear codes, and then advancing to the quantum error-correcting codes, which are critical to the understanding -
Resource State Structure for Controlled Quantum Key Distribution
EPJ manuscript No. (will be inserted by the editor) Resource state structure for controlled quantum key distribution Arpan Das1;2;a, Sumit Nandi1;2;b, Sk Sazim3;c, and Pankaj Agrawal1;2;d 1 Institute of Physics, Sachivalaya Marg, Bhubaneswar 751005, Odisha, India. 2 Homi Bhabha National Institute, Training School Complex, Anushakti Nagar, Mumbai 400085, India. 3 Harish-Chandra Research Institute, HBNI, Allahabad 211019, India. Received: date / Revised version: date Abstract. Quantum entanglement plays a pivotal role in many communication protocols, like secret sharing and quantum cryptography. We consider a scenario where more than two parties are involved in a protocol and share a multipartite entangled state. In particular, we considered the protocol of Controlled Quantum Key Distribution (CoQKD), introduced in the Ref. Chin. Phys. Lett. 20, 183-185 (2003), where, two parties, Alice and Bob establish a key with the cooperation of other parties. Other parties control/supervise whether Alice and Bob can establish the key, its security and key rate. We discuss the case of three parties in detail and find suitable resource states. We discuss the controlling power of the third party, Charlie. We also examine the usefulness of the new resource states for generating conference key and for cooperative teleportation. We find that recently introduced Bell inequalities can be useful to establish the security of the conference key. We also generalize the scenario to more than three parties. PACS. XX.XX.XX No PACS code given 1 Introduction the two parties may be dishonest, ii) one of the two par- ties may be compromised by some eavesdropper, iii) the Quantum entanglement is an exquisite resource behind communication may be done only under some supervision. -
Metadefender Core V4.17.3
MetaDefender Core v4.17.3 © 2020 OPSWAT, Inc. All rights reserved. OPSWAT®, MetadefenderTM and the OPSWAT logo are trademarks of OPSWAT, Inc. All other trademarks, trade names, service marks, service names, and images mentioned and/or used herein belong to their respective owners. Table of Contents About This Guide 13 Key Features of MetaDefender Core 14 1. Quick Start with MetaDefender Core 15 1.1. Installation 15 Operating system invariant initial steps 15 Basic setup 16 1.1.1. Configuration wizard 16 1.2. License Activation 21 1.3. Process Files with MetaDefender Core 21 2. Installing or Upgrading MetaDefender Core 22 2.1. Recommended System Configuration 22 Microsoft Windows Deployments 22 Unix Based Deployments 24 Data Retention 26 Custom Engines 27 Browser Requirements for the Metadefender Core Management Console 27 2.2. Installing MetaDefender 27 Installation 27 Installation notes 27 2.2.1. Installing Metadefender Core using command line 28 2.2.2. Installing Metadefender Core using the Install Wizard 31 2.3. Upgrading MetaDefender Core 31 Upgrading from MetaDefender Core 3.x 31 Upgrading from MetaDefender Core 4.x 31 2.4. MetaDefender Core Licensing 32 2.4.1. Activating Metadefender Licenses 32 2.4.2. Checking Your Metadefender Core License 37 2.5. Performance and Load Estimation 38 What to know before reading the results: Some factors that affect performance 38 How test results are calculated 39 Test Reports 39 Performance Report - Multi-Scanning On Linux 39 Performance Report - Multi-Scanning On Windows 43 2.6. Special installation options 46 Use RAMDISK for the tempdirectory 46 3.