Kryptografie/tmp: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
K Textersetzung - „Kryptografies“ durch „Kryptografie“
 
(142 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Motivation ==
siehe [[Kryptografie/Motivation]]


== Preface ==
== Geheime Übermittlung ==
Do not talk unencrypted
=== Voraussetzungen ===
[[Image:Bild1.png|top|alt="Neboltai"]]
* Der Empfänger kennt den Schlüssel
* aber sonst niemand
* Ohne Kenntnis des Schlüssels
* ist es unmöglich oder sehr schwierig den Klartext herauszufinden


== Acknowledgements ==
=== Schwierigkeiten ===
We would like to express our thanks to the following reviewers and people who have generously offered their time and interest (in alphabetical order):
* Schlüssel muss vorher vereinbart werden
Brown, ScottBrulebois, CyrilBurghardt, KrzysztofDirksen-Thedens, MathisDulaunoy, AlexandreEndres, JohannesGühring PhilippGrigg, IanHaslinger, GunnarHorenbeck, MaartenHuebl, AxelKnecht, PascalKoetter, Patrick BenKovacic, DanielLenzhofer, StefanLorünser, ThomasMaass, MaxMehlmauer, ChristianMillauer, TobiasMirbach, AndreasO’Brien, HughPacher, ChristophPalfrader, PeterPape, Tobias (layout)Petukhova, Anna (Logo)Pichler, PatrickRiebesel, NicolasRoeckx, KurtRoesen, JensRublik, MartinSchiffbauer, MarcSchosser, AndreasSchüpany, MathiasSchulze, AndreasSchwartzkopff, MichaelSchwarz, René («DigNative»)Seidl, Eva (PDF layout)Van Horenbeeck, MaartenWagner, Sebastian («sebix»)Zangerl, Alexander
* Schlüssel muss geheim bleiben „geheimer Kanal“
The reviewers did review parts of the document in their area of expertise; all remaining errors in this document are the sole responsibility of the primary authors.
* Das Kryptografieverfahren muss sicher sein


== Abstract ==
=== Vorhängeschloss-Analogie ===
Unfortunately, the computer security and cryptology communities have drifted apart over the last 25 years. Security people don’t always understand the available crypto tools, and crypto people don’t always understand the real-world problems.
* Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.
— Ross Anderson ''([https://bettercrypto.org/#bibliography-default-anderson2008security Anderson, 2008])''
This guide arose out of the need for system administrators to have an updated, solid, well researched and thought-through guide for configuring SSL, PGP, SSH and other cryptographic tools in the post-Snowden age. Triggered by the NSA leaks in the summer of 2013, many system administrators and IT security officers saw the need to strengthen their encryption settings. This guide is specifically written for these system administrators.
As Schneier noted in ([https://bettercrypto.org/#bibliography-default-Sch13 Schneier, 2013]), it seems that intelligence agencies and adversaries on the Internet are not breaking so much the mathematics of encryption per se, but rather use software and hardware weaknesses, subvert standardization processes, plant backdoors, rig random number generators and most of all exploit careless settings in server configurations and encryption systems to listen in on private communications. Worst of all, most communication on the internet is not encrypted at all by default (for SMTP, opportunistic TLS would be a solution).
This guide can only address one aspect of securing our information systems: getting the crypto settings right to the best of the authors' current knowledge. Other attacks, as the above mentioned, require different protection schemes which are not covered in this guide. This guide is not an introduction to cryptography. For background information on cryptography and cryptoanalysis we would like to refer the reader to the references in appendix [https://bettercrypto.org/#links Links] and [https://bettercrypto.org/#suggested_reading Suggested Reading] at the end of this document.
The focus of this guide is merely to give current ''best practices for configuring complex cipher suites'' and related parameters in a ''copy & paste-able manner''. The guide tries to stay as concise as is possible for such a complex topic as cryptography. Naturally, it can not be complete. There are many excellent guides ([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]) and best practice documents available when it comes to cryptography. However none of them focuses specifically on what an average system administrator needs for hardening his or her systems' crypto settings.
This guide tries to fill this gap.


{| style="border-spacing:0;width:17cm;"
== Kryptographisches Grundprinzip ==
|- style="border:none;padding:0.049cm;"
||
|| The guide was produced in an open source manner: every step of editing can be traced back to a specific author via our version control system.
|-
|}


= I: Introduction =
=== Umwandlung eines Klartextes  ===
 
* (p, plain text) in einem chiffrierten Text (c, ciphertext)
== Audience ==
* mit Hilfe einer reversiblen kryptographischen Funktion f:
Sysadmins. Sysadmins. Sysadmins. They are a force-multiplier.


== Related publications ==
=== symmetrische und asymmetrische Algorithmen ===
Ecrypt II [https://bettercrypto.org/#ii2011ecrypt [ii2011ecrypt]]
* Kryptografie / Entschlüsselung
Ecrypt II ([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]), ENISA’s report on Algorithms, key sizes and parameters ([https://bettercrypto.org/#bibliography-default-ENISA2013 ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson, 2013]) and BSI’s Technische Richtlinie TR-02102 ([https://bettercrypto.org/#bibliography-default-TR02102 für Sicherheit in der Informationstechnik (BSI), 2018]) are great publications which are more in depth than this guide. However, this guide has a different approach: it focuses on ''copy & paste-able settings'' for system administrators, effectively breaking down the complexity in the above mentioned reports to an easy to use format for the intended target audience.
* Schlüssel als zusätzliches Argument zu Funktion f


== How to read this guide ==
== Verschlüsseln mit symmetrischen Verfahren ==
This guide tries to accommodate two needs: first of all, having a handy reference on how to configure the most common services’ crypto settings and second of all, explain a bit of background on cryptography. This background is essential if the reader wants to choose his or her own cipher string settings.
System administrators who want to copy & paste recommendations quickly without spending a lot of time on background reading on cryptography or cryptanalysis can do so, by simply searching for the corresponding section in [https://bettercrypto.org/#bestpractice Best Practice].
It is important to know that in this guide the authors arrived at two recommendations: ''Cipher string A'' and ''Cipher string B''. While the former is a hardened recommendation a latter is a weaker one but provides wider compatibility. ''Cipher strings A and B'' are described in [https://bettercrypto.org/#recommendedciphers Recommended cipher suites].
However, for the quick copy & paste approach it is important to know that this guide assumes users are happy with ''Cipher string B''.
While [https://bettercrypto.org/#bestpractice Best Practice] is intended to serve as a copy & paste reference, [https://bettercrypto.org/#theory Theory] explains the reasoning behind ''cipher string B''. In particular [https://bettercrypto.org/#ciphersuites Architectural overview] explains how to choose individual cipher strings. We advise the reader to actually read this section and challenge our reasoning in choosing ''Cipher string B'' and to come up with a better or localized solution.


== Disclaimer ==
=== Kryptografie und Entschlüsselung mit selbem Schlüssel ===
A chain is no stronger than its weakest link, and life is after all a chain. 
* DES, IDEA
— William James
* Effizient, aber Schlüsselaustauschproblem
Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it. 
— Edward Snowden ''answering questions live on the Guardian’s website''
This guide specifically does not address physical security, protecting software and hardware against exploits, basic IT security housekeeping, information assurance techniques, traffic analysis attacks, issues with key-roll over and key management, securing client PCs and mobile devices (theft, loss), proper [https://en.wikipedia.org/wiki/Operations_security Operations Security], social engineering attacks, protection against tempest ([https://bettercrypto.org/#bibliography-default-Wikipedia:Tempest i_wikipedia_Tempest (codename)_, 2018]) attack techniques, thwarting different side-channel attacks (timing–, cache timing–, differential fault analysis, differential power analysis or power monitoring attacks), downgrade attacks, jamming the encrypted channel or other similar attacks which are typically employed to circumvent strong encryption.
The authors can not overstate the importance of these other techniques. Interested readers are advised to read about these attacks in detail since they give a lot of insight into other parts of cryptography engineering which need to be dealt with[[https://bettercrypto.org/#_footnotedef_1 1]]) ].
This guide does not talk much about the well-known insecurities of trusting a public-key infrastructure (PKI)[[https://bettercrypto.org/#_footnotedef_2 2]]. Nor does this text fully explain how to run your own Certificate Authority (CA).
Most of this zoo of information security issues are addressed in the very comprehensive book ''Security Engineering'' by Ross Anderson ([https://bettercrypto.org/#bibliography-default-anderson2008security Anderson, 2008]).
For some experts in cryptography this text might seem too informal. However, we strive to keep the language as non-technical as possible and fitting for our target audience: system administrators who can collectively improve the security level for all of their users.
Security is a process, not a product. 
— Bruce Schneier
This guide can only describe what the authors currently ''believe'' to be the best settings based on their personal experience and after intensive cross checking with literature and experts. For a complete list of people who reviewed this paper, see the <acknowledgements>. Even though multiple specialists reviewed the guide, the authors can give ''no guarantee whatsoever'' that they made the right recommendations. Keep in mind that tomorrow there might be new attacks on some ciphers and many of the recommendations in this guide might turn out to be wrong. Security is a process.
We therefore recommend that system administrators keep up to date with recent topics in IT security and cryptography.
In this sense, this guide is very focused on getting the cipher strings done right even though there is much more to do in order to make a system more secure. We the authors, need this document as much as the reader needs it.


=== Scope ===
=== Ver- und Entschlüsselung mit symmetrischer Kryptografie ===
In this guide, we restricted ourselves to:* Internet-facing services
* Commonly used services
* Devices which are used in business environments (this specifically excludes XBoxes, Playstations and similar consumer devices)
* OpenSSL
We explicitly excluded:* Specialized systems such as medical devices, most embedded systems, industrial control systems (ICS), etc.
* Wireless Access Points
* Smart-cards/chip cards


== Methods ==
=== Symmetrische Substitution ===
C.O.S.H.E.R - completely open source, headers, engineering and research. 
=== Sender und Empfänger müssen den gleichen Schlüssel besitzen ===
— A. Kaplan ''His mail signature for many years''
* um miteinander Kommunizieren zu können
For writing this guide, we chose to collect the most well researched facts about cryptography settings and let as many trusted specialists as possible review those settings. The review process is completely open and done on a public mailing list.
* Secret-Key-Verfahren
The document is available (read-only) to the public Internet on the web page and the source code of this document is on a public git server, mirrored on GitHub.com and open for public scrutiny. However, write permissions to the document are only granted to vetted people. The list of reviewers can be found in [https://bettercrypto.org/#acknowledgements Acknowledgements].
* Eignet sich gut, um große Datenmengen zu verschlüsseln
Every write operation to the document is logged via the <tt>git</tt> version control system and can thus be traced back to a specific author. We accept git pull requests on the [https://github.com/BetterCrypto/Applied-Crypto-Hardening github mirror] for this paper.
* Nachteil
Public peer-review and multiple eyes checking of our guide is the best strategy we can imagine at the present moment [[https://bettercrypto.org/#_footnotedef_3 3]].
* Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
We invite the gentle reader to participate in this public review process. Please read the [https://github.com/BetterCrypto/Applied-Crypto-Hardening/blob/master/CONTRIBUTING.md Contributing] document.
* was einen Schwachpunkt darstellt


= III: Theory =
=== Symmetrische Substitutionsverfahren ===


== Overview ==
=== Klassifizierungen ===
Number theorists are like lotus-eaters - having tasted this food they can never give it up.
* Zeichenchiffren
— Leopold Kronecker
* Blockchiffren
This chapter provides the necessary background information on why chapter [https://bettercrypto.org/#practicalsettings [practicalsettings]] recommended ''cipher string B''.
* Stromchiffren
We start off by explaining the structure of cipher strings in section [https://bettercrypto.org/#architecture [architecture]] (architecture) and define PFS in [https://bettercrypto.org/#pfs [pfs]]. Next we present ''Cipher String A'' and ''Cipher String B'' in section [https://bettercrypto.org/#recommendedciphers Recommended cipher suites].
* Zeichenchiffrierung
This concludes the section on cipher strings. In theory, the reader should now be able to construct his or her own cipher string. However, the question why certain settings were chosen still remains. To answer this part, we need to look at recommended keylengths, problems in specific algorithms and hash functions and other cryptographic parameters. As mentioned initially in section [https://bettercrypto.org/#relatedPublications [relatedPublications]], the ENISA ([https://bettercrypto.org/#bibliography-default-ENISA2013 ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson, 2013]), ECRYPT 2 ([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]) and BSI ([https://bettercrypto.org/#bibliography-default-TR02102 für Sicherheit in der Informationstechnik (BSI), 2018]) reports go much more into these topics and should be consulted in addition.
* Ermittelt jedes Zeichen des Geheimtextes aus dem entsprechenden Zeichen des Klartextes mit Hilfe des Schlüssels
We try to answer the questions by explaining issues with random number generators (section [https://bettercrypto.org/#rngs Random Number Generators]), keylengths (section [https://bettercrypto.org/#keylengths Keylengths]), current issues in ECC (section [https://bettercrypto.org/#EllipticCurveCryptography A note on Elliptic Curve Cryptography]), a note of warning on SHA-1 (section [https://bettercrypto.org/#sha A note on SHA-1]) and some comments on Diffie Hellman key exchanges (section [https://bettercrypto.org/#dh A note on Diffie Hellman Key Exchanges]). All of this is important in understanding why certain choices were made for ''Cipher String A and B''. However, for most system administrators, the question of compatibility is one of the most pressing ones. Having the freedom to be compatible with any client (even running on outdated operating systems) of course, reduces the security of our cipher strings. We address these topics in section [https://bettercrypto.org/#compatibility TODO]. All these sections will allow a system administrator to balance his or her needs for strong encryption with usability and compatibility.
* Cäsar-Addition
Last but not least, we finish this chapter by talking about issues in PKIs (section [https://bettercrypto.org/#pkis Public Key Infrastructures]), Certificate Authorities and on hardening a PKI. Note that these last few topics deserve a book on their own. Hence this guide can only mention a few current topics in this area.
* Stromchiffrierung
* Der Klartext wird Byte-weise über eine XOR-Operation verschlüsselt
* Sie Erzeugt eine sich zyklisch verändernde Byte-Folge, die mit dem Klartext verknüpft wird
* Blockchiffrierung
* Klartext wird in Bitgruppen geteilt
* über mehrstufige Verfahren mit dem Schlüssel über gleichbleibende Operationen in Geheimtext umgewandelt
* DES


== Cipher suites ==
== Asymmetrischer Kryptografie/public key-Kryptografie ==


=== Architectural overview ===
=== Public Key Kryptografie ===
This section defines some terms which will be used throughout this guide.
A cipher suite is a standardized collection of key exchange algorithms, encryption algorithms (ciphers) and Message authentication codes (MAC) algorithm that provides authenticated encryption schemes. It consists of the following components:
Key exchange protocol 
 
Authentication 
 
Cipher 
 
Message authentication code (MAC) 
 
Authenticated Encryption with Associated Data (AEAD) 
 
Listing 46. Composition of a typical cipher string
+-----+  +-----+  +--------+  +--------+
| DHE +--+ RSA +--+ AES256 +--+ SHA256 +
+-----+  +-----+  +--------+  +--------+


{| style="border-spacing:0;width:17cm;"
=== Ver- und Entschlüsselung mit verschiedenen Schlüsseln ===
|- style="border:none;padding:0.049cm;"
* “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
||
* Schlüssel-Paare: Öffentlicher und privater Schlüssel
|| A note on nomenclature
* z.&nbsp;B.&nbsp;: RSA, ElGamal, Elliptische Kurven (ECC)
There are two common naming schemes for cipher strings – IANA names (see appendix [https://bettercrypto.org/#links Links]) and the more well known OpenSSL names. In this document we will always use OpenSSL names unless a specific service uses IANA names.
* Problem
|-
* Meist ineffizienter als symmetrische Verfahren
|}
* deshalb häufig nur zum Austausch symmetrischer Schlüssel und für Unterschriften
* Der private Schlüssel darf aus dem öffentlichen nicht errechenbar sein
* Einwegfunktion mit Falltür
* Nur unter Kenntnis einer zusätzlichen Information effizient umkehrbar
* z.&nbsp;B.&nbsp;x = loga y mod n (RSA-Verfahren) unter Kenntnis der Primfaktoren


=== Forward Secrecy ===
=== Asymmetrische Substitution ===
Forward Secrecy or Perfect Forward Secrecy is a property of a cipher suite that ensures confidentiality even if the server key has been compromised. Thus if traffic has been recorded it can not be decrypted even if an adversary has got hold of the server key.* [https://en.wikipedia.org/wiki/Forward_secrecy Forward secrecy] (Wikipedia)
* Es werden 2 komplementäre Schlüssel benötigt
* [https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection Pushing for Perfect Forward Secrecy, an Important Web Privacy Protection] (EFF)
* 1 Key zum chiffrieren der Nachricht
* [https://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html SSL: Intercepted today, decrypted tomorrow] (Netcraft)
* 2 Key zum dechiffrieren der Nachricht
* Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
* Wird mit einem Schlüssel chiffriert
* kann nur mit dem anderen Schlüssel dechiffriert werden


=== Recommended cipher suites ===
=== Vorteile von Public-Key-Verfahren ===
* Jeder Kommunikationspartner benötigt einen Schlüssel
* seinen Private Key
* Der zweite Schlüssel wird veröffentlicht
* Nachteil
* Hohe Komplexität der durchzuführenden Operationen
* Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
* während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann


== Recommended cipher suites ==
=== Absicherung der asymmetrischen Substitution ===
In principle system administrators who want to improve their communication security have to make a difficult decision between effectively locking out some users and keeping high cipher suite security while supporting as many users as possible. The web-site [https://www.ssllabs.com/ Qualys SSL Labs] gives administrators and security engineers a tool to test their setup and compare compatibility with clients. The authors made use of ssllabs.com to arrive at a set of cipher suites which we will recommend throughout this document.
* Schwäche
* keine eindeutige Zuordnung des öffentlichen Schlüssels zu seinem Besitzer
* Ein „Man-in-the-Middle“ könnte sich dazwischen schalten und die Nachrichten unbemerkt entschlüsseln
* Informationen des öffentlichen Schlüssels und seines Besitzers sollten aus vertrauenswürdiger Quelle stammen
* Möglichkeiten im Rahmen der Public Key Infrastructure (PKI)
* Schlüssel kann über ein sicher betrachtetes Medium übertragen werden
* Beispiel
* Persönliche Übergabe, Telefon, Brief, Fax
* Identität des Schlüsselinhabers Zertifizieren lassen


{| style="border-spacing:0;width:17cm;"
=== Trust Center ===
|- style="border:none;padding:0.049cm;"
==== Certification Authority [CA] ====
||
* Zertifizierungsinstanz (Trust Center)
|| Caution
* Zur Überprüfung der Schlüsselinhaber
these settings can only represent a subjective choice of the authors at the time of writing. It might be a wise choice to select your own and review cipher suites based on the instructions in section [https://bettercrypto.org/#ChoosingYourOwnCipherSuites [ChoosingYourOwnCipherSuites]].
* Sender und Empfänger verwalten Listen von Zertifizierungsinstanzen
|-
* Überprüfung Zusammenhang öffentlicher Schlüssel und deren Absender
|}
* Zertifikat nach ITU-Standard X.509
* ALTERNATIVE
* Authentizität eines öffentlichen Schlüssels durch einen bekannten Kommunikationspartner bestätigen lassen
* „Web of True“ von PGP


=== Configuration A: Strong ciphers, fewer clients ===
== Substitution vs. Signatur ==
At the time of writing, our recommendation is to use the following set of strong cipher suites which may be useful in an environment where one does not depend on many, different clients and where compatibility is not a big issue. An example of such an environment might be machine-to-machine communication or corporate deployments where software that is to be used can be defined without restrictions.
* Algorithmen asymetrischer Kryptografieen unterscheiden sich
We arrived at this set of cipher suites by selecting:* TLS 1.2
* ob eine Nachricht verschlüsselt oder signiet werden soll
* Perfect forward secrecy / ephemeral Diffie Hellman
* strong MACs (SHA-2) or
* GCM as Authenticated Encryption scheme
This results in the OpenSSL string: <tt>EDH+aRSA+AES256:EECDH+aRSA+AES256:!SSLv3</tt>
Table 14. Configuration A ciphers


{| style="border-spacing:0;width:17cm;"
=== Substitution ===
|- style="border:none;padding:0.049cm;"
* Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers
! align=center| ID
* so, dass er sie mit seinem privaten Schlüssel wieder im Klartext lesen kann
! align=center| OpenSSL Name
! align=center| Version
! align=center| KeyEx
! align=center| Auth
! align=center| Cipher
! align=center| MAC
|- style="border:none;padding:0.049cm;"
|| '''0x009F'''
|| DHE-RSA-AES256-GCM-SHA384
|| TLSv1.2
|| DH
|| RSA
|| AESGCM(256)
|| AEAD
|- style="border:none;padding:0.049cm;"
|| '''0x006B'''
|| DHE-RSA-AES256-SHA256
|| TLSv1.2
|| DH
|| RSA
|| AES(256) (CBC)
|| SHA256
|- style="border:none;padding:0.049cm;"
|| '''0xC030'''
|| ECDHE-RSA-AES256-GCM-SHA384
|| TLSv1.2
|| ECDH
|| RSA
|| AESGCM(256)
|| AEAD
|- style="border:none;padding:0.049cm;"
|| '''0xC028'''
|| ECDHE-RSA-AES256-SHA384
|| TLSv1.2
|| ECDH
|| RSA
|| AES(256) (CBC)
|| SHA384
|-
|}


{| style="border-spacing:0;width:17cm;"
=== Signatur ===
|- style="border:none;padding:0.049cm;"
* Absender erzeugt mit seinem privatem Schlüssel eine Signatur
||
* Empfänger kann durch Verwendung des öffentlichen Schlüssel des Absenders die Nachricht verifiziert
|| Compatibility
At the time of this writing only Win 7 and Win 8.1 crypto stack, OpenSSL >= 1.0.1e, Safari 6 / iOS 6.0.1 and Safari 7 / OS X 10.9 are covered by that cipher string.
|-
|}


=== Configuration B: Weaker ciphers but better compatibility ===
== Tunneling ==
In this section we propose a slightly weaker set of cipher suites. For example, there are known weaknesses for the SHA-1 hash function that is included in this set. The advantage of this set of cipher suites is not only better compatibility with a broad range of clients, but also less computational workload on the provisioning hardware.
siehe [[Kryptografie/Tunneling]]
'''All examples in this publication use Configuration B'''.
We arrived at this set of cipher suites by selecting:* TLS 1.2, TLS 1.1, TLS 1.0
* allowing SHA-1 (see the comments on SHA-1 in section [https://bettercrypto.org/#SHA [SHA]])
This results in the OpenSSL string:
<tt>'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'</tt>
Table 15. Configuration B ciphers


{| style="border-spacing:0;width:17cm;"
= Wie baut man eine sicheren Block Cipher? =
|- style="border:none;padding:0.049cm;"
=== Probleme bei der Entwicklung von Kryptografieverfahren ===
! align=center| ID
{| class="wikitable sortable options"
! align=center| OpenSSL Name
! align=center| Version
! align=center| KeyEx
! align=center| Auth
! align=center| Cipher
! align=center| MAC
|- style="border:none;padding:0.049cm;"
|| '''0x009F'''
|| DHE-RSA-AES256-GCM-SHA384
|| TLSv1.2
|| DH
|| RSA
|| AESGCM(256)
|| AEAD
|- style="border:none;padding:0.049cm;"
|| '''0x006B'''
|| DHE-RSA-AES256-SHA256
|| TLSv1.2
|| DH
|| RSA
|| AES(256)
|| SHA256
|- style="border:none;padding:0.049cm;"
|| '''0xC030'''
|| ECDHE-RSA-AES256-GCM-SHA384
|| TLSv1.2
|| ECDH
|| RSA
|| AESGCM(256)
|| AEAD
|- style="border:none;padding:0.049cm;"
|| '''0xC028'''
|| ECDHE-RSA-AES256-SHA384
|| TLSv1.2
|| ECDH
|| RSA
|| AES(256)
|| SHA384
|- style="border:none;padding:0.049cm;"
|| '''0x009E'''
|| DHE-RSA-AES128-GCM-SHA256
|| TLSv1.2
|| DH
|| RSA
|| AESGCM(128)
|| AEAD
|- style="border:none;padding:0.049cm;"
|| '''0x0067'''
|| DHE-RSA-AES128-SHA256
|| TLSv1.2
|| DH
|| RSA
|| AES(128)
|| SHA256
|- style="border:none;padding:0.049cm;"
|| '''0xC02F'''
|| ECDHE-RSA-AES128-GCM-SHA256
|| TLSv1.2
|| ECDH
|| RSA
|| AESGCM(128)
|| AEAD
|- style="border:none;padding:0.049cm;"
|| '''0xC027'''
|| ECDHE-RSA-AES128-SHA256
|| TLSv1.2
|| ECDH
|| RSA
|| AES(128)
|| SHA256
|- style="border:none;padding:0.049cm;"
|| '''0x0088'''
|| DHE-RSA-CAMELLIA256-SHA
|| SSLv3
|| DH
|| RSA
|| Camellia(256)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0x0039'''
|| DHE-RSA-AES256-SHA
|| SSLv3
|| DH
|| RSA
|| AES(256)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0xC014'''
|| ECDHE-RSA-AES256-SHA
|| SSLv3
|| ECDH
|| RSA
|| AES(256)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0x0045'''
|| DHE-RSA-CAMELLIA128-SHA
|| SSLv3
|| DH
|| RSA
|| Camellia(128)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0x0033'''
|| DHE-RSA-AES128-SHA
|| SSLv3
|| DH
|| RSA
|| AES(128)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0xC013'''
|| ECDHE-RSA-AES128-SHA
|| SSLv3
|| ECDH
|| RSA
|| AES(128)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0x0084'''
|| CAMELLIA256-SHA
|| SSLv3
|| RSA
|| RSA
|| Camellia(256)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0x0035'''
|| AES256-SHA
|| SSLv3
|| RSA
|| RSA
|| AES(256)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0x0041'''
|| CAMELLIA128-SHA
|| SSLv3
|| RSA
|| RSA
|| Camellia(128)
|| SHA1
|- style="border:none;padding:0.049cm;"
|| '''0x002F'''
|| AES128-SHA
|| SSLv3
|| RSA
|| RSA
|| AES(128)
|| SHA1
|-
|-
|}
| [[Vertraulichkeit]] || Schutz der Daten vor unberechtigter Einsichtnahme
 
{| style="border-spacing:0;width:16.478cm;"
|- style="border:none;padding:0.049cm;"
||
|| Compatibility
Note that these cipher suites will not work with Windows XP’s crypto stack (e.g. IE, Outlook),
|-
|-
|}
| [[Authentisierung]] || Sicherstellung der Herkunft, Verbindlichkeit
 
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
||
|| Explanation
For a detailed explanation of the cipher suites chosen, please see [https://bettercrypto.org/#ChoosingYourOwnCipherSuites [ChoosingYourOwnCipherSuites]]. In short, finding a single perfect cipher string is practically impossible and there must be a tradeoff between compatibility and security. On the one hand there are mandatory and optional ciphers defined in a few RFCs, on the other hand there are clients and servers only implementing subsets of the specification.
Straightforwardly, the authors wanted strong ciphers, forward secrecy [[https://bettercrypto.org/#_footnotedef_25 25]] and the best client compatibility possible while still ensuring a cipher string that can be used on legacy installations (e.g. OpenSSL 0.9.8).
|-
|-
|}
| [[Anonymität]] || Schutz vor Bekanntwerden des Absenders und Empfängers
Our recommended cipher strings are meant to be used via copy and paste and need to work "out of the box".* TLSv1.2 is preferred over TLSv1.0 (while still providing a useable cipher string for TLSv1.0 servers).
* AES256 and CAMELLIA256 count as very strong ciphers at the moment.
* AES128 and CAMELLIA128 count as strong ciphers at the moment
* DHE or ECDHE for forward secrecy
* RSA as this will fit most of today’s setups
* AES256-SHA as a last resort: with this cipher at the end, even server systems with very old OpenSSL versions will work out of the box (version 0.9.8 for example does not provide support for ECC and TLSv1.1 or above). Note however that this cipher suite will not provide forward secrecy. It is meant to provide the same client coverage(eg. support Microsoft crypto libraries) on legacy setups.
 
=== Compatibility ===
 
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
||
|| TODO
Write this section. The idea here is to first document which server (and openssl) version we assumed. Once these parameters are fixed, we then list all clients which are supported for Variant A) and B). Therefore we can document compatibilities to some extent. The sysadmin can then choose roughly what he looses or gains by omitting certain cipher suites.
|-
|-
| [[Integrität]] || Unveränderlichkeit von Daten und Verlässlichkeit von Programmen
|}
|}


== Random Number Generators ==
== Mary Stuart 1516 - 1558 ==
[[Image:Bild11.png|top|alt="A real fair random number generator"]]
Bekanntes Opfer der Kryptoanalye
(Image license: [http://creativecommons.org/licenses/by-nc/2.5/ CC-BY-NC])
A good source of random numbers is essential for many crypto operations. The key feature of a good random number generator is the non-predictability of the generated numbers. This means that hardware support for generating entropy is essential.
Hardware random number generators in operating systems or standalone components collect entropy from various random events mostly by using the (low bits of the) time an event occurs as an entropy source. The entropy is merged into an entropy pool and in some implementations there is some bookkeeping about the number of random bits available.


=== When Random Number Generators Fail ===
== Shannon‘s Principle of Confusion ==
Random number generators can fail – returning predictable non-random numbers – if not enough entropy is available when random numbers should be generated.
Substitution Cipher
This typically occurs for embedded devices and virtual machines. Embedded devices lack some entropy sources other devices have, e.g.:* No persistent clock, so boot-time is not contributing to the initial RNG state.
* No hard-disk: No entropy from hard-disk timing, no way to store entropy between reboots.
Virtual machines emulate some hardware components so that the generated entropy is over-estimated. The most critical component that has been shown to return wrong results is an emulated environment is the timing source ([https://bettercrypto.org/#bibliography-default-Eng11 Engblom, 2011]).
Typically the most vulnerable time where low-entropy situations occur is shortly after a reboot. Unfortunately many operating system installers create cryptographic keys shortly after a reboot ([https://bettercrypto.org/#bibliography-default-HDWH12 Heninger, Durumeric, Wustrow, & Halderman, 2012]).
Another problem is that OpenSSL seeds its internal random generator only seldomly from the hardware random number generator of the operating system. This can lead to situations where a daemon that is started at a time when entropy is low keeps this low-entropy situation for hours leading to predictable session keys ([https://bettercrypto.org/#bibliography-default-HDWH12 Heninger, Durumeric, Wustrow, & Halderman, 2012]).
For systems where – during the lifetime of the keys – it is expected that low-entropy situations occur, RSA keys should be preferred over DSA keys: For DSA, if there is ever insufficient entropy at the time keys are used for signing this may lead to repeated ephemeral keys. An attacker who can guess an ephemeral private key used in such a signature can compromise the DSA secret key. For RSA this can lead to discovery of encrypted plaintext or forged signatures but not to the compromise of the secret key ([https://bettercrypto.org/#bibliography-default-HDWH12 Heninger, Durumeric, Wustrow, & Halderman, 2012]).


== Keylengths ==
== Shannon‘s Principle of Diffusion ==
On the choice between AES256 and AES128: I would never consider
Transposition Cipher
using AES256, just like I don't wear a helmet when I sit inside my car. It's
too much bother for the epsilon improvement in security.
Recommendations on keylengths need to be adapted regularly. Since this document first of all is static and second of all, does not consider itself to be authoritative on keylengths, we would rather refer to existing publications and websites. Recommending a safe key length is a hit-and-miss issue.
Furthermore, when choosing an encryption algorithm and key length, the designer/sysadmin always needs to consider the value of the information and how long it must be protected. In other words: consider the number of years the data needs to stay confidential.
The [http://www.ecrypt.eu.org/ecrypt2/documents.html ECRYPT II publication] gives a fascinating overview of strengths of symmetric keys in chapter 5 and chapter 7. Summarizing ECRYPT II, we recommend 128 bit of key strength for symmetric keys. In ECRYPT II, this is considered safe for security level 7, long term protection.
In the same ECRYPT II publication you can find a practical comparison of key size equivalence between symmetric key sizes and RSA, discrete log (DLOG) and EC keylengths. ECRYPT II arrives at the interesting conclusion that for an equivalence of 128 bit symmetric size, you will need to use an 3248 bit RSA key&nbsp;([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]).
There are a couple of other studies comparing keylengths and their respective strengths. The website [https://www.keylength.com/ https://www.keylength.com/] compares these papers and offers a good overview of approximations for key lengths based on recommendations by different standardization bodies and academic publications. Figure #fig:keylengths.com[1] shows a typical comparison of keylengths on this web site.
[[Image:Bild12.png|top|alt="Screenshot for 128 bit symmetric key size equivalents"]]


=== Summary ===
== Symmetrische Kryptografieverfahren ==
For asymmetric public-key cryptography we consider any key length below 3248 bits to be deprecated at the time of this writing (for long term protection).
=== Einfachster Einsatz  ===
For elliptic curve cryptography we consider key lengths below 256 bits to be inadequate for long term protection.
* basiert auf der logischen Exklusiv-Oder-Funktion
For symmetric algorithms we consider anything below 128 bits to be inadequate for long term protection.
* 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
* Es entspricht also der Inversen Verknüpfung:
* (A+B)+B=A+(B+B)Assoziativgesetz=A+0Eigenschaft von XOR=AEigenschaft von XOR
* Der Sender verschlüsselt ein Zeichen A mit einem Schlüssel B per XOR und versendet das Ergebnis
* Der Empfänger verknüpft das Ergebnis erneut mit Schlüssel B und erhält dann wieder das Zeichen A


=== Special remark on 3DES: ===
=== Symmetric Algorithms: Block Ciphers ===
We want to note that 3DES theoretically has 168 bits of security, however based on the NIST Special Publication 800-57 [[https://bettercrypto.org/#_footnotedef_26 26]].
Due to several [https://en.wikipedia.org/wiki/Triple_DES#Security security problems] the effective key length should be considered 80 bits. The NIST [https://csrc.nist.gov/news/2017/update-to-current-use-and-deprecation-of-tdea recommends] not to use 3DES any more and to migrate to AES as soon as possible.


== A note on Elliptic Curve Cryptography ==
=== Some Popular Block Ciphers ===
Everyone knows what a curve is, until he has studied enough
mathematics to become confused through the countless number
of possible exceptions.
Elliptic Curve Cryptography (simply called ECC from now on) is a branch of cryptography that emerged in the mid-1980s. The security of the RSA algorithm is based on the assumption that factoring large numbers is infeasible. Likewise, the security of ECC, DH and DSA is based on the discrete logarithm problem ([https://bettercrypto.org/#bibliography-default-Wikipedia:Discrete i_wikipedia_Discrete logarithm_, 2013]). Finding the discrete logarithm of an elliptic curve from its public base point is thought to be infeasible. This is known as the Elliptic Curve Discrete Logarithm Problem (ECDLP). ECC and the underlying mathematical foundation are not easy to understand - luckily, there have been some great introductions on the topic. [[https://bettercrypto.org/#_footnotedef_27 27]] [[https://bettercrypto.org/#_footnotedef_28 28]] [[https://bettercrypto.org/#_footnotedef_29 29]].
ECC provides for much stronger security with less computationally expensive operations in comparison to traditional asymmetric algorithms (See the Section [https://bettercrypto.org/#keylengths Keylengths]). The security of ECC relies on the elliptic curves and curve points chosen as parameters for the algorithm in question. Well before the NSA-leak scandal, there has been a lot of discussion regarding these parameters and their potential subversion. A part of the discussion involved recommended sets of curves and curve points chosen by different standardization bodies such as the National Institute of Standards and Technology (NIST) [[https://bettercrypto.org/#_footnotedef_30 30]] which were later widely implemented in most common crypto libraries. Those parameters came under question repeatedly from cryptographers ([https://bettercrypto.org/#bibliography-default-BL13 Bernstein & Lange, 2013]).
At the time of writing, there is ongoing research as to the security of various ECC parameters ([https://bettercrypto.org/#bibliography-default-DJBSC SafeCurves: choosing safe curves for elliptic-curve cryptography, 2013]). Most software configured to rely on ECC (be it client or server) is not able to promote or black-list certain curves. It is the hope of the authors that such functionality will be deployed widely soon. The authors of this paper include configurations and recommendations with and without ECC - the reader may choose to adopt those settings as he finds best suited to his environment. The authors will not make this decision for the reader.


{| style="border-spacing:0;width:17cm;"
== Symmetric Algorithms: Stream Ciphers ==
|- style="border:none;padding:0.049cm;"
||
|| Warning
One should get familiar with ECC, different curves and parameters if one chooses to adopt ECC configurations. Since there is much discussion on the security of ECC, flawed settings might very well compromise the security of the entire system!
|-
|}


== A note on SHA-1 ==
= RC4 =
In the last years several weaknesses have been shown for SHA-1. In particular, collisions on SHA-1 can be found using 263 operations, and recent results even indicate a lower complexity. Therefore, ECRYPT II and NIST recommend against using SHA-1 for generating digital signatures and for other applications that require collision resistance. The use of SHA-1 in message authentication, e.g. HMAC, is not immediately threatened.
=== RC Rivest Cipher  ===
We recommend using SHA-2 whenever available. Since SHA-2 is not supported by older versions of TLS, SHA-1 can be used for message authentication if a higher compatibility with a more diverse set of clients is needed.
* Stromverschlüsselungsverfahren
Our configurations A and B reflect this. While configuration A does not include SHA-1, configuration B does and thus is more compatible with a wider range of clients.
* Basiert auf XOR-Verknüpfung
* Sehr schnell und einfach
* Eignet sich gut in Software
* Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
* Dieser wird zur Chiffrierung des Klartextes verwendet
* RC4 Speichert 258 verschiedene Zusatzinformationen
* 256 sind Permutationen von 0-255 und somit gleich verteilt


== A note on Diffie Hellman Key Exchanges ==
= DES =
A common question is which Diffie-Hellman (DH) parameters should be used for Diffie Hellman key-exchanges [[https://bettercrypto.org/#_footnotedef_31 31]]. We follow the recommendations in ECRYPT II ([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]).
=== Familie der Blockchiffren ===
Where configurable, we recommend using the Diffie Hellman groups defined for IKE, specifically groups 14-18 (2048–8192 bit MODP) ([https://bettercrypto.org/#bibliography-default-rfc3526 Kivinen & Kojo, 2003]). These groups have been checked by many eyes and can be assumed to be secure.
* Teilt eine Nachricht in 64 Bit große Datenblöcke
For convenience, we provide these parameters as PEM files on our webserver [[https://bettercrypto.org/#_footnotedef_32 32]].
* 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
* Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
* Nachfolger: 3DES
* Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus


== Public Key Infrastructures ==
=== Data Encryption Standard (DES)Sicherheit von DES ===
Public-Key Infrastructures try to solve the problem of verifying whether a public key belongs to a given entity, so as to prevent Man In The Middle attacks.
* DES
There are two approaches to achieve that: ''Certificate Authorities'' and the ''Web of Trust''.
* erlaubt mit 56 Bit Schlüssellänge
Certificate Authorities (CAs) sign end-entities’ certificates, thereby associating some kind of identity (e.g. a domain name or an email address) with a public key. CAs are used with TLS and S/MIME certificates, and the CA system has a big list of possible and real problems which are summarized in section [https://bettercrypto.org/#hardeningpki Hardening PKI] and ([https://bettercrypto.org/#bibliography-default-https13 Durumeric, Kasten, Bailey, & Halderman, 2013]).
* 72 Billiarden mögliche Schlüssel
The Web of Trust is a decentralized system where people sign each other’s keys, so that there is a high chance that there is a "trust path" from one key to another. This is used with PGP keys, and while it avoids most of the problems of the CA system, it is more cumbersome.
* ist heute nicht mehr ausreichend
As alternatives to these public systems, there are two more choices: running a private CA, and manually trusting keys (as it is used with SSH keys or manually trusted keys in web browsers).
* per Brute-Force in 5 Tagen (?) geknackt
The first part of this section addresses how to obtain a certificate in the CA system. The second part offers recommendations on how to improve the security of your PKI.


=== Certificate Authorities ===
== Permutation ==
In order to get a certificate, you can find an external CA willing to issue a certificate for you, run your own CA, or use self-signed certificates. As always, there are advantages and disadvantages for every one of these options; a balance of security versus usability needs to be found.
* DES besteht aus 3 Bearbeitungsschritten
* Initiale Permutation
* Ver-/Entschlüsselung in mehreren Runden
* finale Permutation
* DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
* durch die damals noch kleinen CPU Register
* Finale Permutation = Inverse der initialen Permutation
* Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle


==== Certificates From an External Certificate Authority ====
; Kryptografie
There is a fairly large number of commercial CAs that will issue certificates for money. Some of the most ubiquitous commercial CAs are Verisign, GoDaddy, and Teletrust. However, there are also CAs that offer certificates for free. The most notable examples are StartSSL, which is a company that offers some types of certificates for free, and CAcert, which is a non-profit volunteer-based organization that does not charge at all for issuing certificates. Finally, in the research and education field, a number of CAs exist that are generally well-known and well-accepted within the higher-education community.
* DES basiert auf einer 64 Bit Kryptografie
A large number of CAs is pre-installed in client software’s or operating system’s`‘trust stores’'; depending on your application, you have to select your CA according to this, or have a mechanism to distribute the chosen CA’s root certificate to the clients.
* wovon jedoch nur 56 Bit kryptographisch relevant sind
When requesting a certificate from a CA, it is vital that you generate the key pair yourself. In particular, the private key should never be known to the CA. If a CA offers to generate the key pair for you, you should not trust that CA.
* Jedes 8 Bit = Parity-Bit
Generating a key pair and a certificate request can be done with a number of tools. On Unix-like systems, it is likely that the OpenSSL suite is available to you. In this case, you can generate a private key and a corresponding certificate request as follows:
* DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
$ openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
* Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
Country Name (2 letter code) [AU]:DE
* Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
State or Province Name (full name) [Some-State]:Bavaria
* Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
Locality Name (eg, city) []:Munich
* 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example
Organizational Unit Name (eg, section) []:Example Section
Common Name (e.g. server FQDN or YOUR name) []:example.com
Email Address []:admin@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:


==== Setting Up Your Own Certificate Authority ====
== Kryptografie ==
In some situations it is advisable to run your own certificate authority. Whether this is a good idea depends on the exact circumstances. Generally speaking, the more centralized the control of the systems in your environment, the fewer pains you will have to go through to deploy your own CA. On the other hand, running your own CA maximizes the trust level that you can achieve because it minimizes external trust dependencies.
* DES teilt den Klartext in 64 Bit Blöcke und
Again using OpenSSL as an example, you can set up your own CA with the following commands on a Debian system:
* splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
$ cd /usr/lib/ssl/misc
* R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.
$ sudo ./CA.pl -newca
Answer the questions according to your setup. Now that you have configured your basic settings and issued a new root certificate, you can issue new certificates as follows:
$ cd /usr/lib/ssl/misc
$ sudo ./CA.pl -newreq
Alternatively, software such as TinyCA that acts as a "wrapper" around OpenSSL and tries to make life easier is available.


==== Creating a Self-Signed Certificate ====
== Genügen 128 Bit? ==
If the desired trust level is very high and the number of systems involved is limited, the easiest way to set up a secure environment may be to use self-signed certificates. A self-signed certificate is not issued by any CA at all, but is signed by the entity that it is issued to. Thus, the organizational overhead of running a CA is eliminated at the expense of having to establish all trust relationships between entities manually.
* IDEA
With OpenSSL, you can self-sign a previously created certificate with this command:
* International Data Encryption Algorithm
$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
* arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
You can also create a self-signed certificate in just one command:
* 3.43669 * 1038
$ openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256
* knacken benötigt etwa 1012 Jahre
The resulting certificate will by default not be trusted by anyone at all, so in order to be useful, the certificate will have to be made known a priori to all parties that may encounter it.
* Daher gilt der IDEA heute als sicher


=== Hardening PKI ===
== Asymmetrische Kryptografieverfahren ==
In recent years several CAs were compromised by attackers in order to get a hold of trusted certificates for malicious activities. In 2011 the Dutch CA Diginotar was hacked and all certificates were revoked&nbsp;([https://bettercrypto.org/#bibliography-default-diginotar-hack Elinor Mills, 2011]). Recently Google found certificates issued to them, which were not used by the company&nbsp;([https://bettercrypto.org/#bibliography-default-googlecahack Damon Poeter, 2011]). The concept of PKIs heavily depends on the security of CAs. If they get compromised the whole PKI system will fail. Some CAs tend to incorrectly issue certificates that were designated to do a different job than what they were intended to by the CA&nbsp;([https://bettercrypto.org/#bibliography-default-gocode Adam Langley, et. al., 2013]).
Therefore several security enhancements were introduced by different organizations and vendors&nbsp;([https://bettercrypto.org/#bibliography-default-tschofenig-webpki H. Tschofenig and E. Lear, 2013]). Currently two methods are used, DANE ([https://bettercrypto.org/#bibliography-default-rfc6698 Hoffman & Schlyter, 2012]) and Certificate Pinning&nbsp;([https://bettercrypto.org/#bibliography-default-draft-ietf-websec-key-pinning C. Evans and C. Palmer, 2013]). Google recently proposed a new system to detect malicious CAs and certificates called Certificate Transparency&nbsp;([https://bettercrypto.org/#bibliography-default-certtransparency Adam Langley, Ben Laurie, Emilia Kasper, 2013]). In addition, RFC 6844 describes Certification Authorization Records, a mechanism for domain name owners to signal which Certificate Authorities are authorized to issue certificates for their domain.


=== Certification Authorization Records ===
=== Setzen auf 2 unterschiedliche Schlüssel ===
RFC 6844 describes Certification Authorization Records, a mechanism for domain name owners to signal which Certificate Authorities are authorized to issue certificates for their domain.
* Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
When a CAA record is defined for a particular domain, it specifies that the domain owner requests Certificate Authorities to validate any request against the CAA record. If the certificate issuer is not listed in the CAA record, it should not issue the certificate.
* Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
The RFC also permits Certificate Evaluators to test an issued certificate against the CAA record, but should exercise caution, as the CAA record may change during the lifetime of a certificate, without affecting its validity.
* Es lässt sich nicht vom public key auf den private key schließen
CAA also supports an iodef property type which can be requested by a Certificate Authority to report certificate issue requests which are inconsistent with the issuer’s Certificate Policy.
* Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
* die der Besitzer des private keys nur entschlüsseln kann


==== Configuration of CAA records ====
=== Bekanntester Vertreter ===
BIND supports CAA records as of version 9.9.6.
* RSA-Algorythmus
A CAA record can be configured by adding it to the zone file:
* Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
$ORIGIN example.com
* während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet
      CAA 0 issue "ca1.example"
      CAA 0 iodef "mailto:security@example.com"
If your organization uses multiple CA’s, you can configure multiple records:
      CAA 0 issue "ca1.example"
      CAA 0 issue "ca2.example"
"ca1.example" and "ca2.example" are unique identifiers for the CA you plan on using. These strings can be obtained from your Certificate Authority, and typically are its top level domain. An example is "letsencrypt.org" for the Let’s Encrypt CA operated by the Internet Security Research Group.
Knot-DNS supports CAA records as of version 2.2.0.


==== Validation of CAA records ====
= RSA =
Once a CAA record is deployed, it can be validated using the following dig query:
=== Basiert auf folgenden 4 Schritten ===
$ dig CAA google.com
* Wähle 2 große Primzahlen p und q, die geheim bleiben
<nowiki>; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com</nowiki>
* Berechne das Produkt n = p*q
<nowiki>;; ANSWER SECTION:</nowiki>
* Für öffentlichen Schlüssel wähle e < n
google.com.          3600 IN  CAA  0 issue "symantec.com"
* die teilerfremd zur Eulerschen Funktion E(n) = (p-1)*(q-1) ist
On older versions of Dig, which do not support CAA records, you can query the record type manually:
* Für privaten Schlüssel bestimme eine Zahl
$ dig +short -t TYPE257 google.com
* d = e^-1 mod E(n)
\# 19 0005697373756573796D616E7465632E636F6D
* Dann gilt
* e*d = 1 mod E(n)
* [d,n] ist der private Schlüssel


== TLS and its support mechanisms ==
=== Algorithmus bei der Kryptografie ===
* Alice verschlüsselt
* ihren Klartext m gemäß c = m^e mod n und
* sendet ihn an Bob.
* In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
* Bob entschlüsselt
* den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
* und erhält auf Grund des Zusammenhangs von d und e den Klartext m


=== HTTP Strict Transport Security (HSTS) ===
* Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
HTTP Strict Transport Security (HSTS) is a web security policy mechanism. HSTS is realized through HTTP header by which a web server declares that complying user agents (web browsers) should interact with it by using ''only'' secure HTTPS connections. [[https://bettercrypto.org/#_footnotedef_33 33]]
* Algorythmus zur Erzeugung und Überprüfung von Signaturen
HSTS header is bound to a DNS name or domain by which the server was accessed. For example if server serves content for two domains and it is HTTPS enabled only for one domain, the browser won’t enforce HSTS for the latter.
* Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
HSTS reduces the risk of active man-in-the-middle attacks such as SSL stripping, and impersonation attacks with ''untrusted'' certificate. HSTS also helps to avoid unintentional mistakes such as insecure links to a secure web site (missing HTTPS links [[https://bettercrypto.org/#_footnotedef_34 34]]), and mistyped HTTPS URLs.
* [d,n] = Privater Schlüssen von Alice
After the web browser receives a HSTS header in a ''correctly'' [[https://bettercrypto.org/#_footnotedef_35 35]] prepared SSL session it will automatically use secure HTTPS links for accessing the server.
* Bob entschlüsselt die Signatur gemäß m = s^e mod n und erhält auf Grund des Zusammenhangs von d und e den Klartext m
This prevents unencrypted HTTP access (SSL striping, mistyped HTTPS URLs, etc.) when the server is accessed later by the client.
* [e,n] = öffentlicher Schlüssel von Alice
When a server (that previously emitted a HSTS header) starts using an untrusted certificate, complying user agents must show an error message and ''block the server connection''. Thus impersonation MITM attack with ''untrusted'' certificates cannot occur.
For the initial setup HSTS header needs a trusted secure connection over HTTPS. This limitation can be addressed by compiling a list of STS enabled sites directly into a browser. [[https://bettercrypto.org/#_footnotedef_36 36]]


==== HSTS Header Directives ====
= Advanced Encryption Standard =
HSTS header can be parametrized by two directives:* max-age=<number-of-seconds>
* Nachfolgestandard für DES
* includeSubdomains
* 3DES mit 128 Bit gilt noch als sicher
''max-age'' is a required directive. This directive indicates the number of seconds during which the user agent should enforce the HSTS policy (after the reception of the STS header field from a server).
* wegen der Dreifachverschlüsselung deutlich langsamer als AES
''includeSubdomains'' is an optional directive. This directive indicates that the HSTS policy applies to this HSTS host as well as ''any subdomains of the host’s domain name''.
* AES unterstützt 128, 192 und 256 Bit lange Schlüssel
* Beispiel Hamachi
* AES mit 256 Bit Schlüssellänge
* im Modus Cipher-Block-Chaining


==== HSTS Client Support ====
== Advanced Encryption Standard (AES)http://www.nist.gov/aes ==
HSTS is supported [[https://bettercrypto.org/#_footnotedef_37 37]] by these web browsers:* Firefox version >= v4.0
* DES is nearly 25 years old!
* Chrome version >= 4.0
* Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
* Android Browser >=4.4
* Single DES with 56 bit key is permitted for legacy systems only.
* Opera version >= 12.0
* Evaluation of an Advanced Encryption Standard
* Opera mobile >= 16.0
* The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
* Safari >= 7.0
* 5 final candidate algorithms. Decision by NIST in Spring 2001
* Microsoft Internet Explorer >= 11 (with update provided 09. June 2015)
* Requirements for AES
* Microsoft Edge >= 12
* AES shall be publicly defined.
* AES shall be a symmetric block cipher.
* AES shall be implementable in both hardware and software.
* AES shall be designed so that the key length may be increased as needed.
* AES block size n = 128 bits, key size k = 128, 192, 256 bits


==== HSTS Considerations ====
== AES Round 2 Finalists ==
Before enabling HSTS it is recommended to consider following:* Is it ''required'' to serve content or services over HTTP?
* MARS(IBM)
* Enabling ''includeSubdomains'' and SSL certificate management.
* Modified Feistel Network - 32 Rounds
* Proper value of ''max-age''.
* Based on Mixed Structure DES
It is recommended to serve all content using HTTPS, but there are exceptions to this rule as well. Consider running a private PKI [[https://bettercrypto.org/#_footnotedef_38 38]]. CRLs and OCSP responses are published typically by HTTP protocol. If HSTS is enabled on the site where OCSP and CRLs are published the browser might fail fetching CRL or validating OCSP response.
* RC6 (RSA)
Similar reasoning goes for ''includeSubdomains''. One needs to be sure that HTTPS can be enforced for all subdomains. Moreover the administrators are advised to watch for expiration of the SSL certificate and handle the renewal process with caution. If a SSL certificate is renewed after expiration or misses a (HSTS enabled) domain name, the connection to site will break (without providing override mechanism to the end user).
* Feistel Network - 20 Rounds
Finally HSTS should be tested with lower ''max-age'' values and deployed with higher ''max-age'' values.
* Based on Modified RC5
* Rijndal(Joan Daemen / Vincent Rijmen)
* Modified Substitution Permutation Network - 10 Rounds
* Based on Square
* Serpent (Ross Anderson / Eli Biham / Lars Knudsen)
* Substitution Permutation Network - 32 Rounds
* Based on Bitlice Operations
* Twofish(Bruce Schneier)
* Feistel Network - 16 Rounds
* Based on Modified Blowfish


==== Testing HSTS ====
== Cipher Block Chaining (CBC) ==
HSTS can be tested either using locally or through the Internet.
* Um eine Frquenzanalyse zu verhindern wird eine Verkettung von Datenblöcken durchgeführt
For local testing it is possible to utilize Chrome Web browser UI by typing chrome://net-internals/#hsts [[https://bettercrypto.org/#_footnotedef_39 39]] in the address bar.
* Dabei wird der zu verschlüsselnde Datenblock exklusiv mit dem letzten verschlüsselten Datenblock verknüpft
Testing over the Internet can be conducted by Qualys SSL Labs test [https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/]. ''Strict Transport Security (HSTS)'' information is located in the ''Protocol Details'' section.
* Gleiche Datenblöcke werden so unterschiedlich modifiziert und unterschiedlich verschlüsselt
* Problem: Erste Datenblock
* Erzeugung eines Initialisierungs-Vekros (IV)
* Der IV wird zur Entschlüsselung benötigt
* daher wird er dem Empfänger übermittelt
* Vertraulichkeit ist nicht erforderlich
* IPsec – Protokolle übertragen den IV in jedem Datenpaket


==== References ====
== Advanced Encryption Standard ==
* Websites Must Use HSTS in Order to Be Secure: [https://www.eff.org/deeplinks/2014/02/websites-hsts https://www.eff.org/deeplinks/2014/02/websites-hsts]
=== CBC-Mode Entstehung von Mustern ===
* OWASP: HTTP Strict Transport Security: [https://www.owasp.org/index.php/HTTP_Strict_Transport_Security https://www.owasp.org/index.php/HTTP_Strict_Transport_Security]
* Rückschlüsse auf den Klartext
* HSTS Browser Compatibility List: [https://caniuse.com/stricttransportsecurity https://caniuse.com/stricttransportsecurity]
* Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
* RFC 6797:HTTP Strict Transport Security (HSTS) - Examples: [https://tools.ietf.org/html/rfc6797#section-6.2 https://tools.ietf.org/html/rfc6797#section-6.2]
* Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
* Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
* Angreifer versucht im Chiffrat einzelne Bit manipulieren
* ohne Kenntnis des Schlüssels
* ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
* auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
* Da sich so der Inhalt manipulieren lässt
* In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
* Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
* wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
* Da Daten blockweise verschlüsselt werden
* muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
* die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten


=== HTTP Public Key Pinning (HPKP) ===
== Vergleich: AES und 3DES ==
Much like HTTP Strict Transport Security (HSTS), HTTP Public Key Pinning (HPKP) is a Trust-On-First-Use (TOFU) mechanism. It protects HTTPS websites from impersonation using certificates issued by compromised certificate authorities. The data for Pinning is supplied by an HTTP-Header sent by the WebServer.


==== HPKP Header Directives ====
= IDEA =
HPKP provides two different types of headers:* Public-Key-Pins
=== Familie der Blockchiffrierung ===
* Public-Key-Pins-Report-Only
* jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
HPKP header can be parametrized by following directives:* pin-sha256="<YOUR_PUBLICKEY_HASH⇒"
* Basiert auf einer Mischung 3 mathematischen Funktionen
* max-age=<number-of-seconds>
* die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
* includeSubdomains
* Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
* report-uri="<[https://YOUR.URL/TO-REPORT%3E https://YOUR.URL/TO-REPORT>"]
* Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
'''pin-sha256''' is a required directive. It can and should be used several (at least two) times for specifying the public keys of your domain-certificates or CA-certificates. Operators can pin any one or more of the public keys in the certificate-chain, and indeed must pin to issuers not in the chain (as, for example, a backup-pin). Pinning to an intermediate issuer, or even to a trust anchor or root, still significantly reduces the number of issuers who can issue end-entity certificates for the Known Pinned Host, while still giving that host flexibility to change keys without a disruption of service. OpenSSL can be used to convert the public-key of an X509-certificate as follows:
* Trotz komplizierter Verfahren, schneller und sicherer als DES
$ openssl x509 -in <certificate.cer> -pubkey -noout |
openssl rsa -pubin -outform der |
openssl dgst -sha256 -binary |
openssl enc -base64
writing RSA key
pG3WsstDsfMkRdF3hBClXRKYxxKUJIOu8DwabG8MFrU=
This piped usage of OpenSSL first gets the Public-Key of <certificate.cer>, converts it do DER (binary) format, calculates an SHA256 Hash and finally encodes it Base64. The output (including the ending Equal-Sign) is exactly whats needed for the ''pin-sha256="<YOUR_PUBLICKEY_HASH⇒"'' parameter.
To generate the hash for a prepared backup-key just create a certificate-signing-request and replace <tt>openssl x509</tt> by <tt>openssl req -in <backup-cert.csr> -pubkey -noout</tt> as first OpenSSL command.
Instead of using OpenSSL even web-services like [https://report-uri.io/home/pkp_hash/ https://report-uri.io/home/pkp_hash/] can be used to get a suggestion for the possible Public-Key-Hashes for a given website.
'''max-age''' is a required directive (when using the ''Public-Key-Pins'' header). This directive specifies the number of seconds during which the user agent should regard the host (from whom the message was received) as a "Known Pinned Host".
'''includeSubdomains''' is an optional directive. This directive indicates that the same pinning applies to this host as well as ''any subdomains of the host’s domain name''. Be careful - you need to use a multi-domain/wildcard-certificate or use the same pub/private-keypair in all subdomain-certificates or need to pin to CA-certificates signing all your subdomain-certificates.
'''report-uri''' is an optional directive. The presence of a report-uri directive indicates to the web-browser that in the event of pin-validation failure, it should post a report to the report-uri (HTTP-Post is done using JSON, Syntax see {RFC-7469 Section 3} [[https://bettercrypto.org/#_footnotedef_40 40]]). There are WebServices like [https://report-uri.io/ https://report-uri.io/] out there which can be used to easily collect and visualize these reports.


==== HPKP Client Support ====
== Hybride Kryptografieverfahren ==
HPKP is supported [[https://bettercrypto.org/#_footnotedef_41 41]] by these web browsers:* Firefox version >= 35
* Chrome version between version 38 and 72
* Android Browser >= 44
* Opera version >= 25
Currently (20. Dec 2018) there is no HPKP support in: Apple Safari, Microsoft Internet Explorer and Edge. HPKP Support has been removed from Google Chrome and Chromium from version 72 onwards.


==== HPKP Considerations ====
=== Vorteile aus asymmetrischen und symmetrischen Kryptografie  ===
Before enabling HPKP it is recommended to consider following:* Which Public-Keys to use for Pinning (Certificate + Backup-Certificate, CAs, Intermediate-CAs)
* Hohe Effizienz
* Proper value of ''max-age''. Start testing with a short Period, increase Period after deployment.
* gesteigerte Sicherheit
* Be careful when using ''includeSubdomains'', are all your subdomains covered by the defined Public-Key-Hashes?
* Flexibilität
The administrators are advised to watch for expiration of the SSL certificate and handle the renewal process with caution.
* Austausch der erforderlichen Schlüssel
If a SSL certificate is renewed without keeping the public-key (reusing the CSR) for an HPKP enabled domain name, the connection to site will break (without providing override mechanism to the end user).
* erfolgt über ein asymmetrisches Verfahren
* Kryptografie größerer Datenmengen
* kommen symetrische Algorythmen zum Einsatz


==== Testing HPKP ====
== Vergleich Klassisch - Modern ==
HPKP can be tested either using locally or through the Internet.
There is a handy bash-script which uses OpenSSL for doing several SSL/TLS-Tests available at [https://testssl.sh/ https://testssl.sh/]
$ wget -q https://testssl.sh/testssl.sh
$ wget -q https://testssl.sh/mapping-rfc.txt
$ chmod 755 ./testssl.sh
$ ./testssl.sh https://example.com
<nowiki># Sample Output, just HSTS and HPKP Section (Full report is quite long!):</nowiki>
Strict Transport Security    182 days=15724800 s, includeSubDomains
Public Key Pinning # of keys: 2, 90 days=7776000 s, just this domain
          matching host key: pG3WsstDsfMkRdF3hBClXRKYxxKUJIOu8DwabG8MFrU
For local testing it is possible to utilize Google Chrome web-browser, just open the Chrome net-internals-URL: chrome://net-internals/#hsts.
For Mozilla Firefox there is an plug-in provided by the "Secure Information Technology Center Austria" available: [https://demo.a-sit.at/firefox-plugin-highlighting-safety-information/ https://demo.a-sit.at/firefox-plugin-highlighting-safety-information/]
Testing over the Internet can be conducted by Qualys SSL Labs test [https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/]. ''Public Key Pinning (HPKP)'' information is located in the ''Protocol Details'' section.
There is also a fast online HPKP-only check at [https://report-uri.io/home/pkp_analyse https://report-uri.io/home/pkp_analyse].


==== References ====
=== Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA… ===
* OWASP: Certificate and Public Key Pinning: [https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning]
* …benötigen einen Schlüssel der beiden Parteien im Vornherein bekannt ist
* HPKP Browser Compatibility List: [https://caniuse.com//#feat=publickeypinning https://caniuse.com/\#feat=publickeypinning]
* …sind symmetrisch (Entschlüsselung ist Umkehrung der Kryptografie)
* RFC 7469:Public Key Pinning Extension for HTTP - Examples: [https://tools.ietf.org/html/rfc7469/#section-2.1.5 https://tools.ietf.org/html/rfc7469\#section-2.1.5]
* …sind in gewissen Masse anfällig auf Kryptoanalyse (z.&nbsp;B.&nbsp;Brute-Force)


= IV: Appendix =
== Fazit ==


== Tools ==
=== Die Geschichte der Kryptografie ist ein Wettbewerb  ===
This section lists tools for checking the security settings.
* zwischen Kryptografiespezialisten und Kryptoanalysten
* Momentan liegen die Verschlüssler mit dem IDEA vorne
* da dieses Verfahren nur mit Brute-Force geknackt werden kann
* dies wegen der großen Schlüssellänge auch auf modernsten Computern noch zu lange dauert


=== SSL & TLS ===
= TMP =
Server checks via the web
=== Abstract ===
[https://ssllabs.com/ ssllabs.com] offers a great way to check your webserver for misconfigurations. See [https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/]. Furthermore, ''ssllabs.com'' has a good best practices tutorial, which focuses on avoiding the most common mistakes in SSL.
* Unfortunately, the computer security and cryptology communities have drifted apart over the last 25 years. Security people don’t always understand the available crypto tools, and crypto people don’t always understand the real-world problems.
SSL Server certificate installation issues [https://www.sslshopper.com/ssl-checker.html https://www.sslshopper.com/ssl-checker.html]
* — Ross Anderson ''([https://bettercrypto.org/#bibliography-default-anderson2008security Anderson, 2008])''
Check SPDY protocol support and basic TLS setup [http://spdycheck.org/ http://spdycheck.org/]
* This guide arose out of the need for system administrators to have an updated, solid, well researched and thought-through guide for configuring SSL, PGP, SSH and other cryptographic tools in the post-Snowden age. Triggered by the NSA leaks in the summer of 2013, many system administrators and IT security officers saw the need to strengthen their encryption settings. This guide is specifically written for these system administrators.
XMPP/Jabber Server check (Client-to-Server and Server-to-Server) [https://xmpp.net/ https://xmpp.net/]
* As Schneier noted in ([https://bettercrypto.org/#bibliography-default-Sch13 Schneier, 2013]), it seems that intelligence agencies and adversaries on the Internet are not breaking so much the mathematics of encryption per se, but rather use software and hardware weaknesses, subvert standardization processes, plant backdoors, rig random number generators and most of all exploit careless settings in server configurations and encryption systems to listen in on private communications. Worst of all, most communication on the internet is not encrypted at all by default (for SMTP, opportunistic TLS would be a solution).
Luxsci SMTP TLS Checker [https://luxsci.com/extranet/tlschecker.html https://luxsci.com/extranet/tlschecker.html]
* This guide can only address one aspect of securing our information systems: getting the crypto settings right to the best of the authors' current knowledge. Other attacks, as the above mentioned, require different protection schemes which are not covered in this guide. This guide is not an introduction to cryptography. For background information on cryptography and cryptoanalysis we would like to refer the reader to the references in appendix [https://bettercrypto.org/#links Links] and [https://bettercrypto.org/#suggested_reading Suggested Reading] at the end of this document.
DNSsec and DANE support of your domain and e-mail server? [https://dane.sys4.de/ https://dane.sys4.de]
* The focus of this guide is merely to give current ''best practices for configuring complex cipher suites'' and related parameters in a ''copy & paste-able manner''. The guide tries to stay as concise as is possible for such a complex topic as cryptography. Naturally, it can not be complete. There are many excellent guides ([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]) and best practice documents available when it comes to cryptography. However none of them focuses specifically on what an average system administrator needs for hardening his or her systems' crypto settings.
[http://checktls.com/ http://checktls.com] is a tool for testing arbitrary TLS services.
* This guide tries to fill this gap.
[http://tls.secg.org/ http://tls.secg.org] is a tool for testing interoperability of HTTPS implementations for ECC cipher suites.
[http://www.whynopadlock.com/ http://www.whynopadlock.com/] Testing for mixed SSL parts loaded via http that can totally lever your HTTPS.


=== Browser Checks ===
; The guide was produced in an open source manner: every step of editing can be traced back to a specific author via our version control system.
Check your browser’s SSL capabilities: [https://cc.dcsec.uni-hannover.de/ https://cc.dcsec.uni-hannover.de/] and [https://www.ssllabs.com/ssltest/viewMyClient.html https://www.ssllabs.com/ssltest/viewMyClient.html].
Check Browsers SSL/TLS support and vulnerability to attacks: [https://www.howsmyssl.com/ https://www.howsmyssl.com]


=== Command Line Tools ===
== Introduction ==
[https://sourceforge.net/projects/sslscan https://sourceforge.net/projects/sslscan] connects to a given SSL service and shows the cipher suites that are offered.
=== Audience ===
[http://www.bolet.org/TestSSLServer/ http://www.bolet.org/TestSSLServer/] tests for BEAST and CRIME vulnerabilities.
Sysadmins. Sysadmins. Sysadmins. They are a force-multiplier.
[https://github.com/drwetter/testssl.sh https://github.com/drwetter/testssl.sh] checks a server’s service on any port for the support of TLS/SSL ciphers, protocols as well as some cryptographic flaws (CRIME, BREACH, CCS, Heartbleed).
[https://github.com/iSECPartners/sslyze https://github.com/iSECPartners/sslyze] Fast and full-featured SSL scanner.
[https://github.com/jvehent/cipherscan https://github.com/jvehent/cipherscan] Fast TLS scanner (ciphers, order, protocols, key size and more)
[http://nmap.org/ http://nmap.org/] nmap security scanner
[http://www.openssl.net/ http://www.openssl.net] OpenSSL s_client
Monitoring TLS services with Zabbix (sorry, German) [https://blog.sys4.de/zertifikate-uberwachen-mit-zabbix-de.html https://blog.sys4.de/zertifikate-uberwachen-mit-zabbix-de.html]


=== Key length ===
=== Related publications ===
[http://www.keylength.com/ http://www.keylength.com] comprehensive online resource for comparison of key lengths according to common recommendations and standards in cryptography.
* Ecrypt II [https://bettercrypto.org/#ii2011ecrypt [ii2011ecrypt]]
* Ecrypt II ([https://bettercrypto.org/#bibliography-default-ii2011ecrypt II & SYM, 2012]), ENISA’s report on Algorithms, key sizes and parameters ([https://bettercrypto.org/#bibliography-default-ENISA2013 ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson, 2013])&nbsp;and BSI’s Technische Richtlinie TR-02102 ([https://bettercrypto.org/#bibliography-default-TR02102 für Sicherheit in der Informationstechnik (BSI), 2018]) are great publications which are more in depth than this guide. However, this guide has a different approach: it focuses on ''copy & paste-able settings'' for system administrators, effectively breaking down the complexity in the above mentioned reports to an easy to use format for the intended target audience.


=== Random Number Generators ===
=== How to read this guide ===
[http://www.fourmilab.ch/random/ ENT] is a pseudo random number generator sequence tester.
* This guide tries to accommodate two needs: first of all, having a handy reference on how to configure the most common services’ crypto settings and second of all, explain a bit of background on cryptography. This background is essential if the reader wants to choose his or her own cipher string settings.
[http://www.phy.duke.edu/~rgb/General/dieharder.php Dieharder] a random number generator testing tool.
* System administrators who want to copy & paste recommendations quickly without spending a lot of time on background reading on cryptography or cryptanalysis can do so, by simply searching for the corresponding section in [https://bettercrypto.org/#bestpractice Best Practice].
[http://www.cacert.at/random/ CAcert Random] another random number generator testing service.
* It is important to know that in this guide the authors arrived at two recommendations: ''Cipher string A'' and ''Cipher string B''. While the former is a hardened recommendation a latter is a weaker one but provides wider compatibility. ''Cipher strings A and B'' are described in [https://bettercrypto.org/#recommendedciphers Recommended cipher suites].
* However, for the quick copy & paste approach it is important to know that this guide assumes users are happy with ''Cipher string B''.
* While [https://bettercrypto.org/#bestpractice Best Practice] is intended to serve as a copy & paste reference, [https://bettercrypto.org/#theory Theory] explains the reasoning behind ''cipher string B''. In particular [https://bettercrypto.org/#ciphersuites Architectural overview] explains how to choose individual cipher strings. We advise the reader to actually read this section and challenge our reasoning in choosing ''Cipher string B'' and to come up with a better or localized solution.


=== Guides ===
=== Disclaimer ===
See: [https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf].
* A chain is no stronger than its weakest link, and life is after all a chain.
* — William James
*  Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.
* — Edward Snowden ''answering questions live on the Guardian’s website''
* This guide specifically does not address physical security, protecting software and hardware against exploits, basic IT security housekeeping, information assurance techniques, traffic analysis attacks, issues with key-roll over and key management, securing client PCs and mobile devices (theft, loss), proper [https://en.wikipedia.org/wiki/Operations_security Operations Security], social engineering attacks, protection against tempest ([https://bettercrypto.org/#bibliography-default-Wikipedia:Tempest i_wikipedia_Tempest (codename)_, 2018])&nbsp;attack techniques, thwarting different side-channel attacks (timing–, cache timing–, differential fault analysis, differential power analysis or power monitoring attacks), downgrade attacks, jamming the encrypted channel or other similar attacks which are typically employed to circumvent strong encryption.
* The authors can not overstate the importance of these other techniques. Interested readers are advised to read about these attacks in detail since they give a lot of insight into other parts of cryptography engineering which need to be dealt with[[https://bettercrypto.org/#_footnotedef_1 1]]) ].
* This guide does not talk much about the well-known insecurities of trusting a public-key infrastructure (PKI)[[https://bettercrypto.org/#_footnotedef_2 2]]. Nor does this text fully explain how to run your own Certificate Authority (CA).
* Most of this zoo of information security issues are addressed in the very comprehensive book ''Security Engineering'' by Ross Anderson ([https://bettercrypto.org/#bibliography-default-anderson2008security Anderson, 2008]).
* For some experts in cryptography this text might seem too informal. However, we strive to keep the language as non-technical as possible and fitting for our target audience: system administrators who can collectively improve the security level for all of their users.
*  Security is a process, not a product.
* — Bruce Schneier
* This guide can only describe what the authors currently ''believe'' to be the best settings based on their personal experience and after intensive cross checking with literature and experts. For a complete list of people who reviewed this paper, see the <acknowledgements>. Even though multiple specialists reviewed the guide, the authors can give ''no guarantee whatsoever'' that they made the right recommendations. Keep in mind that tomorrow there might be new attacks on some ciphers and many of the recommendations in this guide might turn out to be wrong. Security is a process.
* We therefore recommend that system administrators keep up to date with recent topics in IT security and cryptography.
* In this sense, this guide is very focused on getting the cipher strings done right even though there is much more to do in order to make a system more secure. We the authors, need this document as much as the reader needs it.


== Links ==
==== Scope ====
[https://www.iana.org/assignments/tls-parameters/tls-parameters.txt IANA official list of Transport Layer Security (TLS) Parameters]
In this guide, we restricted ourselves to:* Internet-facing services
[https://www.imperialviolet.org/2010/12/04/ecc.html Elliptic curves and their implementation (04 Dec 2010)]
* Commonly used services
[https://arstechnica.com/information-technology/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ A (relatively easy to understand) primer on elliptic curve cryptography]
* Devices which are used in business environments (this specifically excludes XBoxes, Playstations and similar consumer devices)
[https://github.com/ioerror/duraconf Duraconf, A collection of hardened configuration files for SSL/TLSservices (Jacob Appelbaum’s github)]
* OpenSSL
[https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/ssl_attacks_survey.pdf Attacks on SSL a comprehensive study of BEAST, CRIME, TIME, BREACH, LUCKY 13 & RC4 Biases]
We explicitly excluded:* Specialized systems such as medical devices, most embedded systems, industrial control systems (ICS), etc.
[https://www.eff.org/https-everywhere/deploying-https EFF How to deploy HTTPS correctly]
* Wireless Access Points
[https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/?pp=3 Bruce Almighty: Schneier preaches security to Linux faithful (on not recommending to use Blowfish anymore in favor of Twofish)]
* Smart-cards/chip cards
[https://bugzilla.mindrot.org/show_bug.cgi?id=1647 Implement FIPS 183-3 for DSA keys (1024bit constraint)]
[https://eprint.iacr.org/2013/734.pdf Elliptic Curve Cryptography in Practice]
[https://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf Factoring as a Service]
[https://dankaminsky.com/2012/08/06/bo2012/ Black Ops of TCP/IP 2012]
[https://www.youtube.com/watch?v=Z7Wl2FW2TcA SSL and the Future of Authenticity, Moxie Marlinspike - Black Hat USA 2011]
[https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report ENISA - Algorithms, Key Sizes and Parameters Report (Oct.’13]
[https://tools.ietf.org/html/rfc3526 Diffie-Hellman Groups standardized in RFC3526]
[https://www.cosic.esat.kuleuven.be/ecc2013/files/kenny.pdf TLS Security (Survey + Lucky13 + RC4 Attack) by Kenny Paterson]
[https://arxiv.org/abs/1309.7366v1 Ensuring High-Quality Randomness in Cryptographic Key Generation]
[https://en.wikipedia.org/wiki/Ciphertext_stealing Wikipedia: Ciphertext Stealing]
[https://en.wikipedia.org/wiki/Malleability_(cryptography) Wikipedia: Malleability (Cryptography)]
[http://www.ciphersbyritter.com/GLOSSARY.HTM Ritter’s Crypto Glossary and Dictionary of Technical Cryptography]


== Suggested Reading ==
=== Methods ===
This section contains suggested reading material.
#  C.O.S.H.E.R - completely open source, headers, engineering and research.
Cryptography Engineering: Design Principles and Practical Applications, Ferguson, N. and Schneier, B. and Kohno, T. (ISBN-13: 978-0470474242)
# — A. Kaplan ''His mail signature for many years''
Security Engineering: A Guide to Building Dependable Distributed Systems, Anderson, R.J. (ISBN-13: 978-0470068526)
# For writing this guide, we chose to collect the most well researched facts about cryptography settings and let as many trusted specialists as possible review those settings. The review process is completely open and done on a public mailing list.
Applied cryptography: protocols, algorithms, and source code in C, Schneier, B. (ISBN-13: 978-0471117094)
# The document is available (read-only) to the public Internet on the web page and the source code of this document is on a public git server, mirrored on GitHub.com and open for public scrutiny. However, write permissions to the document are only granted to vetted people. The list of reviewers can be found in [https://bettercrypto.org/#acknowledgements Acknowledgements].
Guide to Elliptic Curve Cryptography, Hankerson, D. and Vanstone, S. and Menezes, A.J. (ISBN-13: 978-0387952734)
# Every write operation to the document is logged via the <tt>git</tt> version control system and can thus be traced back to a specific author. We accept git pull requests on the [https://github.com/BetterCrypto/Applied-Crypto-Hardening github mirror] for this paper.
A Introduction To The Theory of Numbers, Godfrey Harold Hardy, E. M. Wrigh (ISBN-13: 978-0199219865)
# Public peer-review and multiple eyes checking of our guide is the best strategy we can imagine at the present moment [[https://bettercrypto.org/#_footnotedef_3 3]].
Malicious Cryptography: Exposing Cryptovirology, Young A., Yung, M. (ISBN-13: 978-0764549755)
# We invite the gentle reader to participate in this public review process. Please read the [https://github.com/BetterCrypto/Applied-Crypto-Hardening/blob/master/CONTRIBUTING.md Contributing] document.


== Cipher Suite Name Cross-Reference ==
== Appendix ==
This table shows the cipher suite names as IANA defined them, the names OpenSSL uses, and the respective codes.
=== Links ===
# [https://www.iana.org/assignments/tls-parameters/tls-parameters.txt IANA official list of Transport Layer Security (TLS) Parameters]
# [https://www.imperialviolet.org/2010/12/04/ecc.html Elliptic curves and their implementation (04 Dec 2010)]
# [https://arstechnica.com/information-technology/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ A (relatively easy to understand) primer on elliptic curve cryptography]
# [https://github.com/ioerror/duraconf Duraconf, A collection of hardened configuration files for SSL/TLSservices (Jacob Appelbaum’s github)]
# [https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/ssl_attacks_survey.pdf Attacks on SSL a comprehensive study of BEAST, CRIME, TIME, BREACH, LUCKY 13 & RC4 Biases]
# [https://www.eff.org/https-everywhere/deploying-https EFF How to deploy HTTPS correctly]
# [https://www.computerworld.com.au/article/46254/bruce_almighty_schneier_preaches_security_linux_faithful/?pp=3 Bruce Almighty: Schneier preaches security to Linux faithful (on not recommending to use Blowfish anymore in favor of Twofish)]
# [https://bugzilla.mindrot.org/show_bug.cgi?id=1647 Implement FIPS 183-3 for DSA keys (1024bit constraint)]
# [https://eprint.iacr.org/2013/734.pdf Elliptic Curve Cryptography in Practice]
# [https://crypto.2013.rump.cr.yp.to/981774ce07e51813fd4466612a78601b.pdf Factoring as a Service]
# [https://dankaminsky.com/2012/08/06/bo2012/ Black Ops of TCP/IP 2012]
# [https://www.youtube.com/watch?v=Z7Wl2FW2TcA SSL and the Future of Authenticity, Moxie Marlinspike - Black Hat USA 2011]
# [https://www.enisa.europa.eu/publications/algorithms-key-sizes-and-parameters-report ENISA - Algorithms, Key Sizes and Parameters Report (Oct.’13]
# [https://tools.ietf.org/html/rfc3526 Diffie-Hellman Groups standardized in RFC3526]
# [https://www.cosic.esat.kuleuven.be/ecc2013/files/kenny.pdf TLS Security (Survey + Lucky13 + RC4 Attack) by Kenny Paterson]
# [https://arxiv.org/abs/1309.7366v1 Ensuring High-Quality Randomness in Cryptographic Key Generation]
# [https://en.wikipedia.org/wiki/Ciphertext_stealing Wikipedia: Ciphertext Stealing]
# [https://en.wikipedia.org/wiki/Malleability_(cryptography) Wikipedia: Malleability (Cryptography)]
# [http://www.ciphersbyritter.com/GLOSSARY.HTM Ritter’s Crypto Glossary and Dictionary of Technical Cryptography]


{| style="border-spacing:0;width:17cm;"
=== Suggested Reading ===
|- style="border:none;padding:0.049cm;"
# This section contains suggested reading material.
! align=center| Code
# Cryptography Engineering: Design Principles and Practical Applications, Ferguson, N. and Schneier, B. and Kohno, T. (ISBN-13: 978-0470474242)
! align=center| IANA Name
# Security Engineering: A Guide to Building Dependable Distributed Systems, Anderson, R.J. (ISBN-13: 978-0470068526)
! align=center| OpenSSL Name
# Applied cryptography: protocols, algorithms, and source code in C, Schneier, B. (ISBN-13: 978-0471117094)
|- style="border:none;padding:0.049cm;"
# Guide to Elliptic Curve Cryptography, Hankerson, D. and Vanstone, S. and Menezes, A.J. (ISBN-13: 978-0387952734)
|| <tt>0x00,0x00</tt>
# A Introduction To The Theory of Numbers, Godfrey Harold Hardy, E. M. Wrigh (ISBN-13: 978-0199219865)
|| <tt>TLS_NULL_WITH_NULL_NULL</tt>
# Malicious Cryptography: Exposing Cryptovirology, Young A., Yung, M. (ISBN-13: 978-0764549755)
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x01</tt>
|| <tt>TLS_RSA_WITH_NULL_MD5</tt>
|| <tt>NULL-MD5</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x02</tt>
|| <tt>TLS_RSA_WITH_NULL_SHA</tt>
|| <tt>NULL-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x03</tt>
|| <tt>TLS_RSA_EXPORT_WITH_RC4_40_MD5</tt>
|| <tt>EXP-RC4-MD5</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x04</tt>
|| <tt>TLS_RSA_WITH_RC4_128_MD5</tt>
|| <tt>RC4-MD5</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x05</tt>
|| <tt>TLS_RSA_WITH_RC4_128_SHA</tt>
|| <tt>RC4-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x06</tt>
|| <tt>TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5</tt>
|| <tt>EXP-RC2-CBC-MD5</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x07</tt>
|| <tt>TLS_RSA_WITH_IDEA_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x08</tt>
|| <tt>TLS_RSA_EXPORT_WITH_DES40_CBC_SHA</tt>
|| <tt>EXP-DES-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x09</tt>
|| <tt>TLS_RSA_WITH_DES_CBC_SHA</tt>
|| <tt>DES-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x0A</tt>
|| <tt>TLS_RSA_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x0B</tt>
|| <tt>TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x0C</tt>
|| <tt>TLS_DH_DSS_WITH_DES_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x0D</tt>
|| <tt>TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x0E</tt>
|| <tt>TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x0F</tt>
|| <tt>TLS_DH_RSA_WITH_DES_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x10</tt>
|| <tt>TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x11</tt>
|| <tt>TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA</tt>
|| <tt>EXP-EDH-DSS-DES-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x12</tt>
|| <tt>TLS_DHE_DSS_WITH_DES_CBC_SHA</tt>
|| <tt>EDH-DSS-DES-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x13</tt>
|| <tt>TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>EDH-DSS-DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x14</tt>
|| <tt>TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA</tt>
|| <tt>EXP-EDH-RSA-DES-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x15</tt>
|| <tt>TLS_DHE_RSA_WITH_DES_CBC_SHA</tt>
|| <tt>EDH-RSA-DES-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x16</tt>
|| <tt>TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>EDH-RSA-DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x17</tt>
|| <tt>TLS_DH_anon_EXPORT_WITH_RC4_40_MD5</tt>
|| <tt>EXP-ADH-RC4-MD5</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x18</tt>
|| <tt>TLS_DH_anon_WITH_RC4_128_MD5</tt>
|| <tt>ADH-RC4-MD5</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x19</tt>
|| <tt>TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA</tt>
|| <tt>EXP-ADH-DES-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x1A</tt>
|| <tt>TLS_DH_anon_WITH_DES_CBC_SHA</tt>
|| <tt>ADH-DES-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x1B</tt>
|| <tt>TLS_DH_anon_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>ADH-DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x1E</tt>
|| <tt>TLS_KRB5_WITH_DES_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x1F</tt>
|| <tt>TLS_KRB5_WITH_3DES_EDE_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x20</tt>
|| <tt>TLS_KRB5_WITH_RC4_128_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x21</tt>
|| <tt>TLS_KRB5_WITH_IDEA_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x22</tt>
|| <tt>TLS_KRB5_WITH_DES_CBC_MD5</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x23</tt>
|| <tt>TLS_KRB5_WITH_3DES_EDE_CBC_MD5</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x24</tt>
|| <tt>TLS_KRB5_WITH_RC4_128_MD5</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x25</tt>
|| <tt>TLS_KRB5_WITH_IDEA_CBC_MD5</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x26</tt>
|| <tt>TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x27</tt>
|| <tt>TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x28</tt>
|| <tt>TLS_KRB5_EXPORT_WITH_RC4_40_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x29</tt>
|| <tt>TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x2A</tt>
|| <tt>TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x2B</tt>
|| <tt>TLS_KRB5_EXPORT_WITH_RC4_40_MD5</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x2C</tt>
|| <tt>TLS_PSK_WITH_NULL_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x2D</tt>
|| <tt>TLS_DHE_PSK_WITH_NULL_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x2E</tt>
|| <tt>TLS_RSA_PSK_WITH_NULL_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x2F</tt>
|| <tt>TLS_RSA_WITH_AES_128_CBC_SHA</tt>
|| <tt>AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x30</tt>
|| <tt>TLS_DH_DSS_WITH_AES_128_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x31</tt>
|| <tt>TLS_DH_RSA_WITH_AES_128_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x32</tt>
|| <tt>TLS_DHE_DSS_WITH_AES_128_CBC_SHA</tt>
|| <tt>DHE-DSS-AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x33</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_128_CBC_SHA</tt>
|| <tt>DHE-RSA-AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x34</tt>
|| <tt>TLS_DH_anon_WITH_AES_128_CBC_SHA</tt>
|| <tt>ADH-AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x35</tt>
|| <tt>TLS_RSA_WITH_AES_256_CBC_SHA</tt>
|| <tt>AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x36</tt>
|| <tt>TLS_DH_DSS_WITH_AES_256_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x37</tt>
|| <tt>TLS_DH_RSA_WITH_AES_256_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x38</tt>
|| <tt>TLS_DHE_DSS_WITH_AES_256_CBC_SHA</tt>
|| <tt>DHE-DSS-AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x39</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_256_CBC_SHA</tt>
|| <tt>DHE-RSA-AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x3A</tt>
|| <tt>TLS_DH_anon_WITH_AES_256_CBC_SHA</tt>
|| <tt>ADH-AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x3B</tt>
|| <tt>TLS_RSA_WITH_NULL_SHA256</tt>
|| <tt>NULL-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x3C</tt>
|| <tt>TLS_RSA_WITH_AES_128_CBC_SHA256</tt>
|| <tt>AES128-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x3D</tt>
|| <tt>TLS_RSA_WITH_AES_256_CBC_SHA256</tt>
|| <tt>AES256-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x3E</tt>
|| <tt>TLS_DH_DSS_WITH_AES_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x3F</tt>
|| <tt>TLS_DH_RSA_WITH_AES_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x40</tt>
|| <tt>TLS_DHE_DSS_WITH_AES_128_CBC_SHA256</tt>
|| <tt>DHE-DSS-AES128-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x41</tt>
|| <tt>TLS_RSA_WITH_CAMELLIA_128_CBC_SHA</tt>
|| <tt>CAMELLIA128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x42</tt>
|| <tt>TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x43</tt>
|| <tt>TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x44</tt>
|| <tt>TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA</tt>
|| <tt>DHE-DSS-CAMELLIA128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x45</tt>
|| <tt>TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA</tt>
|| <tt>DHE-RSA-CAMELLIA128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x46</tt>
|| <tt>TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA</tt>
|| <tt>ADH-CAMELLIA128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x67</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_128_CBC_SHA256</tt>
|| <tt>DHE-RSA-AES128-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x68</tt>
|| <tt>TLS_DH_DSS_WITH_AES_256_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x69</tt>
|| <tt>TLS_DH_RSA_WITH_AES_256_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x6A</tt>
|| <tt>TLS_DHE_DSS_WITH_AES_256_CBC_SHA256</tt>
|| <tt>DHE-DSS-AES256-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x6B</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_256_CBC_SHA256</tt>
|| <tt>DHE-RSA-AES256-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x6C</tt>
|| <tt>TLS_DH_anon_WITH_AES_128_CBC_SHA256</tt>
|| <tt>ADH-AES128-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x6D</tt>
|| <tt>TLS_DH_anon_WITH_AES_256_CBC_SHA256</tt>
|| <tt>ADH-AES256-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x84</tt>
|| <tt>TLS_RSA_WITH_CAMELLIA_256_CBC_SHA</tt>
|| <tt>CAMELLIA256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x85</tt>
|| <tt>TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x86</tt>
|| <tt>TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x87</tt>
|| <tt>TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA</tt>
|| <tt>DHE-DSS-CAMELLIA256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x88</tt>
|| <tt>TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA</tt>
|| <tt>DHE-RSA-CAMELLIA256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x89</tt>
|| <tt>TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA</tt>
|| <tt>ADH-CAMELLIA256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x8A</tt>
|| <tt>TLS_PSK_WITH_RC4_128_SHA</tt>
|| <tt>PSK-RC4-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x8B</tt>
|| <tt>TLS_PSK_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>PSK-3DES-EDE-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x8C</tt>
|| <tt>TLS_PSK_WITH_AES_128_CBC_SHA</tt>
|| <tt>PSK-AES128-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x8D</tt>
|| <tt>TLS_PSK_WITH_AES_256_CBC_SHA</tt>
|| <tt>PSK-AES256-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x8E</tt>
|| <tt>TLS_DHE_PSK_WITH_RC4_128_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x8F</tt>
|| <tt>TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x90</tt>
|| <tt>TLS_DHE_PSK_WITH_AES_128_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x91</tt>
|| <tt>TLS_DHE_PSK_WITH_AES_256_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x92</tt>
|| <tt>TLS_RSA_PSK_WITH_RC4_128_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x93</tt>
|| <tt>TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x94</tt>
|| <tt>TLS_RSA_PSK_WITH_AES_128_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x95</tt>
|| <tt>TLS_RSA_PSK_WITH_AES_256_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x96</tt>
|| <tt>TLS_RSA_WITH_SEED_CBC_SHA</tt>
|| <tt>SEED-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x97</tt>
|| <tt>TLS_DH_DSS_WITH_SEED_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x98</tt>
|| <tt>TLS_DH_RSA_WITH_SEED_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x99</tt>
|| <tt>TLS_DHE_DSS_WITH_SEED_CBC_SHA</tt>
|| <tt>DHE-DSS-SEED-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x9A</tt>
|| <tt>TLS_DHE_RSA_WITH_SEED_CBC_SHA</tt>
|| <tt>DHE-RSA-SEED-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x9B</tt>
|| <tt>TLS_DH_anon_WITH_SEED_CBC_SHA</tt>
|| <tt>ADH-SEED-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x9C</tt>
|| <tt>TLS_RSA_WITH_AES_128_GCM_SHA256</tt>
|| <tt>AES128-GCM-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x9D</tt>
|| <tt>TLS_RSA_WITH_AES_256_GCM_SHA384</tt>
|| <tt>AES256-GCM-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x9E</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</tt>
|| <tt>DHE-RSA-AES128-GCM-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x9F</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</tt>
|| <tt>DHE-RSA-AES256-GCM-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA0</tt>
|| <tt>TLS_DH_RSA_WITH_AES_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA1</tt>
|| <tt>TLS_DH_RSA_WITH_AES_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA2</tt>
|| <tt>TLS_DHE_DSS_WITH_AES_128_GCM_SHA256</tt>
|| <tt>DHE-DSS-AES128-GCM-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA3</tt>
|| <tt>TLS_DHE_DSS_WITH_AES_256_GCM_SHA384</tt>
|| <tt>DHE-DSS-AES256-GCM-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA4</tt>
|| <tt>TLS_DH_DSS_WITH_AES_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA5</tt>
|| <tt>TLS_DH_DSS_WITH_AES_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA6</tt>
|| <tt>TLS_DH_anon_WITH_AES_128_GCM_SHA256</tt>
|| <tt>ADH-AES128-GCM-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA7</tt>
|| <tt>TLS_DH_anon_WITH_AES_256_GCM_SHA384</tt>
|| <tt>ADH-AES256-GCM-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA8</tt>
|| <tt>TLS_PSK_WITH_AES_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xA9</tt>
|| <tt>TLS_PSK_WITH_AES_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xAA</tt>
|| <tt>TLS_DHE_PSK_WITH_AES_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xAB</tt>
|| <tt>TLS_DHE_PSK_WITH_AES_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xAC</tt>
|| <tt>TLS_RSA_PSK_WITH_AES_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xAD</tt>
|| <tt>TLS_RSA_PSK_WITH_AES_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xAE</tt>
|| <tt>TLS_PSK_WITH_AES_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xAF</tt>
|| <tt>TLS_PSK_WITH_AES_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB0</tt>
|| <tt>TLS_PSK_WITH_NULL_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB1</tt>
|| <tt>TLS_PSK_WITH_NULL_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB2</tt>
|| <tt>TLS_DHE_PSK_WITH_AES_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB3</tt>
|| <tt>TLS_DHE_PSK_WITH_AES_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB4</tt>
|| <tt>TLS_DHE_PSK_WITH_NULL_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB5</tt>
|| <tt>TLS_DHE_PSK_WITH_NULL_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB6</tt>
|| <tt>TLS_RSA_PSK_WITH_AES_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB7</tt>
|| <tt>TLS_RSA_PSK_WITH_AES_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB8</tt>
|| <tt>TLS_RSA_PSK_WITH_NULL_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xB9</tt>
|| <tt>TLS_RSA_PSK_WITH_NULL_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xBA</tt>
|| <tt>TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xBB</tt>
|| <tt>TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xBC</tt>
|| <tt>TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xBD</tt>
|| <tt>TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xBE</tt>
|| <tt>TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xBF</tt>
|| <tt>TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xC0</tt>
|| <tt>TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xC1</tt>
|| <tt>TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xC2</tt>
|| <tt>TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xC3</tt>
|| <tt>TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xC4</tt>
|| <tt>TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xC5</tt>
|| <tt>TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0xFF</tt>
|| <tt>TLS_EMPTY_RENEGOTIATION_INFO_SCSV</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x01</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_NULL_SHA</tt>
|| <tt>ECDH-ECDSA-NULL-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x02</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_RC4_128_SHA</tt>
|| <tt>ECDH-ECDSA-RC4-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x03</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>ECDH-ECDSA-DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x04</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA</tt>
|| <tt>ECDH-ECDSA-AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x05</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA</tt>
|| <tt>ECDH-ECDSA-AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x06</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_NULL_SHA</tt>
|| <tt>ECDHE-ECDSA-NULL-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x07</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_RC4_128_SHA</tt>
|| <tt>ECDHE-ECDSA-RC4-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x08</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>ECDHE-ECDSA-DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x09</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA</tt>
|| <tt>ECDHE-ECDSA-AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x0A</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA</tt>
|| <tt>ECDHE-ECDSA-AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x0B</tt>
|| <tt>TLS_ECDH_RSA_WITH_NULL_SHA</tt>
|| <tt>ECDH-RSA-NULL-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x0C</tt>
|| <tt>TLS_ECDH_RSA_WITH_RC4_128_SHA</tt>
|| <tt>ECDH-RSA-RC4-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x0D</tt>
|| <tt>TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>ECDH-RSA-DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x0E</tt>
|| <tt>TLS_ECDH_RSA_WITH_AES_128_CBC_SHA</tt>
|| <tt>ECDH-RSA-AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x0F</tt>
|| <tt>TLS_ECDH_RSA_WITH_AES_256_CBC_SHA</tt>
|| <tt>ECDH-RSA-AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x10</tt>
|| <tt>TLS_ECDHE_RSA_WITH_NULL_SHA</tt>
|| <tt>ECDHE-RSA-NULL-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x11</tt>
|| <tt>TLS_ECDHE_RSA_WITH_RC4_128_SHA</tt>
|| <tt>ECDHE-RSA-RC4-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x12</tt>
|| <tt>TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>ECDHE-RSA-DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x13</tt>
|| <tt>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</tt>
|| <tt>ECDHE-RSA-AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x14</tt>
|| <tt>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA</tt>
|| <tt>ECDHE-RSA-AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x15</tt>
|| <tt>TLS_ECDH_anon_WITH_NULL_SHA</tt>
|| <tt>AECDH-NULL-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x16</tt>
|| <tt>TLS_ECDH_anon_WITH_RC4_128_SHA</tt>
|| <tt>AECDH-RC4-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x17</tt>
|| <tt>TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>AECDH-DES-CBC3-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x18</tt>
|| <tt>TLS_ECDH_anon_WITH_AES_128_CBC_SHA</tt>
|| <tt>AECDH-AES128-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x19</tt>
|| <tt>TLS_ECDH_anon_WITH_AES_256_CBC_SHA</tt>
|| <tt>AECDH-AES256-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x1A</tt>
|| <tt>TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>SRP-3DES-EDE-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x1B</tt>
|| <tt>TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>SRP-RSA-3DES-EDE-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x1C</tt>
|| <tt>TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA</tt>
|| <tt>SRP-DSS-3DES-EDE-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x1D</tt>
|| <tt>TLS_SRP_SHA_WITH_AES_128_CBC_SHA</tt>
|| <tt>SRP-AES-128-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x1E</tt>
|| <tt>TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA</tt>
|| <tt>SRP-RSA-AES-128-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x1F</tt>
|| <tt>TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA</tt>
|| <tt>SRP-DSS-AES-128-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x20</tt>
|| <tt>TLS_SRP_SHA_WITH_AES_256_CBC_SHA</tt>
|| <tt>SRP-AES-256-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x21</tt>
|| <tt>TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA</tt>
|| <tt>SRP-RSA-AES-256-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x22</tt>
|| <tt>TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA</tt>
|| <tt>SRP-DSS-AES-256-CBC-SHA</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x23</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256</tt>
|| <tt>ECDHE-ECDSA-AES128-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x24</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384</tt>
|| <tt>ECDHE-ECDSA-AES256-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x25</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256</tt>
|| <tt>ECDH-ECDSA-AES128-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x26</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384</tt>
|| <tt>ECDH-ECDSA-AES256-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x27</tt>
|| <tt>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</tt>
|| <tt>ECDHE-RSA-AES128-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x28</tt>
|| <tt>TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384</tt>
|| <tt>ECDHE-RSA-AES256-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x29</tt>
|| <tt>TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256</tt>
|| <tt>ECDH-RSA-AES128-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x2A</tt>
|| <tt>TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384</tt>
|| <tt>ECDH-RSA-AES256-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x2B</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256</tt>
|| <tt>ECDHE-ECDSA-AES128-GCM-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x2C</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384</tt>
|| <tt>ECDHE-ECDSA-AES256-GCM-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x2D</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256</tt>
|| <tt>ECDH-ECDSA-AES128-GCM-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x2E</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384</tt>
|| <tt>ECDH-ECDSA-AES256-GCM-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x2F</tt>
|| <tt>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</tt>
|| <tt>ECDHE-RSA-AES128-GCM-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x30</tt>
|| <tt>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</tt>
|| <tt>ECDHE-RSA-AES256-GCM-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x31</tt>
|| <tt>TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256</tt>
|| <tt>ECDH-RSA-AES128-GCM-SHA256</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x32</tt>
|| <tt>TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384</tt>
|| <tt>ECDH-RSA-AES256-GCM-SHA384</tt>
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x33</tt>
|| <tt>TLS_ECDHE_PSK_WITH_RC4_128_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x34</tt>
|| <tt>TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x35</tt>
|| <tt>TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x36</tt>
|| <tt>TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x37</tt>
|| <tt>TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x38</tt>
|| <tt>TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x39</tt>
|| <tt>TLS_ECDHE_PSK_WITH_NULL_SHA</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x3A</tt>
|| <tt>TLS_ECDHE_PSK_WITH_NULL_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x3B</tt>
|| <tt>TLS_ECDHE_PSK_WITH_NULL_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x3C</tt>
|| <tt>TLS_RSA_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x3D</tt>
|| <tt>TLS_RSA_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x3E</tt>
|| <tt>TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x3F</tt>
|| <tt>TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x40</tt>
|| <tt>TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x41</tt>
|| <tt>TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x42</tt>
|| <tt>TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x43</tt>
|| <tt>TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x44</tt>
|| <tt>TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x45</tt>
|| <tt>TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x46</tt>
|| <tt>TLS_DH_anon_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x47</tt>
|| <tt>TLS_DH_anon_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x48</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x49</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x4A</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x4B</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x4C</tt>
|| <tt>TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x4D</tt>
|| <tt>TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x4E</tt>
|| <tt>TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x4F</tt>
|| <tt>TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x50</tt>
|| <tt>TLS_RSA_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x51</tt>
|| <tt>TLS_RSA_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x52</tt>
|| <tt>TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x53</tt>
|| <tt>TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x54</tt>
|| <tt>TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x55</tt>
|| <tt>TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x56</tt>
|| <tt>TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x57</tt>
|| <tt>TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x58</tt>
|| <tt>TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x59</tt>
|| <tt>TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x5A</tt>
|| <tt>TLS_DH_anon_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x5B</tt>
|| <tt>TLS_DH_anon_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x5C</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x5D</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x5E</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x5F</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x60</tt>
|| <tt>TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x61</tt>
|| <tt>TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x62</tt>
|| <tt>TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x63</tt>
|| <tt>TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x64</tt>
|| <tt>TLS_PSK_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x65</tt>
|| <tt>TLS_PSK_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x66</tt>
|| <tt>TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x67</tt>
|| <tt>TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x68</tt>
|| <tt>TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x69</tt>
|| <tt>TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x6A</tt>
|| <tt>TLS_PSK_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x6B</tt>
|| <tt>TLS_PSK_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x6C</tt>
|| <tt>TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x6D</tt>
|| <tt>TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x6E</tt>
|| <tt>TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x6F</tt>
|| <tt>TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x70</tt>
|| <tt>TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x71</tt>
|| <tt>TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x72</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x73</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x74</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x75</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x76</tt>
|| <tt>TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x77</tt>
|| <tt>TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x78</tt>
|| <tt>TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x79</tt>
|| <tt>TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x7A</tt>
|| <tt>TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x7B</tt>
|| <tt>TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x7C</tt>
|| <tt>TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x7D</tt>
|| <tt>TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x7E</tt>
|| <tt>TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x7F</tt>
|| <tt>TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x80</tt>
|| <tt>TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x81</tt>
|| <tt>TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x82</tt>
|| <tt>TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x83</tt>
|| <tt>TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x84</tt>
|| <tt>TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x85</tt>
|| <tt>TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x86</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x87</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x88</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x89</tt>
|| <tt>TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x8A</tt>
|| <tt>TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x8B</tt>
|| <tt>TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x8C</tt>
|| <tt>TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x8D</tt>
|| <tt>TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x8E</tt>
|| <tt>TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x8F</tt>
|| <tt>TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x90</tt>
|| <tt>TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x91</tt>
|| <tt>TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x92</tt>
|| <tt>TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x93</tt>
|| <tt>TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x94</tt>
|| <tt>TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x95</tt>
|| <tt>TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x96</tt>
|| <tt>TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x97</tt>
|| <tt>TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x98</tt>
|| <tt>TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x99</tt>
|| <tt>TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x9A</tt>
|| <tt>TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x9B</tt>
|| <tt>TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x9C</tt>
|| <tt>TLS_RSA_WITH_AES_128_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x9D</tt>
|| <tt>TLS_RSA_WITH_AES_256_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x9E</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_128_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0x9F</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_256_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA0</tt>
|| <tt>TLS_RSA_WITH_AES_128_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA1</tt>
|| <tt>TLS_RSA_WITH_AES_256_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA2</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_128_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA3</tt>
|| <tt>TLS_DHE_RSA_WITH_AES_256_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA4</tt>
|| <tt>TLS_PSK_WITH_AES_128_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA5</tt>
|| <tt>TLS_PSK_WITH_AES_256_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA6</tt>
|| <tt>TLS_DHE_PSK_WITH_AES_128_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA7</tt>
|| <tt>TLS_DHE_PSK_WITH_AES_256_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA8</tt>
|| <tt>TLS_PSK_WITH_AES_128_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xA9</tt>
|| <tt>TLS_PSK_WITH_AES_256_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xAA</tt>
|| <tt>TLS_PSK_DHE_WITH_AES_128_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xAB</tt>
|| <tt>TLS_PSK_DHE_WITH_AES_256_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xAC</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_128_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xAD</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_256_CCM</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xAE</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8</tt>
||
|- style="border:none;padding:0.049cm;"
|| <tt>0xC0,0xAF</tt>
|| <tt>TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8</tt>
||
|-
|}
The list of IANA cipher suite names was retrieved from [https://www.iana.org/assignments/tls-parameters/tls-parameters-4.csv https://www.iana.org/assignments/tls-parameters/tls-parameters-4.csv] on Tue Jun 3 22:36:58 2014.
The list of OpenSSL Ciphers was generated with OpenSSL 1.0.1e 11 Feb 2013.


== Further Research ==
=== Further Research ===
The following is a list of services, software packages, hardware devices or protocols that we considered documenting but either did not manage to document yet or might be able to document later. We encourage input from the community.
The following is a list of services, software packages, hardware devices or protocols that we considered documenting but either did not manage to document yet or might be able to document later. We encourage input from the community.
Table 16. Further Protocols


; Further Protocols
{| style="border-spacing:0;width:14.018cm;"
{| style="border-spacing:0;width:14.018cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
Zeile 2.024: Zeile 498:
|-
|-
|}
|}
Table 17. Further Protocols (Network centric)


; Further Protocols (Network centric)
{| style="border-spacing:0;width:9.917cm;"
{| style="border-spacing:0;width:9.917cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
Zeile 2.069: Zeile 543:
|-
|-
|}
|}
Table 18. Further Applications


; Further Applications
{| style="border-spacing:0;width:7.853cm;"
{| style="border-spacing:0;width:7.853cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
Zeile 2.086: Zeile 560:
|-
|-
|}
|}
Commerical Network Equipment Vendors
 
;Commerical Network Equipment Vendors
Other ideas:
Other ideas:
SAML federated auth providers [[https://bettercrypto.org/#_footnotedef_42 42]]
* SAML federated auth providers [[https://bettercrypto.org/#_footnotedef_42 42]]
Elastic Load Balancing (ELB)[[https://bettercrypto.org/#_footnotedef_43 43]]
* Elastic Load Balancing (ELB)[[https://bettercrypto.org/#_footnotedef_43 43]]
 
==== Software not covered by this guide ====
# telnet: Usage of telnet for anything other than fun projects is highly discouraged
# Puppet DB: A Proxy or a tunnel is recommended if it needs to be facing public network interfaces.[[https://bettercrypto.org/#_footnotedef_44 44]]
# rsync: Best use it only via SSH for an optimum of security and easiest to maintain.
 
=== Bibliography ===
# Adam Langley, Ben Laurie, Emilia Kasper. (2013). Certificate Transparency. [http://www.certificate-transparency.org/ http://www.certificate-transparency.org] [https://datatracker.ietf.org/doc/rfc6962/ https://datatracker.ietf.org/doc/rfc6962/] .
# Adam Langley, et. al. (2013). Go X.509 Verification Source Code. [https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173 https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173] .
# Anderson, R. (2008). ''Security engineering''. Wiley.com. Retrieved from [http://www.cl.cam.ac.uk/ rja14/book.html http://www.cl.cam.ac.uk/ rja14/book.html]
# Bernstein, D. J., & Lange, T. (2013). ''Security dangers of the NIST curves'' (Presentation slides). Retrieved from [http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf]
# C. Evans and C. Palmer. (2013). Public Key Pinning Extension for HTTP. [https://tools.ietf.org/html/draft-ietf-websec-key-pinning-09 https://tools.ietf.org/html/draft-ietf-websec-key-pinning-09] .
# Damon Poeter. (2011). Fake Google Certificate Puts Gmail at Risk. [http://www.pcmag.com/article2/0,2817,2392063,00.asp http://www.pcmag.com/article2/0,2817,2392063,00.asp] .
# Durumeric, Z., Kasten, J., Bailey, M., & Halderman, J. A. (2013). Analysis of the HTTPS Certificate Ecosystem. In ''Proceedings of the 13th Internet Measurement Conference''. Retrieved from [https://jhalderm.com/pub/papers/https-imc13.pdf https://jhalderm.com/pub/papers/https-imc13.pdf]
# Elinor Mills. (2011). Fraudulent Google certificate points to Internet attack. [http://news.cnet.com/8301-27080_3-20098894-245/fraudulent-google-certificate-points-to-internet-attack/ http://news.cnet.com/8301-27080_3-20098894-245/fraudulent-google-certificate-points-to-internet-attack/] .
# Engblom, J. (2011). ''Evaluating HAVEGE Randomness'' (Blog: Observations from Uppsala). Retrieved from [http://jakob.engbloms.se/archives/1374 http://jakob.engbloms.se/archives/1374]
# ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson. (2013). ''ENISA - Algorithms, Key Sizes and Parameters Report''. Retrieved from [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report]
# für Sicherheit in der Informationstechnik (BSI), B. (2018). ''BSI TR-02102 Kryptographische Verfahren''. Retrieved from [https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/tr02102_node.html https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/tr02102_node.html]
# H. Tschofenig and E. Lear. (2013). Evolving the Web Public Key Infrastructure. [https://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-01.txt https://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-01.txt] .
# Heninger, N., Durumeric, Z., Wustrow, E., & Halderman, J. A. (2012). Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. In ''Proceedings of the 21st USENIX Security Symposium''. Retrieved from [https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf]
# Hoffman, P., & Schlyter, J. (2012). The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. IETF. Retrieved from [https://www.ietf.org/rfc/rfc6698.txt https://www.ietf.org/rfc/rfc6698.txt]
# i_mit_Realm configuration decisions_. (2013). (Documentation). Retrieved from [http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html]
# i_wikipedia_Discrete logarithm_. (2013). (Wikipedia). Retrieved from [https://en.wikipedia.org/wiki/Discrete_logarithm https://en.wikipedia.org/wiki/Discrete_logarithm]
# i_wikipedia_Tempest (codename)''. (2018). (Wikipedia). Retrieved from [https://en.wikipedia.org/wiki/Tempest https://en.wikipedia.org/wiki/Tempest](codename)
# II, E. C. R. Y. P. T., & SYM, D. (2012). ECRYPT II, 79–86. Retrieved from [http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf]
# Katz, J., & Lindell, Y. (2008). ''Introduction to modern cryptography''. Chapman & Hall/CRC. Retrieved from [http://books.google.at/books?id=WIc_AQAAIAAJ http://books.google.at/books?id=WIc_AQAAIAAJ]
# Kivinen, T., & Kojo, M. (2003). More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). IETF. Retrieved from [https://www.ietf.org/rfc/rfc3526.txt https://www.ietf.org/rfc/rfc3526.txt]
# Postel, J. (1980). DoD standard Transmission Control Protocol. IETF. Retrieved from [https://www.ietf.org/rfc/rfc761.txt https://www.ietf.org/rfc/rfc761.txt]
# Raeburn, K. (2005). Advanced Encryption Standard (AES) Encryption for Kerberos 5. IETF. Retrieved from [https://www.ietf.org/rfc/rfc3962.txt https://www.ietf.org/rfc/rfc3962.txt]
# ''SafeCurves: choosing safe curves for elliptic-curve cryptography''. (2013). (Technical Background). Retrieved from [http://safecurves.cr.yp.to/rigid.html http://safecurves.cr.yp.to/rigid.html]
# Schneier, B. (2013). ''The NSA Is Breaking Most Encryption on the Internet'' (Blog: Schneier on Security). Retrieved from [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html]
# Yarom, Y., & Falkner, K. (2013). Flush+ Reload: a high resolution, low noise, L3 cache side-channel attack. Cryptology ePrint Archive, Report 2013/448, 2013. [http://eprint/ http://eprint]. iacr. org/2013/448/. 3. Retrieved from [http://eprint.iacr.org/2013/448.pdf http://eprint.iacr.org/2013/448.pdf]
 
=== Weblinks ===
# https://bettercrypto.org/
[[Kategorie:Tmp]]
 
= Kryptografie =
 
== Geheime Kommunikation von Caesar bis 1950 ==
 
== Monoalphabetische Substitution Caesar-Chiffre ==
 
== Skytale ==
 
=== Der Skytale verwendet einen Transpositions-Algorithmus ===
 
== Atbash und Rot-13 ==
 
=== Bei Atbash wird der erste Buchstabe durch den letzten ausgetauscht ===
 
=== Julius Cäsar verwendete das Verfahren Rot-13 ===
 
== Kryptografie mit der Vigenere Tabelle ==
 
== Geheime Kommunikation von 1950 bis heute ==
 
= Kryptografie =
Grundlagen
 
== Kryptografie - Terminologie ==
 
== Teilbereiche der Kryptografie ==
 
=== Kryptografie  ===
* Durchführung und Studium Ver- und Entschlüsselung
* Daten werden mathematisch so kodiert, dass nur ausgewählte Personen die Daten decodieren können
* Dazu werden lesbare Daten (Klartext) durch einen mathematischen Algorithmus mit einem geheimen Schlüssel kodiert (Chiffretext)
* Ziel ist eine möglichst sichere Kryptografie
 
=== Kryptoanalyse ===
* Hier ist das Ziel eine Kryptografie zu brechen und so
* Sicherheitslücken zu entdecken
 
== Das Problem ==
 
=== Nur Bob soll die Nachricht von Alice empfangen können… ===
 
== Die Lösung ==
 
== Klassische Kryptografie ==
* Der Klartext (K) wird mittels eines Schlüssels verschlüsselt.
* Mithilfe desselben Schlüssels kann der Geheimtext (G) wieder entschlüsselt werden.
 
== Kryptografie - Terminologie (II) ==
 
== Geheime Übermittlung ==
 
=== Voraussetzungen ===
* Der Empfänger kennt den Schlüssel
* aber sonst niemand
* Ohne Kenntnis des Schlüssels
* ist es unmöglich oder sehr schwierig den Klartext herauszufinden
 
=== Schwierigkeiten ===
* Schlüssel muss vorher vereinbart werden
* Schlüssel muss geheim bleiben, „geheimer Kanal“
* Das Kryptografieverfahren muss sicher sein
 
== Vorhängeschloss-Analogie ==
* Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.
 
== Kryptographisches Grundprinzip ==
 
=== Umwandlung eines Klartextes  ===
* (p, plain text) in einem chiffrierten Text (c, ciphertext)
* mithilfe einer reversiblen kryptografischen Funktion f:
 
=== symmetrische und asymmetrische Algorithmen ===
* Kryptografie / Entschlüsselung
* Schlüssel als zusätzliches Argument zu Funktion f
 
== Verschlüsseln mit symmetrischen Verfahren ==
 
=== Kryptografie und Entschlüsselung mit selbem Schlüssel ===
* z.&nbsp;B.&nbsp;: DES, IDEA
* Effizient, aber Schlüsselaustauschproblem
 
== Ver- und Entschlüsselung mit symmetrischer Kryptografie ==
 
== Man-in-the-Middle ==
* Der Man-in-the-Middle (Mellory)
* schaltet sich zwischen eine Kommunikation
* fängt die gesendeten Datenpakete ab
* Diese kann er nun entschlüsseln, verändern, verschlüsseln und unbemerkt an den Empfänger weiterleiten
* Alice und Bob glauben direkt miteinander zu kommunizieren
* Dies ist jedoch nur möglich, wenn der Mellory die Möglichkeit hatte, an der Verteilung der öffentlich Schlüssel eine Manipulation vorzunehmen
* Wird der Schlüssel über ein zuverlässiges Medium übertragen
* ist der Diffie-Hellman-Algorythmus gegen solche Angriffe geschützt
 
== Asymmetrischer Kryptografiepublic key-Kryptografie ==
 
== Asymmetrischer Kryptografiepublic key-Kryptografie ==
 
== Public Key Kryptografie ==
 
=== Ver- und Entschlüsselung mit verschiedenen Schlüsseln ===
* “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
* Schlüssel-Paare: Öffentlicher und privater Schlüssel
* z.&nbsp;B.&nbsp;: RSA, ElGamal, Elliptische Kurven (ECC)
* Problem
* Meist ineffizienter als symmetrische Verfahren
* deshalb häufig nur zum Austausch symmetrischer Schlüssel und für Unterschriften
* Der private Schlüssel darf aus dem öffentlichen nicht errechenbar sein
* Einwegfunktion mit Falltür
* Nur unter Kenntnis einer zusätzlichen Information effizient umkehrbar
* z.&nbsp;B.&nbsp;x = loga y mod n (RSA-Verfahren) unter Kenntnis der Primfaktoren
 
== Transposition vs. Substitution ==
 
=== Transposition  ===
* jeweils 2 aufeinander folgende Buchstaben vertauschen
* wodurch sich neue Wörter ergeben
* wir auch als Scambling (Verwürfelung) bezeichnet
* Beispiel
* Netz = Enzt
* Einsatzgebiet
* drahtlose Übertragungstechniken
 
=== Substitution ===
* Bei der Substitution werden die Buchstaben des Klartextes im Geheimtext durch andere ersetzt
* Dabei wird jeder Buchstabe durch den ersetzt, der im Alphabet 3 Stellen weiter hinten steht.
* Cäsar-Addition
* Beispiel
* Netz = Qhzc
 
== Symmetrische Substitution ==
 
=== Sender und Empfänger müssen den gleichen Schlüssel besitzen ===
* um miteinander Kommunizieren zu können
* Secret-Key-Verfahren
* Eignet sich gut, um große Datenmengen zu verschlüsseln
* Nachteil
* Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
* was einen Schwachpunkt darstellt
 
== Symmetrische Substitutionsverfahren ==
 
=== Klassifizierungen ===
* Zeichenchiffren
* Blockchiffren
* Stromchiffren
* Zeichenchiffrierung
* Ermittelt jedes Zeichen des Geheimtextes aus dem entsprechenden Zeichen des Klartextes mit Hilfe des Schlüssels
* Cäsar-Addition
* Stromchiffrierung
* Der Klartext wird Byte-weise über eine XOR-Operation verschlüsselt
* Sie Erzeugt eine sich zyklisch verändernde Byte-Folge, die mit dem Klartext verknüpft wird
* Blockchiffrierung
* Klartext wird in Bitgruppen geteilt
* über mehrstufige Verfahren mit dem Schlüssel über gleichbleibende Operationen in Geheimtext umgewandelt
* DES
 
== Asymmetrische Substitution ==
* Es werden 2 komplementäre Schlüssel benötigt
* 1 Key zum Chiffrieren der Nachricht
* 2 Key zum Dechiffrieren der Nachricht
* Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
* Wird mit einem Schlüssel chiffriert
* kann nur mit dem anderen Schlüssel dechiffriert werden
 
== Vorteile von Public-Key-Verfahren ==
* Jeder Kommunikationspartner benötigt einen Schlüssel
* seinen Private Key
* Der zweite Schlüssel wird veröffentlicht
* Nachteil
* Hohe Komplexität der durchzuführenden Operationen
* Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
* während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann
 
== Absicherung der asymmetrischen Substitution ==
* Schwäche
* keine eindeutige Zuordnung des öffentlichen Schlüssels zu seinem Besitzer
* Ein „Man-in-the-Middle“ könnte sich dazwischenschalten und die Nachrichten unbemerkt entschlüsseln
* Informationen des öffentlichen Schlüssels und seines Besitzers sollten aus vertrauenswürdiger Quelle stammen
* Möglichkeiten im Rahmen der Public Key Infrastructure (PKI)
* Schlüssel kann über ein sicher betrachtetes Medium übertragen werden
* Beispiel
* Persönliche Übergabe, Telefon, Brief, Fax
* Identität des Schlüsselinhabers zertifizieren lassen
 
== Trust Center ==
 
=== Certification Authority [CA] ===
* Zertifizierungsinstanz (Trust Center)
* Zur Überprüfung der Schlüsselinhaber
* Sender und Empfänger verwalten Listen von Zertifizierungsinstanzen
* Überprüfung Zusammenhang öffentlicher Schlüssel und deren Absender
* Zertifikat nach ITU-Standard X.509
* ALTERNATIVE
* Authentizität eines öffentlichen Schlüssels durch einen bekannten Kommunikationspartner bestätigen lassen
* „Web of True“ von PGP
 
== Kryptografie ==
 
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Message Authentication Code</div>
 
== Einweg-Hash-Funktion ==
 
=== Message Authentication Code (MAC) ===
* Dienen bei Datenbank-Anwendungen der einfachen Indizierung von Informationen.
* Dabei werden beispielsweise Kundendaten durch Bildung einer Quersumme zu einem Wert zusammengefasst, denn man Hash-Wert nennt
* Ebenfalls einsetzbar als Authentifizierung und Signatur
* Es darf nicht möglich sein
* die original Information zu rekonstruieren
* durch eine ähnliche Information denselben Hash-Wert zu bekommen
* Es werden keine Schlüssel benutzt, da sie für jeden berechenbar sein sollen
 
== Hash-Funktion ==
 
=== Message Authentication Code (MAC) ===
* Ableitung von „to hash up“
* zerhacken, zerkleinern, durcheinander bringen
* generiert aus einer beliebig langen Zeichenkette eine zweite Zeichenfolge fixer länge.
* Anforderungen
* muss eindeutig sein
* muss einfach zu berechnen sein
* inverse Funktion muss schwierig zu berechnen sein
* muss kollisionsresistent sein
* Hashes lassen sich nicht zur Kryptografie einsetzen
* sie sind nicht reversibel
 
== Hash-Algorithmus ==
* Prüfsumme
* Über einen Hash-Algorithmus lässt sich aus einem beliebig langen Datensatz eine Prüfsumme fester Länge berechnen
* Kollisionsfreiheit
* Dieser Hashwert soll möglichst einmalig sein
* Damit ist sichergestellt, dass der Datensatz nicht so manipuliert werden kann, dass der Hashwert trotzdem noch derselbe ist
* SHA-1 und MD5
* Üblicherweise kommen SHA-1 (Secure Hash Algorithm) mit 160 Bit
* MD5 (Message Digest Algorithm) mit 128 Bit zum Einsatz
* ESP mit 96 Bit
* Bei ESP wird der Hashwert von 128, respektive 160 Bit auf 96 Bit abgeschnitten
* (Keyed-)Hash Message Authentication Codes
* Zur Authentisierung von Daten
* HMAC ist eine Sonderform des MAC, bei der zusammen mit einem geheimen Schlüssel ein Hash-Wert etwa über Datenpaket gebildet wird
* Bei VPNs benutzt man in der Regel HMAC-MD5 oder HMAC-SHA-1
 
== MD-5 ==
 
=== Am weitesten verbreitete Message-Digest-Funktion ===
* Mit MD-2 und MD-4 einer der Hash-Funktionen, die stetig verbessert werden
* Nachrichten werden in 512 Bit Blöcken verarbeitet
* indem es 16 x 32 Bit Blöcke zusammenfasst
* Auch als MAC erhält man einen 128 Bit langen Block aus 32 Bit Blöcken
* Die Verarbeitung findet in mehreren Stufen statt
* Dabei dienen ein 512 langer Block und das MAC der vorangegangenen Stufe als Eingangsfolge
 
== SHA-1 ==
 
=== Schwäche von MD-5 ===
* relativ schnelle Kollisionen der Hash-Werte
* SHA-1 generiert aus einer maximal 2^64 Bit langen Eingangsfolge eine 160 Bit lange Zeichenfolge
* Dabei arbeite es mit 512 bit Blöcken
* Der Algorithmus verwendet 5 Stufen mit jeweils 80 Schritten
* Ergebnisfolge ist wesentlich länger als bei MD-5
* wodurch Kollisionen unwahrscheinlicher sind
* Durchschnittliche Kollisionen:
* MD-5=2^60
* SHA-1=2^80
 
== Digital Signature Algorythm (DSA) ==
* Chiffriert einen, durch eine Hash-Funktion generierten, MAC mittels eines privaten Schlüssels
* Vorgehen eines mit SHA-1 generierten MAC
* Auswahl einer Primzahl p zwischen 512 und 1024 Bit
* Berechnung des Primfaktors q der Zahl (p-1). q ist 160 Bit lang
* Berechnung einer Zahl g
* mit g = h^(p-1/q) mod p, wobei h < p und g > 1
* Auswahl einer weiteren Zahl x
* als Privater Schlüssel des Senders Alice (x < q)
* Zahl y = g^x mod p wird nun als öffentlicher Schlüssel verwendet
 
== Substitution vs. Signatur ==
* Algorithmen asymmetrischer Kryptografien unterscheiden sich
* ob eine Nachricht verschlüsselt oder signiert werden soll
 
=== Substitution ===
* Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers
* so, dass er sie mit seinem privaten Schlüssel wieder im Klartext lesen kann
 
=== Signatur ===
* Absender erzeugt mit seinem privaten Schlüssel eine Signatur
* Empfänger kann durch Verwendung des öffentlichen Schlüssels des Absenders die Nachricht verifiziert
 
== Kryptografie ==
 
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Tunneling</div>
 
== Ende-zu-Ende vs. Abschnittsweise Sicherheit ==
 
=== Ende-zu-Ende ===
* 2 Endgeräte handeln einen sicheren Kanal, bauen ihn auf und halten ihn aufrecht
* Alternativ können nur kritische Übertragungen verschlüsselt werden
* Beispiel
* Kommunikation zwischen 2 Mailservern, wenn der Client eine Nachricht verschlüsselt überträgt
 
=== Vor- und Nachteile ===
* Ende-zu-Ende hat eine geringe Angriffsfläche
* benötigt jedoch viel Rechenleistung und eine gute Konfiguration
* Abschnittssicherheit hat eine größere Angriffsfläche
* beschränkt jedoch hohe Sicherheitsanforderungen auf die Gateways
 
== Tunneling ==
 
=== Mehrfaches Einpacken eines Pakets auf einer Transportebene ===
* Einsatzgebiet heute meist bei abschnittsweise Sicherheit
* IP/IP-Tunneling
* Für Transport über klassische IP-basierte Netze kann man IPv6 über IPv4 tunneln
 
=== Layer-2-Tunneling ===
* Pakete der OSI-Schicht 2
* meist PPP-frames
* werden in IP-Pakete verpackt
* So tunnelt man alle „Nicht-IP-Protokolle“
 
== Tunneling ==
 
=== Layer-3-Tunnelung ===
* Die Pakete der Vermittlungsschicht werden in IP-Frames verpackt
* Bekanntes Verfahren dieser Art ist IPsec
 
== Kryptografie ==
=== Wie baut man eine sicheren Block Cipher? ===
 
== Probleme bei der Entwicklung von Kryptografieverfahren ==
 
=== Vertraulichkeit ===
* Schutz der Daten vor unberechtigter Einsichtnahme
 
=== Authentisierung ===
* Sicherstellung der Herkunft
* Verbindlichkeit
 
=== Anonymität ===
* Schutz vor Bekanntwerden des Absenders und Empfängers
 
=== Integrität ===
* Unveränderlichkeit von Daten und Verlässlichkeit von Programmen
 
== Wie baut man eine sicheren Block Cipher? ==
 
== Mary Stuart 1516 - 1558Bekanntes Opfer der Kryptoanalyse ==
 
== Shannon‘s Principle of ConfusionSubstitution Cipher ==
 
== Shannon‘s Principle of DiffusionTransposition Cipher ==
 
== Kryptografie ==
 
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Angriffe auf Kryptografieen</div>
 
== Entschlüsselung ==
* Die Entschlüsselung ist die Umkehrung der Kryptografie (symmetrische Verfahren)
* Das heisst beim Beispiel-Caesar-Verfahren jetzt um 3 Buchstaben zurückverschieben:
* ABCDEFGHIJKLMNOPQRSTUVWXYZ
* xyzabcdefghijklmnopqrstuvw
* So wird aus „KDOOR“ wieder ein „hallo“.
 
=== Moderne Verfahren ===
* Das heute im kommerziellen Gebrauch am häufigsten eingesetzte Verfahren heisst DES
* DES steht für „Data Encryption Standard“
* Es funktioniert im Prinzip wie ein mehrfach hintereinander angewandtes Substitutionsverfahren
 
== Angriffe auf Kryptografieen ==
 
=== Chifertext-Only Angriff ===
* Versucht eine Kryptografie nur bei Kenntnis des chiffrierten Textes zu lösen
* Gößte Herausforderung für jeden Kryptoanalytiker
 
=== Known-plaintext-Angriff ===
* Der Angreifer besitzt neben dem Chiffretext auch den Klartext (oder einen Teil davon) und hat nun die Aufgabe den Schlüssel oder den Kryptografiealgorithmus zu finden.
 
=== Chosen-Plaintext Attack  ===
* Auch Teile des Klartextes können wertvolle Hilfe leisten
* Attacker can choose the plaintext that gets encrypted thereby potentially getting more information about the key
 
=== Adaptive Chosen-Plaintext Attack ===
* Attacker can choose a series of plaintexts, basing choice on the result of previous encryption
* differential cryptanalysis!
 
=== Brute Force Angriff ===
* Nacheinander werden alle möglichen Schlüssel durchprobiert
* Kann bei jeder Kryptografiemethode eingesetzt werden
* Der Angreifer muss jedoch erkennen, wann der richtige Schlüssel gefunden wurde, daher werden diese Angriffe oft als Known-plaintext-Angriff durchgeführt
 
== Dechiffrierung verschlüsselter NachrichtenBrute Force Angriff ==
* Die Brute-force Methode ist bei sehr großen Schlüsseln wirkungslos
* Dann muss sich der Gegner auf die Analyse des Chiffrats verlassen
* Dabei muss der Angreifer eine gewisse Vorstellung haben, um was für eine Art Ausgangstext es sich handelt
* zum Beispiel eine .exe-Datei, Word-Datei oder einen Text mit deutschem Inhalt
* Oder der Gegner spekuliert auf bestimmte Muster des Klartextes
* Word-Dateien fangen zum Beispiel immer mit dem selben Muster an
* Kryptoanalyse basiert auf der Ausnutzung
* von Spuren der Struktur oder
* des Musters des Klartextes
* Diese bestehen auch nach Kryptografie und sind im Chiffretext zu erkennen
 
== Exhaustive Testing ==
 
=== Monoalphabetischen Substitution (Cäsar) ===
* jedem Buchstaben eines Alphabets mit 27 Buchstaben (26 + ein Satzzeichen) wird ein beliebig anderen zuordnet
* 27 Möglichkeiten für den ersten Buchstaben
* 26 Möglichkeiten für den zweiten Buchstaben
* 25 Möglichkeiten für den dritten Buchstaben
* etc.
* Das enspricht 27 * 26 * .... * 2 * 1 = 27!
* rund 1,09*10e28 Zuordnungsmöglichkeiten
 
== Statische Analyse ==
* Angreifer nutzen die Schwachstellen der Kryptverfahren
* Dabei analysieren sie statisch den verschlüsselten Datenverkehr
* Im Fall der monoalphabetischen bedeutet das
* Die Häufigkeit der verschlüsselten Buchstaben bleibt gleich und kann durch einfache Häufigkeitsanalyse Rückschlüsse auf den Originaltext ziehen
* Jedoch muss deren Sprache kennen bzw.&nbsp;erraten
* Der Buchstabe „e“ tritt in der deutschen Sprache am häufigsten auf
* Auch Buchstabenpaare (Biagramme) treten mit unterschiedlicher Häufigkeit auf
* Durch diese Kenntnisse können monoalphabetische Codes schnell entschlüsselt werden
 
== Known oder Chosen Plaintext ==
* Teilweise vorhersehbar
* Kryptografieen und Kryptografien zu knacken fällt einem Angreifer leichter, wenn er Teile des Klartextes bereits kennt.
* Die Header-Daten von IP Paketen lassen sich unschwer erraten/ermitteln und ermöglichen so Know-Plaintext-Attacken
* Diese Methode funktioniert auch bei Paketen, bei denen Teile der Informationen im Header vorhersagbar sind
* Der Angreifer hat auch die Möglichkeit, eigenen Text zu verschlüsseln.
* Ist dieser abhörbar, so können Rückschlüsse über den Verschlüssellungsalgorythmus gezogen werden
 
== MustererkennungDie Methode des wahrscheinlichen Wortes ==
 
=== Bei der „Methode des wahrscheinlichen Wortes“ wählt man ein Wort aus, dass mit hoher Wahrscheinlichkeit im Klartext vorkommt, und sucht das Chiffrat ab, ob und wo das Muster dieses Wortes in ihm enthalten ist. Bsp.: „neun“ (Muster: ABCA) ===
 
== Most Cryptoanalytic Attacks base on theRedundancy of Natural Language Texts ==
 
== Angriffsarten ==
* Angreifer hat mehrere Möglichkeiten
* Informationen einer verschlüsselten Nachricht zu erhalten
* die vom Sender A („Alice“) an Empfänger B („Bob“) geschickt wird
* Am leichtesten können Nachrichten an
* Hubs
* Switches und
* Router abgehört werden
 
== Kryptografie ==
 
<div style="text-align:center;margin-left:0cm;margin-right:0cm;">Kryptologische Verfahren</div>
 
== Der Schlüsselaustausch ==
* Sicherheitsrelevant für alle bisher kennen gelernten Verfahren ist der Schlüsselaustausch
* muss zuvor über einen geheimen Kanal stattfinden
* Nicht immer hat man aber die Möglichkeit sich z.&nbsp;B.&nbsp;persönlich zu treffen
* Public-Key
* Es gibt jedoch ein Möglichkeiten, auch über einen unsicheren Kanal den Schlüsselaustausch durchzuführen
* Diese Verfahren tragen den Namen „Public-Key“
* Schlüsselaustausch ist ein Problem …
* Verschiedene Schlüssel für verschiedene Kommunikationspartner notwendig
* Diffie-Hellman Schlüsselaustausch-Verfahren
* Basiert auf Schwierigkeit, den „diskreten Logarithmus“ zu berechnen
* Gegeben sein ein Primzahl-Modulus p und eine Zahl x
* 1) Alice wählt eine zufällige, geheime Zahl a und berechnet y1=x^a mod p
* 2) Bob wählt eine zufällige, geheime Zahl b und berechnet y2=x^b mod p
* Beide senden sich ihr y1 bzw.&nbsp;y2 zu
* Alice berechnet s = y2^a = x^(ba) mod p
* Bob berechnet s‘ = y1^b = x^(ab) mod p = s
 
== Diffie-Hellman-Key-Exchange ==
* Über das Diffie-Hellman-Key-Exchange-Verfahren (DH) lassen sich kryptographische Schlüssel sicher über unsichere Kanäle aushandeln
* Es ist selbst kein Kryptografieverfahren und tauscht auch keine Schlüssel im eigentlichen Sinne aus
* Das von Martin Hellman und Whitfield Diffie entwickelte Verfahren beruht auf den Eigenschaften diskreter Logarithmen:
* zwar ist es einfach, eine Zahl zu potenzieren
* Es ist aber nur mit sehr großem Aufwand möglich, den diskreten Logarithmus einer Zahl zu berechnen
* Bei der Aushandlung einigen sich die VPN-Peers auf eine Primzahl p und eine Primitivwurzel g mod p
* Beide Faktoren dürfen unverschlüsselt übertragen werden
* Anschließend erzeugt jede Seite eine geheime Zufallszahl a/b und berechnet daraus den Wert Za= ga mod p beziehungsweise Zb = gb mod p
* Za und Zb werden an den Partner übertragen
* Daraus kann nun jede Seite den gemeinsamen symmetrischen Schlüssel K berechnen:
* Zba mod p = Zab mod p = K
 
== Diffie-Hellman-Key-Exchange ==
* Sind die eingesetzten Zahlen hinreichend groß, ist es für einen Angreifer so gut wie unmöglich, den Key zu knacken
* Große Zahlen erfordern allerdings mehr Rechenaufwand
* Die Größe der Zahlen bestimmt die gewählte DH-Gruppe
* Die kleinste DH Gruppe 1 hat 768 Bit und die größte definierte Gruppe 18 besitzt 8192 Bit
* Empfohlen wird derzeit der Gebrauch der Gruppe 5 mit 1536 Bit
 
== Diffie-Hellman ==
* Vereinbarung eines gemeinsamen symmetrischen Schlüssels über einen unsicheren Kanal.
* Basiert auf 2 Schlüsseln
* Alice und Bob sind einer große Primzahl p und ein ganzahliger Wert g (Generator) frei zugänglich
* Alice generiert eine große Zufallszahl a, berechnet eine Zahl A = g^a mod p
* Bob generiert ebenfalls eine große Zufallszahl b, berechnet eine Zahl B = g^b mod p
* und sendet B an Alice
* Alice berechnet eine Zahl K[1] = B^a mod p.
* Bob berechnet eine Zahl K[2] = A^b mod p.
* K[1] und K[2] sidn gleich.
* Es gilt K = K[2] = K[2] = g^a*b mod p
* K wird als geheimer symmetrischer Schlüssel verwendet
 
== Symmetrische Kryptografieverfahren ==
 
=== Einfachster Einsatz  ===
* basiert auf der logischen Exklusiv-Oder-Funktion
* 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
* Es entspricht also der Inversen Verknüpfung:
* (A+B)+B=A+(B+B)Assoziativgesetz=A+0Eigenschaft von XOR=AEigenschaft von XOR
* Der Sender verschlüsselt ein Zeichen A mit einem Schlüssel B per XOR und versendet das Ergebnis
* Der Empfänger verknüpft das Ergebnis erneut mit Schlüssel B und erhält dann wieder das Zeichen A
 
== Symmetric Algorithms: Block Ciphers ==
 
== Some Popular Block Ciphers ==
 
== Symmetric Algorithms: Stream Ciphers ==
 
== RC4 ==
 
=== RC = Rivest Cipher  ===
* Stromverschlüsselungsverfahren
* Basiert auf XOR-Verknüpfung
* Sehr schnell und einfach
* Eignet sich gut in Software
* Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
* Dieser wird zur Chiffrierung des Klartextes verwendet
* RC4 Speichert 258 verschiedene Zusatzinformationen
* 256 sind Permutationen von 0-255 und somit gleich verteilt
 
== DES ==
 
=== Familie der Blockchiffren ===
* Teilt eine Nachricht in 64 Bit große Datenblöcke
* 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
* Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
* Nachfolger: 3DES
* Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus
 
== Data Encryption Standard (DES)Sicherheit von DES ==
* DES
* erlaubt mit 56 Bit Schlüssellänge
* 72 Billiarden mögliche Schlüssel
* ist heute nicht mehr ausreichend
* per Brute-Force in 5 Tagen (?) geknackt
 
== Permutation ==
* DES besteht aus 3 Bearbeitungsschritten
* Initiale Permutation
* Ver-/Entschlüsselung in mehreren Runden
* finale Permutation
* DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
* durch die damals noch kleinen CPU Register
* Finale Permutation = Inverse der initialen Permutation
* Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle
 
== Kryptografie ==
* DES basiert auf einer 64 Bit Kryptografie
* wovon jedoch nur 56 Bit kryptographisch relevant sind
* Jedes 8 Bit = Parity-Bit
* DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
* Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
* Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
* Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
* 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]
 
== Kryptografie ==
* DES teilt den Klartext in 64 Bit Blöcke und
* splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
* R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.
 
== Genügen 128 Bit? ==
* IDEA
* International Data Encryption Algorithm
* arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
* 3.43669 * 1038
* knacken benötigt etwa 1012 Jahre
* Daher gilt der IDEA heute als sicher
 
== Asymmetrische Kryptografieverfahren ==
 
=== Setzen auf 2 unterschiedliche Schlüssel ===
* Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
* Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
* Es lässt sich nicht vom public key auf den private key schließen
* Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
* die der Besitzer des private keys nur entschlüsseln kann
 
=== Bekanntester Vertreter ===
* RSA-Algorythmus
* Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
* während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet
 
== RSA ==
 
=== Basiert auf folgenden 4 Schritten ===
* Wähle 2 große Primzahlen p und q, die geheim bleiben
* Berechne das Produkt n = p*q
* Für öffentlichen Schlüssel wähle e < n
* die teilerfremd zur Eulerschen Funktion E(n) = (p-1)*(q-1) ist
* Für privaten Schlüssel bestimme eine Zahl
* d = e^-1 mod E(n)
* Dann gilt
* e*d = 1 mod E(n)
* [d,n] ist der private Schlüssel
 
== RSA ==
 
=== Algorithmus bei der Kryptografie ===
* Alice verschlüsselt
* ihren Klartext m gemäß c = m^e mod n und
* sendet ihn an Bob.
* In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
* Bob entschlüsselt
* den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
* und erhält auf Grund des Zusammenhangs von d und e den Klartext m
 
== RSA ==
* Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
* Algorythmus zur Erzeugung und Überprüfung von Signaturen
* Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
* [d,n] = Privater Schlüssen von Alice
* Bob entschlüsselt die Signatur gemäß m = s^e mod n und erhält auf Grund des Zusammenhangs von d und e den Klartext m
* [e,n] = öffentlicher Schlüssel von Alice
 
== Advanced Encryption Standard ==
* Nachfolgestandard für DES
* 3DES mit 128 Bit gilt noch als sicher
* wegen der Dreifachverschlüsselung deutlich langsamer als AES
* AES unterstützt 128, 192 und 256 Bit lange Schlüssel
* Beispiel Hamachi
* AES mit 256 Bit Schlüssellänge
* im Modus Cipher-Block-Chaining
 
== Advanced Encryption Standard (AES)http://www.nist.gov/aes ==
* DES is nearly 25 years old!
* Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
* Single DES with 56 bit key is permitted for legacy systems only.
* Evaluation of an Advanced Encryption Standard
* The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
* 5 final candidate algorithms. Decision by NIST in Spring 2001
* Requirements for AES
* AES shall be publicly defined.
* AES shall be a symmetric block cipher.
* AES shall be implementable in both hardware and software.
* AES shall be designed so that the key length may be increased as needed.
* AES block size n = 128 bits, key size k = 128, 192, 256 bits
 
== AES Round 2 Finalists ==
* MARS(IBM)
* Modified Feistel Network - 32 Rounds
* Based on Mixed Structure DES
* RC6 (RSA)
* Feistel Network - 20 Rounds
* Based on Modified RC5
* Rijndal(Joan Daemen / Vincent Rijmen)
* Modified Substitution Permutation Network - 10 Rounds
* Based on Square
* Serpent (Ross Anderson / Eli Biham / Lars Knudsen)
* Substitution Permutation Network - 32 Rounds
* Based on Bitlice Operations
* Twofish(Bruce Schneier)
* Feistel Network - 16 Rounds
* Based on Modified Blowfish
 
== Cipher Block Chaining (CBC) ==
* Um eine Frquenzanalyse zu verhindern wird eine Verkettung von Datenblöcken durchgeführt
* Dabei wird der zu verschlüsselnde Datenblock exklusiv mit dem letzten verschlüsselten Datenblock verknüpft
* Gleiche Datenblöcke werden so unterschiedlich modifiziert und unterschiedlich verschlüsselt
* Problem: Erste Datenblock
* Erzeugung eines Initialisierungs-Vekros (IV)
* Der IV wird zur Entschlüsselung benötigt
* daher wird er dem Empfänger übermittelt
* Vertraulichkeit ist nicht erforderlich
* IPsec – Protokolle übertragen den IV in jedem Datenpaket
 
== Advanced Encryption Standard ==
 
=== CBC-Mode Entstehung von Mustern ===
* Rückschlüsse auf den Klartext
* Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
* Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
* Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
* Angreifer versucht im Chiffrat einzelne Bit manipulieren
* ohne Kenntnis des Schlüssels
* ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
* auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
* Da sich so der Inhalt manipulieren lässt
* In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
* Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
* wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
* Da Daten blockweise verschlüsselt werden
* muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
* die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten
 
== Vergleich: AES und 3DES ==
 
== IDEA ==
 
=== Familie der Blockchiffrierung ===
* jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
* Basiert auf einer Mischung 3 mathematischen Funktionen
* die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
* Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
* Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
* Trotz komplizierter Verfahren, schneller und sicherer als DES
 
== Hybride Kryptografieverfahren ==
 
=== Vorteile aus asymmetrischen und symmetrischen Kryptografie  ===
* Hohe Effizienz
* gesteigerte Sicherheit
* Flexibilität
* Austausch der erforderlichen Schlüssel
* erfolgt über ein asymmetrisches Verfahren
* Kryptografie größerer Datenmengen
* kommen symetrische Algorythmen zum Einsatz
 
== Vergleich Klassisch - Modern ==
 
=== Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA… ===
* …benötigen einen Schlüssel der beiden Parteien im Vornherein bekannt ist
* …sind symmetrisch (Entschlüsselung ist Umkehrung der Kryptografie)
* …sind in gewissen Masse anfällig auf Kryptoanalyse (z.&nbsp;B.&nbsp;Brute-Force)
 
== Fazit ==
 
=== Die Geschichte der Kryptografie ist ein Wettbewerb  ===
* zwischen Kryptografiespezialisten und Kryptoanalysten
* Momentan liegen die Verschlüssler mit dem IDEA vorne
* da dieses Verfahren nur mit Brute-Force geknackt werden kann
* dies wegen der großen Schlüssellänge auch auf modernsten Computern noch zu lange dauert
 
== Kryptografie ==
 
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Geschwindigkeit</div>
 
== Geschwindigkeit ==


=== Software not covered by this guide ===
== Geschwindigkeit ==
telnet: Usage of telnet for anything other than fun projects is highly discouraged
Puppet DB: A Proxy or a tunnel is recommended if it needs to be facing public network interfaces.[[https://bettercrypto.org/#_footnotedef_44 44]]
rsync: Best use it only via SSH for an optimum of security and easiest to maintain.


== Bibliography ==
== Geschwindigkeit ==
Adam Langley, Ben Laurie, Emilia Kasper. (2013). Certificate Transparency. [http://www.certificate-transparency.org/ http://www.certificate-transparency.org] [https://datatracker.ietf.org/doc/rfc6962/ https://datatracker.ietf.org/doc/rfc6962/] .
Adam Langley, et. al. (2013). Go X.509 Verification Source Code. [https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173 https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173] .
Anderson, R. (2008). ''Security engineering''. Wiley.com. Retrieved from [http://www.cl.cam.ac.uk/ rja14/book.html http://www.cl.cam.ac.uk/ rja14/book.html]
Bernstein, D. J., & Lange, T. (2013). ''Security dangers of the NIST curves'' (Presentation slides). Retrieved from [http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf]
C. Evans and C. Palmer. (2013). Public Key Pinning Extension for HTTP. [https://tools.ietf.org/html/draft-ietf-websec-key-pinning-09 https://tools.ietf.org/html/draft-ietf-websec-key-pinning-09] .
Damon Poeter. (2011). Fake Google Certificate Puts Gmail at Risk. [http://www.pcmag.com/article2/0,2817,2392063,00.asp http://www.pcmag.com/article2/0,2817,2392063,00.asp] .
Durumeric, Z., Kasten, J., Bailey, M., & Halderman, J. A. (2013). Analysis of the HTTPS Certificate Ecosystem. In ''Proceedings of the 13th Internet Measurement Conference''. Retrieved from [https://jhalderm.com/pub/papers/https-imc13.pdf https://jhalderm.com/pub/papers/https-imc13.pdf]
Elinor Mills. (2011). Fraudulent Google certificate points to Internet attack. [http://news.cnet.com/8301-27080_3-20098894-245/fraudulent-google-certificate-points-to-internet-attack/ http://news.cnet.com/8301-27080_3-20098894-245/fraudulent-google-certificate-points-to-internet-attack/] .
Engblom, J. (2011). ''Evaluating HAVEGE Randomness'' (Blog: Observations from Uppsala). Retrieved from [http://jakob.engbloms.se/archives/1374 http://jakob.engbloms.se/archives/1374]
ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson. (2013). ''ENISA - Algorithms, Key Sizes and Parameters Report''. Retrieved from [http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report]
für Sicherheit in der Informationstechnik (BSI), B. (2018). ''BSI TR-02102 Kryptographische Verfahren''. Retrieved from [https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/tr02102_node.html https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/tr02102_node.html]
H. Tschofenig and E. Lear. (2013). Evolving the Web Public Key Infrastructure. [https://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-01.txt https://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-01.txt] .
Heninger, N., Durumeric, Z., Wustrow, E., & Halderman, J. A. (2012). Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. In ''Proceedings of the 21st USENIX Security Symposium''. Retrieved from [https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf]
Hoffman, P., & Schlyter, J. (2012). The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. IETF. Retrieved from [https://www.ietf.org/rfc/rfc6698.txt https://www.ietf.org/rfc/rfc6698.txt]
i_mit_Realm configuration decisions_. (2013). (Documentation). Retrieved from [http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html]
i_wikipedia_Discrete logarithm_. (2013). (Wikipedia). Retrieved from [https://en.wikipedia.org/wiki/Discrete_logarithm https://en.wikipedia.org/wiki/Discrete_logarithm]
i_wikipedia_Tempest (codename)''. (2018). (Wikipedia). Retrieved from [https://en.wikipedia.org/wiki/Tempest https://en.wikipedia.org/wiki/Tempest](codename)
II, E. C. R. Y. P. T., & SYM, D. (2012). ECRYPT II, 79–86. Retrieved from [http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf]
Katz, J., & Lindell, Y. (2008). ''Introduction to modern cryptography''. Chapman & Hall/CRC. Retrieved from [http://books.google.at/books?id=WIc_AQAAIAAJ http://books.google.at/books?id=WIc_AQAAIAAJ]
Kivinen, T., & Kojo, M. (2003). More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). IETF. Retrieved from [https://www.ietf.org/rfc/rfc3526.txt https://www.ietf.org/rfc/rfc3526.txt]
Postel, J. (1980). DoD standard Transmission Control Protocol. IETF. Retrieved from [https://www.ietf.org/rfc/rfc761.txt https://www.ietf.org/rfc/rfc761.txt]
Raeburn, K. (2005). Advanced Encryption Standard (AES) Encryption for Kerberos 5. IETF. Retrieved from [https://www.ietf.org/rfc/rfc3962.txt https://www.ietf.org/rfc/rfc3962.txt]
''SafeCurves: choosing safe curves for elliptic-curve cryptography''. (2013). (Technical Background). Retrieved from [http://safecurves.cr.yp.to/rigid.html http://safecurves.cr.yp.to/rigid.html]
Schneier, B. (2013). ''The NSA Is Breaking Most Encryption on the Internet'' (Blog: Schneier on Security). Retrieved from [https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html]
Yarom, Y., & Falkner, K. (2013). Flush+ Reload: a high resolution, low noise, L3 cache side-channel attack. Cryptology ePrint Archive, Report 2013/448, 2013. [http://eprint/ http://eprint]. iacr. org/2013/448/. 3. Retrieved from [http://eprint.iacr.org/2013/448.pdf http://eprint.iacr.org/2013/448.pdf]


== Index ==
== Geschwindigkeit ==
[https://bettercrypto.org/#_footnoteref_1 1]. An easy to read yet very insightful recent example is the "FLUSH+RELOAD" technique&nbsp;for leaking cryptographic keys from one virtual machine to another via L3 cache timing attacks. (xref:bibliography-default-yarom2013flush[Yarom & Falkner, 2013
[https://bettercrypto.org/#_footnoteref_2 2]. Interested readers are referred to [https://bugzilla.mozilla.org/show_bug.cgi?id=647959 https://bugzilla.mozilla.org/show_bug.cgi?id=647959] or [http://www.h-online.com/security/news/item/Honest-Achmed-asks-for-trust-1231314.html http://www.h-online.com/security/news/item/Honest-Achmed-asks-for-trust-1231314.html] which brings the problem of trusting PKIs right to the point
[https://bettercrypto.org/#_footnoteref_3 3]. [http://www.wired.com/opinion/2013/10/how-to-design-and-defend-against-the-perfect-backdoor/ http://www.wired.com/opinion/2013/10/how-to-design-and-defend-against-the-perfect-backdoor/]
[https://bettercrypto.org/#_footnoteref_4 4]. [https://www.mail-archive.com/openssl-dev@openssl.org/msg33405.html https://www.mail-archive.com/openssl-dev@openssl.org/msg33405.html]
[https://bettercrypto.org/#_footnoteref_5 5]. [https://bugzilla.mindrot.org/show_bug.cgi?id=1647 https://bugzilla.mindrot.org/show_bug.cgi?id=1647]
[https://bettercrypto.org/#_footnoteref_6 6]. [https://www.dovecot.org/doc/NEWS-2.2 https://www.dovecot.org/doc/NEWS-2.2]
[https://bettercrypto.org/#_footnoteref_7 7]. [https://hg.dovecot.org/dovecot-2.2/rev/43ab5abeb8f0 https://hg.dovecot.org/dovecot-2.2/rev/43ab5abeb8f0]
[https://bettercrypto.org/#_footnoteref_8 8]. [https://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa9-5/ESA_9-5_Release_Notes.pdf https://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa9-5/ESA_9-5_Release_Notes.pdf], Changed Behaviour, page 4
[https://bettercrypto.org/#_footnoteref_9 9]. 64 possible values = 6 bits
[https://bettercrypto.org/#_footnoteref_10 10]. RFC6379&nbsp;, RFC4308&nbsp;
[https://bettercrypto.org/#_footnoteref_11 11]. [http://ikecrack.sourceforge.net/ http://ikecrack.sourceforge.net/]
[https://bettercrypto.org/#_footnoteref_12 12]. [https://sweet32.info/ https://sweet32.info/]
[https://bettercrypto.org/#_footnoteref_13 13]. [https://sweet32.info/#impact https://sweet32.info/#impact]
[https://bettercrypto.org/#_footnoteref_14 14]. [https://community.openvpn.net/openvpn/ticket/304 https://community.openvpn.net/openvpn/ticket/304]
[https://bettercrypto.org/#_footnoteref_15 15]. [http://technet.microsoft.com/en-us/security/advisory/2743314 http://technet.microsoft.com/en-us/security/advisory/2743314]
[https://bettercrypto.org/#_footnoteref_16 16]. [https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/]
[https://bettercrypto.org/#_footnoteref_17 17]. Early versions seem to have a few bugs - although officially supported, it did not work in tests with version 15.06. Version 16.01 is confirmed to work.
[https://bettercrypto.org/#_footnoteref_18 18]. [https://docs.ejabberd.im/ https://docs.ejabberd.im]
[https://bettercrypto.org/#_footnoteref_19 19]. [http://irc.netsplit.de/networks/top10.php IRC-Netze - Top 10 im Jahresvergleich]
[https://bettercrypto.org/#_footnoteref_20 20]. named old-des3-cbc-sha1
[https://bettercrypto.org/#_footnoteref_21 21]. alias des3-cbc-sha1, des3-hmac-sha1
[https://bettercrypto.org/#_footnoteref_22 22]. since 7, Server 2008R2
[https://bettercrypto.org/#_footnoteref_23 23]. since 1.9
[https://bettercrypto.org/#_footnoteref_24 24]. since 1.9
[https://bettercrypto.org/#_footnoteref_25 25]. [https://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html https://nikmav.blogspot.com/2011/12/price-to-pay-for-perfect-forward.html]
[https://bettercrypto.org/#_footnoteref_26 26]. [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf], page 51
[https://bettercrypto.org/#_footnoteref_27 27]. [https://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography https://arstechnica.com/security/2013/10/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography]
[https://bettercrypto.org/#_footnoteref_28 28]. [https://www.imperialviolet.org/2010/12/04/ecc.html https://www.imperialviolet.org/2010/12/04/ecc.html]
[https://bettercrypto.org/#_footnoteref_29 29]. [http://www.isg.rhul.ac.uk/~sdg/ecc.html http://www.isg.rhul.ac.uk/~sdg/ecc.html]
[https://bettercrypto.org/#_footnoteref_30 30]. [https://www.nist.gov/ https://www.nist.gov]
[https://bettercrypto.org/#_footnoteref_31 31]. [http://crypto.stackexchange.com/questions/1963/how-large-should-a-diffie-hellman-p-be http://crypto.stackexchange.com/questions/1963/how-large-should-a-diffie-hellman-p-be]
[https://bettercrypto.org/#_footnoteref_32 32]. [https://www.bettercrypto.org/static/dhparams/ https://www.bettercrypto.org/static/dhparams/]
[https://bettercrypto.org/#_footnoteref_33 33]. [https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security]
[https://bettercrypto.org/#_footnoteref_34 34]. Thus, it might be useful for fixing HTTPS mixed-content related errors, see [https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl].
[https://bettercrypto.org/#_footnoteref_35 35]. Website must load without SSL/TLS browser warnings (certificate is issued by a trusted CA, contains correct DNS name, it is time valid, etc.).
[https://bettercrypto.org/#_footnoteref_36 36]. List of the preloaded sites can be found at [https://www.chromium.org/hsts https://www.chromium.org/hsts]. This list is managed by Google/Chrome, but it is also used by Firefox [https://wiki.mozilla.org/Privacy/Features/HSTS_Preload_List https://wiki.mozilla.org/Privacy/Features/HSTS_Preload_List]
[https://bettercrypto.org/#_footnoteref_37 37]. [https://caniuse.com/stricttransportsecurity https://caniuse.com/stricttransportsecurity]
[https://bettercrypto.org/#_footnoteref_38 38]. see [https://bettercrypto.org/#pkis Public Key Infrastructures]
[https://bettercrypto.org/#_footnoteref_39 39]. see [https://blog.chromium.org/2011/06/new-chromium-security-features-june.html https://blog.chromium.org/2011/06/new-chromium-security-features-june.html]
[https://bettercrypto.org/#_footnoteref_40 40]. [https://tools.ietf.org/html/rfc7469/#section-3 https://tools.ietf.org/html/rfc7469\#section-3]
[https://bettercrypto.org/#_footnoteref_41 41]. [https://caniuse.com//#feat=publickeypinning https://caniuse.com/\#feat=publickeypinning]
[https://bettercrypto.org/#_footnoteref_42 42]. e.g., all the REFEDS folks ([https://refeds.org/ https://refeds.org/]), including InCommon ([http://www.incommon.org/federation/metadata.html http://www.incommon.org/federation/metadata.html] [https://wiki.shibboleth.net/confluence/display/SHIB2/TrustManagement https://wiki.shibboleth.net/confluence/display/SHIB2/TrustManagement])
[https://bettercrypto.org/#_footnoteref_43 43]. [https://lists.cert.at/pipermail/ach/2014-May/001422.html https://lists.cert.at/pipermail/ach/2014-May/001422.html]
[https://bettercrypto.org/#_footnoteref_44 44]. [https://lists.cert.at/pipermail/ach/2014-November/001626.html https://lists.cert.at/pipermail/ach/2014-November/001626.html]

Aktuelle Version vom 27. Juli 2024, 10:37 Uhr

Motivation

siehe Kryptografie/Motivation

Geheime Übermittlung

Voraussetzungen

  • Der Empfänger kennt den Schlüssel
  • aber sonst niemand
  • Ohne Kenntnis des Schlüssels
  • ist es unmöglich oder sehr schwierig den Klartext herauszufinden

Schwierigkeiten

  • Schlüssel muss vorher vereinbart werden
  • Schlüssel muss geheim bleiben „geheimer Kanal“
  • Das Kryptografieverfahren muss sicher sein

Vorhängeschloss-Analogie

  • Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.

Kryptographisches Grundprinzip

Umwandlung eines Klartextes

  • (p, plain text) in einem chiffrierten Text (c, ciphertext)
  • mit Hilfe einer reversiblen kryptographischen Funktion f:

symmetrische und asymmetrische Algorithmen

  • Kryptografie / Entschlüsselung
  • Schlüssel als zusätzliches Argument zu Funktion f

Verschlüsseln mit symmetrischen Verfahren

Kryptografie und Entschlüsselung mit selbem Schlüssel

  • DES, IDEA
  • Effizient, aber Schlüsselaustauschproblem

Ver- und Entschlüsselung mit symmetrischer Kryptografie

Symmetrische Substitution

Sender und Empfänger müssen den gleichen Schlüssel besitzen

  • um miteinander Kommunizieren zu können
  • Secret-Key-Verfahren
  • Eignet sich gut, um große Datenmengen zu verschlüsseln
  • Nachteil
  • Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
  • was einen Schwachpunkt darstellt

Symmetrische Substitutionsverfahren

Klassifizierungen

  • Zeichenchiffren
  • Blockchiffren
  • Stromchiffren
  • Zeichenchiffrierung
  • Ermittelt jedes Zeichen des Geheimtextes aus dem entsprechenden Zeichen des Klartextes mit Hilfe des Schlüssels
  • Cäsar-Addition
  • Stromchiffrierung
  • Der Klartext wird Byte-weise über eine XOR-Operation verschlüsselt
  • Sie Erzeugt eine sich zyklisch verändernde Byte-Folge, die mit dem Klartext verknüpft wird
  • Blockchiffrierung
  • Klartext wird in Bitgruppen geteilt
  • über mehrstufige Verfahren mit dem Schlüssel über gleichbleibende Operationen in Geheimtext umgewandelt
  • DES

Asymmetrischer Kryptografie/public key-Kryptografie

Public Key Kryptografie

Ver- und Entschlüsselung mit verschiedenen Schlüsseln

  • “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
  • Schlüssel-Paare: Öffentlicher und privater Schlüssel
  • z. B. : RSA, ElGamal, Elliptische Kurven (ECC)
  • Problem
  • Meist ineffizienter als symmetrische Verfahren
  • deshalb häufig nur zum Austausch symmetrischer Schlüssel und für Unterschriften
  • Der private Schlüssel darf aus dem öffentlichen nicht errechenbar sein
  • Einwegfunktion mit Falltür
  • Nur unter Kenntnis einer zusätzlichen Information effizient umkehrbar
  • z. B. x = loga y mod n (RSA-Verfahren) unter Kenntnis der Primfaktoren

Asymmetrische Substitution

  • Es werden 2 komplementäre Schlüssel benötigt
  • 1 Key zum chiffrieren der Nachricht
  • 2 Key zum dechiffrieren der Nachricht
  • Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
  • Wird mit einem Schlüssel chiffriert
  • kann nur mit dem anderen Schlüssel dechiffriert werden

Vorteile von Public-Key-Verfahren

  • Jeder Kommunikationspartner benötigt einen Schlüssel
  • seinen Private Key
  • Der zweite Schlüssel wird veröffentlicht
  • Nachteil
  • Hohe Komplexität der durchzuführenden Operationen
  • Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
  • während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann

Absicherung der asymmetrischen Substitution

  • Schwäche
  • keine eindeutige Zuordnung des öffentlichen Schlüssels zu seinem Besitzer
  • Ein „Man-in-the-Middle“ könnte sich dazwischen schalten und die Nachrichten unbemerkt entschlüsseln
  • Informationen des öffentlichen Schlüssels und seines Besitzers sollten aus vertrauenswürdiger Quelle stammen
  • Möglichkeiten im Rahmen der Public Key Infrastructure (PKI)
  • Schlüssel kann über ein sicher betrachtetes Medium übertragen werden
  • Beispiel
  • Persönliche Übergabe, Telefon, Brief, Fax
  • Identität des Schlüsselinhabers Zertifizieren lassen

Trust Center

Certification Authority [CA]

  • Zertifizierungsinstanz (Trust Center)
  • Zur Überprüfung der Schlüsselinhaber
  • Sender und Empfänger verwalten Listen von Zertifizierungsinstanzen
  • Überprüfung Zusammenhang öffentlicher Schlüssel und deren Absender
  • Zertifikat nach ITU-Standard X.509
  • ALTERNATIVE
  • Authentizität eines öffentlichen Schlüssels durch einen bekannten Kommunikationspartner bestätigen lassen
  • „Web of True“ von PGP

Substitution vs. Signatur

  • Algorithmen asymetrischer Kryptografieen unterscheiden sich
  • ob eine Nachricht verschlüsselt oder signiet werden soll

Substitution

  • Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers
  • so, dass er sie mit seinem privaten Schlüssel wieder im Klartext lesen kann

Signatur

  • Absender erzeugt mit seinem privatem Schlüssel eine Signatur
  • Empfänger kann durch Verwendung des öffentlichen Schlüssel des Absenders die Nachricht verifiziert

Tunneling

siehe Kryptografie/Tunneling

Wie baut man eine sicheren Block Cipher?

Probleme bei der Entwicklung von Kryptografieverfahren

Vertraulichkeit Schutz der Daten vor unberechtigter Einsichtnahme
Authentisierung Sicherstellung der Herkunft, Verbindlichkeit
Anonymität Schutz vor Bekanntwerden des Absenders und Empfängers
Integrität Unveränderlichkeit von Daten und Verlässlichkeit von Programmen

Mary Stuart 1516 - 1558

Bekanntes Opfer der Kryptoanalye

Shannon‘s Principle of Confusion

Substitution Cipher

Shannon‘s Principle of Diffusion

Transposition Cipher

Symmetrische Kryptografieverfahren

Einfachster Einsatz

  • basiert auf der logischen Exklusiv-Oder-Funktion
  • 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
  • Es entspricht also der Inversen Verknüpfung:
  • (A+B)+B=A+(B+B)Assoziativgesetz=A+0Eigenschaft von XOR=AEigenschaft von XOR
  • Der Sender verschlüsselt ein Zeichen A mit einem Schlüssel B per XOR und versendet das Ergebnis
  • Der Empfänger verknüpft das Ergebnis erneut mit Schlüssel B und erhält dann wieder das Zeichen A

Symmetric Algorithms: Block Ciphers

Some Popular Block Ciphers

Symmetric Algorithms: Stream Ciphers

RC4

RC Rivest Cipher

  • Stromverschlüsselungsverfahren
  • Basiert auf XOR-Verknüpfung
  • Sehr schnell und einfach
  • Eignet sich gut in Software
  • Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
  • Dieser wird zur Chiffrierung des Klartextes verwendet
  • RC4 Speichert 258 verschiedene Zusatzinformationen
  • 256 sind Permutationen von 0-255 und somit gleich verteilt

DES

Familie der Blockchiffren

  • Teilt eine Nachricht in 64 Bit große Datenblöcke
  • 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
  • Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
  • Nachfolger: 3DES
  • Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus

Data Encryption Standard (DES)Sicherheit von DES

  • DES
  • erlaubt mit 56 Bit Schlüssellänge
  • 72 Billiarden mögliche Schlüssel
  • ist heute nicht mehr ausreichend
  • per Brute-Force in 5 Tagen (?) geknackt

Permutation

  • DES besteht aus 3 Bearbeitungsschritten
  • Initiale Permutation
  • Ver-/Entschlüsselung in mehreren Runden
  • finale Permutation
  • DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
  • durch die damals noch kleinen CPU Register
  • Finale Permutation = Inverse der initialen Permutation
  • Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle
Kryptografie
  • DES basiert auf einer 64 Bit Kryptografie
  • wovon jedoch nur 56 Bit kryptographisch relevant sind
  • Jedes 8 Bit = Parity-Bit
  • DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
  • Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
  • Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
  • Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
  • 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]

Kryptografie

  • DES teilt den Klartext in 64 Bit Blöcke und
  • splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
  • R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.

Genügen 128 Bit?

  • IDEA
  • International Data Encryption Algorithm
  • arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
  • 3.43669 * 1038
  • knacken benötigt etwa 1012 Jahre
  • Daher gilt der IDEA heute als sicher

Asymmetrische Kryptografieverfahren

Setzen auf 2 unterschiedliche Schlüssel

  • Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
  • Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
  • Es lässt sich nicht vom public key auf den private key schließen
  • Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
  • die der Besitzer des private keys nur entschlüsseln kann

Bekanntester Vertreter

  • RSA-Algorythmus
  • Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
  • während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet

RSA

Basiert auf folgenden 4 Schritten

  • Wähle 2 große Primzahlen p und q, die geheim bleiben
  • Berechne das Produkt n = p*q
  • Für öffentlichen Schlüssel wähle e < n
  • die teilerfremd zur Eulerschen Funktion E(n) = (p-1)*(q-1) ist
  • Für privaten Schlüssel bestimme eine Zahl
  • d = e^-1 mod E(n)
  • Dann gilt
  • e*d = 1 mod E(n)
  • [d,n] ist der private Schlüssel

Algorithmus bei der Kryptografie

  • Alice verschlüsselt
  • ihren Klartext m gemäß c = m^e mod n und
  • sendet ihn an Bob.
  • In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
  • Bob entschlüsselt
  • den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
  • und erhält auf Grund des Zusammenhangs von d und e den Klartext m
  • Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
  • Algorythmus zur Erzeugung und Überprüfung von Signaturen
  • Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
  • [d,n] = Privater Schlüssen von Alice
  • Bob entschlüsselt die Signatur gemäß m = s^e mod n und erhält auf Grund des Zusammenhangs von d und e den Klartext m
  • [e,n] = öffentlicher Schlüssel von Alice

Advanced Encryption Standard

  • Nachfolgestandard für DES
  • 3DES mit 128 Bit gilt noch als sicher
  • wegen der Dreifachverschlüsselung deutlich langsamer als AES
  • AES unterstützt 128, 192 und 256 Bit lange Schlüssel
  • Beispiel Hamachi
  • AES mit 256 Bit Schlüssellänge
  • im Modus Cipher-Block-Chaining

Advanced Encryption Standard (AES)http://www.nist.gov/aes

  • DES is nearly 25 years old!
  • Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
  • Single DES with 56 bit key is permitted for legacy systems only.
  • Evaluation of an Advanced Encryption Standard
  • The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
  • 5 final candidate algorithms. Decision by NIST in Spring 2001
  • Requirements for AES
  • AES shall be publicly defined.
  • AES shall be a symmetric block cipher.
  • AES shall be implementable in both hardware and software.
  • AES shall be designed so that the key length may be increased as needed.
  • AES block size n = 128 bits, key size k = 128, 192, 256 bits

AES Round 2 Finalists

  • MARS(IBM)
  • Modified Feistel Network - 32 Rounds
  • Based on Mixed Structure DES
  • RC6 (RSA)
  • Feistel Network - 20 Rounds
  • Based on Modified RC5
  • Rijndal(Joan Daemen / Vincent Rijmen)
  • Modified Substitution Permutation Network - 10 Rounds
  • Based on Square
  • Serpent (Ross Anderson / Eli Biham / Lars Knudsen)
  • Substitution Permutation Network - 32 Rounds
  • Based on Bitlice Operations
  • Twofish(Bruce Schneier)
  • Feistel Network - 16 Rounds
  • Based on Modified Blowfish

Cipher Block Chaining (CBC)

  • Um eine Frquenzanalyse zu verhindern wird eine Verkettung von Datenblöcken durchgeführt
  • Dabei wird der zu verschlüsselnde Datenblock exklusiv mit dem letzten verschlüsselten Datenblock verknüpft
  • Gleiche Datenblöcke werden so unterschiedlich modifiziert und unterschiedlich verschlüsselt
  • Problem: Erste Datenblock
  • Erzeugung eines Initialisierungs-Vekros (IV)
  • Der IV wird zur Entschlüsselung benötigt
  • daher wird er dem Empfänger übermittelt
  • Vertraulichkeit ist nicht erforderlich
  • IPsec – Protokolle übertragen den IV in jedem Datenpaket

Advanced Encryption Standard

CBC-Mode Entstehung von Mustern

  • Rückschlüsse auf den Klartext
  • Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
  • Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
  • Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
  • Angreifer versucht im Chiffrat einzelne Bit manipulieren
  • ohne Kenntnis des Schlüssels
  • ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
  • auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
  • Da sich so der Inhalt manipulieren lässt
  • In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
  • Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
  • wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
  • Da Daten blockweise verschlüsselt werden
  • muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
  • die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten

Vergleich: AES und 3DES

IDEA

Familie der Blockchiffrierung

  • jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
  • Basiert auf einer Mischung 3 mathematischen Funktionen
  • die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
  • Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
  • Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
  • Trotz komplizierter Verfahren, schneller und sicherer als DES

Hybride Kryptografieverfahren

Vorteile aus asymmetrischen und symmetrischen Kryptografie

  • Hohe Effizienz
  • gesteigerte Sicherheit
  • Flexibilität
  • Austausch der erforderlichen Schlüssel
  • erfolgt über ein asymmetrisches Verfahren
  • Kryptografie größerer Datenmengen
  • kommen symetrische Algorythmen zum Einsatz

Vergleich Klassisch - Modern

Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA…

  • …benötigen einen Schlüssel der beiden Parteien im Vornherein bekannt ist
  • …sind symmetrisch (Entschlüsselung ist Umkehrung der Kryptografie)
  • …sind in gewissen Masse anfällig auf Kryptoanalyse (z. B. Brute-Force)

Fazit

Die Geschichte der Kryptografie ist ein Wettbewerb

  • zwischen Kryptografiespezialisten und Kryptoanalysten
  • Momentan liegen die Verschlüssler mit dem IDEA vorne
  • da dieses Verfahren nur mit Brute-Force geknackt werden kann
  • dies wegen der großen Schlüssellänge auch auf modernsten Computern noch zu lange dauert

TMP

Abstract

  • Unfortunately, the computer security and cryptology communities have drifted apart over the last 25 years. Security people don’t always understand the available crypto tools, and crypto people don’t always understand the real-world problems.
  • — Ross Anderson (Anderson, 2008)
  • This guide arose out of the need for system administrators to have an updated, solid, well researched and thought-through guide for configuring SSL, PGP, SSH and other cryptographic tools in the post-Snowden age. Triggered by the NSA leaks in the summer of 2013, many system administrators and IT security officers saw the need to strengthen their encryption settings. This guide is specifically written for these system administrators.
  • As Schneier noted in (Schneier, 2013), it seems that intelligence agencies and adversaries on the Internet are not breaking so much the mathematics of encryption per se, but rather use software and hardware weaknesses, subvert standardization processes, plant backdoors, rig random number generators and most of all exploit careless settings in server configurations and encryption systems to listen in on private communications. Worst of all, most communication on the internet is not encrypted at all by default (for SMTP, opportunistic TLS would be a solution).
  • This guide can only address one aspect of securing our information systems: getting the crypto settings right to the best of the authors' current knowledge. Other attacks, as the above mentioned, require different protection schemes which are not covered in this guide. This guide is not an introduction to cryptography. For background information on cryptography and cryptoanalysis we would like to refer the reader to the references in appendix Links and Suggested Reading at the end of this document.
  • The focus of this guide is merely to give current best practices for configuring complex cipher suites and related parameters in a copy & paste-able manner. The guide tries to stay as concise as is possible for such a complex topic as cryptography. Naturally, it can not be complete. There are many excellent guides (II & SYM, 2012) and best practice documents available when it comes to cryptography. However none of them focuses specifically on what an average system administrator needs for hardening his or her systems' crypto settings.
  • This guide tries to fill this gap.
The guide was produced in an open source manner
every step of editing can be traced back to a specific author via our version control system.

Introduction

Audience

Sysadmins. Sysadmins. Sysadmins. They are a force-multiplier.

Related publications

How to read this guide

  • This guide tries to accommodate two needs: first of all, having a handy reference on how to configure the most common services’ crypto settings and second of all, explain a bit of background on cryptography. This background is essential if the reader wants to choose his or her own cipher string settings.
  • System administrators who want to copy & paste recommendations quickly without spending a lot of time on background reading on cryptography or cryptanalysis can do so, by simply searching for the corresponding section in Best Practice.
  • It is important to know that in this guide the authors arrived at two recommendations: Cipher string A and Cipher string B. While the former is a hardened recommendation a latter is a weaker one but provides wider compatibility. Cipher strings A and B are described in Recommended cipher suites.
  • However, for the quick copy & paste approach it is important to know that this guide assumes users are happy with Cipher string B.
  • While Best Practice is intended to serve as a copy & paste reference, Theory explains the reasoning behind cipher string B. In particular Architectural overview explains how to choose individual cipher strings. We advise the reader to actually read this section and challenge our reasoning in choosing Cipher string B and to come up with a better or localized solution.

Disclaimer

  • A chain is no stronger than its weakest link, and life is after all a chain.
  • — William James
  • Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on. Unfortunately, endpoint security is so terrifically weak that NSA can frequently find ways around it.
  • — Edward Snowden answering questions live on the Guardian’s website
  • This guide specifically does not address physical security, protecting software and hardware against exploits, basic IT security housekeeping, information assurance techniques, traffic analysis attacks, issues with key-roll over and key management, securing client PCs and mobile devices (theft, loss), proper Operations Security, social engineering attacks, protection against tempest (i_wikipedia_Tempest (codename)_, 2018) attack techniques, thwarting different side-channel attacks (timing–, cache timing–, differential fault analysis, differential power analysis or power monitoring attacks), downgrade attacks, jamming the encrypted channel or other similar attacks which are typically employed to circumvent strong encryption.
  • The authors can not overstate the importance of these other techniques. Interested readers are advised to read about these attacks in detail since they give a lot of insight into other parts of cryptography engineering which need to be dealt with[1]) ].
  • This guide does not talk much about the well-known insecurities of trusting a public-key infrastructure (PKI)[2]. Nor does this text fully explain how to run your own Certificate Authority (CA).
  • Most of this zoo of information security issues are addressed in the very comprehensive book Security Engineering by Ross Anderson (Anderson, 2008).
  • For some experts in cryptography this text might seem too informal. However, we strive to keep the language as non-technical as possible and fitting for our target audience: system administrators who can collectively improve the security level for all of their users.
  • Security is a process, not a product.
  • — Bruce Schneier
  • This guide can only describe what the authors currently believe to be the best settings based on their personal experience and after intensive cross checking with literature and experts. For a complete list of people who reviewed this paper, see the <acknowledgements>. Even though multiple specialists reviewed the guide, the authors can give no guarantee whatsoever that they made the right recommendations. Keep in mind that tomorrow there might be new attacks on some ciphers and many of the recommendations in this guide might turn out to be wrong. Security is a process.
  • We therefore recommend that system administrators keep up to date with recent topics in IT security and cryptography.
  • In this sense, this guide is very focused on getting the cipher strings done right even though there is much more to do in order to make a system more secure. We the authors, need this document as much as the reader needs it.

Scope

In this guide, we restricted ourselves to:* Internet-facing services

  • Commonly used services
  • Devices which are used in business environments (this specifically excludes XBoxes, Playstations and similar consumer devices)
  • OpenSSL

We explicitly excluded:* Specialized systems such as medical devices, most embedded systems, industrial control systems (ICS), etc.

  • Wireless Access Points
  • Smart-cards/chip cards

Methods

  1. C.O.S.H.E.R - completely open source, headers, engineering and research.
  2. — A. Kaplan His mail signature for many years
  3. For writing this guide, we chose to collect the most well researched facts about cryptography settings and let as many trusted specialists as possible review those settings. The review process is completely open and done on a public mailing list.
  4. The document is available (read-only) to the public Internet on the web page and the source code of this document is on a public git server, mirrored on GitHub.com and open for public scrutiny. However, write permissions to the document are only granted to vetted people. The list of reviewers can be found in Acknowledgements.
  5. Every write operation to the document is logged via the git version control system and can thus be traced back to a specific author. We accept git pull requests on the github mirror for this paper.
  6. Public peer-review and multiple eyes checking of our guide is the best strategy we can imagine at the present moment [3].
  7. We invite the gentle reader to participate in this public review process. Please read the Contributing document.

Appendix

Links

  1. IANA official list of Transport Layer Security (TLS) Parameters
  2. Elliptic curves and their implementation (04 Dec 2010)
  3. A (relatively easy to understand) primer on elliptic curve cryptography
  4. Duraconf, A collection of hardened configuration files for SSL/TLSservices (Jacob Appelbaum’s github)
  5. Attacks on SSL a comprehensive study of BEAST, CRIME, TIME, BREACH, LUCKY 13 & RC4 Biases
  6. EFF How to deploy HTTPS correctly
  7. Bruce Almighty: Schneier preaches security to Linux faithful (on not recommending to use Blowfish anymore in favor of Twofish)
  8. Implement FIPS 183-3 for DSA keys (1024bit constraint)
  9. Elliptic Curve Cryptography in Practice
  10. Factoring as a Service
  11. Black Ops of TCP/IP 2012
  12. SSL and the Future of Authenticity, Moxie Marlinspike - Black Hat USA 2011
  13. ENISA - Algorithms, Key Sizes and Parameters Report (Oct.’13
  14. Diffie-Hellman Groups standardized in RFC3526
  15. TLS Security (Survey + Lucky13 + RC4 Attack) by Kenny Paterson
  16. Ensuring High-Quality Randomness in Cryptographic Key Generation
  17. Wikipedia: Ciphertext Stealing
  18. Wikipedia: Malleability (Cryptography)
  19. Ritter’s Crypto Glossary and Dictionary of Technical Cryptography

Suggested Reading

  1. This section contains suggested reading material.
  2. Cryptography Engineering: Design Principles and Practical Applications, Ferguson, N. and Schneier, B. and Kohno, T. (ISBN-13: 978-0470474242)
  3. Security Engineering: A Guide to Building Dependable Distributed Systems, Anderson, R.J. (ISBN-13: 978-0470068526)
  4. Applied cryptography: protocols, algorithms, and source code in C, Schneier, B. (ISBN-13: 978-0471117094)
  5. Guide to Elliptic Curve Cryptography, Hankerson, D. and Vanstone, S. and Menezes, A.J. (ISBN-13: 978-0387952734)
  6. A Introduction To The Theory of Numbers, Godfrey Harold Hardy, E. M. Wrigh (ISBN-13: 978-0199219865)
  7. Malicious Cryptography: Exposing Cryptovirology, Young A., Yung, M. (ISBN-13: 978-0764549755)

Further Research

The following is a list of services, software packages, hardware devices or protocols that we considered documenting but either did not manage to document yet or might be able to document later. We encourage input from the community.

Further Protocols
DNSSec (mention BCPs) DANE Tor
S/Mime (check are there any BCPs? ) TrueCrypt, LUKS, FileVault AFS
Kerberos NNTP NTPs tlsdate
Moxa , APC, und co…​ ICS
rsyslog tftp (s)ftp(s)
haproxy
Further Protocols (Network centric)
IPv6 security
Wi-Fi, 802.1x SIP SRTP
Kerberos NNTP NTPs tlsdate
BGP / OSPF LDAP seclayer-tcp
RADIUS (RADSEC) racoon strongswan
l2tp
Ethernet to serial DSL modems
UPnP, natPmp
HTTP Key Pinning (HTKP)
Monitoring: SNMPv3
Further Applications
Lync Tomcat
Microsoft SQL Server Microsoft Exchange
IBM HTTP Server
Commerical Network Equipment Vendors

Other ideas:

  • SAML federated auth providers [42]
  • Elastic Load Balancing (ELB)[43]

Software not covered by this guide

  1. telnet: Usage of telnet for anything other than fun projects is highly discouraged
  2. Puppet DB: A Proxy or a tunnel is recommended if it needs to be facing public network interfaces.[44]
  3. rsync: Best use it only via SSH for an optimum of security and easiest to maintain.

Bibliography

  1. Adam Langley, Ben Laurie, Emilia Kasper. (2013). Certificate Transparency. http://www.certificate-transparency.org https://datatracker.ietf.org/doc/rfc6962/ .
  2. Adam Langley, et. al. (2013). Go X.509 Verification Source Code. https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173 .
  3. Anderson, R. (2008). Security engineering. Wiley.com. Retrieved from rja14/book.html http://www.cl.cam.ac.uk/ rja14/book.html
  4. Bernstein, D. J., & Lange, T. (2013). Security dangers of the NIST curves (Presentation slides). Retrieved from http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf
  5. C. Evans and C. Palmer. (2013). Public Key Pinning Extension for HTTP. https://tools.ietf.org/html/draft-ietf-websec-key-pinning-09 .
  6. Damon Poeter. (2011). Fake Google Certificate Puts Gmail at Risk. http://www.pcmag.com/article2/0,2817,2392063,00.asp .
  7. Durumeric, Z., Kasten, J., Bailey, M., & Halderman, J. A. (2013). Analysis of the HTTPS Certificate Ecosystem. In Proceedings of the 13th Internet Measurement Conference. Retrieved from https://jhalderm.com/pub/papers/https-imc13.pdf
  8. Elinor Mills. (2011). Fraudulent Google certificate points to Internet attack. http://news.cnet.com/8301-27080_3-20098894-245/fraudulent-google-certificate-points-to-internet-attack/ .
  9. Engblom, J. (2011). Evaluating HAVEGE Randomness (Blog: Observations from Uppsala). Retrieved from http://jakob.engbloms.se/archives/1374
  10. ENISA and Vincent Rijmen, Nigel P. Smart, Bogdan warinschi, Gaven Watson. (2013). ENISA - Algorithms, Key Sizes and Parameters Report. Retrieved from http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report
  11. für Sicherheit in der Informationstechnik (BSI), B. (2018). BSI TR-02102 Kryptographische Verfahren. Retrieved from https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/tr02102_node.html
  12. H. Tschofenig and E. Lear. (2013). Evolving the Web Public Key Infrastructure. https://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-01.txt .
  13. Heninger, N., Durumeric, Z., Wustrow, E., & Halderman, J. A. (2012). Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices. In Proceedings of the 21st USENIX Security Symposium. Retrieved from https://factorable.net/weakkeys12.extended.pdf
  14. Hoffman, P., & Schlyter, J. (2012). The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. IETF. Retrieved from https://www.ietf.org/rfc/rfc6698.txt
  15. i_mit_Realm configuration decisions_. (2013). (Documentation). Retrieved from http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html
  16. i_wikipedia_Discrete logarithm_. (2013). (Wikipedia). Retrieved from https://en.wikipedia.org/wiki/Discrete_logarithm
  17. i_wikipedia_Tempest (codename). (2018). (Wikipedia). Retrieved from https://en.wikipedia.org/wiki/Tempest(codename)
  18. II, E. C. R. Y. P. T., & SYM, D. (2012). ECRYPT II, 79–86. Retrieved from http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf
  19. Katz, J., & Lindell, Y. (2008). Introduction to modern cryptography. Chapman & Hall/CRC. Retrieved from http://books.google.at/books?id=WIc_AQAAIAAJ
  20. Kivinen, T., & Kojo, M. (2003). More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE). IETF. Retrieved from https://www.ietf.org/rfc/rfc3526.txt
  21. Postel, J. (1980). DoD standard Transmission Control Protocol. IETF. Retrieved from https://www.ietf.org/rfc/rfc761.txt
  22. Raeburn, K. (2005). Advanced Encryption Standard (AES) Encryption for Kerberos 5. IETF. Retrieved from https://www.ietf.org/rfc/rfc3962.txt
  23. SafeCurves: choosing safe curves for elliptic-curve cryptography. (2013). (Technical Background). Retrieved from http://safecurves.cr.yp.to/rigid.html
  24. Schneier, B. (2013). The NSA Is Breaking Most Encryption on the Internet (Blog: Schneier on Security). Retrieved from https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html
  25. Yarom, Y., & Falkner, K. (2013). Flush+ Reload: a high resolution, low noise, L3 cache side-channel attack. Cryptology ePrint Archive, Report 2013/448, 2013. http://eprint. iacr. org/2013/448/. 3. Retrieved from http://eprint.iacr.org/2013/448.pdf

Weblinks

  1. https://bettercrypto.org/

Kryptografie

Geheime Kommunikation von Caesar bis 1950

Monoalphabetische Substitution Caesar-Chiffre

Skytale

Der Skytale verwendet einen Transpositions-Algorithmus

Atbash und Rot-13

Bei Atbash wird der erste Buchstabe durch den letzten ausgetauscht

Julius Cäsar verwendete das Verfahren Rot-13

Kryptografie mit der Vigenere Tabelle

Geheime Kommunikation von 1950 bis heute

Kryptografie

Grundlagen

Kryptografie - Terminologie

Teilbereiche der Kryptografie

Kryptografie

  • Durchführung und Studium Ver- und Entschlüsselung
  • Daten werden mathematisch so kodiert, dass nur ausgewählte Personen die Daten decodieren können
  • Dazu werden lesbare Daten (Klartext) durch einen mathematischen Algorithmus mit einem geheimen Schlüssel kodiert (Chiffretext)
  • Ziel ist eine möglichst sichere Kryptografie

Kryptoanalyse

  • Hier ist das Ziel eine Kryptografie zu brechen und so
  • Sicherheitslücken zu entdecken

Das Problem

Nur Bob soll die Nachricht von Alice empfangen können…

Die Lösung

Klassische Kryptografie

  • Der Klartext (K) wird mittels eines Schlüssels verschlüsselt.
  • Mithilfe desselben Schlüssels kann der Geheimtext (G) wieder entschlüsselt werden.

Kryptografie - Terminologie (II)

Geheime Übermittlung

Voraussetzungen

  • Der Empfänger kennt den Schlüssel
  • aber sonst niemand
  • Ohne Kenntnis des Schlüssels
  • ist es unmöglich oder sehr schwierig den Klartext herauszufinden

Schwierigkeiten

  • Schlüssel muss vorher vereinbart werden
  • Schlüssel muss geheim bleiben, „geheimer Kanal“
  • Das Kryptografieverfahren muss sicher sein

Vorhängeschloss-Analogie

  • Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.

Kryptographisches Grundprinzip

Umwandlung eines Klartextes

  • (p, plain text) in einem chiffrierten Text (c, ciphertext)
  • mithilfe einer reversiblen kryptografischen Funktion f:

symmetrische und asymmetrische Algorithmen

  • Kryptografie / Entschlüsselung
  • Schlüssel als zusätzliches Argument zu Funktion f

Verschlüsseln mit symmetrischen Verfahren

Kryptografie und Entschlüsselung mit selbem Schlüssel

  • z. B. : DES, IDEA
  • Effizient, aber Schlüsselaustauschproblem

Ver- und Entschlüsselung mit symmetrischer Kryptografie

Man-in-the-Middle

  • Der Man-in-the-Middle (Mellory)
  • schaltet sich zwischen eine Kommunikation
  • fängt die gesendeten Datenpakete ab
  • Diese kann er nun entschlüsseln, verändern, verschlüsseln und unbemerkt an den Empfänger weiterleiten
  • Alice und Bob glauben direkt miteinander zu kommunizieren
  • Dies ist jedoch nur möglich, wenn der Mellory die Möglichkeit hatte, an der Verteilung der öffentlich Schlüssel eine Manipulation vorzunehmen
  • Wird der Schlüssel über ein zuverlässiges Medium übertragen
  • ist der Diffie-Hellman-Algorythmus gegen solche Angriffe geschützt

Asymmetrischer Kryptografiepublic key-Kryptografie

Asymmetrischer Kryptografiepublic key-Kryptografie

Public Key Kryptografie

Ver- und Entschlüsselung mit verschiedenen Schlüsseln

  • “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
  • Schlüssel-Paare: Öffentlicher und privater Schlüssel
  • z. B. : RSA, ElGamal, Elliptische Kurven (ECC)
  • Problem
  • Meist ineffizienter als symmetrische Verfahren
  • deshalb häufig nur zum Austausch symmetrischer Schlüssel und für Unterschriften
  • Der private Schlüssel darf aus dem öffentlichen nicht errechenbar sein
  • Einwegfunktion mit Falltür
  • Nur unter Kenntnis einer zusätzlichen Information effizient umkehrbar
  • z. B. x = loga y mod n (RSA-Verfahren) unter Kenntnis der Primfaktoren

Transposition vs. Substitution

Transposition

  • jeweils 2 aufeinander folgende Buchstaben vertauschen
  • wodurch sich neue Wörter ergeben
  • wir auch als Scambling (Verwürfelung) bezeichnet
  • Beispiel
  • Netz = Enzt
  • Einsatzgebiet
  • drahtlose Übertragungstechniken

Substitution

  • Bei der Substitution werden die Buchstaben des Klartextes im Geheimtext durch andere ersetzt
  • Dabei wird jeder Buchstabe durch den ersetzt, der im Alphabet 3 Stellen weiter hinten steht.
  • Cäsar-Addition
  • Beispiel
  • Netz = Qhzc

Symmetrische Substitution

Sender und Empfänger müssen den gleichen Schlüssel besitzen

  • um miteinander Kommunizieren zu können
  • Secret-Key-Verfahren
  • Eignet sich gut, um große Datenmengen zu verschlüsseln
  • Nachteil
  • Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
  • was einen Schwachpunkt darstellt

Symmetrische Substitutionsverfahren

Klassifizierungen

  • Zeichenchiffren
  • Blockchiffren
  • Stromchiffren
  • Zeichenchiffrierung
  • Ermittelt jedes Zeichen des Geheimtextes aus dem entsprechenden Zeichen des Klartextes mit Hilfe des Schlüssels
  • Cäsar-Addition
  • Stromchiffrierung
  • Der Klartext wird Byte-weise über eine XOR-Operation verschlüsselt
  • Sie Erzeugt eine sich zyklisch verändernde Byte-Folge, die mit dem Klartext verknüpft wird
  • Blockchiffrierung
  • Klartext wird in Bitgruppen geteilt
  • über mehrstufige Verfahren mit dem Schlüssel über gleichbleibende Operationen in Geheimtext umgewandelt
  • DES

Asymmetrische Substitution

  • Es werden 2 komplementäre Schlüssel benötigt
  • 1 Key zum Chiffrieren der Nachricht
  • 2 Key zum Dechiffrieren der Nachricht
  • Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
  • Wird mit einem Schlüssel chiffriert
  • kann nur mit dem anderen Schlüssel dechiffriert werden

Vorteile von Public-Key-Verfahren

  • Jeder Kommunikationspartner benötigt einen Schlüssel
  • seinen Private Key
  • Der zweite Schlüssel wird veröffentlicht
  • Nachteil
  • Hohe Komplexität der durchzuführenden Operationen
  • Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
  • während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann

Absicherung der asymmetrischen Substitution

  • Schwäche
  • keine eindeutige Zuordnung des öffentlichen Schlüssels zu seinem Besitzer
  • Ein „Man-in-the-Middle“ könnte sich dazwischenschalten und die Nachrichten unbemerkt entschlüsseln
  • Informationen des öffentlichen Schlüssels und seines Besitzers sollten aus vertrauenswürdiger Quelle stammen
  • Möglichkeiten im Rahmen der Public Key Infrastructure (PKI)
  • Schlüssel kann über ein sicher betrachtetes Medium übertragen werden
  • Beispiel
  • Persönliche Übergabe, Telefon, Brief, Fax
  • Identität des Schlüsselinhabers zertifizieren lassen

Trust Center

Certification Authority [CA]

  • Zertifizierungsinstanz (Trust Center)
  • Zur Überprüfung der Schlüsselinhaber
  • Sender und Empfänger verwalten Listen von Zertifizierungsinstanzen
  • Überprüfung Zusammenhang öffentlicher Schlüssel und deren Absender
  • Zertifikat nach ITU-Standard X.509
  • ALTERNATIVE
  • Authentizität eines öffentlichen Schlüssels durch einen bekannten Kommunikationspartner bestätigen lassen
  • „Web of True“ von PGP

Kryptografie

Message Authentication Code

Einweg-Hash-Funktion

Message Authentication Code (MAC)

  • Dienen bei Datenbank-Anwendungen der einfachen Indizierung von Informationen.
  • Dabei werden beispielsweise Kundendaten durch Bildung einer Quersumme zu einem Wert zusammengefasst, denn man Hash-Wert nennt
  • Ebenfalls einsetzbar als Authentifizierung und Signatur
  • Es darf nicht möglich sein
  • die original Information zu rekonstruieren
  • durch eine ähnliche Information denselben Hash-Wert zu bekommen
  • Es werden keine Schlüssel benutzt, da sie für jeden berechenbar sein sollen

Hash-Funktion

Message Authentication Code (MAC)

  • Ableitung von „to hash up“
  • zerhacken, zerkleinern, durcheinander bringen
  • generiert aus einer beliebig langen Zeichenkette eine zweite Zeichenfolge fixer länge.
  • Anforderungen
  • muss eindeutig sein
  • muss einfach zu berechnen sein
  • inverse Funktion muss schwierig zu berechnen sein
  • muss kollisionsresistent sein
  • Hashes lassen sich nicht zur Kryptografie einsetzen
  • sie sind nicht reversibel

Hash-Algorithmus

  • Prüfsumme
  • Über einen Hash-Algorithmus lässt sich aus einem beliebig langen Datensatz eine Prüfsumme fester Länge berechnen
  • Kollisionsfreiheit
  • Dieser Hashwert soll möglichst einmalig sein
  • Damit ist sichergestellt, dass der Datensatz nicht so manipuliert werden kann, dass der Hashwert trotzdem noch derselbe ist
  • SHA-1 und MD5
  • Üblicherweise kommen SHA-1 (Secure Hash Algorithm) mit 160 Bit
  • MD5 (Message Digest Algorithm) mit 128 Bit zum Einsatz
  • ESP mit 96 Bit
  • Bei ESP wird der Hashwert von 128, respektive 160 Bit auf 96 Bit abgeschnitten
  • (Keyed-)Hash Message Authentication Codes
  • Zur Authentisierung von Daten
  • HMAC ist eine Sonderform des MAC, bei der zusammen mit einem geheimen Schlüssel ein Hash-Wert etwa über Datenpaket gebildet wird
  • Bei VPNs benutzt man in der Regel HMAC-MD5 oder HMAC-SHA-1

MD-5

Am weitesten verbreitete Message-Digest-Funktion

  • Mit MD-2 und MD-4 einer der Hash-Funktionen, die stetig verbessert werden
  • Nachrichten werden in 512 Bit Blöcken verarbeitet
  • indem es 16 x 32 Bit Blöcke zusammenfasst
  • Auch als MAC erhält man einen 128 Bit langen Block aus 32 Bit Blöcken
  • Die Verarbeitung findet in mehreren Stufen statt
  • Dabei dienen ein 512 langer Block und das MAC der vorangegangenen Stufe als Eingangsfolge

SHA-1

Schwäche von MD-5

  • relativ schnelle Kollisionen der Hash-Werte
  • SHA-1 generiert aus einer maximal 2^64 Bit langen Eingangsfolge eine 160 Bit lange Zeichenfolge
  • Dabei arbeite es mit 512 bit Blöcken
  • Der Algorithmus verwendet 5 Stufen mit jeweils 80 Schritten
  • Ergebnisfolge ist wesentlich länger als bei MD-5
  • wodurch Kollisionen unwahrscheinlicher sind
  • Durchschnittliche Kollisionen:
  • MD-5=2^60
  • SHA-1=2^80

Digital Signature Algorythm (DSA)

  • Chiffriert einen, durch eine Hash-Funktion generierten, MAC mittels eines privaten Schlüssels
  • Vorgehen eines mit SHA-1 generierten MAC
  • Auswahl einer Primzahl p zwischen 512 und 1024 Bit
  • Berechnung des Primfaktors q der Zahl (p-1). q ist 160 Bit lang
  • Berechnung einer Zahl g
  • mit g = h^(p-1/q) mod p, wobei h < p und g > 1
  • Auswahl einer weiteren Zahl x
  • als Privater Schlüssel des Senders Alice (x < q)
  • Zahl y = g^x mod p wird nun als öffentlicher Schlüssel verwendet

Substitution vs. Signatur

  • Algorithmen asymmetrischer Kryptografien unterscheiden sich
  • ob eine Nachricht verschlüsselt oder signiert werden soll

Substitution

  • Absender verschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Empfängers
  • so, dass er sie mit seinem privaten Schlüssel wieder im Klartext lesen kann

Signatur

  • Absender erzeugt mit seinem privaten Schlüssel eine Signatur
  • Empfänger kann durch Verwendung des öffentlichen Schlüssels des Absenders die Nachricht verifiziert

Kryptografie

Tunneling

Ende-zu-Ende vs. Abschnittsweise Sicherheit

Ende-zu-Ende

  • 2 Endgeräte handeln einen sicheren Kanal, bauen ihn auf und halten ihn aufrecht
  • Alternativ können nur kritische Übertragungen verschlüsselt werden
  • Beispiel
  • Kommunikation zwischen 2 Mailservern, wenn der Client eine Nachricht verschlüsselt überträgt

Vor- und Nachteile

  • Ende-zu-Ende hat eine geringe Angriffsfläche
  • benötigt jedoch viel Rechenleistung und eine gute Konfiguration
  • Abschnittssicherheit hat eine größere Angriffsfläche
  • beschränkt jedoch hohe Sicherheitsanforderungen auf die Gateways

Tunneling

Mehrfaches Einpacken eines Pakets auf einer Transportebene

  • Einsatzgebiet heute meist bei abschnittsweise Sicherheit
  • IP/IP-Tunneling
  • Für Transport über klassische IP-basierte Netze kann man IPv6 über IPv4 tunneln

Layer-2-Tunneling

  • Pakete der OSI-Schicht 2
  • meist PPP-frames
  • werden in IP-Pakete verpackt
  • So tunnelt man alle „Nicht-IP-Protokolle“

Tunneling

Layer-3-Tunnelung

  • Die Pakete der Vermittlungsschicht werden in IP-Frames verpackt
  • Bekanntes Verfahren dieser Art ist IPsec

Kryptografie

Wie baut man eine sicheren Block Cipher?

Probleme bei der Entwicklung von Kryptografieverfahren

Vertraulichkeit

  • Schutz der Daten vor unberechtigter Einsichtnahme

Authentisierung

  • Sicherstellung der Herkunft
  • Verbindlichkeit

Anonymität

  • Schutz vor Bekanntwerden des Absenders und Empfängers

Integrität

  • Unveränderlichkeit von Daten und Verlässlichkeit von Programmen

Wie baut man eine sicheren Block Cipher?

Mary Stuart 1516 - 1558Bekanntes Opfer der Kryptoanalyse

Shannon‘s Principle of ConfusionSubstitution Cipher

Shannon‘s Principle of DiffusionTransposition Cipher

Kryptografie

Angriffe auf Kryptografieen

Entschlüsselung

  • Die Entschlüsselung ist die Umkehrung der Kryptografie (symmetrische Verfahren)
  • Das heisst beim Beispiel-Caesar-Verfahren jetzt um 3 Buchstaben zurückverschieben:
  • ABCDEFGHIJKLMNOPQRSTUVWXYZ
  • xyzabcdefghijklmnopqrstuvw
  • So wird aus „KDOOR“ wieder ein „hallo“.

Moderne Verfahren

  • Das heute im kommerziellen Gebrauch am häufigsten eingesetzte Verfahren heisst DES
  • DES steht für „Data Encryption Standard“
  • Es funktioniert im Prinzip wie ein mehrfach hintereinander angewandtes Substitutionsverfahren

Angriffe auf Kryptografieen

Chifertext-Only Angriff

  • Versucht eine Kryptografie nur bei Kenntnis des chiffrierten Textes zu lösen
  • Gößte Herausforderung für jeden Kryptoanalytiker

Known-plaintext-Angriff

  • Der Angreifer besitzt neben dem Chiffretext auch den Klartext (oder einen Teil davon) und hat nun die Aufgabe den Schlüssel oder den Kryptografiealgorithmus zu finden.

Chosen-Plaintext Attack

  • Auch Teile des Klartextes können wertvolle Hilfe leisten
  • Attacker can choose the plaintext that gets encrypted thereby potentially getting more information about the key

Adaptive Chosen-Plaintext Attack

  • Attacker can choose a series of plaintexts, basing choice on the result of previous encryption
  • differential cryptanalysis!

Brute Force Angriff

  • Nacheinander werden alle möglichen Schlüssel durchprobiert
  • Kann bei jeder Kryptografiemethode eingesetzt werden
  • Der Angreifer muss jedoch erkennen, wann der richtige Schlüssel gefunden wurde, daher werden diese Angriffe oft als Known-plaintext-Angriff durchgeführt

Dechiffrierung verschlüsselter NachrichtenBrute Force Angriff

  • Die Brute-force Methode ist bei sehr großen Schlüsseln wirkungslos
  • Dann muss sich der Gegner auf die Analyse des Chiffrats verlassen
  • Dabei muss der Angreifer eine gewisse Vorstellung haben, um was für eine Art Ausgangstext es sich handelt
  • zum Beispiel eine .exe-Datei, Word-Datei oder einen Text mit deutschem Inhalt
  • Oder der Gegner spekuliert auf bestimmte Muster des Klartextes
  • Word-Dateien fangen zum Beispiel immer mit dem selben Muster an
  • Kryptoanalyse basiert auf der Ausnutzung
  • von Spuren der Struktur oder
  • des Musters des Klartextes
  • Diese bestehen auch nach Kryptografie und sind im Chiffretext zu erkennen

Exhaustive Testing

Monoalphabetischen Substitution (Cäsar)

  • jedem Buchstaben eines Alphabets mit 27 Buchstaben (26 + ein Satzzeichen) wird ein beliebig anderen zuordnet
  • 27 Möglichkeiten für den ersten Buchstaben
  • 26 Möglichkeiten für den zweiten Buchstaben
  • 25 Möglichkeiten für den dritten Buchstaben
  • etc.
  • Das enspricht 27 * 26 * .... * 2 * 1 = 27!
  • rund 1,09*10e28 Zuordnungsmöglichkeiten

Statische Analyse

  • Angreifer nutzen die Schwachstellen der Kryptverfahren
  • Dabei analysieren sie statisch den verschlüsselten Datenverkehr
  • Im Fall der monoalphabetischen bedeutet das
  • Die Häufigkeit der verschlüsselten Buchstaben bleibt gleich und kann durch einfache Häufigkeitsanalyse Rückschlüsse auf den Originaltext ziehen
  • Jedoch muss deren Sprache kennen bzw. erraten
  • Der Buchstabe „e“ tritt in der deutschen Sprache am häufigsten auf
  • Auch Buchstabenpaare (Biagramme) treten mit unterschiedlicher Häufigkeit auf
  • Durch diese Kenntnisse können monoalphabetische Codes schnell entschlüsselt werden

Known oder Chosen Plaintext

  • Teilweise vorhersehbar
  • Kryptografieen und Kryptografien zu knacken fällt einem Angreifer leichter, wenn er Teile des Klartextes bereits kennt.
  • Die Header-Daten von IP Paketen lassen sich unschwer erraten/ermitteln und ermöglichen so Know-Plaintext-Attacken
  • Diese Methode funktioniert auch bei Paketen, bei denen Teile der Informationen im Header vorhersagbar sind
  • Der Angreifer hat auch die Möglichkeit, eigenen Text zu verschlüsseln.
  • Ist dieser abhörbar, so können Rückschlüsse über den Verschlüssellungsalgorythmus gezogen werden

MustererkennungDie Methode des wahrscheinlichen Wortes

Bei der „Methode des wahrscheinlichen Wortes“ wählt man ein Wort aus, dass mit hoher Wahrscheinlichkeit im Klartext vorkommt, und sucht das Chiffrat ab, ob und wo das Muster dieses Wortes in ihm enthalten ist. Bsp.: „neun“ (Muster: ABCA)

Most Cryptoanalytic Attacks base on theRedundancy of Natural Language Texts

Angriffsarten

  • Angreifer hat mehrere Möglichkeiten
  • Informationen einer verschlüsselten Nachricht zu erhalten
  • die vom Sender A („Alice“) an Empfänger B („Bob“) geschickt wird
  • Am leichtesten können Nachrichten an
  • Hubs
  • Switches und
  • Router abgehört werden

Kryptografie

Kryptologische Verfahren

Der Schlüsselaustausch

  • Sicherheitsrelevant für alle bisher kennen gelernten Verfahren ist der Schlüsselaustausch
  • muss zuvor über einen geheimen Kanal stattfinden
  • Nicht immer hat man aber die Möglichkeit sich z. B. persönlich zu treffen
  • Public-Key
  • Es gibt jedoch ein Möglichkeiten, auch über einen unsicheren Kanal den Schlüsselaustausch durchzuführen
  • Diese Verfahren tragen den Namen „Public-Key“
  • Schlüsselaustausch ist ein Problem …
  • Verschiedene Schlüssel für verschiedene Kommunikationspartner notwendig
  • Diffie-Hellman Schlüsselaustausch-Verfahren
  • Basiert auf Schwierigkeit, den „diskreten Logarithmus“ zu berechnen
  • Gegeben sein ein Primzahl-Modulus p und eine Zahl x
  • 1) Alice wählt eine zufällige, geheime Zahl a und berechnet y1=x^a mod p
  • 2) Bob wählt eine zufällige, geheime Zahl b und berechnet y2=x^b mod p
  • Beide senden sich ihr y1 bzw. y2 zu
  • Alice berechnet s = y2^a = x^(ba) mod p
  • Bob berechnet s‘ = y1^b = x^(ab) mod p = s

Diffie-Hellman-Key-Exchange

  • Über das Diffie-Hellman-Key-Exchange-Verfahren (DH) lassen sich kryptographische Schlüssel sicher über unsichere Kanäle aushandeln
  • Es ist selbst kein Kryptografieverfahren und tauscht auch keine Schlüssel im eigentlichen Sinne aus
  • Das von Martin Hellman und Whitfield Diffie entwickelte Verfahren beruht auf den Eigenschaften diskreter Logarithmen:
  • zwar ist es einfach, eine Zahl zu potenzieren
  • Es ist aber nur mit sehr großem Aufwand möglich, den diskreten Logarithmus einer Zahl zu berechnen
  • Bei der Aushandlung einigen sich die VPN-Peers auf eine Primzahl p und eine Primitivwurzel g mod p
  • Beide Faktoren dürfen unverschlüsselt übertragen werden
  • Anschließend erzeugt jede Seite eine geheime Zufallszahl a/b und berechnet daraus den Wert Za= ga mod p beziehungsweise Zb = gb mod p
  • Za und Zb werden an den Partner übertragen
  • Daraus kann nun jede Seite den gemeinsamen symmetrischen Schlüssel K berechnen:
  • Zba mod p = Zab mod p = K

Diffie-Hellman-Key-Exchange

  • Sind die eingesetzten Zahlen hinreichend groß, ist es für einen Angreifer so gut wie unmöglich, den Key zu knacken
  • Große Zahlen erfordern allerdings mehr Rechenaufwand
  • Die Größe der Zahlen bestimmt die gewählte DH-Gruppe
  • Die kleinste DH Gruppe 1 hat 768 Bit und die größte definierte Gruppe 18 besitzt 8192 Bit
  • Empfohlen wird derzeit der Gebrauch der Gruppe 5 mit 1536 Bit

Diffie-Hellman

  • Vereinbarung eines gemeinsamen symmetrischen Schlüssels über einen unsicheren Kanal.
  • Basiert auf 2 Schlüsseln
  • Alice und Bob sind einer große Primzahl p und ein ganzahliger Wert g (Generator) frei zugänglich
  • Alice generiert eine große Zufallszahl a, berechnet eine Zahl A = g^a mod p
  • Bob generiert ebenfalls eine große Zufallszahl b, berechnet eine Zahl B = g^b mod p
  • und sendet B an Alice
  • Alice berechnet eine Zahl K[1] = B^a mod p.
  • Bob berechnet eine Zahl K[2] = A^b mod p.
  • K[1] und K[2] sidn gleich.
  • Es gilt K = K[2] = K[2] = g^a*b mod p
  • K wird als geheimer symmetrischer Schlüssel verwendet

Symmetrische Kryptografieverfahren

Einfachster Einsatz

  • basiert auf der logischen Exklusiv-Oder-Funktion
  • 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
  • Es entspricht also der Inversen Verknüpfung:
  • (A+B)+B=A+(B+B)Assoziativgesetz=A+0Eigenschaft von XOR=AEigenschaft von XOR
  • Der Sender verschlüsselt ein Zeichen A mit einem Schlüssel B per XOR und versendet das Ergebnis
  • Der Empfänger verknüpft das Ergebnis erneut mit Schlüssel B und erhält dann wieder das Zeichen A

Symmetric Algorithms: Block Ciphers

Some Popular Block Ciphers

Symmetric Algorithms: Stream Ciphers

RC4

RC = Rivest Cipher

  • Stromverschlüsselungsverfahren
  • Basiert auf XOR-Verknüpfung
  • Sehr schnell und einfach
  • Eignet sich gut in Software
  • Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
  • Dieser wird zur Chiffrierung des Klartextes verwendet
  • RC4 Speichert 258 verschiedene Zusatzinformationen
  • 256 sind Permutationen von 0-255 und somit gleich verteilt

DES

Familie der Blockchiffren

  • Teilt eine Nachricht in 64 Bit große Datenblöcke
  • 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
  • Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
  • Nachfolger: 3DES
  • Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus

Data Encryption Standard (DES)Sicherheit von DES

  • DES
  • erlaubt mit 56 Bit Schlüssellänge
  • 72 Billiarden mögliche Schlüssel
  • ist heute nicht mehr ausreichend
  • per Brute-Force in 5 Tagen (?) geknackt

Permutation

  • DES besteht aus 3 Bearbeitungsschritten
  • Initiale Permutation
  • Ver-/Entschlüsselung in mehreren Runden
  • finale Permutation
  • DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
  • durch die damals noch kleinen CPU Register
  • Finale Permutation = Inverse der initialen Permutation
  • Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle

Kryptografie

  • DES basiert auf einer 64 Bit Kryptografie
  • wovon jedoch nur 56 Bit kryptographisch relevant sind
  • Jedes 8 Bit = Parity-Bit
  • DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
  • Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
  • Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
  • Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
  • 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]

Kryptografie

  • DES teilt den Klartext in 64 Bit Blöcke und
  • splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
  • R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.

Genügen 128 Bit?

  • IDEA
  • International Data Encryption Algorithm
  • arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
  • 3.43669 * 1038
  • knacken benötigt etwa 1012 Jahre
  • Daher gilt der IDEA heute als sicher

Asymmetrische Kryptografieverfahren

Setzen auf 2 unterschiedliche Schlüssel

  • Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
  • Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
  • Es lässt sich nicht vom public key auf den private key schließen
  • Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
  • die der Besitzer des private keys nur entschlüsseln kann

Bekanntester Vertreter

  • RSA-Algorythmus
  • Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
  • während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet

RSA

Basiert auf folgenden 4 Schritten

  • Wähle 2 große Primzahlen p und q, die geheim bleiben
  • Berechne das Produkt n = p*q
  • Für öffentlichen Schlüssel wähle e < n
  • die teilerfremd zur Eulerschen Funktion E(n) = (p-1)*(q-1) ist
  • Für privaten Schlüssel bestimme eine Zahl
  • d = e^-1 mod E(n)
  • Dann gilt
  • e*d = 1 mod E(n)
  • [d,n] ist der private Schlüssel

RSA

Algorithmus bei der Kryptografie

  • Alice verschlüsselt
  • ihren Klartext m gemäß c = m^e mod n und
  • sendet ihn an Bob.
  • In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
  • Bob entschlüsselt
  • den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
  • und erhält auf Grund des Zusammenhangs von d und e den Klartext m

RSA

  • Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
  • Algorythmus zur Erzeugung und Überprüfung von Signaturen
  • Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
  • [d,n] = Privater Schlüssen von Alice
  • Bob entschlüsselt die Signatur gemäß m = s^e mod n und erhält auf Grund des Zusammenhangs von d und e den Klartext m
  • [e,n] = öffentlicher Schlüssel von Alice

Advanced Encryption Standard

  • Nachfolgestandard für DES
  • 3DES mit 128 Bit gilt noch als sicher
  • wegen der Dreifachverschlüsselung deutlich langsamer als AES
  • AES unterstützt 128, 192 und 256 Bit lange Schlüssel
  • Beispiel Hamachi
  • AES mit 256 Bit Schlüssellänge
  • im Modus Cipher-Block-Chaining

Advanced Encryption Standard (AES)http://www.nist.gov/aes

  • DES is nearly 25 years old!
  • Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
  • Single DES with 56 bit key is permitted for legacy systems only.
  • Evaluation of an Advanced Encryption Standard
  • The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
  • 5 final candidate algorithms. Decision by NIST in Spring 2001
  • Requirements for AES
  • AES shall be publicly defined.
  • AES shall be a symmetric block cipher.
  • AES shall be implementable in both hardware and software.
  • AES shall be designed so that the key length may be increased as needed.
  • AES block size n = 128 bits, key size k = 128, 192, 256 bits

AES Round 2 Finalists

  • MARS(IBM)
  • Modified Feistel Network - 32 Rounds
  • Based on Mixed Structure DES
  • RC6 (RSA)
  • Feistel Network - 20 Rounds
  • Based on Modified RC5
  • Rijndal(Joan Daemen / Vincent Rijmen)
  • Modified Substitution Permutation Network - 10 Rounds
  • Based on Square
  • Serpent (Ross Anderson / Eli Biham / Lars Knudsen)
  • Substitution Permutation Network - 32 Rounds
  • Based on Bitlice Operations
  • Twofish(Bruce Schneier)
  • Feistel Network - 16 Rounds
  • Based on Modified Blowfish

Cipher Block Chaining (CBC)

  • Um eine Frquenzanalyse zu verhindern wird eine Verkettung von Datenblöcken durchgeführt
  • Dabei wird der zu verschlüsselnde Datenblock exklusiv mit dem letzten verschlüsselten Datenblock verknüpft
  • Gleiche Datenblöcke werden so unterschiedlich modifiziert und unterschiedlich verschlüsselt
  • Problem: Erste Datenblock
  • Erzeugung eines Initialisierungs-Vekros (IV)
  • Der IV wird zur Entschlüsselung benötigt
  • daher wird er dem Empfänger übermittelt
  • Vertraulichkeit ist nicht erforderlich
  • IPsec – Protokolle übertragen den IV in jedem Datenpaket

Advanced Encryption Standard

CBC-Mode Entstehung von Mustern

  • Rückschlüsse auf den Klartext
  • Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
  • Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
  • Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
  • Angreifer versucht im Chiffrat einzelne Bit manipulieren
  • ohne Kenntnis des Schlüssels
  • ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
  • auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
  • Da sich so der Inhalt manipulieren lässt
  • In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
  • Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
  • wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
  • Da Daten blockweise verschlüsselt werden
  • muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
  • die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten

Vergleich: AES und 3DES

IDEA

Familie der Blockchiffrierung

  • jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
  • Basiert auf einer Mischung 3 mathematischen Funktionen
  • die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
  • Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
  • Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
  • Trotz komplizierter Verfahren, schneller und sicherer als DES

Hybride Kryptografieverfahren

Vorteile aus asymmetrischen und symmetrischen Kryptografie

  • Hohe Effizienz
  • gesteigerte Sicherheit
  • Flexibilität
  • Austausch der erforderlichen Schlüssel
  • erfolgt über ein asymmetrisches Verfahren
  • Kryptografie größerer Datenmengen
  • kommen symetrische Algorythmen zum Einsatz

Vergleich Klassisch - Modern

Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA…

  • …benötigen einen Schlüssel der beiden Parteien im Vornherein bekannt ist
  • …sind symmetrisch (Entschlüsselung ist Umkehrung der Kryptografie)
  • …sind in gewissen Masse anfällig auf Kryptoanalyse (z. B. Brute-Force)

Fazit

Die Geschichte der Kryptografie ist ein Wettbewerb

  • zwischen Kryptografiespezialisten und Kryptoanalysten
  • Momentan liegen die Verschlüssler mit dem IDEA vorne
  • da dieses Verfahren nur mit Brute-Force geknackt werden kann
  • dies wegen der großen Schlüssellänge auch auf modernsten Computern noch zu lange dauert

Kryptografie

Geschwindigkeit

Geschwindigkeit

Geschwindigkeit

Geschwindigkeit

Geschwindigkeit

Abgerufen von „https://wiki.foxtom.de/index.php?title=Kryptografie/tmp&oldid=103986“