DOCSLIB.ORG

Revision 22.6.5 by Doktor

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Revision 22.6.5 by Doktor SecurityandEncryptionFaq SecurityandEncryptionFAQRevision22.6.5 byDoktorWho "Nooneshallbesubjectedtoarbitraryinterferencewithhisprivacy,family,h omeorcorrespondence,nortoattacksuponhishonourandreputation.Everyoneh astherighttotheprotectionofthelawagainstsuchinterferenceorattacks." Article12UniversalDeclarationofHumanRights ThisFaq/Tutorialisofferedingoodfaithandisintendedtobeanencapsulatio nofmyknowledgeandexperiencesgainedoverthemanyyearsthatIhavebeena computer/Netuser.TherearemanyroadstosecurityandprivacyontheNet,this isonethatIhavepersonallypursuedandcanrecommendfromexperiencesgained .Iamnotmakinganyclaimthatitisthebestortheonlyroutetoprivacyand security,justthatitworksforme. Therearecountlessreasonswhysomeonemayneedthereassuranceofanonymity.T hemostobviousisasaprotectionagainstanoverbearingGovernment.Manypeop leresideincountrieswherehumanrightsaredubiousandtheyneedanonymityto raisepublicawarenessandpublishtheseabusestotheworldatlarge.ThisFaq istohelpsuchpeople. Privacyandanonymityareveryimportantprinciplesassociatedwithbothfreedom ofspeechanddemocracy. "Anonymityisashieldfromthetyrannyofthemajority...Itthusexemplifiest hepurposebehindtheBillofRights,andoftheFirstAmendmentinparticular: toprotectunpopularindividualsfromretaliationandtheirideasfromsuppres sionatthehandofanintolerantsociety." JusticeStevens,McIntyrev.OhioElectionsCommission,1996 Changessincepreviousrevision: NowincludesamethodofanonymouslyobtainingaprepaidDebitCard. Unfortunately,sincemylastFaq,eGoldhasbeencompromizedbytheFBI.Allac countsarenowsubjecttotheirscrutiny,soitisveryinadvisabletouseeGol dfortheforeseeablefuture.Thisrevisionisaholding,meaningtemporary,rev isionandIwillupdatewithalternativewaystofundananonymousprepaidDebit CardassoonasIamable.ReferencestotheuseofeGoldwithinthisFaqshou ldthereforebetreatedwithgreatcareorignored. Part1offersanoverviewapproachtoachievesecurityandanonymity. Part2.Inthesecondpartwillbethepracticalimplementationsofsomeofthe programsmentionedinPart1.Insomecasesthiswillincludedetailedsetupins tructionstohelpachievethegoaloftruecomputerandInternetprivacyandano nymity.Iassumeabasicunderstandingofcomputers,suchastheabilitytocopy andpasteandageneralknowledgeofhowtoinstallprogramsandfollowsetupi nstructions. Part1(Questions1to30) 1.Howdoesencryptionwork? Essentiallytheplaintextiscombinedwithamathematicalalgorithm(asetofru lesforprocessingdata)suchthattheoriginaltextcannotbededucedfromthe outputfile,hencethedataisnowinencryptedform.Toenabletheprocesstob esecure,akeyiscombinedwiththisalgorithm.Thekeyisprotectedbyapassp hrase.Obviouslytheprocessmustbereversible,butonlywiththeaidoftheco rrectkey.Withoutthekey,theprocessshouldbeextremelydifficult.Themathe maticsoftheencryptionshouldbeopenlyavailableforpeerreview.Atfirstsi ghtthismayappeartocompromisetheencryption,butthisisfarfromthecase. Peerreviewensuresthatthereareno"backdoors"orcryptoweaknesseswithin theprogram.Althoughthealgorithmisunderstood,itisthecombinationofits usewiththepassphrasethatensuressecrecy. Thusthepassphraseiscrucialtothesecurityofthedata. 2.IwantmyHardDriveandmyEmailtobesecure,howcanIachievethis? YouneedPGP(PrettyGoodPrivacy)foryourEmailandDCPP(DriveCryptPlusPack )version3and/orTrueCryptversion3foryourharddriveencryptedfiles. BothDCPPandTrueCryptareknownasOTF(OnTheFly)typeprograms.OTFmeanst heencrypteddataisonlydecryptedintoRAM(RandomAccessMemory)andremains atalltimesencryptedonthedrive.Thusacrashclosewillnotleavepacketso fplaintextonyourdrive.Averyimportantfeature. PGPisavailableforallversionsofWindows,Linux,Unix,Macandothers.Thes ourcecodeisavailableforcompilingyourownversionshouldyouwish. DCPPisWin2000/NT/XPcompliantbutnotcompliantwithWin98orearlier.Regrett ably,nosourcecodeisavailable.Ithastwouniqueadvantagesoverotherencry ptionprograms.(a)Itisawholebootdriveencryptionprogram.(b)Itoffersa formofverygoodplausibledeniability. TrueCryptisarelativelynew,freeandopensourceprogramofgreatpromise.It doesnotdisplayanyfileheaderinfotohelpasnooperidentifythefile'spur pose.Theheaderisencryptedandshowsasrandomgarbage.Butitwillidentify whichtypeofformatwasusedtocreatetheTruecryptvolume.DespiteWindowsan dotherprogramsclaimingthepartitionisnotformatted,Truecryptwillitself ratherunhelpfullytelltheworldthatitisobviouslyaTruecryptcreatedvolum e.Iamatalosstounderstandthelogicofthis,butthereitis. Itallowstheencryptionofawholepartitionordrive.Thesourcecodeisfreel yavailablesoitmeansanyonewiththeabilitycancompilethesameprogram.Th eimportanceofthiscannotbetoostronglystressed.Itmeanstheriskofahid denbackdoorisvirtuallyeliminated. Ifthesightingofthesourcecodeisimportanttoyou,IsuggestusingPGPand TrueCrypt.InallcasesyoumustcheckthePGPsignaturesofthesefiles,after downloadingfromatrustedsite.Iwouldneveradvocateusinganyhackedversion ofacriticalsecurityprogram,oronesourcedfromawarezorotherdubioussi te.Certainlynotifyouaretrulyseriousaboutyourprivacy. Note1:PGP,althoughexcellentatensuringEmailprivacy,doesnothingforanon ymity.Thedifferenceiscrucial. Iwillassumethatanonymityisalsoveryhighonyourlistofneedsandsowill concentrateonthatissuefurtherdowntheFaq. 3.Whatisthedifferencebetweentheseencryptionprograms? Oneofthedifficultiesbeforeasymmetricalkeyencryptionwasdiscoveredwasho wtogetthekeytothepersonwantingtosendyouanencryptedmessage.Inthe pasttrustedcourierswereusedtogetthesesecretkeystoadistantlocation, maybeanoverseasembassy.Nowadaysthisisunneccessarybecauseofthediscover yofwhatiscalledpublickeycryptography.Twodifferentkeysareused.Oneke yissecretandtheotherismadepublic.Themostwidespreadprogramofthisty peforprivateuseisPGP,inventedbyPhilZimmerman.Infactithasbecomethe defactostandardontheNet.ThisprogramisidealforEmail. AnybodysendingyoumailsimplyencryptstheirmessagetoyouwithyourPGPpubl ickey.Thepublickeyisobviouslynotsecretinfactitmaybespreadfaran dwidesothatanybodycanfinditiftheywishtosendyouencryptedEmail.The easiestwaytoensurethisisbysendingittoapublickeyserver.Ontheothe rhand,someprefernottosharetheirkey,exceptwithinasmallclosedgroup. Yourchoice. Theonlywaytodecryptthisincomingmessageiswithyoursecretkey.Itisimp ossibletodecryptusingthesamekeythatwasusedtoencryptthemessage,the publickey.Thusitiscalledasymmetricalencryption.PGPissimplicityitself toinstallanduse.Itevenofferstosendyournewlygeneratedpublickeytoa keyserver. Foryournormalharddriveencryption,youwillneedasymmetricaltypeofencry ptionprogram.Thismeansthesamekeyisusedforbothencryptionanddecryptio n.DCPPandTrueCryptareofthistypeandespeciallygoodbecausetheyareOTF (OnTheFly)typeprograms. DCPPandTrueCryptusethepassphrasetoencryptarandomlycreatedkey.DCPPst oresanencryptedcopyofthiskeyinthekeystorewhichisaseparateentityto theencrypteddisk.TrueCryptstoresanencryptedcopyofthekeywithinthehe adersoftheencrypteddevice.Itistheplaintextofthekeythatisusedtoen crypt(anddecrypt)thecontentsofthediskorcontaineronanasneededbasis intoRAMmemory. WithPGPapublickeyischosentoencryptthemessage.PGPwillthengeneratea onetimesessionkeywhichitusestoencryptthemessage.Thissessionkeyis thenitselfencryptedwiththepublickeyoftheintendedrecipientofthemessa ge.Thisencryptedcopyofthesessionkeyisthenwrappedintheheadersandse ntalongwiththeencryptedcopyofthemessagetotherecipient.Onlytherecip ienthastheprivatekeywhichcandecryptthissessionkey.Iftherearemultip lerecipients,thenthissessionkeyisencryptedtothepublickeyofeachreci pientinturn.Allthesedifferentencryptedversionsofthesessionkeyarethe nwrappedintheheadersofthemessage.Eachrecipientcandecrypthisversion ofthesessionkey,whichwillthenbeabletodecryptthemessage.PGPalsohas akeystore.ThekeystoresforbothPGPandDCPPareprotectedbythepassphrase . ThesenderofaPGPmessagemaychoosetosignamessage.Themessagemayormay notbeencrypted.PGPwillthenencryptthehashofthemessagecontentsusing thesendersprivatekey.Hispublickeycanthenbeusedbytherecipienttoche ckthathishashofthemessageisidenticaltotheoriginal,thusprovingitwa smadeusingthesender'sprivatekey.Onlyoneprivatekey,thesender's,cane ncryptthehashsuchthatitwillcheckoutcorrectlywiththesender'spublick ey.Ifevenawhitespacebetweentwowordsisclosedupinamessage,thesigna turewillshowasbad.Thisoffersaverysecuremethodofcheckingboththeacc uracyandtheauthenticiityofamessage. Truecryptandmanyothersymmetricalencryptionprogramsstorethekeywithinth eheadersofthepartitionorcontainer.Onequestionoftenaskedbynewbiesis whetherthepassphraseisalsostoredsomewherewithintheencryptedfile.No.T hepassphraseispassedthroughahash.Itisthehashoutputthatisstoredwit hintheheadersoftheencryptedcontainer.Theprogramwillcomparethishashw iththehashitproducesfromyourpassphrasethatyoutypeintomount(open)t hecontainer.Iftheyareidentical,theprogramwilluseyourpassphrasetodec ryptthekeythattheprogramgeneratedtoencryptthediskorcontainer.Itis thiskeythatwillthenbeusedtodecryptthediskorcontaineronthefly. Hashingisaonewayactiononly;itisimpossibletoderivethekeyfromtheha shoutput.Thehashingprocessissimplyawayofcheckingthatthecorrectpass phrasehasbeeninput.Iftheprogramwassomehowalteredtoforceittousean incorrectpassphrase,theoutputwouldbegarbage.Thereisnoshortcutorfix, withoutthecorrectpassphrasetheoutputwillbejunk. 4.IhaveWindows,amIsafe? Windowsisaclosedsourceoperatingsystemwhichisalawtoitself.Eachnewu pdatethatisreleasedbyMicrosoftseemstoneedfurtherupdatestofixthesec urityholesdiscoveredinthepreviousreleases.Ithasbeenanongoingprocess overmanyyearswithnoendinsight.Theseweaknessescanmanifestthemselvesa ssecurityholeswhenontheNet.Afurtherproblemwiththisoperatingsystemi sitsseemingdeterminationtowritetoyourharddiskallsortsofinformation thatmaybehiddenfromyourviewinallsortsofplacesthatcouldbefoundby aforensicexaminationofyourcomputer. Thuswehaveatwofoldproblem.Firstly,theproblemofWindowshavingthepote
Load more

Recommended publications
  • Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-quite-so-broken TLS Lessons in re-engineering a security protocol specification and implementation David Kaloper Meršinjak Hannes Mehnert Peter Sewell Anil Madhavapeddy University of Cambridge, Computer Labs Usenix Security, Washington DC, 12 August 2015 INT SSL23_GET_CLIENT_HELLO(SSL *S) { CHAR BUF_SPACE[11]; /* REQUEST THIS MANY BYTES IN INITIAL READ. * WE CAN DETECT SSL 3.0/TLS 1.0 CLIENT HELLOS * ('TYPE == 3') CORRECTLY ONLY WHEN THE FOLLOWING * IS IN A SINGLE RECORD, WHICH IS NOT GUARANTEED BY * THE PROTOCOL SPECIFICATION: * BYTE CONTENT * 0 TYPE \ * 1/2 VERSION > RECORD HEADER * 3/4 LENGTH / * 5 MSG_TYPE \ * 6-8 LENGTH > CLIENT HELLO MESSAGE Common CVE sources in 2014 Class # Memory safety 15 State-machine errors 10 Certificate validation 5 ASN.1 parsing 3 (OpenSSL, GnuTLS, SecureTransport, Secure Channel, NSS, JSSE) Root causes Error-prone languages Lack of separation Ambiguous and untestable specification nqsb approach Choice of language and idioms Separation and modular structure A precise and testable specification of TLS Reuse between specification and implementation Choice of language and idioms OCaml: a memory-safe language with expressive static type system Well contained side-effects Explicit flows of data Value-based Explicit error handling We leverage it for abstraction and automated resource management. Formal approaches Either reason about a simplified model of the protocol; or reason about small parts of OpenSSL. In contrast, we are engineering a deployable implementation. nqsb-tls A TLS stack, developed from scratch, with dual goals: Executable specification Usable TLS implementation Structure nqsb-TLS ML module layout Core Is purely functional: VAL HANDLE_TLS : STATE -> BUFFER -> [ `OK OF STATE * BUFFER OPTION * BUFFER OPTION | `FAIL OF FAILURE ] Core OCaml helps to enforce state-machine invariants.
    [Show full text]
  • SL8500 Modular Library System
    StorageTek SL8500 Modular Library System Systems Assurance Guide Part Number: MT9229 May 2010 Revision: L Submit comments about this document by clicking the Feedback [+] link at: http://docs.sun.com StorageTek SL8500 Modular Library System - Systems Assurance Guide MT9229 Revision: L Copyright © 2004, 2010, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related software documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are “commercial computer software” or “commercial technical data” pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).
    [Show full text]
  • Encryption Suite
    comforte_Encryption_Suite.qxp_comforte_Encryption_Suite 29.10.17 13:33 Seite 1 comForte´scomforte’s encryptionencryptio nsuite suite ProtectProtect passwords passwords andand confidentialconfidential applicationapplication data data on on HP HP NonStopE Nonsto psystems systems SSecurCSecurCS Se SecurTNcurTN Se SecurFTPcurFTP Sec SecurLiburLib Secu SecurSHrSH Secu SecurPrintrPrint communication is our Forte comforte_Encryption_Suite.qxp_comforte_Encryption_Suite 29.10.17 13:33 Seite 2 Overview comForte offers a rich set of products The following diagram shows all products All our products take advantage of the most depending on the protocol you want to together. This diagram may look confusing widely used and accepted security protocols: encrypt. Even for a single protocol (such at first glance, but we do believe that our Depending on the product, connections are as Telnet) we offer different solutions rich set of products allows us to tailor our secured either via SSL (Secure Sockets Layer, depending on your requirements. solutions according to the customers’ now standardized by the IETF as Transport requirements rather than according to our Layer Security – TLS) or via SSH2 (Secure Shell product set. The purpose of this flyer is to protocol version 2). provide an overview of the different products and to help you find the right solution for All our solutions can restrict access to your your requirements. NonStop system to “encrypted only” and also provide some basic firewall capabilities. comforte_Encryption_Suite.qxp_comforte_Encryption_Suite 29.10.17 13:33 Seite 3 Telnet Encryption Many organizations are realizing that using Webbrowser access to NonStop 6530 single, integrated product. SecurTN replaces Telnet over a heterogenous TCP/IP network and 3270 applications and services, TELSERV, thereby eliminating the “256 session results in reduced security: all protective delivering them to users both inside only” limit of TELSERV.
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]
  • Continuous Auditing of SSH Servers to Mitigate Brute-Force Attacks Phuong M
    CAUDIT: Continuous Auditing of SSH Servers To Mitigate Brute-Force Attacks Phuong M. Cao, Yuming Wu, and Subho S. Banerjee, UIUC; Justin Azoff and Alex Withers, NCSA; Zbigniew T. Kalbarczyk and Ravishankar K. Iyer, UIUC https://www.usenix.org/conference/nsdi19/presentation/cao This paper is included in the Proceedings of the 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’19). February 26–28, 2019 • Boston, MA, USA ISBN 978-1-931971-49-2 Open access to the Proceedings of the 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’19) is sponsored by CAUDIT: Continuous Auditing of SSH Servers to Mitigate Brute-Force Attacks Phuong M. Cao1, Yuming Wu1, Subho S. Banerjee1, Justin Azoff2;3, Alexander Withers3, Zbigniew T. Kalbarczyk1, Ravishankar K. Iyer1 1University of Illinois at Urbana-Champaign, 2Corelight, 3National Center for Supercomputing Applications Abstract While only a small fraction of such attempts succeed, they This paper describes CAUDIT1, an operational system have led to major misuses in 51% of 1,800 surveyed organi- deployed at the National Center for Supercomputing Applica- zations, with a financial impact of up to $500,000 per organi- tions (NCSA) at the University of Illinois. CAUDIT is a fully zation [7]. automated system that enables the identification and exclusion This paper describes the production deployment of of hosts that are vulnerable to SSH brute-force attacks. Its CAUDIT at the National Center for Supercomputing Ap- key features include: 1) a honeypot for attracting SSH-based plications (NCSA) at the University of Illinois over a period attacks over a /16 IP address range and extracting key meta- of 463 days.
    [Show full text]
  • Scripting the Openssh, SFTP, and SCP Utilities on I Scott Klement
    Scripting the OpenSSH, SFTP, and SCP Utilities on i Presented by Scott Klement http://www.scottklement.com © 2010-2015, Scott Klement Why do programmers get Halloween and Christmas mixed-up? 31 OCT = 25 DEC Objectives Of This Session • Setting up OpenSSH on i • The OpenSSH tools: SSH, SFTP and SCP • How do you use them? • How do you automate them so they can be run from native programs (CL programs) 2 What is SSH SSH is short for "Secure Shell." Created by: • Tatu Ylönen (SSH Communications Corp) • Björn Grönvall (OSSH – short lived) • OpenBSD team (led by Theo de Raadt) The term "SSH" can refer to a secured network protocol. It also can refer to the tools that run over that protocol. • Secure replacement for "telnet" • Secure replacement for "rcp" (copying files over a network) • Secure replacement for "ftp" • Secure replacement for "rexec" (RUNRMTCMD) 3 What is OpenSSH OpenSSH is an open source (free) implementation of SSH. • Developed by the OpenBSD team • but it's available for all major OSes • Included with many operating systems • BSD, Linux, AIX, HP-UX, MacOS X, Novell NetWare, Solaris, Irix… and yes, IBM i. • Integrated into appliances (routers, switches, etc) • HP, Nokia, Cisco, Digi, Dell, Juniper Networks "Puffy" – OpenBSD's Mascot The #1 SSH implementation in the world. • More than 85% of all SSH installations. • Measured by ScanSSH software. • You can be sure your business partners who use SSH will support OpenSSH 4 Included with IBM i These must be installed (all are free and shipped with IBM i **) • 57xx-SS1, option 33 = PASE • 5733-SC1, *BASE = Portable Utilities • 5733-SC1, option 1 = OpenSSH, OpenSSL, zlib • 57xx-SS1, option 30 = QShell (useful, not required) ** in v5r3, had 5733-SC1 had to be ordered separately (no charge.) In v5r4 or later, it's shipped automatically.
    [Show full text]
  • Centrify Putty Guide
    Centrify-enabled PuTTY User’s Guide September 2020 (release 2020) Centrify Corporation • • • • • • Legal Notice This document and the software described in this document are furnished under and are subject to the terms of a license agreement or a non-disclosure agreement. Except as expressly set forth in such license agreement or non-disclosure agreement, Centrify Corporation provides this document and the software described in this document “as is” without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. Some states do not allow disclaimers of express or implied warranties in certain transactions; therefore, this statement may not apply to you. This document and the software described in this document may not be lent, sold, or given away without the prior written permission of Centrify Corporation, except as otherwise permitted by law. Except as expressly set forth in such license agreement or non-disclosure agreement, no part of this document or the software described in this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of Centrify Corporation. Some companies, names, and data in this document are used for illustration purposes and may not represent real companies, individuals, or data. This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of this document. Centrify Corporation may make improvements in or changes to the software described in this document at any time.
    [Show full text]
  • Cryptographic File Systems Performance: What You Don't Know Can Hurt You Charles P
    Cryptographic File Systems Performance: What You Don't Know Can Hurt You Charles P. Wright, Jay Dave, and Erez Zadok Stony Brook University Appears in the proceedings of the 2003 IEEE Security In Storage Workshop (SISW 2003) Abstract interact with disks, caches, and a variety of other com- plex system components — all having a dramatic effect Securing data is more important than ever, yet cryp- on performance. tographic file systems still have not received wide use. In this paper we perform a real world performance One barrier to the adoption of cryptographic file systems comparison between several systems that are used is that the performance impact is assumed to be too high, to secure file systems on laptops, workstations, and but in fact is largely unknown. In this paper we first moderately-sized file servers. We also emphasize multi- survey available cryptographic file systems. Second, programming workloads, which are not often inves- we perform a performance comparison of a representa- tigated. Multi-programmed workloads are becoming tive set of the systems, emphasizing multiprogrammed more important even for single user machines, in which workloads. Third, we discuss interesting and counterin- Windowing systems are often used to run multiple appli- tuitive results. We show the overhead of cryptographic cations concurrently. We expect cryptographic file sys- file systems can be minimal for many real-world work- tems to become a commodity component of future oper- loads, and suggest potential improvements to existing ating systems. systems. We have observed not only general trends with We present results from a variety of benchmarks, an- each of the cryptographic file systems we compared but alyzing the behavior of file systems for metadata op- also anomalies based on complex interactions with the erations, raw I/O operations, and combined with CPU operating system, disks, CPUs, and ciphers.
    [Show full text]
  • Oracle Enterprise Session Border Controller – Acme Packet 4600 and Microsoft Skype for Business for Enterprise SIP Trunking with NTT Communications
    Oracle Enterprise Session Border Controller – Acme Packet 4600 and Microsoft Skype for Business for Enterprise SIP Trunking with NTT Communications Technical Application Note Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. 2 Table of Contents INTENDED AUDIENCE ......................................................................................................................................... ..4 DOCUMENT OVERVIEW ....................................................................................................................................... .4 INTRODUCTION ..................................................................................................................................................... .5 AUDIENCE ............................................................................................................................................................................................ .5 REQUIREMENTS .................................................................................................................................................................................. .5 ARCHITECTURE ..................................................................................................................................................................................
    [Show full text]
  • Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation
    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation David Kaloper-Meršinjak, Hannes Mehnert, Anil Madhavapeddy, and Peter Sewell, University of Cambridge https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Not-quite-so-broken TLS: lessons in re-engineering a security protocol specification and implementation David Kaloper-Mersinjakˇ †, Hannes Mehnert†, Anil Madhavapeddy and Peter Sewell University of Cambridge Computer Laboratory [email protected] † These authors contributed equally to this work Abstract sensitive services, they are not providing the security we need. Transport Layer Security (TLS) is the most widely Transport Layer Security (TLS) implementations have a deployed security protocol on the Internet, used for au- history of security flaws. The immediate causes of these thentication and confidentiality, but a long history of ex- are often programming errors, e.g. in memory manage- ploits shows that its implementations have failed to guar- ment, but the root causes are more fundamental: the chal- antee either property. Analysis of these exploits typically lenges of interpreting the ambiguous prose specification, focusses on their immediate causes, e.g. errors in mem- the complexities inherent in large APIs and code bases, ory management or control flow, but we believe their root inherently unsafe programming choices, and the impos- causes are more fundamental: sibility of directly testing conformance between imple- mentations and the specification.
    [Show full text]
  • A Technical Comparison of Ipsec and SSL
    A Technical Comparison of IPSec and SSL y Ab delNasir Alshamsi Takamichi Saito Tokyo University of Technology Abstract p osed but the most famous secure and widely de ployed are IPSec IP Security and SSL Secure So cket Layer IPSec IP Security and SSL SecureSocket Layer In this pap er we will provide a technical comparison have been the most robust and most potential tools of IPSec and SSL the similarities and the dierences available for securing communications over the Inter of the cryptographic prop erties The results of per net Both IPSec and SSL have advantages and short formance are based on comparing FreeSWAN as comings Yet no paper has been found comparing the IPSec and Stunnel as SSL two protocols in terms of characteristic and functional ity Our objective is to present an analysis of security and performancepr operties for IPSec and SSL IPSec IPSec is an IP layer proto col that enables the Intro duction sending and receiving of cryptographically protected packets of any kind TCPUDPICMPetc without any provides two kinds of crypto mo dication IPSec Securing data over the network is hard and compli graphic services Based on necessity IPSec can provide cated issue while the threat of data mo dication and condentiality and authenticity or it can provide data interruption is rising The goal of network security authenticity only is to provide condentiality integrity and authenticity Condentiality is keeping the data secret from the ESP Encapsulated SecurityPayload unintended listeners on the network Integrity is en suring
    [Show full text]
  • Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D
    Main Points • Applying last week’s lectures in practice • Creating Secure Channels Secure Channels • Example Applications – PGP: Pretty Good Privacy CS 161/194-1 – TLS: Transport Layer Security Anthony D. Joseph – VPN: Virtual Private Network September 26, 2005 September 26, 2005 CS161 Fall 2005 2 Joseph/Tygar/Vazirani/Wagner What is a Secure Channel? Plaintext Plaintext Creating Secure Channels Encryption / Internet Encryption / • Authentication and Data Integrity Decryption Decryption Ciphertext and MAC – Use Public Key Infrastructure or third-party server to authenticate each end to the other • A stream with these security requirements: – Add Message Authentication Code for – Authentication integrity • Ensures sender and receiver are who they claim to be – Confidentiality • Confidentiality • Ensures that data is read only by authorized users – Data integrity – Exchange session key for encrypt/decrypt ops • Ensures that data is not changed from source to destination • Bulk data transfer – Non-repudiation (not discussed today) • Ensures that sender can’t deny message and rcvr can’t deny msg • Key Distribution and Segmentation September 26, 2005 CS161 Fall 2005 3 September 26, 2005 CS161 Fall 2005 4 Joseph/Tygar/Vazirani/Wagner Joseph/Tygar/Vazirani/Wagner Symmetric Key-based Symmetric Key-based Secure Channel Secure Channel Alice Bob • Sender (A) and receiver (B) share secret keys KABencrypt KABencrypt – One key for A è B confidentiality KABauth KABauth – One for A è B authentication/integrity Message MAC Compare? Message – Each message
    [Show full text]