Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard V1.2.3

Total Page:16

File Type:pdf, Size:1020Kb

Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard V1.2.3 Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard v1.2.3 Phong Q. Nguyen CNRS/Ecole´ normale sup´erieure D´epartement d’informatique 45 rue d’Ulm, 75230 Paris Cedex 05, France. [email protected] http://www.di.ens.fr/˜pnguyen Abstract. More and more software use cryptography. But how can one know if what is implemented is good cryptography? For proprietary soft- ware, one cannot say much unless one proceeds to reverse-engineering, and history tends to show that bad cryptography is much more frequent than good cryptography there. Open source software thus sounds like a good solution, but the fact that a source code can be read does not imply that it is actually read, especially by cryptography experts. In this paper, we illustrate this point by examining the case of a basic In- ternet application of cryptography: secure email. We analyze parts of thesourcecodeofthelatestversionofGNUPrivacyGuard(GnuPGor GPG), a free open source alternative to the famous PGP software, com- pliant with the OpenPGP standard, and included in most GNU/Linux distributions such as Debian, MandrakeSoft, Red Hat and SuSE. We ob- serve several cryptographic flaws in GPG v1.2.3. The most serious flaw has been present in GPG for almost four years: we show that as soon as one (GPG-generated) ElGamal signature of an arbitrary message is released, one can recover the signer’s private key in less than a second on a PC. As a consequence, ElGamal signatures and the so-called ElGamal sign+encrypt keys have recently been removed from GPG. Fortunately, ElGamal was not GPG’s default option for signing keys. Keywords: Public-key cryptography, GnuPG, GPG, OpenPGP, Crypt- analysis, RSA, ElGamal, Implementation. 1 Introduction With the advent of standardization in the cryptography world (RSA PKCS [20], IEEE P1363 [14], CRYPTREC [15], NESSIE [8], etc.), one may think that there is more and more good cryptography. But as cryptography becomes “global”, how can one be sure that what is implemented in the real world is actually good cryptography? Numerous examples (such as [4,2,21]) have shown that the frontier between good cryptography and bad cryptography is very thin. For proprietary software, it seems difficult to make any statement unless one proceeds C. Cachin and J. Camenisch (Eds.): EUROCRYPT 2004, LNCS 3027, pp. 555–570, 2004. c International Association for Cryptologic Research 2004 556 Phong Q. Nguyen to the tedious task of reverse-engineering. If a proprietary software claims to implement 2048-bit RSA and 128-bit AES, it does not say much about the actual cryptographic security: which RSA is being used? Could it be textbook RSA [5] (with zero-padding) encrypting a 128-bit AES key with public exponent 3? Are secret keys generated by a weak pseudo-random number generator like old versions of Netscape [9]? Who knows if it is really RSA–OAEP which is implemented [21]? With proprietary software, it is ultimately a matter of trust: unfortunately, history has shown that there is a lot of bad cryptography in proprietary software (see for instance [28,12] for explanations). Open source software thus sounds like a good solution. However, the fact that a source code can be read does not necessarily imply that it is actually read, especially by cryptography experts. The present paper illustrates this point by examining the case of “perhaps the most mature cryptographic technology in use on the Internet” (according to [1]): secure email, which enables Internet users to authentify and/or encrypt emails. Secure email became popular in the early 90s with the appearance of the now famous Pretty Good Privacy (PGP) [27] software developed by Phil Zimmermann in the US. Not so long ago, because of strict export restrictions and other US laws, PGP was unsuitable for many areas outside the US. Although the source code of PGP has been published, it is unknown whether future versions of PGP will be shipped with access to the source code. GNU Privacy Guard [10] (GnuPG, or GPG in short) was developed in the late 90s as an answer to those PGP issues. GPG is a full implementation of OpenPGP [26], the Internet standard that extends PGP. GPG has been released as free software under the GNU General Public License (GNU GPL): As such, full access to the source code is provided at [10], and GPG can be viewed as a free replacement for PGP. The German Federal Ministry of Economics and Technology granted funds for the further development of GPG. GPG has a fairly significant user base: it is included in most GNU/Linux distributions, such as Debian, MandrakeSoft, Red Hat and SuSE. The first stable version of GPG was released on September 7th, 1999. Here, we review the main public- key aspects of the source code of v1.2.3, which was the current stable version (released on August 22nd, 2003) when this paper was submitted to Eurocrypt ’04. Our comments seem to also apply to several previous versions of GPG. However, we stress that our analysis is not claimed to be complete, even for the public-key aspects of GPG. We observe several cryptographic flaws in GPG v1.2.3. The most serious flaw (which turns out to have been present in GPG for almost four years) is related to ElGamal signatures: we present a lattice-based attack which recovers the signer’s private key in less than a second on a PC, given any (GPG-generated) ElGa- mal signature of a (known) arbitrary message and the corresponding public key. This is because both a short private exponent and a short nonce are used for the generation of ElGamal signatures, when the GPG version in use is between 1.0.2 (January 2000) and 1.2.3 (August 2003). As a result, GPG–ElGamal signing keys have been considered compromised [19], especially the so-called primary ElGa- Can We Trust Cryptographic Software? 557 mal sign+encrypt keys: with such keys, one signature is always readily available, because such keys automatically come up with a signature to bind the user iden- tity to the public key, thus leaking the private key used for both encryption and signature. Hence, ElGamal signatures and ElGamal sign+encrypt keys have recently been removed from GPG (see [10] for more information). We notice that GPG encryption provides no chosen-ciphertext security, due to its compliance with OpenPGP [26], which uses the old PKCS #1 v1.5 stan- dard [17]: Bleichenbacher’s chosen-ciphertext attack [4] applies to OpenPGP, ei- ther when RSA or ElGamal is used. Although the relevance of chosen-ciphertext attacks to the context of email communications is debatable, we hope that OpenPGP will replace PKCS #1 v1.5 to achieve chosen-ciphertext security. The other flaws do not seem to lead to any reasonable attack, they only underline the lack of state-of-the-art cryptography in GPG and sometimes OpenPGP. It is worth noting that the OpenPGP standard is fairly loose: it gives non-negligible freedom over the implementation of cryptographic functions, especially regard- ing key generation. Perhaps stricter and less ambiguous guidelines should be given in order to decrease security risks. The only published research on the cryptographic strength of GPG we are aware of is [18,16], which presented chosen-ciphertext attacks with respect to the symmetric encryption used in PGP and GPG. The rest of the paper is organized as follows. In Section 2, we give an overview of the GPG software v1.2.3. In Section 3, we review the GPG implementation of ElGamal and present the attack on ElGamal signatures. In Section 4, we review the GPG implementation of RSA. There is no section devoted to the GPG implementation of DSA, since we have not found any noteworthy weakness in it. In Appendix A, we give a brief introduction to lattice theory, because the attack on ElGamal signatures uses lattices. In Appendix B, we provide a proof (in an idealized model) of the lattice-based attack on ElGamal signatures. 2 An Overview of GPG v1.2.3 GPG v1.2.3 [10] supports ElGamal (signature and encryption), DSA, RSA, AES, 3DES, Blowfish, Twofish, CAST5, MD5, SHA-1, RIPE-MD-160 and TIGER. GPG decrypts and verifies PGP 5, 6 and 7 messages: It is compliant with the OpenPGP standard [26], which is described in RFC 2440 [6]. GPG provides secrecy and/or authentication to emails: it enables users to encrypt/decrypt and/or sign/verify emails using public-key cryptography. The public-key infrastructure is the famous web of trust: users certify public key of other users. GPG v.1.2.3 allows the user to generate several types of public/private keys, with the command gpg --gen-key: – Choices available in the standard mode: • (1) DSA and ElGamal: this is the default option. The DSA keys are signing keys, while the ElGamal keys are encryption keys (type 16 in the OpenPGP terminology). 558 Phong Q. Nguyen • (2) DSA: only for signatures. • (5) RSA: only for signatures. – Additional choices available in the expert mode: • (4) ElGamal for both signature and encryption. In the OpenPGP termi- nology, these are keys of type 20. • (7) RSA for both signature and encryption. In particular, an ElGamal signing key is also an encryption key, but an ElGamal encryption key may be restricted to encryption. In GPG v1.2.3, ElGamal signing keys cannot be created unless one runs the expert mode: however, this was not always the case in previous versions. For instance, the standard mode of GPG v1.0.7 (which was released in April 2002) proposes the choices (1), (2), (4) and (5).
Recommended publications
  • Course 5 Lesson 2
    This material is based on work supported by the National Science Foundation under Grant No. 0802551 Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author (s) and do not necessarily reflect the views of the National Science Foundation C5L3S1 With the advent of the Internet, social networking, and open communication, a vast amount of information is readily available on the Internet for anyone to access. Despite this trend, computer users need to ensure private or personal communications remain confidential and are viewed only by the intended party. Private information such as a social security numbers, school transcripts, medical histories, tax records, banking, and legal documents should be secure when transmitted online or stored locally. One way to keep data confidential is to encrypt it. Militaries,U the governments, industries, and any organization having a desire to maintain privacy have used encryption techniques to secure information. Encryption helps to boost confidence in the security of online commerce and is necessary for secure transactions. In this lesson, you will review encryption and examine several tools used to encrypt data. You will also learn to encrypt and decrypt data. Anyone who desires to administer computer networks and work with private data must have some familiarity with basic encryption protocols and techniques. C5L3S2 You should know what will be expected of you when you complete this lesson. These expectations are presented as objectives. Objectives are short statements of expectations that tell you what you must be able to do, perform, learn, or adjust after reviewing the lesson.
    [Show full text]
  • Chapter 12 Pretty Good Privacy (PGP)
    Chapter 12 Pretty Good Privacy (PGP) With the explosively growing reliance on electronic mail for every conceivable pur- pose, there grows a demand for authentication and confidentiality services. Two schemes stand out as approaches that enjoy widespread use: Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extension (S/MIME). The latter is a security en- hancement to the MIME Internet e-mail format standard, based on technology from RSA Data Security. Although both PGP and S/MIME are on an IETF standards track, it appears likely that S/MIME will emerge as the industry standard for commercial and organisational use, while PGP will remain the choice for personal e-mail security for many users. In this course we will only be looking at PGP. S/MIME is discussed in detail in the recommended text. 12.1 Background PGP is a remarkable phenomenon. Largely the effort of a single person, Phil Zimmer- mann, PGP provides a confidentiality and authentication service that can be used for electronic mail and file storage applications. In essence what Zimmermann has done is the following: 1. Selected the best cryptographic mechanisms (algorithms) as building blocks. 2. Integrated these algorithms into a general purpose application that is independent of operating system and processor and that is based on a small set of easy to use commands. 3. Made the package and its source code freely available via the Internet, bulletin boards, and commercial networks such as America On Line (AOL). 4. Entered into an agreement with a company (Viacrypt, now Network Associates) to provide a fully compatible low cost commercial version of PGP.
    [Show full text]
  • A History of End-To-End Encryption and the Death of PGP
    25/05/2020 A history of end-to-end encryption and the death of PGP Hey! I'm David, a security engineer at the Blockchain team of Facebook (https://facebook.com/), previously a security consultant for the Cryptography Services of NCC Group (https://www.nccgroup.com). I'm also the author of the Real World Cryptography book (https://www.manning.com/books/real-world- cryptography?a_aid=Realworldcrypto&a_bid=ad500e09). This is my blog about cryptography and security and other related topics that I Ûnd interesting. A history of end-to-end encryption and If you don't know where to start, you might want to check these popular the death of PGP articles: posted January 2020 - How did length extension attacks made it 1981 - RFC 788 - Simple Mail Transfer Protocol into SHA-2? (/article/417/how-did-length- extension-attacks-made-it-into-sha-2/) (https://tools.ietf.org/html/rfc788) (SMTP) is published, - Speed and Cryptography the standard for email is born. (/article/468/speed-and-cryptography/) - What is the BLS signature scheme? (/article/472/what-is-the-bls-signature- This is were everything starts, we now have an open peer-to-peer scheme/) protocol that everyone on the internet can use to communicate. - Zero'ing memory, compiler optimizations and memset_s (/article/419/zeroing-memory- compiler-optimizations-and-memset_s/) 1991 - The 9 Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementations The US government introduces the 1991 Senate Bill 266, (/article/461/the-9-lives-of-bleichenbachers- which attempts to allow "the Government to obtain the cat-new-cache-attacks-on-tls- plain text contents of voice, data, and other implementations/) - How to Backdoor Di¸e-Hellman: quick communications when appropriately authorized by law" explanation (/article/360/how-to-backdoor- from "providers of electronic communications services di¸e-hellman-quick-explanation/) and manufacturers of electronic communications - Tamarin Prover Introduction (/article/404/tamarin-prover-introduction/) service equipment".
    [Show full text]
  • Gnu Privacy Guard (Gnupg) Mini Howto (Italiano)
    Gnu Privacy Guard (GnuPG) Mini Howto (italiano) Brenno J.S.A.A.F. de Winter (inglese) <[email protected]>, Michael Fischer v. Mollard (tedesco) <[email protected]>, Arjen Baart (olandese) <[email protected]>, Cristian Riga- monti (italiano) <[email protected]> Versione 0.1.4 12 maggio 2003 Questo documento spiega come usare GNU Privacy Guard (GnuPG), un sistema di crittografia Open Source e compatibile con OpenPGP. Per mantenere il programma totalmente libero, si `eevitato l’uso di RSA e di altri algoritmi brevettati. Il documento originale `escritto in tedesco da Michael Fischer v. Mollard, questa traduzione italiana, a cura di Cristian Rigamonti, `ebasata sulla traduzione inglese del testo originale. Indice 1 Concetti 2 1.1 Crittografia a chiave pubblica .................................... 2 1.2 Firme digitali ............................................. 2 1.3 Rete di fiducia ............................................ 3 1.4 Limiti alla sicurezza ......................................... 3 2 Installazione 3 2.1 Sorgenti di GnuPG .......................................... 3 2.2 Configurazione ............................................ 4 2.3 Compilazione ............................................. 4 2.4 Installazione .............................................. 5 3 Uso delle chiavi 5 3.1 Creare una chiave ........................................... 5 3.2 Esportare le chiavi .......................................... 6 3.3 Importare le chiavi .......................................... 6 3.4 Revocare una chiave ........................................
    [Show full text]
  • Security Analysis and Trust Models in Wireless Networks Lela Mirtskhulava
    Security Analysis and Trust Models in Wireless Networks Lela Mirtskhulava [email protected] Department of Computer Sciences Faculty of Exact and Natural Sciences Iv. Javakhishvili Tbilisi State University University str., 13, Georgia In the given work, we analyse the serious weaknesses recently discovered in WPA2 (Wi-Fi Protected Access 2) in October 2017 and KRACK (Key Reinstallation Attack) attack on WPA2 announced by Computer Science Scientists. The KRACKs were introduced to abuse design flaws in cryptographic protocols to reinstall an already-in-use key. Several types of cryptographic Wi-Fi handshakes are affected by the attack. There are different forms of trust to address different types of network security problems and reduce risk in certain conditions. This paper explores the trust models applied by various cryptographic schemes: a) the web of trust employed by Pretty Good Privacy (PGP) where users using their own set of trusted public keys, b) Kerberos, a secret key distribution scheme using a trusted third party, c) certificates, which allow a set of trusted third parties to authenticate each other and, by implication, each other's users. Each of the above mentioned trust models differs in complexity, scope, scalability and general applicability. Which model of trust to apply in certain circumstances and types of wireless networks are discussed in the given paper. It describes the major security issues and their techniques of building trust model by monitoring network behavior. It is intended to use secure and faster cryptographic solution for Wi-Fi networks security by using an open source public-key NTRU cryptosystem that uses lattice-based cryptography.
    [Show full text]
  • Crypto Projects That Might Not Suck
    Crypto Projects that Might not Suck Steve Weis PrivateCore ! http://bit.ly/CryptoMightNotSuck #CryptoMightNotSuck Today’s Talk ! • Goal was to learn about new projects and who is working on them. ! • Projects marked with ☢ are experimental or are relatively new. ! • Tried to cite project owners or main contributors; sorry for omissions. ! Methodology • Unscientific survey of projects from Twitter and mailing lists ! • Excluded closed source projects & crypto currencies ! • Stats: • 1300 pageviews on submission form • 110 total nominations • 89 unique nominations • 32 mentioned today The People’s Choice • Open Whisper Systems: https://whispersystems.org/ • Moxie Marlinspike (@moxie) & open source community • Acquired by Twitter 2011 ! • TextSecure: Encrypt your texts and chat messages for Android • OTP-like forward security & Axolotl key racheting by @trevp__ • https://github.com/whispersystems/textsecure/ • RedPhone: Secure calling app for Android • ZRTP for key agreement, SRTP for call encryption • https://github.com/whispersystems/redphone/ Honorable Mention • ☢ Networking and Crypto Library (NaCl): http://nacl.cr.yp.to/ • Easy to use, high speed XSalsa20, Poly1305, Curve25519, etc • No dynamic memory allocation or data-dependent branches • DJ Bernstein (@hashbreaker), Tanja Lange (@hyperelliptic), Peter Schwabe (@cryptojedi) ! • ☢ libsodium: https://github.com/jedisct1/libsodium • Portable, cross-compatible NaCL • OpenDNS & Frank Denis (@jedisct1) The Old Standbys • Gnu Privacy Guard (GPG): https://www.gnupg.org/ • OpenSSH: http://www.openssh.com/
    [Show full text]
  • SIGMA: the 'Sign-And-Mac' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols
    SIGMA: the `SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols ∗ Hugo Krawczyky June 12, 2003 Abstract We present the SIGMA family of key-exchange protocols and the \SIGn-and-MAc" approach to authenticated Diffie-Hellman underlying its design. The SIGMA protocols provide perfect forward secrecy via a Diffie-Hellman exchange authenticated with digital signatures, and are specifically designed to ensure sound cryptographic key exchange while supporting a variety of features and trade-offs required in practical scenarios (such as optional identity protection and reduced number of protocol rounds). As a consequence, the SIGMA protocols are very well suited for use in actual applications and for standardized key exchange. In particular, SIGMA serves as the cryptographic basis for the signature-based modes of the standardized Internet Key Exchange (IKE) protocol (versions 1 and 2). This paper describes the design rationale behind the SIGMA approach and protocols, and points out to many subtleties surrounding the design of secure key-exchange protocols in general, and identity-protecting protocols in particular. We motivate the design of SIGMA by comparing it to other protocols, most notable the STS protocol and its variants. In particular, it is shown how SIGMA solves some of the security shortcomings found in previous protocols. ∗A shortened version of this paper appears in the proceedings of CRYPTO'03. For further information related to the SIGMA protocols see http://www.ee.technion.ac.il/~hugo/sigma.html yEE Department, Technion, Haifa, Israel, and IBM T.J. Watson Research Center. Email: [email protected] 1 Contents 1 Introduction 1 2 Preliminaries: On the Security of Key-Exchange Protocols 4 2.1 Overview of the security model and requirements .
    [Show full text]
  • Pgpfone Pretty Good Privacy Phone Owner’S Manual Version 1.0 Beta 7 -- 8 July 1996
    Phil’s Pretty Good Software Presents... PGPfone Pretty Good Privacy Phone Owner’s Manual Version 1.0 beta 7 -- 8 July 1996 Philip R. Zimmermann PGPfone Owner’s Manual PGPfone Owner’s Manual is written by Philip R. Zimmermann, and is (c) Copyright 1995-1996 Pretty Good Privacy Inc. All rights reserved. Pretty Good Privacy™, PGP®, Pretty Good Privacy Phone™, and PGPfone™ are all trademarks of Pretty Good Privacy Inc. Export of this software may be restricted by the U.S. government. PGPfone software is (c) Copyright 1995-1996 Pretty Good Privacy Inc. All rights reserved. Phil’s Pretty Good engineering team: PGPfone for the Apple Macintosh and Windows written mainly by Will Price. Phil Zimmermann: Overall application design, cryptographic and key management protocols, call setup negotiation, and, of course, the manual. Will Price: Overall application design. He persuaded the rest of the team to abandon the original DOS command-line approach and designed a multithreaded event-driven GUI architecture. Also greatly improved call setup protocols. Chris Hall: Did early work on call setup protocols and cryptographic and key management protocols, and did the first port to Windows. Colin Plumb: Cryptographic and key management protocols, call setup negotiation, and the fast multiprecision integer math package. Jeff Sorensen: Speech compression. Will Kinney: Optimization of GSM speech compression code. Kelly MacInnis: Early debugging of the Win95 version. Patrick Juola: Computational linguistic research for biometric word list. -2- PGPfone Owner’s
    [Show full text]
  • Security Analysis of the Signal Protocol Student: Bc
    ASSIGNMENT OF MASTER’S THESIS Title: Security Analysis of the Signal Protocol Student: Bc. Jan Rubín Supervisor: Ing. Josef Kokeš Study Programme: Informatics Study Branch: Computer Security Department: Department of Computer Systems Validity: Until the end of summer semester 2018/19 Instructions 1) Research the current instant messaging protocols, describe their properties, with a particular focus on security. 2) Describe the Signal protocol in detail, its usage, structure, and functionality. 3) Select parts of the protocol with a potential for security vulnerabilities. 4) Analyze these parts, particularly the adherence of their code to their documentation. 5) Discuss your findings. Formulate recommendations for the users. References Will be provided by the supervisor. prof. Ing. Róbert Lórencz, CSc. doc. RNDr. Ing. Marcel Jiřina, Ph.D. Head of Department Dean Prague January 27, 2018 Czech Technical University in Prague Faculty of Information Technology Department of Computer Systems Master’s thesis Security Analysis of the Signal Protocol Bc. Jan Rub´ın Supervisor: Ing. Josef Kokeˇs 1st May 2018 Acknowledgements First and foremost, I would like to express my sincere gratitude to my thesis supervisor, Ing. Josef Kokeˇs,for his guidance, engagement, extensive know- ledge, and willingness to meet at our countless consultations. I would also like to thank my brother, Tom´aˇsRub´ın,for proofreading my thesis. I cannot express enough gratitude towards my parents, Lenka and Jaroslav Rub´ınovi, who supported me both morally and financially through my whole studies. Last but not least, this thesis would not be possible without Anna who re- lentlessly supported me when I needed it most. Declaration I hereby declare that the presented thesis is my own work and that I have cited all sources of information in accordance with the Guideline for adhering to ethical principles when elaborating an academic final thesis.
    [Show full text]
  • IT Acronyms.Docx
    List of computing and IT abbreviations /.—Slashdot 1GL—First-Generation Programming Language 1NF—First Normal Form 10B2—10BASE-2 10B5—10BASE-5 10B-F—10BASE-F 10B-FB—10BASE-FB 10B-FL—10BASE-FL 10B-FP—10BASE-FP 10B-T—10BASE-T 100B-FX—100BASE-FX 100B-T—100BASE-T 100B-TX—100BASE-TX 100BVG—100BASE-VG 286—Intel 80286 processor 2B1Q—2 Binary 1 Quaternary 2GL—Second-Generation Programming Language 2NF—Second Normal Form 3GL—Third-Generation Programming Language 3NF—Third Normal Form 386—Intel 80386 processor 1 486—Intel 80486 processor 4B5BLF—4 Byte 5 Byte Local Fiber 4GL—Fourth-Generation Programming Language 4NF—Fourth Normal Form 5GL—Fifth-Generation Programming Language 5NF—Fifth Normal Form 6NF—Sixth Normal Form 8B10BLF—8 Byte 10 Byte Local Fiber A AAT—Average Access Time AA—Anti-Aliasing AAA—Authentication Authorization, Accounting AABB—Axis Aligned Bounding Box AAC—Advanced Audio Coding AAL—ATM Adaptation Layer AALC—ATM Adaptation Layer Connection AARP—AppleTalk Address Resolution Protocol ABCL—Actor-Based Concurrent Language ABI—Application Binary Interface ABM—Asynchronous Balanced Mode ABR—Area Border Router ABR—Auto Baud-Rate detection ABR—Available Bitrate 2 ABR—Average Bitrate AC—Acoustic Coupler AC—Alternating Current ACD—Automatic Call Distributor ACE—Advanced Computing Environment ACF NCP—Advanced Communications Function—Network Control Program ACID—Atomicity Consistency Isolation Durability ACK—ACKnowledgement ACK—Amsterdam Compiler Kit ACL—Access Control List ACL—Active Current
    [Show full text]
  • Analysis and Implementation of the Messaging Layer Security Protocol
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by AMS Tesi di Laurea Alma Mater Studiorum · Universita` di Bologna CAMPUS DI CESENA Dipartimento di Informatica - Scienza e Ingegneria Corso di Laurea Magistrale in Ingegneria e Scienze Informatiche Analysis and Implementation of the Messaging Layer Security Protocol Tesi in Sicurezza delle Reti Relatore: Presentata da: Gabriele D'Angelo Nicola Giancecchi Anno Accademico 2018/2019 Parole chiave Network Security Messaging MLS Protocol Ratchet Trees \Oh me, oh vita! Domande come queste mi perseguitano. Infiniti cortei d'infedeli, citt`agremite di stolti, che v'`edi nuovo in tutto questo, oh me, oh vita! Risposta: Che tu sei qui, che la vita esiste e l’identit`a. Che il potente spettacolo continua, e che tu puoi contribuire con un verso." - Walt Whitman Alla mia famiglia. Introduzione L'utilizzo di servizi di messaggistica su smartphone `eincrementato in maniera considerevole negli ultimi anni, complice la sempre maggiore disponi- bilit`adi dispositivi mobile e l'evoluzione delle tecnologie di comunicazione via Internet, fattori che hanno di fatto soppiantato l'uso dei classici SMS. Tale incremento ha riguardato anche l'utilizzo in ambito business, un contesto dove `epi`ufrequente lo scambio di informazioni confidenziali e quindi la necessit`adi proteggere la comunicazione tra due o pi`upersone. Ci`onon solo per un punto di vista di sicurezza, ma anche di privacy personale. I maggiori player mondiali hanno risposto implementando misure di sicurezza all'interno dei propri servizi, quali ad esempio la crittografia end-to-end e regole sempre pi`ustringenti sul trattamento dei dati personali.
    [Show full text]
  • Case Study on the Official Scripts Electronic Applications in Bantul)
    I.J. Information Engineering and Electronic Business, 2017, 4, 1-6 Published Online July 2017 in MECS (http://www.mecs-press.org/) DOI: 10.5815/ijieeb.2017.04.01 The Implementation of Pretty Good Privacy in eGovernment Applications (Case Study on the Official Scripts Electronic Applications in Bantul) Didit Suprihanto Department of Electrical Engineering Universitas Mulawarman, Kalimantan Timur, Indonesia, 75123 Email: [email protected] Tri Kuntoro Priyambodo Department of Computer Sciences & Electronics, Universitas Gadjah Mada, Yogyakarta, Indonesia, 55281 Corresponding Author Email: [email protected] Abstract—eGovernment application has evolved from the world [1]. The United Nations‘ global survey reports simply appearing as a website providing news and some ICT indicators that point to the measure of how far information, to the application that provides various a nation has gone in the implementation of e-governance services through online transactions. Provision of online such as: 1.E-readiness, 2.Web measure index, 3. transactions require the effectively and safely service, so Telecommunications infrastructure index, 4. Human the users can make sure that the entry data is secure and capital index, 5. E-participation index[2] will not be used by other parties which are not authorized. Information security is a major factor in the service of Security is also necessary for the service provider side of eGovernment. The using of the host to host in previous online transactions, it is necessary to keep the system, and services of eGovernment is considered as lacking in the data transactions sent through the communications security. Therefore, it needs more security to serve clients media and the data stored in the database are secured.
    [Show full text]