DOCSLIB.ORG

Problems with Elliptic Curve Cryptography in TLS and SSH

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Problems with Elliptic Curve Cryptography in TLS and SSH Problems With Elliptic Curve Cryptography In TLS and SSH Joe Testa Positron Security October 19, 2017 Overview ● Elliptic Curve Cryptography (ECC) became pretty popular in the last decade. – Used in TLS and SSH ● Common parameters are… shady. – Some people think they're backdoored by the NSA. ● What can you do about it? – From a sysadmin's perspective. What is Elliptic Curve Cryptography? ● ECC is done with elliptic curves over finite fields in the form of: y2 = x3 + ax + b (mod p) ● Its security is based on the discrete log problem. – Diffie-Hellman & DSA depend on this as well. ● There are EC equivalents of Diffie-Hellman and DSA: – ECDH – ECDSA Why Does ECC Matter? ● The same security levels can be achieved with much smaller keys: Source: NIST SP 800-57 Pt. 1 Rev. 4, page 53 Why Does ECC Matter? ● If keys are much smaller, then: – Key generation is much faster. – Embedded devices can encrypt & decrypt faster. – Embedded devices can use less power. – High-volume servers can perform more operations. ● A 256 bit security level becomes practical. – Otherwise, you'd need a 15,360-bit RSA key. Curve Parameters ● ECC isn't immediately ready for use like RSA. ● Curve parameters must be set: y2 = x3 + ax + b (mod p) ● What do you use for a, b, p? – You also need the prime order r, the coefficient, and a base point, G. NIST Curve Parameters ● National Institute of Standards and Technology (NIST) FIPS 186-2, January 2000. – “Hey everybody! Just use these curves!” ● “And don't ask any questions...” ● Defines three classes of curves: – 5 over prime fields, generated “randomly” – 5 over binary fields, also “random” – 5 special-case binary field Koblitz curves. ● Many people consider these “random” parameters suspicious! NIST Curve Parameters ● The “random” parameters were generated using SHA-1(seed value). ● No mention of how the seed values were obtained! – For P-256: c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 ● The NSA could have iterated over many seeds to find parameters that introduce weaknesses. – This is exactly what the BADA55 project did with GPUs recently! https://bada55.cr.yp.to/ NIST Curve Parameters ● In FIPS 186-2: – “The pseudo-random curves are generated via the SHA-1 based method given in the ANSI X9.62 and IEEE P1363 standards.” – Why weren’t they included?? ● Neither are available for free. – ANSI X9.62 costs $100. – IEEE P1363 costs $97 for the public; $77 for members. – The ANSI doc cost $500+ in 2006... ● I've never encountered proof that the seeds even yield the parameters(!) NIST Curve Parameters ● The five prime field curves started to become popular: – P-192 – P-224 – P-256 – P-384 – P-521 (not a typo) ● P-256 has a security level of 128 bits. – This curve became the most popular. NSA Suite B ● In 2005, the National Security Agency released their “Suite B” protocols. ● Suite B is a set of publicly-known algorithms deemed suitable for Top Secret data. – Suite A are classified protocols. ● Recommended ECDSA, ECDH, and appropriate parameters. – Curve P-256 was included. – “If its back-doored, why was it included?” ECC Added To TLS ● In May 2006, ECC was formally added to TLS v1.0 and v1.1. – RFC 4492 ● All curves included from: SEC 2: Recommended Elliptic Curve Domain Parameters (Certicom, 2000). – This includes all the NIST P-curves. ● In August 2008, TLS 1.2 was specified, and included the same ones. Bitcoin ● In 2009, Satoshi Nakamoto avoided these popular NIST curves for Bitcoin. ● Chose the rarely-used secp256k1 from SEC 2. – Not even specified in NIST FIPS 186-2. ● secp256k1 is a Koblitz curve. – Parameters were chosen without NIST/NSA interference. – Has ~30% performance improvements over P- curves. Dual_EC_DRBG Backdoor ● Dual_EC_DRBG is effectively a random number generator. ● It first came to light in ANSI X9.82 (published Sept. 2007; early drafts in 2004?). – Members of ANSI committee were suspicious of it. – Tradeoff: suspicious parameters could be re- generated by the users. – However, later the suspicious parameters were mandatory to attain FIPS 140-2 certification. ● Source: http://marc.info/?l=openssl-announce&m=138747119822324&w=2 Dual_EC_DRBG Backdoor ● NIST Special Publication 800-90 published it in June 2006. ● Microsoft employees D. Shumow and N. Ferguson give an informal presentation in August 2007, detailing their suspicions. – http://rump2007.cr.yp.to/15-shumow.pdf ● Dual_EC_DRBG was also published in ISO 18031 on Nov. 2011 (?). Dual_EC_DRBG Backdoor ● Snowden leaks confirmed that Dual_EC_DRBG had an intentional back door placed there by the NSA: “Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.”” – New York Times, Sept. 5, 2013, http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.h tml?pagewanted=all Dual_EC_DRBG Backdoor ● On Dec. 20, 2013, Reuters reports that the National Security Agency paid RSA $10M include it as the default RNG in their BSAFE crypto toolkit. – http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C2201 31220 ● So naturally, this made people even more afraid of the NIST P-curves. SafeCurves Project ● D. Bernstein and T. Lange's SafeCurves Project (2014) evaluated 20 curves across 11 criteria. – https://safecurves.cr.yp.to/index.html ● Included were three of the NIST P-curves, along with secp256k1. – Wanna guess the results? SafeCurves Project Partial summary of results: Source: https://safecurves.cr.yp.to/index.html NSA Updates Long-Term Strategy ● In August 2015, NSA released a bombshell statement: “For those partners and vendors that have not yet made the transition to Suite B elliptic curve algorithms, we recommend not making a significant expenditure to do so at this point but instead to prepare for the upcoming quantum resistant algorithm transition.” – https://web.archive.org/web/20151123081120/https://www.nsa.gov/ia/pr ograms/suiteb_cryptography ● The NSA had been pushing ECC hard for about two decades, then suddenly dumps it! ● Also, P-256 was removed from Suite B with no rationale provided. Koblitz and Menezes Weigh In ● Koblitz & Menezes publish an informal and in- depth 21-page paper a few months later (Oct. 2015). – http://eprint.iacr.org/2015/1018.pdf ● Examines the possibility of NIST curves backdoored. – Show estimations that if NSA could iterate over 248 seeds, then 2209 weak curves would exist in a pool of 2257 Koblitz and Menezes Weigh In “This would mean that this huge class of weak curves was known to the NSA in 1997 but is still undiscovered by outside researchers in 2015. It is highly unlikely that such a large family of weak elliptic curves would have escaped detection by the cryptographic research community from 1997 to the present.” Summary of NIST Curves ● Estimation & rationale by Koblitz & Menezes sound compelling… ● But why do seed values of P-curves appear random? – For P-256: c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 – For P-384: a335926a a319a27a 1d00896a 6773a482 7acdac73 – For P-521: d09e8800 291cb853 96cc6717 393284aa a0da64ba ● No rationale was ever given for these values! – It was recently shown that “random” seeds can be used to generate weak curve parameters with GPUs… – https://bada55.cr.yp.to/ Summary of NIST Curves ● NSA got caught red-handed with EC_DUAL_DRBG. ● The standardization path for EC_DUAL_DRBG is similar to how the NIST P-curves came about. – Pushed into ANSI, then NIST; parameters with little/no rationale. ● “Why would the government use back-doored algorithms?” Summary of NIST Curves ● NObody But US (“NOBUS”) policy. Quote from former NSA Directory Hayden (Oct. 2013): “You look at a vulnerability through a different lens if even with the vulnerability it requires substantial computational power or substantial other attributes and you have to make the judgment who else can do this? If there's a vulnerability here that weakens encryption but you still need four acres of Cray computers in the basement in order to work it you kind of think "NOBUS" and that's a vulnerability we are not ethically or legally compelled to try to patch – it's one that ethically and legally we could try to exploit in order to keep Americans safe from others.” https://www.washingtonpost.com/news/the-switch/wp/2013/10/04/why-everyone-is-lef t-less-secure-when-the-nsa-doesnt-help-fix-security-flaws/ Summary of NIST Curves ● The NOBUS policy can be interpreted as the missing link. ● “Why would the US government push backdoored curves, then use them for classified intel itself?” ● Because NOBUS! – They reasonably think nobody else can break them. Summary of NIST Curves ● My personal suspicion: the NSA intentionally chose parameters that looked weak at the time. ● They couldn't exploit the weaknesses immediately, but hoped to gain the ability in the future. ● Maybe they succeeded 10 years later? Maybe just two years ago? Maybe they never did? – Maybe they will three years from now? Summary of NIST Curves ● Fact: the SafeCurves study showed that P-256 and P-384 have some bad properties. ● Fact: NSA no longer recommends P-256 for classified data. ● There are other curves created by the community with better properties. ● Verdict: don't use the NIST curves. Improved Curves ● Curve25519, proposed by D. Bernstein in 2005. – Offers 128 bits of security. – Rationale provided for all parameters. – Offers excellent performance. – Became default for key exchange in OpenSSH 6.5 (Jan. 2014). ● Curve448 (aka Ed448-Goldilocks) – Same perks as Curve25519, but with ~224 bits of security. ● Both are formalized in RFC 7748. – Referenced in upcoming TLSv1.3 draft! How To Avoid NIST Curves? ● Some people wonder how to avoid NIST curves.
Load more

Recommended publications
  • Horizontal PDF Slides
    1 2 The first 10 years of Curve25519 Abstract: “This paper explains the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done. free key compression, free key validation, and state-of-the-art 2005.09.15: Software online. timing-attack protection), 2005.09.20: Invited talk at ECC. more than twice as fast as other authors’ results at the same 2005.11.15: Paper online; conjectured security level (with submitted to PKC 2006. or without the side benefits).” 1 2 3 The first 10 years of Curve25519 Abstract: “This paper explains Elliptic-curve computations the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done. free key compression, free key validation, and state-of-the-art 2005.09.15: Software online. timing-attack protection), 2005.09.20: Invited talk at ECC. more than twice as fast as other authors’ results at the same 2005.11.15: Paper online; conjectured security level (with submitted to PKC 2006. or without the side benefits).” 1 2 3 The first 10 years of Curve25519 Abstract: “This paper explains Elliptic-curve computations the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done.
    [Show full text]
  • Fast Elliptic Curve Cryptography in Openssl
    Fast Elliptic Curve Cryptography in OpenSSL Emilia K¨asper1;2 1 Google 2 Katholieke Universiteit Leuven, ESAT/COSIC [email protected] Abstract. We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224. Our implementation is fully integrated into OpenSSL 1.0.1: full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key ex- change over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster. In ad- dition, our implementation is immune to timing attacks|most notably, we show how to do small table look-ups in a cache-timing resistant way, allowing us to use precomputation. To put our results in context, we also discuss the various security-performance trade-offs available to TLS applications. Keywords: elliptic curve cryptography, OpenSSL, side-channel attacks, fast implementations 1 Introduction 1.1 Introduction to TLS Transport Layer Security (TLS), the successor to Secure Socket Layer (SSL), is a protocol for securing network communications. In its most common use, it is the \S" (standing for \Secure") in HTTPS. Two of the most popular open- source cryptographic libraries implementing SSL and TLS are OpenSSL [19] and Mozilla Network Security Services (NSS) [17]: OpenSSL is found in, e.g., the Apache-SSL secure web server, while NSS is used by Mozilla Firefox and Chrome web browsers, amongst others. TLS provides authentication between connecting parties, as well as encryp- tion of all transmitted content. Thus, before any application data is transmit- ted, peers perform authentication and key exchange in a TLS handshake.
    [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]
  • NUMS Elliptic Curves and Their Efficient Implementation
    Fourℚ-based cryptography for high-performance and low-power applications Real World Cryptography Conference 2017 January 4-6, New York, USA Patrick Longa Microsoft Research Next-generation elliptic curves New IETF Standards • The Crypto Forum Research Group (CFRG) selected two elliptic curves: Bernstein’s Curve25519 and Hamburg’s Ed448-Goldilocks • RFC 7748: “Elliptic Curves for Security” (published on January 2016) • Curve details; generation • DH key exchange for both curves • Ongoing work: signature scheme • draft-irtf-cfrg-eddsa-08, “Edwards-curve Digital Signature Algorithm (EdDSA)” 1/23 Next-generation elliptic curves Farrel-Moriarity-Melkinov-Paterson [NIST ECC Workshop 2015]: “… the real motivation for work in CFRG is the better performance and side- channel resistance of new curves developed by academic cryptographers over the last decade.” Plus some additional requirements such as: • Rigidity in curve generation process. • Support for existing cryptographic algorithms. 2/23 Next-generation elliptic curves Farrel-Moriarity-Melkinov-Paterson [NIST ECC Workshop 2015]: “… the real motivation for work in CFRG is the better performance and side- channel resistance of new curves developed by academic cryptographers over the last decade.” Plus some additional requirements such as: • Rigidity in curve generation process. • Support for existing cryptographic algorithms. 2/23 State-of-the-art ECC: Fourℚ [Costello-L, ASIACRYPT 2015] • CM endomorphism [GLV01] and Frobenius (ℚ-curve) endomorphism [GLS09, Smi16, GI13] • Edwards form [Edw07] using efficient Edwards ℚ coordinates [BBJ+08, HCW+08] Four • Arithmetic over the Mersenne prime 푝 = 2127 −1 Features: • Support for secure implementations and top performance. • Uniqueness: only curve at the 128-bit security level with properties above.
    [Show full text]
  • Simple High-Level Code for Cryptographic Arithmetic - with Proofs, Without Compromises
    Simple High-Level Code for Cryptographic Arithmetic - With Proofs, Without Compromises The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Erbsen, Andres et al. “Simple High-Level Code for Cryptographic Arithmetic - With Proofs, Without Compromises.” Proceedings - IEEE Symposium on Security and Privacy, May-2019 (May 2019) © 2019 The Author(s) As Published 10.1109/SP.2019.00005 Publisher Institute of Electrical and Electronics Engineers (IEEE) Version Author's final manuscript Citable link https://hdl.handle.net/1721.1/130000 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike Detailed Terms http://creativecommons.org/licenses/by-nc-sa/4.0/ Simple High-Level Code For Cryptographic Arithmetic – With Proofs, Without Compromises Andres Erbsen Jade Philipoom Jason Gross Robert Sloan Adam Chlipala MIT CSAIL, Cambridge, MA, USA fandreser, jadep, [email protected], [email protected], [email protected] Abstract—We introduce a new approach for implementing where X25519 was the only arithmetic-based crypto primitive cryptographic arithmetic in short high-level code with machine- we need, now would be the time to declare victory and go checked proofs of functional correctness. We further demonstrate home. Yet most of the Internet still uses P-256, and the that simple partial evaluation is sufficient to transform such initial code into the fastest-known C code, breaking the decades- current proposals for post-quantum cryptosystems are far from old pattern that the only fast implementations are those whose Curve25519’s combination of performance and simplicity. instruction-level steps were written out by hand.
    [Show full text]
  • The Double Ratchet Algorithm
    The Double Ratchet Algorithm Trevor Perrin (editor) Moxie Marlinspike Revision 1, 2016-11-20 Contents 1. Introduction 3 2. Overview 3 2.1. KDF chains . 3 2.2. Symmetric-key ratchet . 5 2.3. Diffie-Hellman ratchet . 6 2.4. Double Ratchet . 13 2.6. Out-of-order messages . 17 3. Double Ratchet 18 3.1. External functions . 18 3.2. State variables . 19 3.3. Initialization . 19 3.4. Encrypting messages . 20 3.5. Decrypting messages . 20 4. Double Ratchet with header encryption 22 4.1. Overview . 22 4.2. External functions . 26 4.3. State variables . 26 4.4. Initialization . 26 4.5. Encrypting messages . 27 4.6. Decrypting messages . 28 5. Implementation considerations 29 5.1. Integration with X3DH . 29 5.2. Recommended cryptographic algorithms . 30 6. Security considerations 31 6.1. Secure deletion . 31 6.2. Recovery from compromise . 31 6.3. Cryptanalysis and ratchet public keys . 31 1 6.4. Deletion of skipped message keys . 32 6.5. Deferring new ratchet key generation . 32 6.6. Truncating authentication tags . 32 6.7. Implementation fingerprinting . 32 7. IPR 33 8. Acknowledgements 33 9. References 33 2 1. Introduction The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. Typically the parties will use some key agreement protocol (such as X3DH [1]) to agree on the shared secret key. Following this, the parties will use the Double Ratchet to send and receive encrypted messages. The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones.
    [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]
  • 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]
  • 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]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [Show full text]
  • Signal E2E-Crypto Why Can’T I Hold All These Ratchets
    Signal E2E-Crypto Why Can’t I Hold All These Ratchets oxzi 23.03.2021 In the next 30 minutes there will be I a rough introduction in end-to-end encrypted instant messaging, I an overview of how Signal handles those E2E encryption, I and finally a demo based on a WeeChat plugin. Historical Background I Signal has not reinvented the wheel - and this is a good thing! I Goes back to Off-the-Record Communication (OTR)1. OTR Features I Perfect forward secrecy I Deniable authentication 1Borisov, Goldberg, and Brewer. “Off-the-record communication, or, why not to use PGP”, 2004 Influence and Evolution I OTR influenced the Signal Protocol, Double Ratchet. I Double Ratchet influence OMEMO; supports many-to-many communication. I Also influenced Olm, E2E encryption of the Matrix protocol. I OTR itself was influenced by this, version four was introduced in 2018. Double Ratchet The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. The Double Ratchet algorithm2 is essential in Signal’s E2E crypto. But first, some basics. 2Perrin, and Marlinspike. “The Double Ratchet Algorithm”, 2016 Cryptographic Ratchet A ratchet is a cryptographic function that only moves forward. In other words, one cannot easily reverse its output. Triple Ratchet, I guess.3 3By Salvatore Capalbi, https://www.flickr.com/photos/sheldonpax/411551322/, CC BY-SA 2.5 Symmetric-Key Ratchet Symmetric-Key Ratchet In everyday life, Keyed-Hash Message Authentication Code (HMAC) or HMAC-based KDFs (HKDF) are used. func ratchet(ckIn[]byte)(ckOut, mk[]byte){ kdf := hmac.New(sha256.New, ckIn) kdf.Write(c) // publicly known constant c out := kdf.Sum(nil) return out[:32], out[32:] } ck0 :=[]byte{0x23, 0x42, ...} // some initial shared secret ck1, mk1 := ratchet(ck0) ck2, mk2 := ratchet(ck1) Diffie-Hellman Key Exchange Diffie-Hellman Key Exchange Diffie-Hellman Key Exchange Originally, DH uses primitive residue classes modulo n.
    [Show full text]
  • Modern End-To-End Encrypted Messaging for the Desktop
    Die approbierte Originalversion dieser Diplom-/ Masterarbeit ist in der Hauptbibliothek der Tech- nischen Universität Wien aufgestellt und zugänglich. http://www.ub.tuwien.ac.at The approved original version of this diploma or master thesis is available at the main library of the Vienna University of Technology. http://www.ub.tuwien.ac.at/eng Modern End-to-End Encrypted Messaging for the Desktop DIPLOMARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur im Rahmen des Studiums Software Engineering and Internet Computing eingereicht von Richard Bayerle Matrikelnummer 1025259 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Privatdozent Dipl.Ing. Mag. Dr. Edgar Weippl Mitwirkung: Dr. Martin Schmiedecker Wien, 2. Oktober 2017 Richard Bayerle Edgar Weippl Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Modern End-to-End Encrypted Messaging for the Desktop DIPLOMA THESIS submitted in partial fulfillment of the requirements for the degree of Diplom-Ingenieur in Software Engineering and Internet Computing by Richard Bayerle Registration Number 1025259 to the Faculty of Informatics at the TU Wien Advisor: Privatdozent Dipl.Ing. Mag. Dr. Edgar Weippl Assistance: Dr. Martin Schmiedecker Vienna, 2nd October, 2017 Richard Bayerle Edgar Weippl Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit Richard Bayerle Seestraße 67 78315 Radolfzell am Bodensee Deutschland Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe.
    [Show full text]