DOCSLIB.ORG

Technical Report ISSN 1476-2986

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Technical Report ISSN 1476-2986 UCAM-CL-TR-709 Technical Report ISSN 1476-2986 Number 709 Computer Laboratory Protocols and technologies for security in pervasive computing and communications Ford Long Wong January 2008 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2008 Ford Long Wong This technical report is based on a dissertation submitted August 2007 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Girton College. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract As the state-of-the-art edges towards Mark Weiser’s vision of ubiquitous computing (ubi- comp), we found that we have to revise some previous assumptions about security engineer- ing for this domain. Ubicomp devices have to be networked together to be able to realize their promise. To communicate securely amongst themselves, they have to establish secret session keys, but this is a difficult problem when this is done primarily over radio in an ad- hoc scenario, i.e. without the aid of an infrastructure (such as a PKI), and when it is assumed that the devices are resource-constrained and cannot perform complex calculations. Sec- ondly, when ubicomp devices are carried by users as personal items, their permanent iden- tifiers inadvertently allow the users to be tracked, to the detriment of user privacy. Unless there are deliberate improvements in designing for location privacy, ubicomp devices can be trivially detected, and linked to individual users, with discomfiting echoes of a surveil- lance society. Our findings and contributions are thus as follow. In considering session key establishment, we learnt that asymmetric cryptography is not axiomatically infeasible, and may in fact be essential, to counter possible attackers, for some of the more computationally capable (and important) devices. We next found existing attacker models to be inadequate, along with existing models of bootstrapping security associations, in ubicomp. We address the inadequacies with a contribution which we call: ‘multi-channel security protocols’, by leveraging on multiple channels, with different properties, existing in the said environment. We gained an appreciation of the fact that location privacy is really a multi-layer problem, particularly so in ubicomp, where an attacker often may have access to different layers. Our contributions in this area are to advance the design for location privacy by introducing a MAC-layer proposal with stronger unlinkability, and a physical-layer proposal with stronger unobservability. Acknowledgements There are many people to whom I owe thanks for the completion of this PhD dissertation. First and foremost, I thank my supervisor, Frank Stajano, for his supervision, guidance, encouragement, feedback, editing, ideas, suggestions and other unnamed contributions. Secondly, I thank my advisor, Prof. Andy Hopper, for his encouragement, support, advice and for providing an innovation-driven and practical-oriented environment in the Digital Technology Group (DTG, previously named Laboratory of Communication Engineering or LCE). Next, I record my thanks to my colleagues in both the DTG and the Security Group, who provided collegiality, entertainment, and a spur and a sounding board for my research; and including Prof. Ross Anderson for his organising of the stimulating atmosphere in the Secu- rity Group, and his feedback. In particular, I thank my collaborators: Jolyon Clulow, Hoon Wei Lim, Min Lin, Shishir Nagaraja and Ian Wassell. The following colleagues/friends: Øistein Andersen, Demetres Christofides, Saar Drimer, Feng Hao, Joon Woong Kim, Francisco Monteiro, Tyler Moore, Steven Murdoch and Piotr Zielinski,´ are also much appreciated for various fruitful discus- sions and help, and some of them for their proofreading of the whole or parts of this disser- tation (though the responsibility for any errors is mine). I am grateful to the Department of Engineering, and the Computer Laboratory, for their financial support of part of my conference travel costs. I thank my parents for raising me and their forbearance of an absent son, and my sister and brother-in-law for family warmth. I gratefully acknowledge sponsorship from DSO Singapore, especially support from the management, which enabled me to undertake my studies. My deep appreciation also goes to my thesis examiners: Professor Bruce Christianson and Dr David Greaves, for their patient reading of the dissertation, and their invaluable sugges- tions for improvements/corrections. Contents 1 Introduction 13 2 Password-based Device Pairing 19 2.1 Outline ........................................... 19 2.2 RelatedWork ........................................ 19 2.3 Ubicomp Environment - Lack of an Infrastructure . ....... 20 2.4 ThePrivateChannel-Passwords . ....... 21 2.4.1 ChannelProperties ................................. 22 2.4.2 Limitations of Passwords . 22 2.5 A Vulnerable Symmetric-Key Two-Party Password-Based Key Agreement Protocol . 23 2.5.1 Bluetooth Pairing - Our Implemented Attack . 25 2.5.2 Performance of Attack . 27 2.5.3 Re-Keying as a Short-Term Remedy . 27 2.6 Secure Asymmetric-Key Two-Party Password-Based Key Agreement Protocols . 29 2.6.1 Required Security Properties . 29 2.6.2 Use of Diffie-Hellman . 31 2.6.2.1 Diffie-Hellman over Multiplicative Groups . 31 2.6.2.2 Diffie-Hellman over Elliptic Curve Groups . 32 2.6.2.3 Implementation . 33 2.6.3 Key Derivation and Key Confirmation . 35 2.6.3.1 Key Derivation . 35 2.6.3.2 Key Confirmation . 36 2.6.4 Implementation Results . 36 2.6.4.1 Performance - Laptop . 36 2.6.4.2 Performance - Handphone . 37 2.7 Comments on Provable Security . 37 2.8 Future Directions . 39 2.9 Summary .......................................... 39 3 Inter-Domain Password-Authenticated Identity-Based Key Agreement 41 3.1 Outline ........................................... 41 3.2 RelatedWork ........................................ 42 3.3 Security Requirements . 43 3.4 Identity-Based Cryptography . ..... 44 3.4.1 Pairings....................................... 44 3.4.2 Boneh-Franklin IBE Scheme . 45 3.5 Architecture........................................ 46 3.5.1 Tier1........................................ 46 3.5.2 Tier2........................................ 46 3.5.3 Tier3........................................ 47 3.6 ProposedProtocol.................................. .... 47 3.7 Security Analysis . 50 3.8 Comparisons ........................................ 53 3.8.1 PKI-Kerberos.................................... 53 3.8.2 Yeh-SunKAAP/KTAP............................... 53 3.8.3 Three 2-party Key Agreements . 54 3.8.4 Comparison Metrics . 56 3.9 Future Directions . 57 3.10Summary .......................................... 57 4 Multi-Channel Security Protocols 59 4.1 Outline ........................................... 59 4.2 RelatedWork ........................................ 60 4.3 Multiple Channels: open insecure channel and auxiliary channel . .......... 61 4.3.1 Inadequacy of Open Insecure Channel . ...... 61 4.3.2 Auxiliary Channel with (Data-Origin) Authenticity . 63 4.3.3 Some Attacks on Protocols under Different Attacker Models . .... 63 4.3.3.1 Attack against Short Check Codes exchanged over Auxiliary Channel . 63 4.3.3.2 Attack against Key Fingerprints exchanged over Auxiliary Channel . 65 4.3.3.3 Eavesdropping Attack on Non-Confidential Auxiliary Channel . 66 4.4 Types and Properties of Channels . ...... 68 4.4.1 DifferencesofChannels ............................. 68 4.4.1.1 Authenticity . 68 4.4.1.2 Bandwidth . 69 4.4.1.3 Input or Output or Input/Output . 69 4.4.1.4 Human-mediation . 70 4.4.1.5 Comparison of Channels . 70 4.4.2 Multi-Channel Attacker Model . 71 4.5 Multiple Channels for Two-Party Key Agreement . ..... 72 4.5.1 Security Requirements . 72 4.5.2 Multi-Channel Security Protocol Proposal . .... 73 4.5.2.1 Protocol with Bidirectional Auxiliary Channels . 73 4.5.2.2 Protocol with Unidirectional Auxiliary Channel Restrictions . 77 4.5.3 Security Analysis . 79 4.5.3.1 Attack I - Solving Diffie-Hellman Problem by Passive Attacker . 79 4.5.3.2 Attack II - One-Shot Guess by Active Attacker . 80 4.5.3.3 Attack III - Brute-Forcing Commitments (and Nonces) . 80 4.6 Implementations . 81 4.6.1 Computing time . 81 4.6.2 VisualChannel ................................... 81 4.6.3 Melodic Audio . 83 4.7 Future Directions . 84 4.8 Summary .......................................... 85 5 Group Key Agreement using Multi-Channel Security Protocols 87 5.1 Outline ........................................... 87 5.2 RelatedWork ........................................ 88 5.3 Security Requirements . 88 5.4 A Straightforward Multi-Party Extension of Two-Party Diffie-Hellman Protocol: Cliques 89 5.4.1 Some Generic Attacks on Group Key Agreement Protocol Cliques . .... 91 5.5 Multi-Channel Security Protocol for Group Key Agreement I . ......... 92 5.5.1 Costs ........................................ 94 5.5.2 Augmented Group Operations . 95 5.6 Arbitrary Topologies . .. 95 5.6.1 Star......................................... 95 5.6.2 Hypercube ..................................... 95 5.6.3 Octopus....................................... 95 5.6.4 Tree......................................... 96 5.6.5 Topology Constraints . 96 5.7 Efficiency and Usability Considerations . .... 96 5.8 Multi-Channel Security Protocol for Group Key Agreement II . ......... 96 5.8.1 Advantages - Efficiency
Load more

Recommended publications
  • Encryption Procedure
    Encrypting Software for Transmission to NIST 1. Scope NIST requires that all software submitted by the participants be signed and encrypted. Signing is done with the participant’s private key, and encrypting is done with the NIST project public key, which is published at http://www.nist.gov/itl/iad/ig/encrypt.cfm. NIST will validate all submitted materials using the participant’s public key, and the authenticity of that key will be verified using the key fingerprint. This fingerprint must be submitted to NIST as part of the signed participant agreement. By encrypting the submissions, we ensure privacy; by signing the submission, we ensure authenticity (the software actually belongs to the submitter). NIST will not take ownership of any submissions that are not signed and encrypted. All cryptographic operations (signing and encrypting) shall be performed with software that implements the OpenPGP standard, as described in Internet RFC 4880. The freely available Gnu Privacy Guard (GPG) software, available at www.gnupg.org, is one such implementation. 2. Submission of software to NIST NIST requires that all software submitted by the participants be signed and encrypted. Two keys pairs are needed: • Signing is done with the software provider's private key, and • Encryption is done with the NIST project public key, which is available at http://www.nist.gov/itl/iad/ig/encrypt.cfm 2.1. Project Specific Parameters The values for the project specific parameters (ProjectName, ProjectPublicKey, and ProjectEmail) mentioned in this document are found at http://www.nist.gov/itl/iad/ig/encrypt.cfm 1 2.2. Creating participant cryptographic key pair The steps below show how to create a public/private key pair and fingerprint using the GPG software.
    [Show full text]
  • Adding Public Key Security to SSH
    Adding Public Key Security to SSH A Thesis Submitted to the Faculty in partial fulfillment of the requirements for the degree of Master of Science in Computer Science by Yasir Ali DARTMOUTH COLLEGE Hanover, New Hampshire Feb, 20th, 2003 Examining Committee: ____________________________ Sean Smith (chair) ____________________________ Edward Feustel ____________________________ Christopher Hawblitzel !!!!!!!!!____________________________ !!!!!!!!!Carol Folt !!!!!!!!! Dean of Graduate Studies 1 2 Abstract SSH, the Secure Shell, is a popular software-based approach to network security. It is a protocol that allows user to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides authentication and encrypted communications over unsecured channels. However, SSH protocol has an inherent security flaw. It is vulnerable to the “man-in-the- middle Attack”, when a user establishes his first SSH connection from a particular client to a remote machine. My thesis entails designing, evaluating and prototyping a public key infrastructure which can be used with the SSH2 protocol, in an academic setting, thus eliminating this vulnerability due to the man in the middle attack. The approach presented is different from the one that is based on the deployment of a Certificate Authority. My scheme does not necessarily require third party verification using a Certificate Authority; it is decentralized in nature and is relatively easy to set up. Keywords used: SSH, PKI, digital certificates, Certificate Authority, certification path, LDAP servers, Certificate Revocation List, X509v3 Certificate, OpenSSL, mutual authentication, and tunneled authentication. 3 Acknowledgments I want to thank Professor Sean Smith for his guidance, assistance and unremitting support over the last two years.
    [Show full text]
  • PGP Command Line User Guide
    PGP Command Line User Guide Last updated: July 2020 Copyright statement Broadcom, the pulse logo, Connecting everything, and Symantec are among the trademarks of Broadcom. Copyright © 2020 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. For more information, please visit www.broadcom.com. Broadcom reserves the right to make changes without further notice to any products or data herein to improve reliability, function, or design. Information furnished by Broadcom is believed to be accurate and reliable. However, Broadcom does not assume any liability arising out of the application or use of this information, nor the application or use of any product or circuit described herein, neither does it convey any license under its patent rights nor the rights of others. Contents About PGP Command Line 1 Important Concepts 1 Technical Support 2 Installing 5 Install Location 5 Installing on AIX 6 Installing on AIX 6 Changing the Home Directory on AIX 7 Uninstalling on AIX 7 Installing on HP-UX 8 Installing on HP-UX 8 Changing the Home Directory on HP-UX 9 Installing to a Non-Default Directory on HP-UX 9 Uninstalling on HP-UX 9 Installing on macOS 10 Installing on macOS 10 Changing the Home Directory on macOS 10 Uninstalling on macOS 11 Installing on Red Hat Enterprise Linux, SLES, or Fedora Core 11 Installing on Red Hat Enterprise Linux or Fedora Core 11 Changing the Home Directory on Linux or Fedora Core 12 Uninstalling on Linux or Fedora Core 12 Installing on Oracle Solaris 13 Installing on Oracle
    [Show full text]
  • How Secure Is Textsecure?
    How Secure is TextSecure? Tilman Frosch∗y, Christian Mainkay, Christoph Badery, Florian Bergsmay,Jorg¨ Schwenky, Thorsten Holzy ∗G DATA Advanced Analytics GmbH firstname.lastname @gdata.de f g yHorst Gortz¨ Institute for IT-Security Ruhr University Bochum firstname.lastname @rub.de f g Abstract—Instant Messaging has gained popularity by users without providing any kind of authentication. Today, many for both private and business communication as low-cost clients implement only client-to-server encryption via TLS, short message replacement on mobile devices. However, until although security mechanisms like Off the Record (OTR) recently, most mobile messaging apps did not protect confi- communication [3] or SCIMP [4] providing end-to-end con- dentiality or integrity of the messages. fidentiality and integrity are available. Press releases about mass surveillance performed by intelli- With the advent of smartphones, low-cost short-message gence services such as NSA and GCHQ motivated many people alternatives that use the data channel to communicate, to use alternative messaging solutions to preserve the security gained popularity. However, in the context of mobile ap- and privacy of their communication on the Internet. Initially plications, the assumption of classical instant messaging, fueled by Facebook’s acquisition of the hugely popular mobile for instance, that both parties are online at the time the messaging app WHATSAPP, alternatives claiming to provide conversation takes place, is no longer necessarily valid. secure communication experienced a significant increase of new Instead, the mobile context requires solutions that allow for users. asynchronous communication, where a party may be offline A messaging app that claims to provide secure instant for a prolonged time.
    [Show full text]
  • Detecting and Preventing Active Attacks Against Autocrypt Release 0.10.0
    Detecting and preventing active attacks against Autocrypt Release 0.10.0 NEXTLEAP researchers Jan 09, 2020 Contents 1 Introduction2 1.1 Attack model and terminology............................2 1.2 Problems of current key-verification techniques...................3 1.3 Integrating key verification with general workflows.................3 1.4 Supplementary key consistency through ClaimChains................4 1.5 Detecting inconsistencies through Gossip and DKIM................5 2 Securing communications against network adversaries6 2.1 Setup Contact protocol................................7 2.2 Verified Group protocol................................ 12 2.3 History-verification protocol............................. 17 2.4 Verifying keys through onion-queries......................... 20 3 Key consistency with ClaimChains 23 3.1 High level overview of the ClaimChain design.................... 23 3.2 Use and architecture................................. 24 3.3 Evaluating ClaimChains to guide verification.................... 26 4 Using Autocrypt key gossip to guide key verification 28 4.1 Attack Scenarios................................... 28 4.2 Probability of detecting an attack through out of band verification......... 29 5 Using DKIM signature checks to guide key verification 32 5.1 DKIM Signatures on Autocrypt Headers....................... 32 5.2 Device loss and MITM attacks............................ 33 5.3 Open Questions.................................... 34 1 1 Introduction This document considers how to secure Autocrypt1-capable mail apps against active network at- tackers. Autocrypt aims to achieve convenient end-to-end encryption of e-mail. The Level 1 Autocrypt specification offers users opt-in e-mail encryption, but only considers passive adver- saries. Active network adversaries, who could, for example, tamper with the Autocrypt header during e-mail message transport, are not considered in the Level 1 specification. Yet, such active attackers might undermine the security of Autocrypt.
    [Show full text]
  • Easy Encryption for Email, Photo, and Other Cloud Services John Seunghyun Koh
    Easy Encryption for Email, Photo, and Other Cloud Services John Seunghyun Koh Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy under the Executive Committee of the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2021 © 2021 John Seunghyun Koh All Rights Reserved Abstract Easy Encryption for Email, Photo, and Other Cloud Services John Seunghyun Koh Modern users carry mobile devices with them at nearly all times, and this likely has contribut- ed to the rapid growth of private user data—such as emails, photos, and more—stored online in the cloud. Unfortunately, the security of many cloud services for user data is lacking, and the vast amount of user data stored in the cloud is an attractive target for adversaries. Even a single compro- mise of a user’s account yields all its data to attackers. A breach of an unencrypted email account gives the attacker full access to years, even decades, of emails. Ideally, users would encrypt their data to prevent this. However, encrypting data at rest has long been considered too difficult for users, even technical ones, mainly due to the confusing nature of managing cryptographic keys. My thesis is that strong security can be made easy to use through client-side encryption using self-generated per-device cryptographic keys, such that user data in cloud services is well pro- tected, encryption is transparent and largely unnoticeable to users even on multiple devices, and encryption can be used with existing services without any server-side modifications. This dis- sertation introduces a new paradigm for usable cryptographic key management, Per-Device Keys (PDK), and explores how self-generated keys unique to every device can enable new client-side encryption schemes that are compatible with existing online services yet are transparent to users.
    [Show full text]
  • Mobile Platforms Maemo
    Maemo and Symbian S60 EPFL October, 10 th 2009 Mobile Platforms Maemo •Maemo is an open development platform for applications and technology innovation for handheld devices •It was originally developed by Nokia and afterwards offered to the community as opensource Solid software architecture on Linux – first in taking Linux desktop paradigm to mobile devices Optimized for Designed for Mobile Internet Internet Devices – experiences – first in implementing the taking web2.0 apps to Maemo multimedia mobile devices based computer promise on Linux Open for innovation– Developed with some of the best open source communities Open for innovation – developed in collaboration with the open source community 14.000 members 700 hosted projects 200 applications Maemo software Community Nokia is a key contributor to Related open projects such as source projects GNOME/GTK+. Maemo.org maemo.org – 140.000 unique visitors the community 14.000 registered users for innovation 700 hosted projects on Maemo. 200 applications Product evolution Internet Optimized Multimedia Computer Nokia 770 Nokia N800 Nokia N810 Nokia N810 1st generation of Nokia In ternet 2nd generation of Nokia Internet WiMAX Edition Taking the positioning of the Tablet Tablets Tablets. Category from a predominantly ‘one- Bringing WiMAX connection to Easy access to the internet. High way’ surfing tool, to a genuine ‘two strengthen the internet story. With resolution touch sc reen. way’ communication device. wider wireless internet coverage, Internet will truly become personal With integrated
    [Show full text]
  • Can Unicorns Help Users Compare Crypto Key Fingerprints?
    Can Unicorns Help Users Compare Crypto Key Fingerprints? Joshua Tan, Lujo Bauer, Joseph Bonneau†, Lorrie Faith Cranor, Jeremy Thomas, Blase Ur∗ Carnegie Mellon University, {jstan, lbauer, lorrie, thomasjm}@cmu.edu † Stanford University, [email protected] * University of Chicago, [email protected] ABSTRACT key. To learn Bob’s key, Alice would typically look it up Many authentication schemes ask users to manually compare on a web site (e.g., a public key server) that publishes such compact representations of cryptographic keys, known as fin- information. Unfortunately, an attacker seeking to intercept gerprints. If the fingerprints do not match, that may signal a Alice’s communications to Bob might try to add his own key man-in-the-middle attack. An adversary performing an attack to the key server under Bob’s name. When trying to find may use a fingerprint that is similar to the target fingerprint, but Bob’s public key, Alice would then unwittingly download the not an exact match, to try to fool inattentive users. Fingerprint attacker’s key. Any messages she composed for Bob would representations should thus be both usable and secure. then be readable by the attacker, and not by Bob. We tested the usability and security of eight fingerprint repre- A more reliable method would be for Bob to deliver his public sentations under different configurations. In a 661-participant key to Alice in person. Because public keys are long strings between-subjects experiment, participants compared finger- of arbitrary bits, this approach is unfortunately unwieldy and prints under realistic conditions and were subjected to a sim- impractical.
    [Show full text]
  • Mobile Connection Explorer for Windows Introduction and Features
    Mobile Connection Explorer 15 May 2013 for Windows Version 21 Introduction and Features Public version Gemfor s.r.o. Tyršovo nám. 600 252 63 Roztoky Czech Republic Gemfor s.r.o. Tyršovo nám. 600 252 63 Roztoky Czech Republic e-mail: [email protected] Contents Contents ...................................................................................................................... 2 History ......................................................................................................................... 3 1. Scope ..................................................................................................................... 3 2. Abbreviations ......................................................................................................... 4 3. Solution .................................................................................................................. 5 4. Specification ........................................................................................................... 5 5. Product description ................................................................................................. 9 5.1 Supported operating systems ....................................................................... 9 5.2 Hardware device connections ....................................................................... 9 5.3 Network connection types ............................................................................. 9 5.4 Customizable graphical skin ......................................................................
    [Show full text]
  • Devices for Which We Currently Recommend Opera Mini 7.0 Number of Device Models
    Devices for which we currently recommend Opera Mini 7.0 Number of device models: 625 Platforms included: JME, BlackBerry, Android, S60 and iOS List generated date: 2012-05-30 -------------------------------------------------------------------------------------------------------------------------------------- au by KDDI IS03 by Sharp BlackBerry 9900 Bold Acer beTouch E110 au by KDDI REGZA Phone BlackBerry Curve 3G 9300 IS04 by Fujitsu-Toshiba Acer beTouch E130 Dell Aero au by KDDI Sirius IS06 by Acer Iconia Tab A500 Pantech Dell Streak Acer Liquid E Ezze S1 Beyond B818 Acer Liquid mt Fly MC160 BlackBerry 8520 Curve Acer Liquid S100 Garmin-Asus nüvifone A10 BlackBerry 8530 Curve Acer Stream Google Android Dev Phone BlackBerry 8800 1 G1 Alcatel One Touch OT-890D BlackBerry 8820 Google Nexus One Alfatel H200 BlackBerry 8830 Google Nexus S i9023 Amoi WP-S1 Skypephone BlackBerry 8900 Curve HTC A6277 Apple iPad BlackBerry 9000 Bold HTC Aria A6366 Apple iPhone BlackBerry 9105 Pearl HTC ChaCha / Status / Apple iPhone 3G BlackBerry 9300 Curve A810e Apple iPhone 3GS BlackBerry 9500 Storm HTC Desire Apple iPhone 4 BlackBerry 9530 Storm HTC Desire HD Apple iPod Touch BlackBerry 9550 Storm2 HTC Desire S Archos 101 Internet Tablet BlackBerry 9630 Tour HTC Desire Z Archos 32 Internet Tablet BlackBerry 9700 Bold HTC Dream Archos 70 Internet Tablet BlackBerry 9800 Torch HTC Droid Eris Asus EeePad Transformer BlackBerry 9860 Torch HTC Droid Incredible TF101 ADR6300 HTC EVO 3D X515 INQ INQ1 LG GU230 HTC EVO 4G Karbonn K25 LG GW300 Etna 2 / Gossip HTC Explorer
    [Show full text]
  • The Enigmail Handbook V1.0.0
    EnigMail openpgp email security for mozilla applications The Handbook by Daniele Raffo with Robert J. Hansen and Patrick Brunschwig v 1.0.0 and earlier 1. Table of Contents 2. Introduction..................................................................................5 3. Acknowledgements.....................................................................8 4. The Enigmail team.......................................................................9 5. Getting started...........................................................................10 5.1. Installing GnuPG.....................................................................................10 5.1.1. Installing GnuPG on Microsoft Windows..........................................10 5.1.2. Installing GnuPG on Macintosh OS X..............................................10 5.1.3. Installing GnuPG on Linux / UNIX....................................................11 5.2. Installing Thunderbird / SeaMonkey........................................................11 5.3. Installing Enigmail....................................................................................12 5.3.1. Installing Enigmail on Thunderbird...................................................12 5.3.2. Installing Enigmail on SeaMonkey...................................................12 5.3.3. Installing a locale for Enigmail..........................................................13 6. Quick start..................................................................................14 6.1. The Setup Wizard....................................................................................15
    [Show full text]
  • PGP Desktop Security for Windows 95, Windows 98, and Windows NT
    PGP Desktop Security for Windows 95, Windows 98, and Windows NT User’s Guide Version 6.5 Int. Copyright © 1990-1999 Network Associates, Inc. and its Affiliated Companies. All Rights Reserved. PGP*, Version 6.5.1 Int. 9-9-99. Printed in the EC. PGP, Pretty Good, and Pretty Good Privacy are registered trademarks of Network Associates, Inc. and/or its Affiliated Companies in the US and other countries. All other registered and unregistered trademarks in this document are the sole property of their respective owners. Portions of this software may use public key algorithms described in U.S. Patent numbers 4,200,770, 4,218,582, 4,405,829, and 4,424,414, licensed exclusively by Public Key Partners; the IDEA(tm) cryptographic cipher described in U.S. patent number 5,214,703, licensed from Ascom Tech AG; and the Northern Telecom Ltd., CAST Encryption Algorithm, licensed from Northern Telecom, Ltd. IDEA is a trademark of Ascom Tech AG. Network Associates Inc. may have patents and/or pending patent applications covering subject matter in this software or its documentation; the furnishing of this software or documentation does not give you any license to these patents. The compression code in PGP is by Mark Adler and Jean-Loup Gailly, used with permission from the free Info-ZIP implementation. LDAP software provided courtesy University of Michigan at Ann Arbor, Copyright © 1992-1996 Regents of the University of Michigan. All rights reserved. This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/).
    [Show full text]