Kryptografie/tmp: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
K Textersetzung - „Kryptografies“ durch „Kryptografie“
 
(143 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 =
 
== Audience ==
Sysadmins. Sysadmins. Sysadmins. They are a force-multiplier.
 
== Related publications ==
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]) 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.
 
== 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 [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 ==
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]) 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 ===
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 ==
C.O.S.H.E.R - completely open source, headers, engineering and research. 
— A. Kaplan ''His mail signature for many years''
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.
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].
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.
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]].
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.


= II: Best Practice =
=== Umwandlung eines Klartextes  ===
* (p, plain text) in einem chiffrierten Text (c, ciphertext)
* mit Hilfe einer reversiblen kryptographischen Funktion f:


== Webservers ==
=== symmetrische und asymmetrische Algorithmen ===
* Kryptografie / Entschlüsselung
* Schlüssel als zusätzliches Argument zu Funktion f


=== Apache ===
== Verschlüsseln mit symmetrischen Verfahren ==
Note that any cipher suite starting with EECDH can be omitted, if in doubt. (Compared to the theory section, EECDH in Apache and ECDHE in OpenSSL are synonyms&nbsp;[[https://bettercrypto.org/#_footnotedef_4 4]])


==== Tested with Versions ====
=== Kryptografie und Entschlüsselung mit selbem Schlüssel ===
* Apache 2.2.22, Debian Wheezy with OpenSSL 1.0.1e
* DES, IDEA
* Apache 2.4.6, Debian Jessie with OpenSSL 1.0.1e
* Effizient, aber Schlüsselaustauschproblem
* Apache 2.4.10, Debian Jessie 8.2 with OpenSSL 1.0.1k
* Apache 2.4.7, Ubuntu 14.04.2 Trusty with OpenSSL 1.0.1f
* Apache 2.4.6, CentOS Linux 7 (Core) with OpenSSL 1.0.1e
* Apache 2.4.18, Ubuntu 16.04.3 LTS with OpenSSL 1.0.2g


==== Settings ====
=== Ver- und Entschlüsselung mit symmetrischer Kryptografie ===
Enabled modules <tt>SSL</tt> and <tt>Headers</tt> are required.
Listing 1. SSL configuration for an Apache vhost
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
<nowiki>#SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt</nowiki>
<nowiki>#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt</nowiki>
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCompression off
Header always set Strict-Transport-Security "max-age=15768000"
<nowiki># Strict-Transport-Security: "max-age=15768000 ; includeSubDomains" </nowiki>
Header always set Public-Key-Pins "pin-sha256=\"YOUR_HASH=\"; pin-sha256=\"YOUR_BACKUP_HASH=\"; max-age=7776000; report-uri=\"https://YOUR.REPORT.URL\""
SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA'


{| style="border-spacing:0;width:17cm;"
=== Symmetrische Substitution ===
|- style="border:none;padding:0.049cm;"
=== Sender und Empfänger müssen den gleichen Schlüssel besitzen ===
||
* um miteinander Kommunizieren zu können
|| Add six earth month HSTS header for all users…​
* Secret-Key-Verfahren
|- style="border:none;padding:0.049cm;"
* Eignet sich gut, um große Datenmengen zu verschlüsseln
||
* Nachteil
|| If you want to protect all subdomains, use the following header. ALL subdomains HAVE TO support HTTPS if you use this!
* Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
|- style="border:none;padding:0.049cm;"
* was einen Schwachpunkt darstellt
||
|| CALL subdomains HAVE TO support HTTPS if you use this! At least use one Backup-Key and/or add whole CA, think of Cert-Updates!
|-
|}


==== Additional settings ====
=== Symmetrische Substitutionsverfahren ===
You might want to redirect everything to <tt>https://</tt> if possible. In Apache you can do this with the following setting inside of a VirtualHost environment:
Listing 2. https auto-redirect vhost
<VirtualHost *:80>
    Redirect permanent / https://SERVER_NAME/
</VirtualHost>


==== References ====
=== Klassifizierungen ===
[https://httpd.apache.org/docs/2.4/ssl/ Apache2 Docs on SSL and TLS]
* 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


==== How to test ====
== Asymmetrischer Kryptografie/public key-Kryptografie ==
See appendix [https://bettercrypto.org/#tools Tools]


=== lighttpd ===
=== Public Key Kryptografie ===


==== Tested with Versions ====
=== Ver- und Entschlüsselung mit verschiedenen Schlüsseln ===
* lighttpd/1.4.31-4 with OpenSSL 1.0.1e on Debian Wheezy
* “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
* lighttpd/1.4.33 with OpenSSL 0.9.8o on Debian Squeeze (note that TLSv1.2 does not work in openssl 0.9.8 thus not all ciphers actually work)
* Schlüssel-Paare: Öffentlicher und privater Schlüssel
* lighttpd/1.4.28-2 with OpenSSL 0.9.8o on Debian Squeeze (note that TLSv1.2 does not work in openssl 0.9.8 thus not all ciphers actually work)
* z.&nbsp;B.&nbsp;: RSA, ElGamal, Elliptische Kurven (ECC)
* lighttpd/1.4.31, Ubuntu 14.04.2 Trusty with Openssl 1.0.1f
* 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


==== Settings ====
=== Asymmetrische Substitution ===
Listing 3. SSL configuration for lighttpd
* Es werden 2 komplementäre Schlüssel benötigt
$SERVER["socket"] == "0.0.0.0:443" {
* 1 Key zum chiffrieren der Nachricht
    ssl.engine = "enable"
* 2 Key zum dechiffrieren der Nachricht
    ssl.use-sslv2 = "disable"
* Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
    ssl.use-sslv3 = "disable"
* Wird mit einem Schlüssel chiffriert
    ssl.pemfile = "/etc/lighttpd/server.pem"
* kann nur mit dem anderen Schlüssel dechiffriert werden
    ssl.ca-file = "/etc/ssl/certs/server.crt"
    ssl.cipher-list = "EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA"
    ssl.honor-cipher-order = "enable"
    setenv.add-response-header  <nowiki>= ( "Strict-Transport-Security" => "max-age=15768000") # six months</nowiki>
    <nowiki># use this only if all subdomains support HTTPS!</nowiki>
    <nowiki># setenv.add-response-header </nowiki> <nowiki>= ( "Strict-Transport-Security" => "max-age=15768000; includeSubDomains")</nowiki>
}
Starting with lighttpd version 1.4.29 Diffie-Hellman and Elliptic-Curve Diffie-Hellman key agreement protocols are supported. By default, elliptic curve "prime256v1" (also "secp256r1") will be used, if no other is given. To select special curves, it is possible to set them using the configuration options <tt>ssl.dh-file</tt> and <tt>ssl.ec-curve</tt>.
Listing 4. SSL EC/DH configuration for lighttpd
<nowiki># use group16 dh parameters</nowiki>
ssl.dh-file = "/etc/lighttpd/ssl/dh4096.pem"
ssl.ec-curve = "secp384r1"
Please read section [https://bettercrypto.org/#dh A note on Diffie Hellman Key Exchanges] for more information on Diffie Hellman key exchange and elliptic curves.


==== Additional settings ====
=== Vorteile von Public-Key-Verfahren ===
As for any other webserver, you might want to automatically redirect <tt>http://</tt> traffic toward <tt>https://</tt>. It is also recommended to set the environment variable <tt>HTTPS</tt>, so the PHP applications run by the webserver can easily detect that HTTPS is in use.
* Jeder Kommunikationspartner benötigt einen Schlüssel
Listing 5. https auto-redirect configuration
* seinen Private Key
$HTTP["scheme"] == "http" {
* Der zweite Schlüssel wird veröffentlicht
    <nowiki># capture vhost name with regex condition -> %0 in redirect pattern</nowiki>
* Nachteil
    <nowiki># must be the most inner block to the redirect rule</nowiki>
* Hohe Komplexität der durchzuführenden Operationen
    $HTTP["host"] =~ ".*" {
* Die Multiplikation 2 Zahlen stellt eine einfache Operation dar
        url.redirect = (".*" => "https://%0$0")
* während der umgekehrte Vorgang, also die Faktorzerlegung eines Produkts, einen enormen Rechenaufwand bedeuten kann
    }
    <nowiki># Set the environment variable properly</nowiki>
    setenv.add-environment = (
        "HTTPS" => "on"
    )
}


==== Additional information ====
=== Absicherung der asymmetrischen Substitution ===
The config option <tt>honor-cipher-order</tt> is available since 1.4.30, the supported ciphers depend on the used OpenSSL-version (at runtime). ECDHE has to be available in OpenSSL at compile-time, which should be default. SSL compression should by deactivated by default at compile-time (if not, it’s active).
* Schwäche
Support for other SSL-libraries like GnuTLS will be available in the upcoming 2.x branch, which is currently under development.
* 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


==== References ====
=== Trust Center ===
* [https://redmine.lighttpd.net/projects/1/wiki/HowToRedirectHttpToHttps How to redirect HTTP requests to HTTPS]
==== Certification Authority [CA] ====
* [https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL Lighttpd Docs: Secure HTTP]
* Zertifizierungsinstanz (Trust Center)
* [https://redmine.lighttpd.net/projects/lighttpd/wiki/Release-1_4_30 Release 1.4.30 (How to mitigate BEAST attack)]
* Zur Überprüfung der Schlüsselinhaber
* [https://redmine.lighttpd.net/issues/2445 Lightpd issue: SSL Compression disabled by default]
* 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


==== How to test ====
== Substitution vs. Signatur ==
See appendix [https://bettercrypto.org/#tools Tools]
* Algorithmen asymetrischer Kryptografieen unterscheiden sich
* ob eine Nachricht verschlüsselt oder signiet werden soll


=== nginx ===
=== 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


==== Tested with Version ====
=== Signatur ===
* 1.4.4 with OpenSSL 1.0.1e on OS X Server 10.8.5
* Absender erzeugt mit seinem privatem Schlüssel eine Signatur
* 1.2.1-2.2+wheezy2 with OpenSSL 1.0.1e on Debian Wheezy
* Empfänger kann durch Verwendung des öffentlichen Schlüssel des Absenders die Nachricht verifiziert
* 1.4.4 with OpenSSL 1.0.1e on Debian Wheezy
* 1.2.1-2.2&nbsp;bpo60+2 with OpenSSL 0.9.8o on Debian Squeeze (note that TLSv1.2 does not work in openssl 0.9.8 thus not all ciphers actually work)
* 1.4.6 with OpenSSL 1.0.1f on Ubuntu 14.04.2 LTS


==== Settings ====
== Tunneling ==
Listing 6. SSL settings for nginx
siehe [[Kryptografie/Tunneling]]
ssl on;
ssl_certificate cert.pem;
ssl_certificate_key cert.key;
ssl_session_timeout 5m;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # not possible to do exclusive
ssl_ciphers 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA';
add_header Strict-Transport-Security "max-age=15768000"; # six months
<nowiki># add_header Strict-Transport-Security "max-age=15768000; includeSubDomains"; </nowiki>


{| style="border-spacing:0;width:8.618cm;"
= Wie baut man eine sicheren Block Cipher? =
|- style="border:none;padding:0.049cm;"
=== Probleme bei der Entwicklung von Kryptografieverfahren ===
||
{| class="wikitable sortable options"
|| Use this only if all subdomains support HTTPS!
|-
| [[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
|}
|}
If you absolutely want to specify your own DH parameters, you can specify them via
ssl_dhparam file;
However, we advise you to read section [https://bettercrypto.org/#dh A note on Diffie Hellman Key Exchanges] and stay with the standard IKE/IETF parameters (as long as they are >1024 bits).


==== Additional settings ====
== Mary Stuart 1516 - 1558 ==
If you decide to trust NIST’s ECC curve recommendation, you can add the following line to nginx’s configuration file to select special curves:
Bekanntes Opfer der Kryptoanalye
Listing 7. SSL EC/DH settings for nginx
ssl_ecdh_curve secp384r1;
You might want to redirect everything to <tt>https://</tt> if possible. In Nginx you can do this with the following setting:
Listing 8. https auto-redirect in nginx
return 301 https://$server_name$request_uri;
The variable <tt>$server_name</tt> refers to the first <tt>server_name</tt> entry in your config file. If you specify more than one <tt>server_name</tt> only the first will be taken. Please be sure to not use the <tt>$host</tt> variable here because it contains data controlled by the user.


==== References ====
== Shannon‘s Principle of Confusion ==
* [https://nginx.org/en/docs/http/ngx_http_ssl_module.html Module ngx_http_ssl_module]
Substitution Cipher
* [https://nginx.org/en/docs/http/configuring_https_servers.html Configuring HTTPS servers]


==== How to test ====
== Shannon‘s Principle of Diffusion ==
See appendix [https://bettercrypto.org/#tools Tools]
Transposition Cipher


=== Cherokee ===
== 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


==== Tested with Version ====
=== Symmetric Algorithms: Block Ciphers ===
* Cherokee/1.2.104 on Debian Wheezy with OpenSSL 1.0.1e 11 Feb 2013


==== Settings ====
=== Some Popular Block Ciphers ===
The configuration of the cherokee webserver is performed by an admin interface available via the web. It then writes the configuration to <tt>/etc/cherokee/cherokee.conf</tt>, the important lines of such a configuration file can be found at the end of this section.* General Settings
** Network
*** ''SSL/TLS back-end'': <tt>OpenSSL/libssl</tt>
** Ports to listen
*** Port: 443, TLS: TLS/SSL port
* Virtual Servers, For each vServer on tab ''Security'':
** ''Required SSL/TLS Values'': Fill in the correct paths for ''Certificate'' and ''Certificate key''
* Advanced Options
** ''Ciphers'':<br/>EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
*** ''Server Preference'': Prefer
*** ''Compression'': Disabled
* Advanced: TLS
** SSL version 2 and SSL version 3: No
** TLS version 1, TLS version 1.1 and TLS version 1.2: Yes


==== Additional settings ====
== Symmetric Algorithms: Stream Ciphers ==
For each vServer on the Security tab it is possible to set the Diffie Hellman length to up to 4096 bits. We recommend to use >1024 bits. More information about Diffie-Hellman and which curves are recommended can be found in section [https://bettercrypto.org/#dh A note on Diffie Hellman Key Exchanges].
In Advanced: TLS it is possible to set the path to a Diffie Hellman parameters file for 512, 1024, 2048 and 4096 bits.
HSTS can be configured on host-basis in section ''vServers'' / ''Security'' / ''HTTP Strict Transport Security (HSTS)'':* ''Enable HSTS'': Accept
* ''HSTS Max-Age'': 15768000
* ''Include Subdomains'': depends on your setup
To redirect HTTP to HTTPS, configure a new rule per Virtual Server in the ''Behavior'' tab. The rule is ''SSL/TLS'' combined with a ''NOT'' operator. As ''Handler'' define ''Redirection'' and use <tt>/(.*)$</tt> as ''Regular Expression'' and <tt>+https://$\{host}/$1+</tt> as ''Substitution''.
Listing 9. SSL configuration for cherokee
server!bind!2!port = 443
server!bind!2!tls = 1
server!tls = libssl
vserver!1!hsts = 1
vserver!1!hsts!max_age = 15768000
vserver!1!hsts!subdomains = 1
vserver!1!rule!5!handler = redir
vserver!1!rule!5!handler!rewrite!10!regex = /(.*)$
vserver!1!rule!5!handler!rewrite!10!show = 1
vserver!1!rule!5!handler!rewrite!10!substring = https://${host}/$1
vserver!1!rule!5!handler!type = just_about
vserver!1!rule!5!match = not
vserver!1!rule!5!match!right = tls
vserver!1!ssl_certificate_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
vserver!1!ssl_certificate_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
vserver!1!ssl_cipher_server_preference = 1
vserver!1!ssl_ciphers = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
vserver!1!ssl_compression = 0
vserver!1!ssl_dh_length = 2048


==== References ====
= RC4 =
* [http://cherokee-project.com/doc/cookbook_ssl.html Cookbook: SSL, TLS and certificates]
=== RC Rivest Cipher  ===
* [http://cherokee-project.com/doc/cookbook_http_to_https.html Cookbook: Redirecting all traffic from HTTP to HTTPS]
* 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


==== How to test ====
= DES =
See appendix [https://bettercrypto.org/#tools Tools]
=== 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


=== MS IIS ===
=== Data Encryption Standard (DES)Sicherheit von DES ===
To configure SSL/TLS on Windows Server [https://www.nartac.com/Products/IISCrypto/ IIS Crypto] can be used.&nbsp;Simply start the Programm, no installation required. The tool changes the registry keys described below. A restart is required for the changes to take effect.
* DES
[[Image:Bild2.png|top|alt="IIS Crypto Tool"]]
* erlaubt mit 56 Bit Schlüssellänge
Instead of using the IIS Crypto Tool the configuration can be set using the Windows Registry. The following Registry keys apply to the newer Versions of Windows (Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2). For detailed information about the older versions see the Microsoft knowledgebase article [https://support.microsoft.com/en-us/help/245030 How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll].
* 72 Billiarden mögliche Schlüssel
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel]
* ist heute nicht mehr ausreichend
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Ciphers]
* per Brute-Force in 5 Tagen (?) geknackt
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\CipherSuites]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Hashes]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\KeyExchangeAlgorithms]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols]


==== Tested with Version ====
== Permutation ==
* Windows Server 2008
* DES besteht aus 3 Bearbeitungsschritten
* Windows Server 2008 R2
* Initiale Permutation
* Windows Server 2012
* Ver-/Entschlüsselung in mehreren Runden
* Windows Server 2012 R2
* finale Permutation
* Windows Vista and Internet Explorer 7 and upwards
* DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
* Windows 7 and Internet Explorer 8 and upwards
* durch die damals noch kleinen CPU Register
* Windows 8 and Internet Explorer 10 and upwards
* Finale Permutation = Inverse der initialen Permutation
* Windows 8.1 and Internet Explorer 11
* Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle


==== Settings ====
; Kryptografie
When trying to avoid RC4 (RC4 biases) as well as CBC (BEAST-Attack) by using GCM and to support perfect forward secrecy, Microsoft SChannel (SSL/TLS, Auth,.. Stack) supports ECDSA but lacks support for RSA signatures (see [https://safecurves.cr.yp.to/rigid.html ECC suite B doubts]).
* DES basiert auf einer 64 Bit Kryptografie
Since one is stuck with ECDSA, an elliptic curve certificate needs to be used.
* wovon jedoch nur 56 Bit kryptographisch relevant sind
The configuration of cipher suites MS IIS will use, can be configured in one of the following ways:# Group Policy: [https://docs.microsoft.com/de-de/windows/desktop/SecAuthN/prioritizing-schannel-cipher-suites Prioritizing Schannel Cipher Suites]
* Jedes 8 Bit = Parity-Bit
# Registry: [https://support.microsoft.com/en-us/help/245030 How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll]
* DES erzeugt 16 verschiedene 48 Bit lange Schlüssel
# [https://www.nartac.com/Products/IISCrypto/ IIS Crypto]
* Es werden aus 56 relevanten Bit mit einer Permutation 2 28 Bit Muster generiert (C[i-1] und D[i-1]).
# Powershell
* Die Teilschlüssel werden nun um 1 oder 2 Bit nach links rotiert.
Table&nbsp;[https://bettercrypto.org/#MS_IIS_Client_Support Client support] shows the process of turning on one algorithm after another and the effect on the supported clients tested using [https://www.ssllabs.com/ https://www.ssllabs.com].
* Die erzeugten Schlüssel C[i] und D[i] werden zu C[i-1] und D[i-1].
<tt>SSL 3.0</tt>, <tt>SSL 2.0</tt> and <tt>MD5</tt> are turned off. <tt>TLS 1.0</tt> and <tt>TLS 1.2</tt> are turned on.
* 2 24Bit Folgen aus C[i] und D[i] werden zum Schlüssel K[n]
Table 1. Client support


{| style="border-spacing:0;width:16.251cm;"
== Kryptografie ==
|- style="border:none;padding:0.049cm;"
* DES teilt den Klartext in 64 Bit Blöcke und
! align=center| Cipher Suite
* splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
! align=center| Client
* R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.
|- style="border:none;padding:0.049cm;"
|| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256+
|| only IE 10,11, OpenSSL 1.0.1e
|- style="border:none;padding:0.049cm;"
|| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256+
|| Chrome 30, Opera 17, Safari 6+
|- style="border:none;padding:0.049cm;"
|| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA+
|| FF 10-24, IE 8+, Safari 5, Java 7
|-
|}
Table&nbsp;[https://bettercrypto.org/#MS_IIS_Client_Support Client support] shows the algorithms from strongest to weakest and why they need to be added in this order. For example insisting on SHA-2 algorithms (only first two lines) would eliminate all versions of Firefox, so the last line is needed to support this browser, but should be placed at the bottom, so capable browsers will choose the stronger SHA-2 algorithms.
<tt>TLS_RSA_WITH_RC4_128_SHA</tt> or equivalent should also be added if MS Terminal Server Connection is used (make sure to use this only in a trusted environment). This suite will not be used for SSL, since we do not use a RSA Key.
Clients not supported:# Java 6
# WinXP
# Bing


==== Additional settings ====
== Genügen 128 Bit? ==
It’s recommended to use ´Strict-Transport-Security: max-age=15768000` for detailed information visit the [https://docs.microsoft.com/en-us/iis/configuration/system.webServer/httpProtocol/customHeaders/ Microsoft knowledgebase article in custom Headers].
* IDEA
You might want to redirect everything to http'''s''':// if possible. In IIS you can do this with the following setting by Powershell:
* International Data Encryption Algorithm
Set-WebConfiguration -Location "$WebSiteName/$WebApplicationName" `
* arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
    -Filter 'system.webserver/security/access' `
* 3.43669 * 1038
    -Value "SslRequireCert"
* knacken benötigt etwa 1012 Jahre
* Daher gilt der IDEA heute als sicher


==== Justification for special settings (if needed) ====
== Asymmetrische Kryptografieverfahren ==


==== References ====
=== Setzen auf 2 unterschiedliche Schlüssel ===
* [https://support.microsoft.com/en-us/help/245030 How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll]
* Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
* [https://support.microsoft.com/en-us/help/187498 How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services]
* Ö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


==== How to test ====
=== Bekanntester Vertreter ===
See appendix [https://bettercrypto.org/#tools Tools]
* RSA-Algorythmus
* Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
* während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet


== SSH ==
= RSA =
This section documents the Secure Shell (SSH) protocol. SSH is used to remotely manage computer systems, secururly transfer files over untrusted networks and to create "ad-hoc" virtual-private networks.
=== Basiert auf folgenden 4 Schritten ===
SSH is defined by the following Internet Standards (RFCs):
* Wähle 2 große Primzahlen p und q, die geheim bleiben
Table 2. SSH Standards
* 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


{| style="border-spacing:0;width:17cm;"
=== Algorithmus bei der Kryptografie ===
|- style="border:none;padding:0.049cm;"
* Alice verschlüsselt
! align=center| RFC
* ihren Klartext m gemäß c = m^e mod n und
! align=center| Title
* sendet ihn an Bob.
! align=center| Link
* In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
|- style="border:none;padding:0.049cm;"
* Bob entschlüsselt
|| '''4251'''
* den Geheimtext c mit seinem privaten Schlüssel [d,n] gemäß m = c^d mod n
|| The Secure Shell (SSH) Protocol Architecture
* und erhält auf Grund des Zusammenhangs von d und e den Klartext m
|| [https://tools.ietf.org/html/rfc4251 https://tools.ietf.org/html/rfc4251]
|- style="border:none;padding:0.049cm;"
|| '''4252'''
|| The Secure Shell (SSH) Authentication Protocol
|| [https://tools.ietf.org/html/rfc4252 https://tools.ietf.org/html/rfc4252]
|- style="border:none;padding:0.049cm;"
|| '''4253'''
|| The Secure Shell (SSH) Transport Layer Protocol
|| [https://tools.ietf.org/html/rfc4253 https://tools.ietf.org/html/rfc4253]
|- style="border:none;padding:0.049cm;"
|| '''6668'''
|| SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
|| [https://tools.ietf.org/html/rfc6668 https://tools.ietf.org/html/rfc6668]
|- style="border:none;padding:0.049cm;"
|| '''8268'''
|| More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)
|| [https://tools.ietf.org/html/rfc8268 https://tools.ietf.org/html/rfc8268]
|- style="border:none;padding:0.049cm;"
|| '''8308'''
|| Extension Negotiation in the Secure Shell (SSH) Protocol
|| [https://tools.ietf.org/html/rfc8308 https://tools.ietf.org/html/rfc8308]
|- style="border:none;padding:0.049cm;"
|| '''8332'''
|| Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol
|| [https://tools.ietf.org/html/rfc8332 https://tools.ietf.org/html/rfc8332]
|-
|}


=== OpenSSH ===
* Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
[https://www.openssh.com/ OpenSSH] is the most popular implementation of the SSH protocol. It is maintained by the [https://openbsd.org/ OpenBSD] project and portable versions are disitributed with many unix-like operating-systems and Windows Server.
* 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


==== Tested with Version ====
= Advanced Encryption Standard =
* OpenSSH 6.6p1 (Gentoo)
* Nachfolgestandard für DES
* OpenSSH 6.6p1-2 on Ubuntu 14.04.2 LTS
* 3DES mit 128 Bit gilt noch als sicher
* OpenSSH 7.2p2 on Ubuntu 16.04.3 LTS
* 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


==== Settings ====
== Advanced Encryption Standard (AES)http://www.nist.gov/aes ==
Listing 10. Important OpenSSH 6.6 security settings
* DES is nearly 25 years old!
<nowiki># Package generated configuration file</nowiki>
* Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
<nowiki># See the sshd_config(5) manpage for details</nowiki>
* Single DES with 56 bit key is permitted for legacy systems only.
<nowiki># What ports, IPs and protocols we listen for</nowiki>
* Evaluation of an Advanced Encryption Standard
Port 22
* The National Institute of Standards and Technology (NIST,U.S. Department of Commerce) started a public contest in 1997.
<nowiki># Use these options to restrict which interfaces/protocols sshd will bind to</nowiki>
* 5 final candidate algorithms. Decision by NIST in Spring 2001
<nowiki>#ListenAddress ::</nowiki>
* Requirements for AES
<nowiki>#ListenAddress 0.0.0.0</nowiki>
* AES shall be publicly defined.
Protocol 2
* AES shall be a symmetric block cipher.
<nowiki># HostKeys for protocol version 2</nowiki>
* AES shall be implementable in both hardware and software.
HostKey /etc/ssh/ssh_host_rsa_key
* AES shall be designed so that the key length may be increased as needed.
<nowiki>#HostKey /etc/ssh/ssh_host_dsa_key</nowiki>
* AES block size n = 128 bits, key size k = 128, 192, 256 bits
<nowiki>#HostKey /etc/ssh/ssh_host_ecdsa_key</nowiki>
HostKey /etc/ssh/ssh_host_ed25519_key
<nowiki>#Privilege Separation is turned on for security</nowiki>
UsePrivilegeSeparation yes
<nowiki># Lifetime and size of ephemeral version 1 server key</nowiki>
KeyRegenerationInterval 3600
ServerKeyBits 1024
<nowiki># Logging</nowiki>
SyslogFacility AUTH
LogLevel INFO
<nowiki># Authentication:</nowiki>
LoginGraceTime 120
PermitRootLogin no # or 'without-password' to allow SSH key based login
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
<nowiki>#AuthorizedKeysFile </nowiki>    %h/.ssh/authorized_keys
<nowiki># Don't read the user's ~/.rhosts and ~/.shosts files</nowiki>
IgnoreRhosts yes
<nowiki># For this to work you will also need host keys in /etc/ssh_known_hosts</nowiki>
RhostsRSAAuthentication no
<nowiki># similar for protocol version 2</nowiki>
HostbasedAuthentication no
<nowiki># Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication</nowiki>
<nowiki>#IgnoreUserKnownHosts yes</nowiki>
<nowiki># To enable empty passwords, change to yes (NOT RECOMMENDED)</nowiki>
PermitEmptyPasswords no
<nowiki># Change to yes to enable challenge-response passwords (beware issues with</nowiki>
<nowiki># some PAM modules and threads)</nowiki>
ChallengeResponseAuthentication no
<nowiki># Change to no to disable tunnelled clear text passwords</nowiki>
<nowiki>#PasswordAuthentication yes</nowiki>
<nowiki># Kerberos options</nowiki>
<nowiki>#KerberosAuthentication no</nowiki>
<nowiki>#KerberosGetAFSToken no</nowiki>
<nowiki>#KerberosOrLocalPasswd yes</nowiki>
<nowiki>#KerberosTicketCleanup yes</nowiki>
<nowiki># GSSAPI options</nowiki>
<nowiki>#GSSAPIAuthentication no</nowiki>
<nowiki>#GSSAPICleanupCredentials yes</nowiki>
<nowiki># Cipher selection</nowiki>
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
<nowiki>#UseLogin no</nowiki>
<nowiki>#MaxStartups 10:30:60</nowiki>
<nowiki>#Banner /etc/issue.net</nowiki>
<nowiki># Allow client to pass locale environment variables</nowiki>
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
<nowiki># Set this to 'yes' to enable PAM authentication, account processing,</nowiki>
<nowiki># and session processing. If this is enabled, PAM authentication will</nowiki>
<nowiki># be allowed through the ChallengeResponseAuthentication and</nowiki>
<nowiki># PasswordAuthentication. </nowiki> Depending on your PAM configuration,
<nowiki># PAM authentication via ChallengeResponseAuthentication may bypass</nowiki>
<nowiki># the setting of "PermitRootLogin without-password".</nowiki>
<nowiki># If you just want the PAM account and session checks to run without</nowiki>
<nowiki># PAM authentication, then enable this but set PasswordAuthentication</nowiki>
<nowiki># and ChallengeResponseAuthentication to 'no'.</nowiki>
UsePAM yes


{| style="border-spacing:0;width:7.874cm;"
== AES Round 2 Finalists ==
|- style="border:none;padding:0.049cm;"
* MARS(IBM)
||
* Modified Feistel Network - 32 Rounds
|| Curve25519
* Based on Mixed Structure DES
OpenSSH 6.6p1 now supports Curve25519.
* 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


==== Tested with Version ====
== Cipher Block Chaining (CBC) ==
* OpenSSH 6.5 (Debian Jessie)
* 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


==== Settings ====
== Advanced Encryption Standard ==
Listing 11. Important OpenSSH 6.5 security settings
=== CBC-Mode Entstehung von Mustern ===
<nowiki># Package generated configuration file</nowiki>
* Rückschlüsse auf den Klartext
<nowiki># See the sshd_config(5) manpage for details</nowiki>
* Anders als der ECB-Mode (Electronic Code Book) verhindert der CBC-Mode (Cipher Block Chaining) bei Kryptografiealgorithmen die Entstehung von Mustern im Chiffrat,
<nowiki># What ports, IPs and protocols we listen for</nowiki>
* Dazu lässt CBC das Ergebnis der vorherigen Blockoperation in die aktuelle einfließen (Chaining)
Port 22
* Sowohl ECB als auch CBC sind für so genannte Bit-Flipping-Attacken anfällig
<nowiki># Use these options to restrict which interfaces/protocols sshd will bind to</nowiki>
* Angreifer versucht im Chiffrat einzelne Bit manipulieren
<nowiki>#ListenAddress ::</nowiki>
* ohne Kenntnis des Schlüssels
<nowiki>#ListenAddress 0.0.0.0</nowiki>
* ohne später beim Entschlüsseln durch den Empfänger einen Fehler zu provozieren
Protocol 2
* auch für verschlüsselte Pakete die Integrität gesichert werden, etwa mit HMAC
<nowiki># HostKeys for protocol version 2</nowiki>
* Da sich so der Inhalt manipulieren lässt
HostKey /etc/ssh/ssh_host_rsa_key
* In CBC werden jeweils Blöcke von jeweils 16 Datenbytes verschlüsselt
<nowiki>#HostKey /etc/ssh/ssh_host_dsa_key</nowiki>
* Das CBC-Verfahren initialisiert mit einem zufällig gewählten 128 Bit langen Initialisierungsvektor
<nowiki>#HostKey /etc/ssh/ssh_host_ecdsa_key</nowiki>
* wird bei ESP-Paket den chiffrierten Nutzdaten vorangestellt
HostKey /etc/ssh/ssh_host_ed25519_key
* Da Daten blockweise verschlüsselt werden
<nowiki>#Privilege Separation is turned on for security</nowiki>
* muss der letzte Datenblock mit Füll-Bytes zur vollen Blocklänge aufgefüllt
UsePrivilegeSeparation yes
* die Anzahl dieser Stopf-Bytes wird im Längen-Byte festgehalten
<nowiki># Lifetime and size of ephemeral version 1 server key</nowiki>
KeyRegenerationInterval 3600
ServerKeyBits 1024
<nowiki># Logging</nowiki>
SyslogFacility AUTH
LogLevel INFO
<nowiki># Authentication:</nowiki>
LoginGraceTime 120
PermitRootLogin no # or 'without-password' to allow SSH key based login
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
<nowiki>#AuthorizedKeysFile </nowiki>    %h/.ssh/authorized_keys
<nowiki># Don't read the user's ~/.rhosts and ~/.shosts files</nowiki>
IgnoreRhosts yes
<nowiki># For this to work you will also need host keys in /etc/ssh_known_hosts</nowiki>
RhostsRSAAuthentication no
<nowiki># similar for protocol version 2</nowiki>
HostbasedAuthentication no
<nowiki># Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication</nowiki>
<nowiki>#IgnoreUserKnownHosts yes</nowiki>
<nowiki># To enable empty passwords, change to yes (NOT RECOMMENDED)</nowiki>
PermitEmptyPasswords no
<nowiki># Change to yes to enable challenge-response passwords (beware issues with</nowiki>
<nowiki># some PAM modules and threads)</nowiki>
ChallengeResponseAuthentication no
<nowiki># Change to no to disable tunnelled clear text passwords</nowiki>
<nowiki>#PasswordAuthentication yes</nowiki>
<nowiki># Kerberos options</nowiki>
<nowiki>#KerberosAuthentication no</nowiki>
<nowiki>#KerberosGetAFSToken no</nowiki>
<nowiki>#KerberosOrLocalPasswd yes</nowiki>
<nowiki>#KerberosTicketCleanup yes</nowiki>
<nowiki># GSSAPI options</nowiki>
<nowiki>#GSSAPIAuthentication no</nowiki>
<nowiki>#GSSAPICleanupCredentials yes</nowiki>
<nowiki># Cipher selection</nowiki>
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
<nowiki>#UseLogin no</nowiki>
<nowiki>#MaxStartups 10:30:60</nowiki>
<nowiki>#Banner /etc/issue.net</nowiki>
<nowiki># Allow client to pass locale environment variables</nowiki>
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
<nowiki># Set this to 'yes' to enable PAM authentication, account processing,</nowiki>
<nowiki># and session processing. If this is enabled, PAM authentication will</nowiki>
<nowiki># be allowed through the ChallengeResponseAuthentication and</nowiki>
<nowiki># PasswordAuthentication. </nowiki> Depending on your PAM configuration,
<nowiki># PAM authentication via ChallengeResponseAuthentication may bypass</nowiki>
<nowiki># the setting of "PermitRootLogin without-password".</nowiki>
<nowiki># If you just want the PAM account and session checks to run without</nowiki>
<nowiki># PAM authentication, then enable this but set PasswordAuthentication</nowiki>
<nowiki># and ChallengeResponseAuthentication to 'no'.</nowiki>
UsePAM yes


==== Tested with Version ====
== Vergleich: AES und 3DES ==
* OpenSSH 6.0p1 (Debian wheezy)


==== Settings ====
= IDEA =
Listing 12. Important OpenSSH 6.0 security settings
=== Familie der Blockchiffrierung ===
<nowiki># Package generated configuration file</nowiki>
* jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
<nowiki># See the sshd_config(5) manpage for details</nowiki>
* Basiert auf einer Mischung 3 mathematischen Funktionen
<nowiki># What ports, IPs and protocols we listen for</nowiki>
* die jeweils auf 16 Bit Blöcke des Testes angewandt werden.
Port 22
* Neben XOR kommt die Addition modulo 2^16 und die Multiplikation modulo 2^16+1 zum Einsatz
<nowiki># Use these options to restrict which interfaces/protocols sshd will bind to</nowiki>
* Alle 3 Operationen werden zu einem recht komplizierten Netzwerk verknüpft, das 8 Runden durchlaufen wird
<nowiki>#ListenAddress ::</nowiki>
* Trotz komplizierter Verfahren, schneller und sicherer als DES
<nowiki>#ListenAddress 0.0.0.0</nowiki>
Protocol 2
<nowiki># HostKeys for protocol version 2</nowiki>
HostKey /etc/ssh/ssh_host_rsa_key
<nowiki>#HostKey /etc/ssh/ssh_host_dsa_key</nowiki>
<nowiki>#HostKey /etc/ssh/ssh_host_ecdsa_key</nowiki>
<nowiki>#Privilege Separation is turned on for security</nowiki>
UsePrivilegeSeparation yes
<nowiki># Lifetime and size of ephemeral version 1 server key</nowiki>
KeyRegenerationInterval 3600
ServerKeyBits 768
<nowiki># Logging</nowiki>
SyslogFacility AUTH
LogLevel INFO
<nowiki># Authentication:</nowiki>
LoginGraceTime 120
PermitRootLogin no # or 'without-password' to allow SSH key based login
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
<nowiki>#AuthorizedKeysFile </nowiki>    %h/.ssh/authorized_keys
<nowiki># Don't read the user's ~/.rhosts and ~/.shosts files</nowiki>
IgnoreRhosts yes
<nowiki># For this to work you will also need host keys in /etc/ssh_known_hosts</nowiki>
RhostsRSAAuthentication no
<nowiki># similar for protocol version 2</nowiki>
HostbasedAuthentication no
<nowiki># Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication</nowiki>
<nowiki>#IgnoreUserKnownHosts yes</nowiki>
<nowiki># To enable empty passwords, change to yes (NOT RECOMMENDED)</nowiki>
PermitEmptyPasswords no
<nowiki># Change to yes to enable challenge-response passwords (beware issues with</nowiki>
<nowiki># some PAM modules and threads)</nowiki>
ChallengeResponseAuthentication no
<nowiki># Change to no to disable tunnelled clear text passwords</nowiki>
<nowiki>#PasswordAuthentication yes</nowiki>
<nowiki># Kerberos options</nowiki>
<nowiki>#KerberosAuthentication no</nowiki>
<nowiki>#KerberosGetAFSToken no</nowiki>
<nowiki>#KerberosOrLocalPasswd yes</nowiki>
<nowiki>#KerberosTicketCleanup yes</nowiki>
<nowiki># GSSAPI options</nowiki>
<nowiki>#GSSAPIAuthentication no</nowiki>
<nowiki>#GSSAPICleanupCredentials yes</nowiki>
<nowiki># Cipher selection</nowiki>
Ciphers aes256-ctr,aes128-ctr
MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
<nowiki>#UseLogin no</nowiki>
<nowiki>#MaxStartups 10:30:60</nowiki>
<nowiki>#Banner /etc/issue.net</nowiki>
<nowiki># Allow client to pass locale environment variables</nowiki>
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
<nowiki># Set this to 'yes' to enable PAM authentication, account processing,</nowiki>
<nowiki># and session processing. If this is enabled, PAM authentication will</nowiki>
<nowiki># be allowed through the ChallengeResponseAuthentication and</nowiki>
<nowiki># PasswordAuthentication. </nowiki> Depending on your PAM configuration,
<nowiki># PAM authentication via ChallengeResponseAuthentication may bypass</nowiki>
<nowiki># the setting of "PermitRootLogin without-password".</nowiki>
<nowiki># If you just want the PAM account and session checks to run without</nowiki>
<nowiki># PAM authentication, then enable this but set PasswordAuthentication</nowiki>
<nowiki># and ChallengeResponseAuthentication to 'no'.</nowiki>
UsePAM yes


{| style="border-spacing:0;width:17cm;"
== Hybride Kryptografieverfahren ==
|- style="border:none;padding:0.049cm;"
||
|| Older '''Linux''' systems won’t support SHA2. PuTTY (Windows) does not support RIPE-MD160. Curve25519, AES-GCM and UMAC are only available upstream (OpenSSH 6.6p1). DSA host keys have been removed on purpose, the DSS standard does not support for DSA keys stronger than 1024bit [[https://bettercrypto.org/#_footnotedef_5 5]] which is far below current standards (see section #section:keylengths). Legacy systems can use this configuration and simply omit unsupported ciphers, key exchange algorithms and MACs.
|-
|}


==== References ====
=== Vorteile aus asymmetrischen und symmetrischen Kryptografie  ===
The OpenSSH [https://www.openssh.org/cgi-bin/man.cgi?query=sshd_config sshd_config — OpenSSH SSH daemon configuration file] man page is the best reference:
* 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


==== How to test ====
== Vergleich Klassisch - Modern ==
Connect a client with verbose logging enabled to the SSH server
$ ssh -vvv myserver.com
and observe the key exchange in the output.


=== Cisco ASA ===
=== 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)


==== Tested with Versions ====
== Fazit ==
* 9.1(3)


==== Settings ====
=== Die Geschichte der Kryptografie ist ein Wettbewerb  ===
crypto key generate rsa modulus 2048
* zwischen Kryptografiespezialisten und Kryptoanalysten
ssh version 2
* Momentan liegen die Verschlüssler mit dem IDEA vorne
ssh key-exchange group dh-group14-sha1
* 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


{| style="border-spacing:0;width:17cm;"
= TMP =
|- style="border:none;padding:0.049cm;"
=== 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.
|| When the ASA is configured for SSH, by default both SSH versions 1 and 2 are allowed. In addition to that, only a group1 DH-key-exchange is used. This should be changed to allow only SSH version 2 and to use a key-exchange with group14. The generated RSA key should be 2048 bit (the actual supported maximum). A non-cryptographic best practice is to reconfigure the lines to only allow SSH-logins.
* — 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.


==== References ====
; 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.
[https://www.cisco.com/en/US/docs/security/asa/asa91/configuration/general/admin_management.html CLI Book 1: Cisco ASA Series General Operations CLI Configuration Guide, 9.1]


==== How to test ====
== Introduction ==
Connect a client with verbose logging enabled to the SSH server
=== Audience ===
$ ssh -vvv myserver.com
Sysadmins. Sysadmins. Sysadmins. They are a force-multiplier.
and observe the key exchange in the output.


=== Cisco IOS ===
=== Related publications ===
* 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.


==== Tested with Versions ====
=== How to read this guide ===
Table 3. Tested Myservice Versions
* 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.


{| style="border-spacing:0;width:9.259cm;"
=== Disclaimer ===
|- style="border:none;padding:0.049cm;"
* A chain is no stronger than its weakest link, and life is after all a chain.
|| Program Version
* — William James
|| OS/Distribution/Version
*  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.
|| Comment
* — Edward Snowden ''answering questions live on the Guardian’s website''
|- style="border:none;padding:0.049cm;"
* 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.
|| 15.0
* 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]]) ].
|| IOS
* 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]).
|- style="border:none;padding:0.049cm;"
* 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.
|| 15.1
*  Security is a process, not a product.
|| IOS
* — 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.
|- style="border:none;padding:0.049cm;"
* We therefore recommend that system administrators keep up to date with recent topics in IT security and cryptography.
|| 15.2
* 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.
|| IOS
||
|-
|}


==== Settings ====
==== Scope ====
crypto key generate rsa modulus 4096 label SSH-KEYS
In this guide, we restricted ourselves to:* Internet-facing services
ip ssh rsa keypair-name SSH-KEYS
* Commonly used services
ip ssh version 2
* Devices which are used in business environments (this specifically excludes XBoxes, Playstations and similar consumer devices)
ip ssh dh min size 2048
* OpenSSL
line vty 0 15
We explicitly excluded:* Specialized systems such as medical devices, most embedded systems, industrial control systems (ICS), etc.
transport input ssh
* Wireless Access Points
 
* Smart-cards/chip cards
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
||
|| Same as with the ASA, also on IOS by default both SSH versions 1 and 2 are allowed and the DH-key-exchange only use a DH-group of 768 Bit. In IOS, a dedicated Key-pair can be bound to SSH to reduce the usage of individual keys-pairs. From IOS Version 15.0 onwards, 4096 Bit rsa keys are supported and should be used according to the paradigm "use longest supported key". Also, do not forget to disable telnet vty access.
|-
|}


==== References ====
=== Methods ===
[https://www.cisco.com/c/en/us/support/docs/security-vpn/secure-shell-ssh/4145-ssh.html Cisco SSH]
#  C.O.S.H.E.R - completely open source, headers, engineering and research.
# — A. Kaplan ''His mail signature for many years''
# 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.
# 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].
# 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.
# 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]].
# 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.


{| style="border-spacing:0;width:17cm;"
== Appendix ==
|- style="border:none;padding:0.049cm;"
=== Links ===
||
# [https://www.iana.org/assignments/tls-parameters/tls-parameters.txt IANA official list of Transport Layer Security (TLS) Parameters]
|| This guide is a basic SSH reference for all routers and switches. Pleaes refer to the specific documentation of the device and IOS version that you are configuring.
# [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]


==== How to test ====
=== Suggested Reading ===
Connect a client with verbose logging enabled to the SSH server
# This section contains suggested reading material.
$ ssh -vvv switch.example.net
# Cryptography Engineering: Design Principles and Practical Applications, Ferguson, N. and Schneier, B. and Kohno, T. (ISBN-13: 978-0470474242)
and observe the key exchange in the output.
# Security Engineering: A Guide to Building Dependable Distributed Systems, Anderson, R.J. (ISBN-13: 978-0470068526)
# Applied cryptography: protocols, algorithms, and source code in C, Schneier, B. (ISBN-13: 978-0471117094)
# Guide to Elliptic Curve Cryptography, Hankerson, D. and Vanstone, S. and Menezes, A.J. (ISBN-13: 978-0387952734)
# A Introduction To The Theory of Numbers, Godfrey Harold Hardy, E. M. Wrigh (ISBN-13: 978-0199219865)
# Malicious Cryptography: Exposing Cryptovirology, Young A., Yung, M. (ISBN-13: 978-0764549755)


== Mailservers ==
=== Further Research ===
This section documents the most common mail servers. Mail servers may usually be grouped into three categories:* Mail Submission Agent (MSA)
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.
* Mail Transfer Agent (MTA) / Mail Exchanger (MX)
* Mail Delivery Agent (MDA)
An email client (mail user agent, MUA) submits mail to the MSA. This is usually been done using the Simple Mail Transfer Protocol (SMTP). Afterwards, the mail is transmitted by the MTA over the Internet to the MTA of the receiver. This happens again via SMTP. Finally, the mail client of the receiver will fetch mail from an MDA usually via the Internet Message Access Protocol (IMAP) or the Post Office Protocol (POP).
As MSAs and MTAs both use SMTP as transfer protocols, both functionalities may often be implemented with the same software. On the other hand, MDA software might or might not implement both IMAP and POP.


=== TLS usage in mail server protocols ===
; Further Protocols
Email protocols support TLS in two different ways. It may be added as a protocol wrapper on a different port. This method is referred to as Implicit TLS or as protocol variants SMTPS, IMAPS and POP3S. The other method is to establish a cleartext session first and switch to TLS afterwards by issuing the STARTTLS command.
{| style="border-spacing:0;width:14.018cm;"
SMTP between MTAs usually makes use of opportunistic TLS. This means that an MTA will accept TLS connections when asked for it but will not require it. MTAs should always try opportunistic TLS handshakes outgoing and always accept incoming opportunistic TLS.
 
=== Recommended configuration ===
We recommend to use the following settings for Mail Transfer Agents:* correctly setup MX, A and PTR RRs without using CNAMEs at all
* the hostname used as HELO/EHLO in outgoing mail shall match the PTR RR
* enable opportunistic TLS, using the STARTTLS mechanism on port 25
* Implicit TLS on port 465 may be offered additionally
* use server and client certificates (most server certificates are client certificates as well)
* either the common name or at least an alternate subject name of the certificate shall match the PTR RR (client mode) or the MX RR (server mode)
* do not use self signed certificates
* accept all cipher suites, as the alternative would be to fall back to cleartext transmission
* an execption to the last sentence is that MTAs '''MUST NOT''' enable SSLv2 protocol support, due to the [https://drownattack.com/drown-attack-paper.pdf DROWN attack].
For MSA operation we recommend:* listen on submission port 587 with mandatory STARTTLS
* optionally listen on port 465 with Implicit TLS
* enforce SMTP AUTH even for local networks
* ensure that SMTP AUTH is not allowed on unencrypted connections
* only use the recommended cipher suites if all connecting MUAs support them
For MDA operation we recommend:* listen on the protocol port (143 for IMAP, 110 for POP3) with mandatory STARTTLS
* optionally listen on Implicit TLS ports (993 for IMAPS, 995 for POP3S)
* enforce authentication even for local networks
* make sure that authentication is not allowed on unencrypted connections
* use the recommended cipher suites if all connecting MUAs support them
* turn off SSLv2 (see: [https://drownattack.com/drown-attack-paper.pdf DROWN attack])
 
=== Dovecot ===
 
==== Tested with Versions ====
Table 4. Tested Dovecot Versions
 
{| style="border-spacing:0;width:15.84cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
|| DNSSec (mention BCPs)
! align=center| OS/Distribution/Version
|| DANE
! align=center| Comment
|| Tor
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| 2.1.7
|| S/Mime (check are there any BCPs? )
|| Debian Wheezy
|| TrueCrypt, LUKS, FileVault
|| without <tt>ssl_prefer_server_ciphers</tt>
|| AFS
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| 2.2.9
|| Kerberos
|| Debian Jessie
|| NNTP
||
|| NTPs tlsdate
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| 2.2.13
|| Moxa , APC, und co…​ ICS
|| Debian 8.2 Jessie
||
||
|- style="border:none;padding:0.049cm;"
|| 2.0.19apple1
|| OS X Server 10.8.5
|| without <tt>ssl_prefer_server_ciphers</tt>
|- style="border:none;padding:0.049cm;"
|| 2.2.9
|| Ubuntu 14.04 Trusty
||
||
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| 2.2.31
|| rsyslog
|| Ubuntu 16.04.3 LTS
|| tftp
||
|| (s)ftp(s)
|-
|}
 
==== Settings ====
Listing 13. Dovecot SSL Configuration
<nowiki># SSL protocols to use, disable SSL, use TLS only</nowiki>
ssl_protocols = !SSLv3 !SSLv2
<nowiki># SSL ciphers to use</nowiki>
ssl_cipher_list = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
<nowiki># Prefer the server's order of ciphers over client's. (Dovecot >=2.2.6 Required)</nowiki>
ssl_prefer_server_ciphers = yes
<nowiki># Diffie-Hellman parameters length (Default is 1024, Dovecot >=2.2.7 Required)</nowiki>
<nowiki># ToDo: for ReGenerating DH-Parameters:</nowiki>
<nowiki># manually delete /var/lib/dovecot/ssl-parameters.dat and restart</nowiki>
<nowiki># Dovecot to regenerate /var/lib/dovecot/ssl-parameters.dat</nowiki>
ssl_dh_parameters_length = 2048
<nowiki># Disable Compression (Dovecot >= 2.2.14 Required)</nowiki>
<nowiki># ssl_options = no_compression</nowiki>
 
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
||
|| haproxy
|| Dovecot 2.0, 2.1: Almost as good as dovecot 2.2. Dovecot does not ignore unknown configuration parameters. Does not support <tt>ssl_prefer_server_ciphers</tt>.
|-
|}
 
==== Limitations ====
* Dovecot <2.2.14 does not support disabling TLS compression.In >2.2.14 [[https://bettercrypto.org/#_footnotedef_6 6]] use: <tt>ssl_options = no_compression</tt>
* Dovecot <2.2.7 uses fixed DH parameters.In >2.2.7 [[https://bettercrypto.org/#_footnotedef_7 7]] greater DH-Parameters are supported: <tt>ssl_dh_parameters_length = 2048</tt>.
 
==== References ====
* [https://wiki2.dovecot.org/SSL https://wiki2.dovecot.org/SSL]
 
==== How to test ====
$ openssl s_client -crlf -connect example.com:993
$ openssl s_client -crlf -connect example.com:995
$ openssl s_client -crlf -starttls imap -connect example.com:143
$ openssl s_client -crlf -starttls pop3 -connect example.com:110
[https://github.com/nabla-c0d3/sslyze/releases SSLyze] offers scanning for common vulnerabilities and displays Protocols and Cipher-Suites.
$ sslyze.exe --regular example.com:993
$ sslyze.exe --regular example.com:995
$ sslyze.exe --regular --starttls=imap example.com:143
$ sslyze.exe --regular --starttls=pop3 example.com:110
 
=== cyrus-imapd ===
 
==== Tested with Versions ====
Table 5. Tested cyrus-imapd Versions
 
{| style="border-spacing:0;width:9.878cm;"
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
! align=center| OS/Distribution/Version
! align=center| Comment
|- style="border:none;padding:0.049cm;"
|| 2.4.17
||
||
||
||
Zeile 882: Zeile 499:
|}
|}


==== Settings ====
; Further Protocols (Network centric)
To activate SSL/TLS configure your certificate with
{| style="border-spacing:0;width:9.917cm;"
Listing 14. Activating TLS in cyrus
tls_cert_file: /etc/ssl/certs/ssl-cert-snakeoil.pem
tls_key_file: /etc/ssl/private/ssl-cert-snakeoil.key
Do not forget to add necessary intermediate certificates to the .pem file.
Limiting the ciphers provided may force (especially older) clients to connect without encryption at all! Sticking to the defaults is recommended.
If you still want to force strong encryption use
Listing 15. TLS cipher selection in cyrus
tls_cipher_list: EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
cyrus-imapd loads hardcoded 1024 bit DH parameters using get_rfc2409_prime_1024() by default. If you want to load your own DH parameters add them PEM encoded to the certificate file given in tls_cert_file. Do not forget to re-add them after updating your certificate.
To prevent unencrypted connections on the STARTTLS ports you can set
Listing 16. Force encrypted connections in cyrus
allowplaintext: no
This way MUAs can only authenticate with plain text authentication schemes after issuing the STARTTLS command. Providing CRAM-MD5 or DIGEST-MD5 methods is not recommended.
To support POP3/IMAP on ports 110/143 with STARTTLS and POP3S/IMAPS on ports 995/993 check the SERVICES section in ''cyrus.conf''
Listing 17. STARTTLS for POP3/IMAP and POP3S/IMAPS in cyrus
SERVICES {
    imap  cmd="imapd -U 30"    listen="imap"  prefork=0 maxchild=100
    imaps cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100
    pop3  cmd="pop3d -U 30"    listen="pop3"  prefork=0 maxchild=50
    pop3s cmd="pop3d -s -U 30" listen="pop3s" prefork=0 maxchild=50
}
 
==== Limitations ====
cyrus-imapd currently (2.4.17, trunk) does not support elliptic curve cryptography. Hence, ECDHE will not work even if defined in your cipher list.
Currently there is no way to prefer server ciphers or to disable compression.
There is a working [https://bugzilla.cyrusimap.org/show_bug.cgi?id=3823 patch] for all three features.
 
==== How to test ====
$ openssl s_client -crlf -connect example.com:993
 
=== Postfix ===
 
==== Tested with Versions ====
Table 6. Tested Postfix Versions
 
{| style="border-spacing:0;width:11.739cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
|| IPv6 security
! align=center| OS/Distribution/Version
! align=center| Comment
|- style="border:none;padding:0.049cm;"
|| 2.9.6
|| Debian Wheezy
|| with OpenSSL 1.0.1e
|- style="border:none;padding:0.049cm;"
|| 2.11.0
|| Ubuntu 14.04.02
|| with OpenSSL 1.0.1f
|- style="border:none;padding:0.049cm;"
|| 3.1.0
|| Ubuntu 16.04.3 LTS
||
||
|-
|}
==== Settings ====
Postfix has five internal lists of ciphers, and the possibility to switch between those with <tt>smtpd_tls_ciphers</tt>. However, we leave this at its default value for server to server connections, as many mail servers only support outdated protocols and ciphers. We consider bad encryption still better than plain text transmission. For connections to MUAs, TLS is mandatory and the ciphersuite is modified.
===== MX and SMTP client configuration: =====
As discussed in section [https://bettercrypto.org/#smtp_general [smtp_general]], because of opportunistic encryption we do not restrict the list of ciphers or protocols for communication with other mail servers to avoid transmission in plain text. There are still some steps needed to enable TLS, all in ''main.cf'':
Listing 18. Opportunistic TLS in Postfix
<nowiki># TLS parameters</nowiki>
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
<nowiki># log TLS connection info</nowiki>
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1
<nowiki># enable opportunistic TLS support in the SMTP server and client</nowiki>
smtpd_tls_security_level = may
smtp_tls_security_level = may
<nowiki># if you have authentication enabled, only offer it after STARTTLS</nowiki>
smtpd_tls_auth_only = yes
tls_ssl_options = NO_COMPRESSION
===== MSA: =====
For the MSA <tt>smtpd</tt> process which communicates with mail clients, we first define the ciphers that are acceptable for the “mandatory” security level, again in ''main.cf'':
Listing 19. MSA TLS configuration in Postfix
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
lmtp_tls_mandatory_protocols = !SSLv2, !SSLv3
lmtp_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
Then, we configure the MSA smtpd in ''master.cf'' with two additional options that are only used for this instance of smtpd:
Listing 20. MSA smtpd service configuration in Postfix
<nowiki># ==========================================================================</nowiki>
<nowiki># service type </nowiki> private unpriv  chroot  wakeup  maxproc command + args
<nowiki># </nowiki>              (yes)  (yes)  (no)    (never) (100)
<nowiki># ==========================================================================</nowiki>
<nowiki># ...</nowiki>
submission inet n      -      -      -      -      smtpd
    -o smtpd_tls_security_level=encrypt
    -o tls_preempt_cipherlist=yes
<nowiki># ...</nowiki>
For those users who want to use EECDH key exchange, it is possible to customize this via: The default value since Postfix 2.8 is “strong”.
Listing 21. EECDH customization in Postfix
smtpd_tls_eecdh_grade = ultra
==== Limitations ====
<tt>tls_ssl_options</tt> is supported from Postfix 2.11 onwards. You can leave the statement in the configuration for older versions, it will be ignored.
<tt>tls_preempt_cipherlist</tt> is supported from Postfix 2.8 onwards. Again, you can leave the statement in for older versions.
==== References ====
* Refer to [https://www.postfix.org/TLS_README.html https://www.postfix.org/TLS_README.html] for an in-depth discussion.
==== Additional settings ====
Postfix has two sets of built-in DH parameters that can be overridden with the <tt>smtpd_tls_dh512_param_file</tt> and <tt>smtpd_tls_dh1024_param_file</tt> options. The “dh512” parameters are used for export ciphers, while the “dh1024” ones are used for all other ciphers.
The “bit length” in those parameter names is just a name, so one could use stronger parameter sets; it should be possible to e.g. use the IKE Group14 parameters (see section [https://bettercrypto.org/#DH [DH]] without much interoperability risk, but we have not tested this yet.
==== How to test ====
You can check the effect of the settings with the following command:
$ zegrep "TLS connection established from.*with cipher" /var/log/mail.log | awk '{printf("%s %s %s %s\n", $12, $13, $14, $15)}' | sort | uniq -c | sort -n
      1 SSLv3 with cipher DHE-RSA-AES256-SHA
    23 TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384
    60 TLSv1 with cipher ECDHE-RSA-AES256-SHA
    270 TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
    335 TLSv1 with cipher DHE-RSA-AES256-SHA
$ openssl s_client -starttls smtp -crlf -connect example.com:25
=== Exim ===
==== Tested with Versions ====
Table 7. Tested Exim Versions
{| style="border-spacing:0;width:11.739cm;"
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
! align=center| OS/Distribution/Version
! align=center| Comment
|- style="border:none;padding:0.049cm;"
|| 4.82
|| Debian Jessie
||
||
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| 4.82
|| Wi-Fi, 802.1x
|| Ubuntu 14.04.2
|| SIP
|| with OpenSSL 1.0.1e
|| SRTP
|-
|}
It is highly recommended to read [https://exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html Encrypted SMTP connections using TLS/SSL] first.
 
===== MSA mode (submission): =====
In the main config section of Exim add:
Listing 22. Certificate selection in Exim (MSA)
tls_certificate = /etc/ssl/exim.crt
tls_privatekey = /etc/ssl/exim.pem
Don’t forget to add intermediate certificates to the .pem file if needed.
Tell Exim to advertise STARTTLS in the EHLO answer to everyone:
Listing 23. TLS advertise in Exim (MSA)
tls_advertise_hosts = *
If you want to support legacy SMTPS on port 465, and STARTTLS on smtp(25)/submission(587) ports set
Listing 24. STARTTLS and SMTPS in Exim (MSA)
daemon_smtp_ports = smtp : smtps : submission
tls_on_connect_ports = 465
It is highly recommended to limit SMTP AUTH to SSL connections only. To do so add
Listing 25. SSL-only authentication in Exim (MSA)
server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
to every authenticator defined.
Add the following rules on top of your acl_smtp_mail:
Listing 26. Submission mode in Exim (MSA)
acl_smtp_mail = acl_check_mail
acl_check_mail:
  warn hosts = *
    control = submission/sender_retain
  accept
This switches Exim to submission mode and allows addition of missing “Message-ID” and “Date” headers.
It is not advisable to restrict the default cipher list for MSA mode if you don’t know all connecting MUAs. If you still want to define one please consult the Exim documentation or ask on the exim-users mailinglist.
The cipher used is written to the logfiles by default. You may want to add
log_selector = <whatever your log_selector already contains> +tls_certificate_verified +tls_peerdn +tls_sni
to get even more TLS information logged.
 
===== Server mode (incoming): =====
In the main config section of Exim add:
Listing 27. Certificate selection in Exim (Server)
tls_certificate = /etc/ssl/exim.crt
tls_privatekey = /etc/ssl/exim.pem
Don’t forget to add intermediate certificates to the .pem file if needed.
Tell Exim to advertise STARTTLS in the EHLO answer to everyone:
Listing 28. TLS advertise in Exim (Server)
tls_advertise_hosts = *
Listen on smtp(25) port only:
Listing 29. STARTTLS on SMTP in Exim (Server)
daemon_smtp_ports = smtp
It is not advisable to restrict the default cipher list for opportunistic encryption as used by SMTP. Do not use cipher lists recommended for HTTPS! If you still want to define one please consult the Exim documentation or ask on the exim-users mailinglist.
If you want to request and verify client certificates from sending hosts set
Listing 30. TLS certificate verification in Exim (Server)
tls_verify_certificates = /etc/pki/tls/certs/ca-bundle.crt
tls_try_verify_hosts = *
<tt>tls_try_verify_hosts</tt> only reports the result to your logfile. If you want to disconnect such clients you have to use
tls_verify_hosts = *
The cipher used is written to the logfiles by default. You may want to add
log_selector = <whatever your log_selector already contains> +tls_certificate_verified +tls_peerdn +tls_sni
to get even more TLS information logged.
 
===== Client mode (outgoing): =====
Exim uses opportunistic encryption in the SMTP transport by default.
Client mode settings have to be done in the configuration section of the smtp transport (<tt>driver = smtp</tt>).
If you want to use a client certificate (most server certificates can be used as client certificate, too) set
Listing 31. Certificate selection in Exim (Client)
tls_certificate = /etc/ssl/exim.crt
tls_privatekey = /etc/ssl/exim.pem
This is recommended for MTA-MTA traffic.
Do not limit ciphers without a very good reason. In the worst case you end up without encryption at all instead of some weak encryption. Please consult the Exim documentation if you really need to define ciphers.
 
===== OpenSSL: =====
Exim already disables SSLv2 by default. We recommend to add
openssl_options = +all +no_sslv2 +no_sslv3 +no_compression +cipher_server_preference
to the main configuration.
 
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
||
|| Kerberos
|| <tt>+all</tt> is misleading here since OpenSSL only activates the most common workarounds. But that’s how <tt>SSL_OP_ALL</tt> is defined.
|| NNTP
|-
|| NTPs tlsdate
|}
You do not need to set dh_parameters. Exim with OpenSSL by default uses parameter initialization with the “2048-bit MODP Group with 224-bit Prime Order Subgroup” defined in section 2.2 of RFC 5114&nbsp;(ike23). If you want to set your own DH parameters please read the TLS documentation of exim.
 
===== GnuTLS: =====
GnuTLS is different in only some respects to OpenSSL:* <tt>tls_require_ciphers</tt> needs a GnuTLS priority string instead of a cipher list. It is recommended to use the defaults by not defining this option. It highly depends on the version of GnuTLS used. Therefore it is not advisable to change the defaults.
* There is no option like <tt>openssl_options</tt>
 
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
||
|| BGP / OSPF
|| Exim string expansion
|| LDAP
Most of the options accept expansion strings. This way you can e.g. set cipher lists or STARTTLS advertisement conditionally. Please follow the link to the official Exim documentation to get more information.
|| seclayer-tcp
|-
|}
 
===== Limitations: =====
Exim currently (4.82) does not support elliptic curves with OpenSSL. This means that ECDHE is not used even if defined in your cipher list. There already is a working [https://bugs.exim.org/show_bug.cgi?id=1397 patch] to provide support.
 
==== How to test ====
$ openssl s_client -starttls smtp -crlf -connect example.com:25
 
=== Cisco ESA/IronPort ===
 
==== Tested with Versions ====
Table 8. Tested Cisco ESA/IronPort Versions
 
{| style="border-spacing:0;width:9.878cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
|| RADIUS (RADSEC)
! align=center| OS/Distribution/Version
|| racoon
! align=center| Comment
|| strongswan
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| l2tp
||
||
|| AsyncOS 7.6.1
||
||
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
||
|| Ethernet to serial
|| AsyncOS 8.5.6
|| DSL modems
||
||
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| UPnP, natPmp
||
||
|| AsyncOS 9.0.0
||
||
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| HTTP Key Pinning (HTKP)
||
||
|| AsyncOS 9.5.0
||
|- style="border:none;padding:0.049cm;"
||
|| AsyncOS 9.6.0
||
||
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| Monitoring: SNMPv3
||
||
|| AsyncOS 9.7.0
||
||
|-
|-
|}
|}


==== Settings ====
; Further Applications
Import your certificate(s) using the WEBUI (Network → Certificates).
{| style="border-spacing:0;width:7.853cm;"
From AsyncOS 9.0 and up, SSL parameters for inbound SMTP, outbound SMTP and GUI access can be configured in one step via the WEBUI (System Administration → SSL Configuration, see figure [https://bettercrypto.org/#ach_ironport_ssl_settings IronPort Default SSL Settings]). For all versions prior to 9.0, you have to connect to the CLI and configure the SSL parameters separately, as shown below using inbound SMTP as example.
ironport.example.com> sslconfig
sslconfig settings:
  GUI HTTPS method:  sslv3tlsv1
  GUI HTTPS ciphers: RC4-SHA:RC4-MD5:ALL
  Inbound SMTP method:  sslv3tlsv1
  Inbound SMTP ciphers: RC4-SHA:RC4-MD5:ALL
  Outbound SMTP method:  sslv3tlsv1
  Outbound SMTP ciphers: RC4-SHA:RC4-MD5:ALL
Choose the operation you want to perform:
- GUI - Edit GUI HTTPS ssl settings.
- INBOUND - Edit Inbound SMTP ssl settings.
- OUTBOUND - Edit Outbound SMTP ssl settings.
- VERIFY - Verify and show ssl cipher list.
[]> inbound
Enter the inbound SMTP ssl method you want to use.
1. SSL v2.
2. SSL v3
3. TLS v1
4. SSL v2 and v3
5. SSL v3 and TLS v1
6. SSL v2, v3 and TLS v1
[5]> 3
Enter the inbound SMTP ssl cipher you want to use.
[RC4-SHA:RC4-MD5:ALL]> EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
sslconfig settings:
  GUI HTTPS method:  sslv3tlsv1
  GUI HTTPS ciphers: RC4-SHA:RC4-MD5:ALL
  Inbound SMTP method:  tlsv1
  Inbound SMTP ciphers: 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
  Outbound SMTP method:  sslv3tlsv1
  Outbound SMTP ciphers: RC4-SHA:RC4-MD5:ALL
 
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| Lync
|| Tomcat
||
||
|| Starting with AsyncOS 9.0 SSLv3 is disabled by default, whereas the default cipher set is still <tt>RC4-SHA:RC4-MD5:ALL</tt> (see figure [https://bettercrypto.org/#ach_ironport_ssl_settings IronPort Default SSL Settings]).
|-
|}
[[Image:Bild3.png|top|alt="IronPort Default SSL Settings"]]
Figure 1. IronPort Default SSL Settings
After committing these changes in the CLI, you have to activate the use of TLS in several locations.
For inbound connections, first select the appropriate certificate in the settings of each listener you want to have TLS enabled on (Network → Listeners, see figure [https://bettercrypto.org/#ach_ironport_ssl_settings IronPort Default SSL Settings]). Afterwards, for each listener, configure all Mail Flow Policies which have their Connection Behavior set to “Accept” or “Relay” to at least prefer TLS (Mail Policies → Mail Flow Policies, see figure [https://bettercrypto.org/#ach_ironport_ssl_settings IronPort Default SSL Settings]). It is recommended to also enable TLS in the default Mail Flow Policy, because these settings will be inherited by newly created policies, unless specifically overwritten. + TLS can be enforced by creating a new Mail Flow Policy with TLS set to “required”, creating a new Sender Group defining the addresses of the sending mail servers for which you want to enforce encryption (Mail Policies → HAT Overview) and using this new Sender Group in conjunction with the newly created Mail Flow Policy.
[[Image:Bild4.png|top|alt="IronPort Listener Settings"]]
Figure 2. IronPort Listener Settings
[[Image:Bild5.png|top|alt="IronPort Mail Flow Policy Security Features"]]
Figure 3. IronPort Mail Flow Policy Security Features
TLS settings for outbound connections have to be configured within the Destination Controls (Mail Policies → Destination Controls). Choose the appropriate SSL certificate within the global settings and configure TLS to be preferred in the default profile to enable it for all outbound connections. After these two steps the Destination Control overview page should look like figure [https://bettercrypto.org/#ach_ironport_dest_control IronPort Destination Control overview] on page . To enforce TLS for a specific destination domain, add an entry to the Destination Control Table and set “TLS Support” to “required”.
[[Image:Bild6.png|top|alt="Destination Control overview"]]
Figure 4. IronPort Destination Control overview
==== Limitations ====
All AsyncOS releases prior to version 9.5 use OpenSSL 0.9.8. Therefore TLS 1.2 is not supported in these versions and some of the suggested ciphers won’t work. Starting with AsyncOS 9.5 TLS 1.2 is fully supported. [[https://bettercrypto.org/#_footnotedef_8 8]] You can check the supported ciphers on the CLI by using the option <tt>verify</tt> from within the <tt>sslconfig</tt> command:
[]> verify
Enter the ssl cipher you want to verify.
[]> EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH      Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH      Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH      Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH      Au=RSA  Enc=AES(128)  Mac=SHA1
CAMELLIA128-SHA        SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
==== How to test ====
$ openssl s_client -starttls smtp -crlf -connect example.com:25
== Virtual Private Networks ==
Virtual Private Networks (VPN) provide means of connecting private networks over external / public transport networks. Since we do not control the transport networks we have to to take care about data integrity and privacy.
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
|| Microsoft SQL Server
|| Microsoft Exchange
||
||
|| Some providers also offer VPNs for connecting company networks via MPLS or simular technologies. The provider promises you that nobody else has access to your data trnfserred over their lines. You have to decide if this promise does fit to your information security requirements.
|-
|}
Basically there are two ways to ensure the privacy and integrity of the data sent via external lines. First you could utilize the built-in security of the Internet Protocol (IPsec). The other way are specific applications that encrypt the data before sending it over the line.
IPsec is an Internet standard (TODO RFC 6071). This guarantees the interoperability between implementations of different vendors. You can establish a secure connection with your customer or your supplier. On the other hand VPN applications mostly utilize TLS to secury the communication between the partners.
TODO: Descision criteria IPsec vs. VPN application.
=== IPsec ===
IPsec is the Internet standard to encrypt the transport of data between private networks.
==== Technology ====
We describe only the use the Internet Key Exchange (IKE) version 2 in this dodument. IKEv1 has some usage and security problems and should not be used any more. (TODO: reference).
==== Authentication ====
IPsec authentication should optimally be performed via RSA signatures, with a key size of 2048 bits or more. Configuring only the trusted CA that issued the peer certificate provides for additional protection against fake certificates.
If you need to use Pre-Shared Key (PSK) authentication:* Choose a ''random'', ''long enough'' PSK (see below)
* Use a ''separate'' PSK for any IPsec connection
* Change the PSKs regularly
* Think aboute a ''secure'' way to exchange the PSK. Sending an SMS it ''not'' secure.
The size of the PSK should not be shorter than the output size of the hash algorithm used in IKE.footnote[It is used in a HMAC, see RFC2104&nbsp; and the discussion starting in TODO: verify [http://www.vpnc.org/ietf-ipsec/02.ipsec/msg00268.html http://www.vpnc.org/ietf-ipsec/02.ipsec/msg00268.html].].
For a key composed only of upper- and lowercase letters, numbers, and two additional characters[[https://bettercrypto.org/#_footnotedef_9 9]], table&nbsp;#tab:IPSEC_psk_len gives the minimum lengths in characters.
===== Cryptographic Suites: =====
IPSEC Cryptographic Suites are pre-defined settings for all the items of a configuration; they try to provide a balanced security level and make setting up VPNs easier. [[https://bettercrypto.org/#_footnotedef_10 10]]
When using any of those suites, make sure to enable “Perfect Forward Secrecy“ for Phase 2, as this is not specified in the suites. The equivalents to the recommended ciphers suites in section [https://bettercrypto.org/#recommendedciphers Recommended cipher suites] are shown in table&nbsp;#tab:IPSEC_suites.
===== Phase 1: =====
TODO: Phase 1 and 2 are phrases from IKEv1. Re-write for IKEv2.
Alternatively to the pre-defined cipher suites, you can define your own, as described in this and the next section.
Phase 1 is the mutual authentication and key exchange phase; table&nbsp;#tab:IPSEC_ph1_params shows the parameters.
Use only “main mode“, as “aggressive mode“ has known security vulnerabilities [[https://bettercrypto.org/#_footnotedef_11 11]].
===== Phase 2: =====
Phase 2 is where the parameters that protect the actual data are negotiated; recommended parameters are shown in table #tab:IPSEC_ph2_params.
==== References ====
* Fergusen, N. and Schneier, B.: ''A Cryptographic Evaluation of IPsec'': [https://www.schneier.com/paper-ipsec.pdf https://www.schneier.com/paper-ipsec.pdf]
=== Check Point Next Generation Firewall ===
==== Tested with Versions ====
Table 9. Tested CheckPoint Versions
{| style="border-spacing:0;width:9.878cm;"
|- style="border:none;padding:0.049cm;"
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
|| IBM HTTP Server
! align=center| OS/Distribution/Version
! align=center| Comment
|- style="border:none;padding:0.049cm;"
|| R77
|| Secure Platform
||
||
|-
|}
==== Settings ====
Please see section [https://bettercrypto.org/#IPSECgeneral IPsec] for guidance on parameter choice. In this section, we will configure a strong setup according to ''Configuration A''.
This is based on the concept of a ''VPN Community'', which has all the settings for the gateways that are included in that community. Communities can be found in the <tt>IPSEC VPN</tt> tab of SmartDashboard.
[[Image:Bild7.png|top|alt="VPN Community encryption properties"]]
[https://bettercrypto.org/#fig:checkpoint_1 [fig:checkpoint_1]]
Either choose one of the encryption suites in the properties dialog (figure [https://bettercrypto.org/#checkpoint_1 [checkpoint_1]], or proceed to <tt>Custom Encryption...</tt>, where you can set encryption and hash for Phase 1 and 2 (figure [https://bettercrypto.org/#checkpoint_2 [checkpoint_2]].
[[Image:Bild8.png|top|alt="Custom Encryption Suite Properties"]]
[https://bettercrypto.org/#checkpoint_2 [checkpoint_2]]
The Diffie-Hellman groups and Perfect Forward Secrecy Settings can be found under <tt>Advanced Settings</tt> / <tt>Advanced VPN Properties</tt> (figure [https://bettercrypto.org/#checkpoint_3 [checkpoint_3]].
[[Image:Bild9.png|top|alt="Advanced VPN Properties"]]
[https://bettercrypto.org/#checkpoint_3 [checkpoint_3]]
==== Additional settings ====
For remote Dynamic IP Gateways, the settings are not taken from the community, but set in the <tt>Global Properties</tt> dialog under <tt>Remote Access</tt> / <tt>VPN Authentication and Encryption</tt>. Via the <tt>Edit...</tt> button, you can configure sets of algorithms that all gateways support (figure [https://bettercrypto.org/#checkpoint_4 [checkpoint_4]]).
[[Image:Bild10.png|top|alt="Remote Access Encryption Properties"]]
[https://bettercrypto.org/#checkpoint_4 [checkpoint_4]]
Please note that these settings restrict the available algorithms for ''all'' gateways, and also influence the VPN client connections.
==== References ====
* Check Point [https://sc1.checkpoint.com/documents/R77/CP_R77_VPN_AdminGuide/html_frameset.htm VPN R77 Administration Guide] (may require a UserCenter account to access)
=== TLS Based Applications ===
==== OpenVPN ====
==== Tested with Versions ====
Table 10. Tested OpenVPN Versions
{| style="border-spacing:0;width:14.91cm;"
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
! align=center| OS/Distribution/Version
! align=center| Comment
|- style="border:none;padding:0.049cm;"
|| 2.3.10
|| Ubuntu Xenial 16.04.1 LTS
|| linked against openssl (libssl.so.1.0.0)
|- style="border:none;padding:0.049cm;"
|| 2.3.2
|| Debian Wheezy (backports)
|| linked against openssl (libssl.so.1.0.0)
|- style="border:none;padding:0.049cm;"
|| 2.2.1
|| Debian Wheezy
|| linked against openssl (libssl.so.1.0.0)
|- style="border:none;padding:0.049cm;"
|| 2.3.2
|| Windows
||
||
|-
|-
|}
|}


===== Settings =====
;Commerical Network Equipment Vendors
Other ideas:
* SAML federated auth providers [[https://bettercrypto.org/#_footnotedef_42 42]]
* Elastic Load Balancing (ELB)[[https://bettercrypto.org/#_footnotedef_43 43]]


====== General ======
==== Software not covered by this guide ====
We describe a configuration with certificate-based authentication; see below for details on the <tt>easyrsa</tt> tool to help you with that.
# telnet: Usage of telnet for anything other than fun projects is highly discouraged
OpenVPN uses TLS only for authentication and key exchange. The bulk traffic is then encrypted and authenticated with the OpenVPN protocol using those keys.
# Puppet DB: A Proxy or a tunnel is recommended if it needs to be facing public network interfaces.[[https://bettercrypto.org/#_footnotedef_44 44]]
Note that while the <tt>tls-cipher</tt> option takes a list of ciphers that is then negotiated as usual with TLS, the <tt>cipher</tt> and <tt>auth</tt> options both take a single argument that must match on client and server.
# rsync: Best use it only via SSH for an optimum of security and easiest to maintain.
OpenVPN duplexes the tunnel into a data and a control channel. The control channel is a usual TLS connection, the data channel currently uses encrypt-then-mac CBC, see [https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/91#issuecomment-75365286 https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/91#issuecomment-75365286]


====== Server Configuration ======
=== 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]


====== Client Configuration ======
=== Weblinks ===
Client and server have to use compatible configurations, otherwise they can’t communicate. The <tt>cipher</tt> and <tt>auth</tt> directives have to be identical.
# https://bettercrypto.org/
[[Kategorie:Tmp]]


==== Justification for special settings ====
= Kryptografie =
OpenVPN 2.3.1 changed the values that the <tt>tls-cipher</tt> option expects from OpenSSL to IANA cipher names. That means from that version on you will get ''Deprecated TLS cipher name'' warnings for the configurations above. You cannot use the selection strings from section [https://bettercrypto.org/#recommendedciphers Recommended cipher suites] directly from 2.3.1 on, which is why we give an explicit cipher list here.
In addition, there is a 256 character limit on configuration file line lengths; that limits the size of cipher suites, so we dropped all ECDHE suites.
The configuration shown above is compatible with all tested versions.


==== References ====
== Geheime Kommunikation von Caesar bis 1950 ==
* OpenVPN Documentation: ''Security Overview'' [https://openvpn.net/index.php/open-source/documentation/security-overview.html https://openvpn.net/index.php/open-source/documentation/security-overview.html]


==== Additional settings ====
== Monoalphabetische Substitution Caesar-Chiffre ==


===== Key renegotiation interval =====
== Skytale ==
The default for renegotiation of encryption keys is one hour (<tt>reneg-sec 3600</tt>). If you transfer huge amounts of data over your tunnel, you might consider configuring a shorter interval, or switch to a byte- or packet-based interval (<tt>reneg-bytes</tt> or <tt>reneg-pkts</tt>).


===== Insecure ciphers =====
=== Der Skytale verwendet einen Transpositions-Algorithmus ===
Sweet32[[https://bettercrypto.org/#_footnotedef_12 12]] is an attack on 64-bit block ciphers, such as <tt>3DES</tt> and <tt>Blowfish</tt> in OpenVPN. The following ciphers are affected, and should no longer be used:* BF-*
* DES* (including 3DES variants)
* RC2-*
The following ciphers are not affected:* AES-*
* CAMELLIA-*
* SEED-*
According to mitigation section on Sweet32 website[[https://bettercrypto.org/#_footnotedef_13 13]] users users should change the cipher from the DES or Blowfish to AES (<tt>cipher AES-128-CBC</tt>). If cipher change is not possible users can mitigate the attack by forcing frequent rekeying (<tt>reneg-bytes 64000000</tt>).


===== Fixing “easy-rsa” =====
== Atbash und Rot-13 ==
When installing an OpenVPN server instance, you are probably using <tt>easy-rsa</tt> to generate keys and certificates. The file <tt>vars</tt> in the easyrsa installation directory has a number of settings that should be changed to secure values:
This will enhance the security of the key generation by using RSA keys with a length of 4096 bits, and set a lifetime of one year for the server/client certificates and five years for the CA certificate.


{| style="border-spacing:0;width:17cm;"
=== Bei Atbash wird der erste Buchstabe durch den letzten ausgetauscht ===
|- style="border:none;padding:0.049cm;"
||
|| 4096 bits is only an example of how to do this with easy-rsa. See also section [https://bettercrypto.org/#keylengths Keylengths] for a discussion on keylengths.
|-
|}
In addition, edit the <tt>pkitool</tt> script and replace all occurrences of <tt>sha1</tt> with <tt>sha256</tt>, to sign the certificates with SHA256.


==== Limitations ====
=== Julius Cäsar verwendete das Verfahren Rot-13 ===
Note that the ciphersuites shown by <tt>openvpn --show-tls</tt> are ''known'', but not necessarily ''supported'' [[https://bettercrypto.org/#_footnotedef_14 14]].
Which cipher suite is actually used can be seen in the logs:
<tt>Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 2048 bit RSA</tt>


=== PPTP ===
== Kryptografie mit der Vigenere Tabelle ==
PPTP is considered insecure, Microsoft recommends to _use a more secure VPN tunnel_[[https://bettercrypto.org/#_footnotedef_15 15]].
There is a cloud service that cracks the underlying MS-CHAPv2 authentication protocol for the price of USD&nbsp;200[[https://bettercrypto.org/#_footnotedef_16 16]], and given the resulting MD4 hash, all PPTP traffic for a user can be decrypted.


=== Cisco ASA ===
== Geheime Kommunikation von 1950 bis heute ==
The following settings reflect our recommendations as best as possible on the Cisco ASA platform. These are - of course - just settings regarding SSL/TLS (i.e. Cisco AnyConnect) and IPsec. For further security settings regarding this platform the appropriate Cisco guides should be followed.


==== Tested with Versions ====
= Kryptografie =
Table 11. Tested Cisco ASA Versions
Grundlagen


{| style="border-spacing:0;width:9.878cm;"
== Kryptografie - Terminologie ==
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
! align=center| OS/Distribution/Version
! align=center| Comment
|- style="border:none;padding:0.049cm;"
|| 9.1(3)
|| X-series model
||
|-
|}


==== Settings ====
== Teilbereiche der Kryptografie ==
crypto ipsec ikev2 ipsec-proposal AES-Fallback
protocol esp encryption aes-256 aes-192 aes
protocol esp integrity sha-512 sha-384 sha-256
crypto ipsec ikev2 ipsec-proposal AES-GCM-Fallback
protocol esp encryption aes-gcm-256 aes-gcm-192 aes-gcm
protocol esp integrity sha-512 sha-384 sha-256
crypto ipsec ikev2 ipsec-proposal AES128-GCM
protocol esp encryption aes-gcm
protocol esp integrity sha-512
crypto ipsec ikev2 ipsec-proposal AES192-GCM
protocol esp encryption aes-gcm-192
protocol esp integrity sha-512
crypto ipsec ikev2 ipsec-proposal AES256-GCM
protocol esp encryption aes-gcm-256
protocol esp integrity sha-512
crypto ipsec ikev2 ipsec-proposal AES
protocol esp encryption aes
protocol esp integrity sha-1 md5
crypto ipsec ikev2 ipsec-proposal AES192
protocol esp encryption aes-192
protocol esp integrity sha-1 md5
crypto ipsec ikev2 ipsec-proposal AES256
protocol esp encryption aes-256
protocol esp integrity sha-1 md5
crypto ipsec ikev2 sa-strength-enforcement
crypto ipsec security-association pmtu-aging infinite
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group14
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev2 ipsec-proposal AES256-GCM AES192-GCM AES128-GCM AES-GCM-Fallback AES-Fallback
crypto map Outside-DMZ_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map Outside-DMZ_map interface Outside-DMZ
crypto ikev2 policy 1
encryption aes-gcm-256
integrity null
group 14
prf sha512 sha384 sha256 sha
lifetime seconds 86400
crypto ikev2 policy 2
encryption aes-gcm-256 aes-gcm-192 aes-gcm
integrity null
group 14
prf sha512 sha384 sha256 sha
lifetime seconds 86400
crypto ikev2 policy 3
encryption aes-256 aes-192 aes
integrity sha512 sha384 sha256
group 14
prf sha512 sha384 sha256 sha
lifetime seconds 86400
crypto ikev2 policy 4
encryption aes-256 aes-192 aes
integrity sha512 sha384 sha256 sha
group 14
prf sha512 sha384 sha256 sha
lifetime seconds 86400
crypto ikev2 enable Outside-DMZ client-services port 443
crypto ikev2 remote-access trustpoint ASDM_TrustPoint0
ssl server-version tlsv1-only
ssl client-version tlsv1-only
ssl encryption dhe-aes256-sha1 dhe-aes128-sha1 aes256-sha1 aes128-sha1
ssl trust-point ASDM_TrustPoint0 Outside-DMZ


==== Justification for special settings ====
=== Kryptografie  ===
New IPsec policies have been defined which do not make use of ciphers that may be cause for concern. Policies have a "Fallback" option to support legacy devices.
* Durchführung und Studium Ver- und Entschlüsselung
3DES has been completely disabled as such Windows XP AnyConnect Clients will no longer be able to connect.
* Daten werden mathematisch so kodiert, dass nur ausgewählte Personen die Daten decodieren können
The Cisco ASA platform does not currently support RSA Keys above 2048bits.
* Dazu werden lesbare Daten (Klartext) durch einen mathematischen Algorithmus mit einem geheimen Schlüssel kodiert (Chiffretext)
Legacy ASA models (e.g. 5505, 5510, 5520, 5540, 5550) do not offer the possibility to configure for SHA256/SHA384/SHA512 nor AES-GCM for IKEv2 proposals.
* Ziel ist eine möglichst sichere Kryptografie


==== References ====
=== Kryptoanalyse ===
* [http://www.cisco.com/en/US/docs/security/asa/roadmap/asaroadmap.html http://www.cisco.com/en/US/docs/security/asa/roadmap/asaroadmap.html]
* Hier ist das Ziel eine Kryptografie zu brechen und so
* [http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html]
* Sicherheitslücken zu entdecken


=== Openswan ===
== Das Problem ==


==== Tested with Version ====
=== Nur Bob soll die Nachricht von Alice empfangen können… ===
Table 12. Tested OpenS/WAN Versions


{| style="border-spacing:0;width:9.878cm;"
== Die Lösung ==
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
! align=center| OS/Distribution/Version
! align=center| Comment
|- style="border:none;padding:0.049cm;"
|| 2.6.39
|| Gentoo
||
|-
|}


==== Settings ====
== Klassische Kryptografie ==
* Der Klartext (K) wird mittels eines Schlüssels verschlüsselt.
* Mithilfe desselben Schlüssels kann der Geheimtext (G) wieder entschlüsselt werden.


{| style="border-spacing:0;width:17cm;"
== Kryptografie - Terminologie (II) ==
|- style="border:none;padding:0.049cm;"
||
|| The available algorithms depend on your kernel configuration (when using protostack=netkey) and/or build-time options.
|-
|}
To list the supported algorithms
$ ipsec auto --status | less
and look for ’algorithm ESP/IKE’ at the beginning.
aggrmode=no
<nowiki># ike format: cipher-hash;dhgroup</nowiki>
<nowiki># recommended ciphers:</nowiki>
<nowiki># - aes</nowiki>
<nowiki># recommended hashes:</nowiki>
<nowiki># - sha2_256 with at least 43 byte PSK</nowiki>
<nowiki># - sha2_512 with at least 86 byte PSK</nowiki>
<nowiki># recommended dhgroups:</nowiki>
<nowiki># - modp2048 = DH14</nowiki>
<nowiki># - modp3072 = DH15</nowiki>
<nowiki># - modp4096 = DH16</nowiki>
<nowiki># - modp6144 = DH17</nowiki>
<nowiki># - modp8192 = DH18</nowiki>
ike=aes-sha2_256;modp2048
type=tunnel
phase2=esp
<nowiki># esp format: cipher-hash;dhgroup</nowiki>
<nowiki># recommended ciphers configuration A:</nowiki>
<nowiki># - aes_gcm_c-256 = AES_GCM_16</nowiki>
<nowiki># - aes_ctr-256</nowiki>
<nowiki># - aes_ccm_c-256 = AES_CCM_16</nowiki>
<nowiki># - aes-256</nowiki>
<nowiki># additional ciphers configuration B:</nowiki>
<nowiki># - camellia-256</nowiki>
<nowiki># - aes-128</nowiki>
<nowiki># - camellia-128</nowiki>
<nowiki># recommended hashes configuration A:</nowiki>
<nowiki># - sha2-256</nowiki>
<nowiki># - sha2-384</nowiki>
<nowiki># - sha2-512</nowiki>
<nowiki># - null (only with GCM/CCM ciphers)</nowiki>
<nowiki># additional hashes configuration B:</nowiki>
<nowiki># - sha1</nowiki>
<nowiki># recommended dhgroups: same as above</nowiki>
phase2alg=aes_gcm_c-256-sha2_256;modp2048
salifetime=8h
pfs=yes
auto=ignore


==== How to test ====
== Geheime Übermittlung ==
Start the vpn and using
$ ipsec auto --status | less
and look for ’IKE algorithms wanted/found’ and ’ESP algorithms wanted/loaded’.


==== References ====
=== Voraussetzungen ===
* [https://www.openswan.org/ https://www.openswan.org/]
* 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


=== tinc ===
=== Schwierigkeiten ===
* Schlüssel muss vorher vereinbart werden
* Schlüssel muss geheim bleiben, „geheimer Kanal“
* Das Kryptografieverfahren muss sicher sein


==== Tested with Versions ====
== Vorhängeschloss-Analogie ==
Table 13. Tested tinc Versions
* Der Klartext ist „eingeschlossen“, und nur Alice und Bob haben den richtigen Schlüssel für das Schloss.


{| style="border-spacing:0;width:13.349cm;"
== Kryptographisches Grundprinzip ==
|- style="border:none;padding:0.049cm;"
! align=center| Program Version
! align=center| OS/Distribution/Version
! align=center| Comment
|- style="border:none;padding:0.049cm;"
|| 1.0.23
|| Gentoo
|| linked against OpenSSL 1.0.1e
|- style="border:none;padding:0.049cm;"
|| 1.0.23
|| Sabayon
|| linked against OpenSSL 1.0.1e
|-
|}
 
===== Defaults =====
tinc uses 2048 bit RSA keys, Blowfish-CBC, and SHA1 as default settings and suggests the usage of CBC mode ciphers. Any key length up to 8192 is supported and it does not need to be a power of two. OpenSSL Ciphers and Digests are supported by tinc.
 
===== Settings =====
Generate keys with
$ tincd -n NETNAME -K8192
Old keys will not be deleted (but disabled), you have to delete them manually. Add the following lines to your tinc.conf on all machines
 
===== References =====
* tincd(8) man page
* tinc.conf(5) man page
* [http://www.tinc-vpn.org/pipermail/tinc/2014-January/003538.html tinc mailinglist http://www.tinc-vpn.org/pipermail/tinc/2014-January/003538.html]
 
== PGP/GPG - Pretty Good Privacy ==
The [https://tools.ietf.org/search/rfc4880 OpenPGP protocol] defines a set of asymmetric- and symmetric encryption algorithms, signature methods and compression protocols. [https://gnupg.org/ GnuPG], a FOSS implementation of the OpenPGP standard, is widely used for mail encryption.
GnuPG signs a message, encrypts it symmetrically and encrypts the symmetric key and the hash with Bob’s public key asymmetrically.
Research on SHA-1 conducted back in 2005 (see: [https://www.schneier.com/blog/archives/2005/02/sha1_broken.html SHA-1 Broken]) as well as the first practical successful collision in early 2017 (see: [https://shattered.io/ SHAttered]) has made clear that collision attacks are a real threat to the security of the SHA-1 hash function.
Since SHA-1 is defined as a must implementation by the OpenPGP specification, GnuPG is still using it. Currently settings should be adapted to preferably avoid using SHA-1.
When using GnuPG, there are a couple of things to take care of:* keylengths (see: [https://bettercrypto.org/#keylengths Keylengths])
* randomness (see: [https://bettercrypto.org/#rngs Random Number Generators])
* preference of symmetric encryption algorithm (see: [https://bettercrypto.org/#ciphersuites Architectural overview])
* preference of hash function (see: [https://bettercrypto.org/#ciphersuites Architectural overview])
Properly dealing with key material, passphrases and the web-of-trust is outside of the scope of this document. The [https://www.gnupg.org/ GnuPG website] has a good tutorial on GnuPG.
After 31 December 2017 GnuPG version 2.0.x is no longer supported and [https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000413.html shall not be used anymore]. Use the new long term version 2.1 instead.


=== Hashing ===
=== Umwandlung eines Klartextes  ===
Avoid SHA-1 by preferring better hashing methods. GnuPG. Edit <tt>$HOME/.gnupg/gpg.conf</tt>:
* (p, plain text) in einem chiffrierten Text (c, ciphertext)
Listing 32. Digest selection in GnuPG
* mithilfe einer reversiblen kryptografischen Funktion f:
personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list AES256 CAMELLIA256 AES192 CAMELLIA192 AES CAMELLIA128 TWOFISH SHA512 SHA384 SHA256 BZIP2 ZLIB ZIP


=== Key Generation ===
=== symmetrische und asymmetrische Algorithmen ===
Because of lack of forward secrecy (see: [https://bettercrypto.org/#pfs [pfs]]) in OpenPGP it is preferable to use large asymmetric keys for long term communication protection. A RSA key of <tt>4096</tt> bits should provide enough confidentiality for the next 10 years (see: [https://www.keylength.com/ Cryptographic Key Length Recommendation]).
* Kryptografie / Entschlüsselung
Listing 33. New key generation with GnuPG version 2.1
* Schlüssel als zusätzliches Argument zu Funktion f
$ gpg --batch --full-gen-key $HOME/Desktop/params.txt`
Listing 34. Parameters for key generation with GnuPG version 2.1
Key-Type: RSA
Key-Length: 4096
Subkey-Type: RSA
Subkey-Length: 4096
Name-Real: <your-name>
Name-Email: <your-email-address>
Passphrase: <password>
Expires: 2y
<nowiki># My preferences: AES256, CAMELLIA256, AES192, CAMELLIA192, AES128, CAMELLIA128, TWOFISH, SHA512, SHA384, SHA256, BZIP2, ZLIB and ZIP</nowiki>
Preferences: S9 S13 S8 S12 S7 S11 S10 H10 H9 H8 Z3 Z2 Z1


{| style="border-spacing:0;width:17cm;"
== Verschlüsseln mit symmetrischen Verfahren ==
|- style="border:none;padding:0.049cm;"
||
|| The preferences parameters S9 to Z1 correspond to AES256, CAMELLIA256, AES192, CAMELLIA192, AES, CAMELLIA128, TWOFISH, SHA512, SHA384, SHA256, BZIP2, ZLIB and ZIP. The parameters 3DES, SHA-1 and uncompressed are set automatically by GnuPG.
|-
|}


=== ECC - Elliptic Curve Cryptography ===
=== Kryptografie und Entschlüsselung mit selbem Schlüssel ===
Since the release of [https://www.gnupg.org/faq/whats-new-in-2.1.html GnuPG version 2.1] end-2014 ECC is supported. Older versions though are still widely used therefore ECC is not yet applicable in practice.
* z.&nbsp;B.&nbsp;: DES, IDEA
* Effizient, aber Schlüsselaustauschproblem


== IPMI, ILO and other lights out management solutions ==
== Ver- und Entschlüsselung mit symmetrischer Kryptografie ==
Consider creating an unrouted management VLAN and access that only via VPN.


{| style="border-spacing:0;width:17cm;"
== Man-in-the-Middle ==
|- style="border:none;padding:0.049cm;"
* Der Man-in-the-Middle (Mellory)
||
* schaltet sich zwischen eine Kommunikation
|| We ''strongly'' recommend that any remote management system for servers such as ILO, iDRAC, IPMI based solutions and similar systems ''never'' be connected to the public internet.
* 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


== Instant Messaging Systems ==
== Asymmetrischer Kryptografiepublic key-Kryptografie ==


=== General server configuration recommendations ===
== Asymmetrischer Kryptografiepublic key-Kryptografie ==
For servers, we mostly recommend to apply what’s proposed by the [https://github.com/stpeter/manifesto Peter’s manifesto].
In short:* require the use of TLS for both client-to-server and server-to-server connections
* prefer or require TLS cipher suites that enable forward secrecy
* deploy certificates issued by well-known and widely-deployed certification authorities (CAs)
The last point being out-of-scope for this section, we will only cover the first two points.


=== ejabberd ===
== Public Key Kryptografie ==


==== Tested with Versions ====
=== Ver- und Entschlüsselung mit verschiedenen Schlüsseln ===
* ejabberd 14.12, Debian 7 Wheezy
* “Vergleichbar mit einem Briefkasten - jeder kann etwas hinein werfen, aber nur einer kann es herausnehmen.”
* ejabberd 14.12, Ubuntu 14.04 Trusty
* Schlüssel-Paare: Öffentlicher und privater Schlüssel
* ejabberd 15.03, Ubuntu 14.04 Trusty
* z.&nbsp;B.&nbsp;: RSA, ElGamal, Elliptische Kurven (ECC)
* ejabberd 16.01, Ubuntu 14.04 Trusty
* 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


==== Settings ====
== Transposition vs. Substitution ==
ejabberd is one of the popular Jabber servers. In order to be compliant with the manifesto, you should adapt your configuration:
Listing 35. TLS setup for ejabberd
listen:
    -
        port: 5222
        module: ejabberd_c2s
        certfile: "/path/to/ssl.pem"
        starttls: true
        starttls_required: true
        protocol_options:
            - "no_sslv3"
            - "no_tlsv1"
            - "cipher_server_preference"
        max_stanza_size: 65536
        dhfile: "/path/to/dhparams.pem"
        shaper: c2s_shaper
        access: c2s
    -
        port: 5269
        module: ejabberd_s2s_in
s2s_use_starttls: required_trusted
s2s_certfile: "/path/to/ssl.pem"
s2s_dhfile: "/etc/ejabberd/dhparams.pem" # Available from version 15.03
s2s_protocol_options:
    - "no_sslv3"
    - "no_tlsv1"
    - "cipher_server_preference"


{| style="border-spacing:0;width:5.398cm;"
=== Transposition  ===
|- style="border:none;padding:0.049cm;"
* jeweils 2 aufeinander folgende Buchstaben vertauschen
||
* wodurch sich neue Wörter ergeben
|| Available from version 15.06
* wir auch als Scambling (Verwürfelung) bezeichnet
|-
* Beispiel
|}
* Netz = Enzt
* Einsatzgebiet
* drahtlose Übertragungstechniken


==== Additional settings ====
=== Substitution ===
It is possible to explicitly specify a cipher string for TLS connections.
* Bei der Substitution werden die Buchstaben des Klartextes im Geheimtext durch andere ersetzt
Listing 36. Specifying a cipher order and enforcing it
* Dabei wird jeder Buchstabe durch den ersetzt, der im Alphabet 3 Stellen weiter hinten steht.
listen:
* Cäsar-Addition
    -
* Beispiel
        port: 5222
* Netz = Qhzc
        module: ejabberd_c2s
        certfile: "/path/to/ssl.pem"
        starttls: true
        starttls_required: true
        protocol_options:
            - "no_sslv3"
            - "no_tlsv1"
        - "cipher_server_preference"
        max_stanza_size: 65536
        dhfile: "/path/to/dhparams.pem"
        ciphers: "EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA"
    -
        port: 5269
        module: ejabberd_s2s_in
s2s_use_starttls: required_trusted
s2s_certfile: "/path/to/ssl.pem"
s2s_dhfile: "/etc/ejabberd/dhparams.pem"
s2s_protocol_options:
    - "no_sslv3"
    - "no_tlsv1"
    - "cipher_server_preference"
s2s_ciphers: "EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA"


{| style="border-spacing:0;width:5.398cm;"
== Symmetrische Substitution ==
|- style="border:none;padding:0.049cm;"
||
|| Available from version 15.06
|- style="border:none;padding:0.049cm;"
||
|| Available from version 15.03
|-
|}


{| style="border-spacing:0;width:17cm;"
=== Sender und Empfänger müssen den gleichen Schlüssel besitzen ===
|- style="border:none;padding:0.049cm;"
* um miteinander Kommunizieren zu können
||
* Secret-Key-Verfahren
|| Weak Ciphers
* Eignet sich gut, um große Datenmengen zu verschlüsseln
Note that we are setting the SSL option <tt>cipher_server_preference</tt>. This enforces our cipher order when negotiating which ciphers are used, as the cipher order of [https://blog.thijsalkema.de/blog/2013/09/02/the-state-of-tls-on-xmpp-3/ some clients chooses weak ciphers] over stronger ciphers.
* Nachteil
|-
* Um die Nachricht verwerten zu können, muss der Schlüssel mit übertragen werden
|}
* was einen Schwachpunkt darstellt
Starting with version 15.03[[https://bettercrypto.org/#_footnotedef_17 17]], it is possible to use custom Diffie-Hellman-Parameters. This allows us to negotiate stronger Diffie-Hellman-keys, and also helps us avoid problems with using common [https://weakdh.org/ weak Diffie-Hellman-Parameters]. You can generate your own parameter file by running:
$ openssl dhparam -out dhparams.pem 4096
By default, ejabberd provides an administration website (look for the ejabberd_http module). Enable TLS protection for it like this:
    port: 5280
    module: ejabberd_http
    web_admin: true
    http_poll: true
    http_bind: true
    captcha: true
    certfile: "/path/to/ssl.pem"
    tls: true


==== Tested with Versions ====
== Symmetrische Substitutionsverfahren ==
* Debian Wheezy 2.1.10-4+deb7u1


==== Settings ====
=== Klassifizierungen ===
Older versions of ejabberd use a different configuration file syntax. In order to be compliant with the manifesto, you should adapt your configuration[[https://bettercrypto.org/#_footnotedef_18 18]] as follows:
* 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


{listen,
== Asymmetrische Substitution ==
    [
* Es werden 2 komplementäre Schlüssel benötigt
        {5222, ejabberd_c2s, [
* 1 Key zum Chiffrieren der Nachricht
        {access, c2s},
* 2 Key zum Dechiffrieren der Nachricht
        {shaper, c2s_shaper},
* Einer der Schlüssel kann gefahrlos öffentlich bekannt gegeben werden (Public-Key)
        {max_stanza_size, 65536},
* Wird mit einem Schlüssel chiffriert
        starttls,
* kann nur mit dem anderen Schlüssel dechiffriert werden
        starttls_required,
        {certfile, "/etc/ejabberd/ejabberd.pem"}
        ]},
    ]}.


{s2s_use_starttls, required_trusted}.
== 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


{s2s_certfile, "/etc/ejabberd/ejabberd.pem"}.
== 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


==== Additional settings ====
== Trust Center ==
Older versions of ejabberd (< 2.0.0) need to be [https://hyperstruct.net/2007/06/20/installing-the-startcom-ssl-certificate-in-ejabberd/ patched] to be able to parse all of the certificates in the CA chain. Specifying a custom cipher string is only possible starting with version 13.12 (see configuration for version 14.12 above).


==== References ====
=== Certification Authority [CA] ===
* [https://docs.ejabberd.im/ ejabberd, your superpowerful messaging framework]
* 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


==== How to test ====
== Kryptografie ==
[https://xmpp.net/ IM Observatory] is a useful website to test Jabber server configurations.


=== Chat privacy - Off-the-Record Messaging (OTR) ===
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Message Authentication Code</div>
[https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html Off-the-Record Messaging Protocol] works on top of the Jabber protocol. It adds to popular chat clients (Adium, Pidgin…​) the following properties for encrypted chats:* Authentication
* Integrity
* Confidentiality
* Forward secrecy
It basically uses Diffie-Hellman, AES and SHA1. Communicating over an insecure instant messaging network, OTR can be used for end to end encryption.
There are no specific configurations required but the protocol itself is worth to be mentioned.


=== Charybdis ===
== Einweg-Hash-Funktion ==
There are numerous implementations of IRC servers. In this section, we choose ''Charybdis'' which serves as basis for [https://github.com/freenode/ircd-seven ircd-seven], developed and used by freenode. Freenode is actually the biggest IRC network[[https://bettercrypto.org/#_footnotedef_19 19]]. ''Charybdis'' is part of the ''Debian'' & ''Ubuntu'' distributions.
Listing 37. SSL relevant configuration for Charybdis/ircd-seven
/* Extensions */
<nowiki>#loadmodule "extensions/chm_sslonly_compat.so";</nowiki>
loadmodule "extensions/extb_ssl.so";
serverinfo {
    ssl_private_key = "etc/test.key";
    ssl_cert = "etc/test.cert";
    ssl_dh_params = "etc/dh.pem";
    <nowiki># set ssld_count as number of cores - 1</nowiki>
    ssld_count = 1;
};
listen {
    sslport = 6697;
};


=== SILC ===
=== Message Authentication Code (MAC) ===
[http://www.silcnet.org/ SILC] is instant messaging protocol publicly released in 2000. SILC is a per-default [https://en.wikipedia.org/wiki/SILC_(protocol) secure chat protocol] thanks to a generalized usage of symmetric encryption. Keys are generated by the server meaning that if compromised, communication could be compromised.
* Dienen bei Datenbank-Anwendungen der einfachen Indizierung von Informationen.
The protocol is not really popular anymore.
* 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


== Databases ==
== Hash-Funktion ==


=== Oracle ===
=== Message Authentication Code (MAC) ===
No information available / known.
* 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


=== MySQL ===
== 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


==== Tested with Versions ====
== MD-5 ==
* MySQL 5.5 on Debian Wheezy
* MySQL 5.7.20 on Ubuntu 16.04.3


==== Settings ====
=== 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


==== References ====
== SHA-1 ==
MySQL Documentation on [https://dev.mysql.com/doc/refman/5.7/en/using-encrypted-connections.html Configuring MySQL to Use Encrypted Connections].


==== How to test ====
=== Schwäche von MD-5 ===
After restarting the server run the following query to see if the ssl settings are correct:
* relativ schnelle Kollisionen der Hash-Werte
show variables like '%ssl%';
* 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


=== DB2 ===
== 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


==== Tested with Version ====
== Substitution vs. Signatur ==
We do not test this here, since we only reference other papers for DB2 so far.
* Algorithmen asymmetrischer Kryptografien unterscheiden sich
* ob eine Nachricht verschlüsselt oder signiert werden soll


==== Settings ====
=== 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


===== ssl_cipherspecs: =====
=== Signatur ===
In the link above the whole SSL-configuration is described in-depth. The following command shows only how to set the recommended ciphersuites.
* Absender erzeugt mit seinem privaten Schlüssel eine Signatur
Listing 38. Recommended and supported ciphersuites
* Empfänger kann durch Verwendung des öffentlichen Schlüssels des Absenders die Nachricht verifiziert
db2 update dbm cfg using SSL_CIPHERSPECS
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA


==== References ====
== Kryptografie ==
IBM DB2 Documentation on ''Supported cipher suites''.[https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.sec.doc/doc/c0053544.html https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.sec.doc/doc/c0053544.html]


=== PostgreSQL ===
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Tunneling</div>


==== Tested with Versions ====
== Ende-zu-Ende vs. Abschnittsweise Sicherheit ==
* Debian Wheezy and PostgreSQL 9.1
* Linux Mint 14 nadia / Ubuntu 12.10 quantal with PostgreSQL 9.1+136 and OpenSSL 1.0.1c


==== Settings ====
=== Ende-zu-Ende ===
To start in SSL mode the <tt>server.crt</tt> and <tt>server.key</tt> must exist in the servers data directory <tt>$PGDATA</tt>.
* 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


{| style="border-spacing:0;width:13.102cm;"
=== Vor- und Nachteile ===
|- style="border:none;padding:0.049cm;"
* Ende-zu-Ende hat eine geringe Angriffsfläche
||
* benötigt jedoch viel Rechenleistung und eine gute Konfiguration
|| Starting with version 9.2, you have the possibility to set the path manually.
* Abschnittssicherheit hat eine größere Angriffsfläche
|-
* beschränkt jedoch hohe Sicherheitsanforderungen auf die Gateways
|}


==== References ====
== Tunneling ==
It’s recommended to read [https://www.postgresql.org/docs/9.1/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SECURITY Security and Authentication] in the manual.
PostgreSQL Documentation on [https://www.postgresql.org/docs/9.1/ssl-tcp.html Secure TCP/IP Connections with SSL].
PostgreSQL Documentation on [https://www.postgresql.org/docs/9.1/auth-pg-hba-conf.html Client Authentication].


==== How to test ====
=== Mehrfaches Einpacken eines Pakets auf einer Transportebene ===
To test your ssl settings, run <tt>psql</tt> with the sslmode parameter:
* Einsatzgebiet heute meist bei abschnittsweise Sicherheit
$ psql "sslmode=require host=postgres-server dbname=database" your-username
* IP/IP-Tunneling
* Für Transport über klassische IP-basierte Netze kann man IPv6 über IPv4 tunneln


== Proxy Solutions ==
=== Layer-2-Tunneling ===
Within enterprise networks and corporations with increased levels of paranoia or at least some defined security requirements it is common '''not''' to allow direct connections to the public internet.
* Pakete der OSI-Schicht 2
For this reason proxy solutions are deployed on corporate networks to intercept and scan the traffic for potential threats within sessions.
* meist PPP-frames
For encrypted traffic there are four options:* Block the connection because it cannot be scanned for threats.
* werden in IP-Pakete verpackt
* Bypass the threat-mitigation and pass the encrypted session to the client, which results in a situation where malicious content is transferred directly to the client without visibility to the security system.
* So tunnelt man alle „Nicht-IP-Protokolle“
* Intercept (i.e. terminate) the session at the proxy, scan there and re-encrypt the session towards the client (effectively MITM).
* Deploy special Certificate Authorities to enable Deep Packet Inspection on the wire.
While the latest solution might be the most "up to date", it arises a new front in the context of this paper, because the most secure part of a client’s connection could only be within the corporate network, if the proxy-server handles the connection to the destination server in an insecure manner.
Conclusion: Don’t forget to check your proxy solutions SSL-capabilities. Also do so for your reverse proxies!


=== Bluecoat / Symantec ===
== Tunneling ==
Blue Coat Systems was a well-known manufacturer of enterprise proxy appliances. In 2016 it was acquired by Symantec. The products are now known as Symantec ProxySG and Advanced Secure Gateway (ASG).
The description below is for the original Blue Coat SG Operating System (SGOS).
BlueCoat Proxy SG Appliances can be used as forward and reverse proxies. The reverse proxy feature is rather under-developed, and while it is possible and supported, there only seems to be limited use of this feature "in the wild" - nonetheless there are a few cipher suites to choose from, when enabling SSL features.


==== Tested with Versions ====
=== Layer-3-Tunnelung ===
 
* Die Pakete der Vermittlungsschicht werden in IP-Frames verpackt
{| style="border-spacing:0;width:10.343cm;"
* Bekanntes Verfahren dieser Art ist IPsec
|- style="border:none;padding:0.049cm;"
! align=center| Proxy Appliance
! align=center| SGOS 6.5.x
! align=center| Blue Coat, now Symantec
|-
|}
 
==== Only allow TLS 1.0,1.1 and 1.2 protocols: ====
$conf t
$(config)ssl
$(config ssl)edit ssl-device-profile default
$(config device-profile default)protocol tlsv1 tlsv1.1 tlsv1.2
  ok
 
==== Select your accepted cipher-suites: ====
$conf t
Enter configuration commands, one per line.  End with CTRL-Z.
$(config)proxy-services
$(config proxy-services)edit ReverseProxyHighCipher
$(config ReverseProxyHighCipher)attribute cipher-suite
Cipher#  Use        Description        Strength
<nowiki>------- </nowiki> ---  <nowiki>----------------------- </nowiki> <nowiki>--------</nowiki>
      1  yes            AES128-SHA256      High
      2  yes            AES256-SHA256      High
      3 yes              AES128-SHA    Medium
      4  yes              AES256-SHA      High
      5  yes      DHE-RSA-AES128-SHA      High
      6  yes      DHE-RSA-AES256-SHA      High
              [...]
    13  yes          EXP-RC2-CBC-MD5    Export
Select cipher numbers to use, separated by commas: 2,5,6
  ok
The same protocols are available for forward proxy settings and should be adjusted accordingly: In your local policy file add the following section:
<ssl>
    DENY server.connection.negotiated_ssl_version=(SSLV2, SSLV3)
Disabling protocols and ciphers in a forward proxy environment could lead to unexpected results on certain (misconfigured?) webservers (i.e. ones accepting only SSLv2/3 protocol connections)
 
=== HAProxy ===
See [https://www.haproxy.org/ https://www.haproxy.org/]
See [https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/ https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/]
See [https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-npn https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#5.1-npn]
See [https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-tune.ssl.cachesize https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-tune.ssl.cachesize]
See [https://kura.io/2014/07/02/haproxy-ocsp-stapling/ https://kura.io/2014/07/02/haproxy-ocsp-stapling/]
See [https://kura.io/2015/01/27/hpkp-http-public-key-pinning-with-haproxy/ https://kura.io/2015/01/27/hpkp-http-public-key-pinning-with-haproxy/]
HAProxy can be used as loadbalancer and proxy for TCP and HTTP-based applications. Since version 1.5 it supports SSL and IPv6.
 
==== Tested with Versions ====
HAProxy 1.5.11 with OpenSSL 1.0.1e on Debian Wheezy
 
==== Settings ====
Listing 39. global configuration
global
    ssl-default-bind-ciphers 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:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
    ssl-default-bind-options no-sslv3 no-tls-tickets #disable SSLv3
    tune.ssl.default-dh-param 2048 #tune DH to 2048
Listing 40. frontend configuration
frontend public
    bind *:80
    bind *:443 ssl crt server.pem
    mode http
    redirect scheme https code 301 if !{ ssl_fc } # redirect HTTP to HTTPS
Listing 41. backend configuration
backend backend
    mode http
    server server 192.168.1.1:80 check
    http-request set-header X-Forwarded-Port %[dst_port]
    http-request add-header X-Forwarded-Proto https if { ssl_fc }
    rspadd Strict-Transport-Security:\ max-age=15768000;\ includeSubDomains #enable HSTS header for this backend
 
==== Additional Settings ====
 
==== Enable NPN Support: ====
    bind *:443 ssl crt server.pem npn "http/1.1,http/1.0"
Append the npn command in the frontend configuration of HAProxy.
 
==== Enable OCSP stapling: ====
HAProxy supports since version 1.5.0 OCSP stapling. To enable it you have to generate the OCSP singing file in the same folder, with the same name as your certificate file plus the extension .ocsp. (e.g. your certificate file is named server.crt then the OCSP file have to be named server.crt.oscp)To generate the OCSP file use these commands:
$ openssl x509 -in your.certificate.crt -noout -ocsp_uri # <- get your ocsp uri
$ openssl ocsp -noverify -issuer ca.root.cert.crt -cert your.certificate.crt -url "YOUR OCSP URI" -respout your.certificate.crt.ocsp
Reload HAProxy and now OCSP stapling should be enabled.Note: This OCSP signature file is only valid for a limited time. The simplest way of updating this file is by using cron.daily or something similar.
 
==== Enable HPKP: ====
Get certificate informations:
$ openssl x509 -in server.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | base64
Then you append the returned string in the HAProxy configuration. Add the following line to the backend configuration:
rspadd Public-Key-Pins:\ pin-sha256="YOUR_KEY";\ max-age=15768000;\ includeSubDomains
Reload HAProxy and HPKP should now be enabled.Note: Keep in mind to generate a backup key in case of problems with your primary key file.
 
==== How to test ====
See appendix [https://bettercrypto.org/#tools Tools]
 
=== Pound ===
 
==== Tested with Versions ====
Pound 2.6
See [http://www.apsis.ch/pound http://www.apsis.ch/pound]
See [https://help.ubuntu.com/community/Pound https://help.ubuntu.com/community/Pound]
 
==== Settings ====
Listing 42. HTTPS Listener in Pound
<nowiki># HTTP Listener, redirects to HTTPS</nowiki>
ListenHTTP
    Address 10.10.0.10
    Port    80
    Service
        Redirect "https://some.site.tld"
    End
End
<nowiki>## HTTPS Listener</nowiki>
ListenHTTPS
    Address      10.10.0.10
    Port        443
    AddHeader    "Front-End-Https: on"
    Cert        "/path/to/your/cert.pem"
    <nowiki>## See 'man ciphers'.</nowiki>
    Ciphers      "TLSv1.2:TLSv1.1:!SSLv3:!SSLv2: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:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA"
    Service
        BackEnd
            Address 10.20.0.10
            Port 80
        End
    End
End
 
=== stunnel ===
 
==== Tested with Versions ====
* stunnel 4.53-1.1ubuntu1 on Ubuntu 14.04 Trusty with OpenSSL 1.0.1f, without disabling Secure Client-Initiated Renegotiation
* stunnel 5.02-1 on Ubuntu 14.04 Trusty with OpenSSL 1.0.1f
* stunnel 4.53-1.1 on Debian Wheezy with OpenSSL 1.0.1e, without disabling Secure Client-Initiated Renegotiation
 
==== Settings ====
Listing 43. HTTPS Listener in stunnel
ciphers = 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:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
curve = secp384r1
options = NO_SSLv2
options = NO_SSLv3
options = cipher_server_preference
<nowiki>; Secure Client-Initiated Renegotiation can only be disabled wit stunnel >= 4.54</nowiki>
<nowiki>;renegotiation = no</nowiki>
 
==== Additional information ====
Secure Client-Initiated Renegotiation can only be disabled for stunnel versions >= 4.54, when the renegotiation parameter has been added (See changelog).
 
==== References ====
stunnel documentation: [https://www.stunnel.org/static/stunnel.html https://www.stunnel.org/static/stunnel.html]
stunnel changelog: [https://www.stunnel.org/sdf_ChangeLog.html https://www.stunnel.org/sdf_ChangeLog.html]
 
==== How to test ====
See appendix [https://bettercrypto.org/#tools Tools]
 
== Kerberos ==
This section discusses various implementations of the Kerberos 5 authentication protocol on Unix and Unix-like systems as well as on Microsoft Windows.
 
=== Overview ===
Kerberos provides mutual authentication of two communicating parties, e.g. a user using a network service. The authentication process is mediated by a trusted third party, the Kerberos key distribution centre (KDC). Kerberos implements secure single-sign-on across a large number of network protocols and operating systems. Optionally, Kerberos can be used to create encrypted communications channels between the user and service.
 
==== Recommended reading ====
An understanding of the Kerberos protocol is necessary for properly implementing a Kerberos setup. Also, in the following section some knowledge about the inner workings of Kerberos is assumed. Therefore we strongly recommend reading the excellent introduction [http://gost.isi.edu/publications/kerberos-neuman-tso.html Kerberos: An Authentication Service for Computer Networks] first.
No further overview over Kerberos terminology and functions will be provided, for a discussion and a selection of relevant papers refer to [https://web.mit.edu/kerberos/papers.html Kerberos Papers and Documentation].
The Kerberos protocol over time has been extended with a variety of extensions and Kerberos implementations provide additional services in addition to the aforementioned KDC. All discussed implementations provide support for trust relations between multiple realms, an administrative network service (kerberos-adm, kadmind) as well as a password changing service (kpasswd). Sometimes, alternative database backends for ticket storage, X.509 and SmartCard authentication are provided. Of those, only administrative and password changing services will be discussed.
 
{| style="border-spacing:0;width:17cm;"
|- style="border:none;padding:0.049cm;"
||
|| Protocol versions
Only the Kerberos 5 protocol and implementation will be discussed. Kerberos 4 is obsolete, insecure and its use is strongly discouraged.
|-
|}


==== Providing a suitable Setup for secure Kerberos Operations ====
== Kryptografie ==
The aim of Kerberos is to unify authentication across a wide range of services, for many different users and use cases and on many computer platforms. The resulting complexity and attack surface make it necessary to carefully plan and continuously evaluate the security of the overall ecosystem in which Kerberos is deployed. Several assumptions are made on which the security of a Kerberos infrastructure relies:* Every KDC in a realm needs to be trustworthy. The KDC’s principal database must not become known to or changed by an attacker. The contents of the principal database enables the attacker to impersonate any user or service in the realm.
=== Wie baut man eine sicheren Block Cipher? ===
* Synchronisation between KDCs must be secure, reliable and frequent. An attacker that is able to intercept or influence synchronisation messages obtains or influences parts of the principal database, enabling impersonation of affected principals. Unreliable or infrequent synchronisation enlarges the window of vulnerability after disabling principals or changing passwords that have been compromised or lost.
* KDCs must be available. An attacker is able to inhibit authentication for services and users by cutting off their access to a KDC.
* Users’ passwords must be secure. Since Kerberos is a single-sign-on mechanism, a single password may enable an attacker to access a large number of services.
* Service keytabs need to be secured against unauthorized access similarly to SSL/TLS server certificates. Obtaining a service keytab enables an attacker to impersonate a service.
* DNS infrastructure must be secure and reliable. Hosts that provide services need consistent forward and reverse DNS entries. The identity of a service is tied to its DNS name, similarly the realm a client belongs to as well as the KDC, kpasswd and kerberos-adm servers may be specified in DNS TXT and SRV records. Spoofed DNS entries will cause denial-of-service situations and might endanger ([https://bettercrypto.org/#bibliography-default-MITKrbDoc:realm_config i_mit_Realm configuration decisions_, 2013]) the security of a Kerberos realm.
* Clients and servers in Kerberos realms need to have synchronized clocks. Tickets in Kerberos are created with a limited, strictly enforced lifetime. This limits an attacker’s window of opportunity for various attacks such as the decryption of tickets in sniffed network traffic or the use of tickets read from a client computer’s memory. Kerberos will refuse tickets with old timestamps or timestamps in the future. This would enable an attacker with access to a systems clock to deny access to a service or all users logging in from a specific host.
Therefore we suggest:* Secure all KDCs at least as strongly as the most secure service in the realm.
* Dedicate physical (i.e. non-VM) machines to be KDCs. Do not run any services on those machines beyond the necessary KDC, kerberos-adm, kpasswd and kprop services.
* Restrict physical and administrative access to the KDCs as severely as possible. E.g. ssh access should be limited to responsible adminstrators and trusted networks.
* Encrypt and secure the KDCs backups.
* Replicate your primary KDC to at least one secondary KDC.
* Prefer easy-to-secure replication (propagation in Kerberos terms) methods.Especially avoid LDAP replication and database backends. LDAP enlarges the attack surface of your KDC and facilitates unauthorized access to the principal database e.g. by ACL misconfiguration.
* Use DNSSEC. If that is not possible, at least ensure that all servers and clients in a realm use a trustworthy DNS server contacted via secure network links.
* Use NTP on a trustworthy server via secure network links.
* Avoid services that require the user to enter a password which is then checked against Kerberos. Prefer services that are able to use authentication via service tickets, usually not requiring the user to enter a password except for the initial computer login to obtain a ticket-granting-ticket (TGT). This limits the ability of attackers to spy out passwords through compromised services.


=== Implementations ===
== Probleme bei der Entwicklung von Kryptografieverfahren ==


==== Cryptographic Algorithms in Kerberos Implementations ====
=== Vertraulichkeit ===
The encryption algorithms (commonly abbreviated ’etypes’ or ’enctypes’) in Kerberos exchanges are subject to negotiation between both sides of an exchange. Similarly, a ticket granting ticket (TGT), which is usually obtained on initial login, can only be issued if the principal contains a version of the password encrypted with an etype that is available both on the KDC and on the client where the login happens.
* Schutz der Daten vor unberechtigter Einsichtnahme
Therefore, to ensure interoperability among components using different implementations as shown in [https://bettercrypto.org/#kerberos_enctypes Commonly supported Kerberos encryption types by implementation. Algorithm names], a selection of available etypes is necessary. However, the negotiation process may be subject to downgrade attacks and weak hashing algorithms endanger integrity protection and password security.


{| style="border-spacing:0;width:17cm;"
=== Authentisierung ===
|- style="border:none;padding:0.049cm;"
* Sicherstellung der Herkunft
||
* Verbindlichkeit
|| This means that the <tt>des3-cbc-sha1-kd</tt> or <tt>rc4-hmac algorithms</tt> should not be used, except if there is a concrete and unavoidable need to do so. Other <tt>des3-*</tt>, <tt>des-*</tt> and <tt>rc4-hmac-exp</tt> algorithms should never be used.
|-
|}
Along the lines of cipher string B, the following etypes are recommended: <tt>aes256-cts-hmac-sha1-96</tt> <tt>camellia256-cts-cmac</tt> <tt>aes128-cts-hmac-sha1-96</tt> <tt>camellia128-cts-cmac</tt>.
Commonly supported Kerberos encryption types by implementation. Algorithm names
according to RFC3961, except where aliases can be used or the algorithm is named differently altogether as stated ([https://bettercrypto.org/#bibliography-default-rfc3962 Raeburn, 2005])


{| style="border-spacing:0;width:17cm;"
=== Anonymität ===
|- style="border:none;padding:0.049cm;"
* Schutz vor Bekanntwerden des Absenders und Empfängers
! align=center| ID
! align=center| Algorithm
! align=center| MIT
! align=center| Heimdal
! align=center| GNU Shishi
! align=center| MS ActiveDirectory
|- style="border:none;padding:0.049cm;"
|| 1
|| des-cbc-crc
|| yes
|| yes
|| yes
|| yes
|- style="border:none;padding:0.049cm;"
|| 2
|| des-cbc-md4
|| yes
|| yes
|| yes
|| no
|- style="border:none;padding:0.049cm;"
|| 3
|| des-cbc-md5
|| yes
|| yes
|| yes
|| yes
|- style="border:none;padding:0.049cm;"
|| 6
|| des3-cbc-none
|| no
|| yes
|| yes
|| no
|- style="border:none;padding:0.049cm;"
|| 7
|| des3-cbc-sha1
|| no
|| yes[[https://bettercrypto.org/#_footnotedef_20 20]]
|| no
|| no
|- style="border:none;padding:0.049cm;"
|| 16
|| des3-cbc-sha1-kd
|| yes[[https://bettercrypto.org/#_footnotedef_21 21]]
|| yesfoonote:[named des3-cbc-sha1]
|| yes
|| no
|- style="border:none;padding:0.049cm;"
|| 17
|| aes128-cts-hmac-sha1-96
|| yes
|| yes
|| yes
|| yesfoonote:[since Vista, Server 2008]
|- style="border:none;padding:0.049cm;"
|| 18
|| aes256-cts-hmac-sha1-96
|| yes
|| yes
|| yes
|| yes[[https://bettercrypto.org/#_footnotedef_22 22]]
|- style="border:none;padding:0.049cm;"
|| 23
|| rc4-hmac
|| yes
|| yes
|| yes
|| yes
|- style="border:none;padding:0.049cm;"
|| 24
|| rc4-hmac-exp
|| yes
|| no
|| yes
|| yes
|- style="border:none;padding:0.049cm;"
|| 25
|| camellia128-cts-cmac
|| yes[[https://bettercrypto.org/#_footnotedef_23 23]]
|| no
|| no
|| no
|- style="border:none;padding:0.049cm;"
|| 26
|| camellia256-cts-cmac
|| yes[[https://bettercrypto.org/#_footnotedef_24 24]]
|| no
|| no
|| no
|-
|}


==== Existing installations ====
=== Integrität ===
The configuration samples below assume new installations without preexisting principals.
* Unveränderlichkeit von Daten und Verlässlichkeit von Programmen
For existing installations:* Existing setups should be migrated to a new master key if the current master key is using a weak enctype.
* When changing the list of supported_enctypes, principals where all enctypes are no longer supported will cease to work.
* Be aware that Kerberos 4 is obsolete and should not be used.
* Principals with weak enctypes pose an increased risk for password bruteforce attacks if an attacker gains access to the database.
To get rid of principals with unsupported or weak enctypes, a password change is usually the easiest way. Service principals can simply be recreated.


==== MIT krb5 ====
== Wie baut man eine sicheren Block Cipher? ==


===== KDC configuration =====
== Mary Stuart 1516 - 1558Bekanntes Opfer der Kryptoanalyse ==
In <tt>/etc/krb5kdc/kdc.conf</tt> set the following in your realm’s configuration:
Listing 44. Encryption flags for MIT krb5 KDC
supported_enctypes = aes256-cts-hmac-sha1-96:normal camellia256-cts-cmac:normal aes128-cts-hmac-sha1-96:normal camellia128-cts-cmac:normal
default_principal_flags = +preauth
In <tt>/etc/krb5.conf</tt> set in the <tt>[libdefaults]</tt> section:
Listing 45. Encryption flags for MIT krb5 client
[libdefaults]
allow_weak_crypto = false
permitted_enctypes= aes256-cts-hmac-sha1-96 camellia256-cts-cmac aes128-cts-hmac -sha1-96 camellia128-cts-cmac
default_tkt_enctypes= aes256-cts-hmac-sha1-96 camellia256-cts-cmac aes128-cts-hmac-sha1-96 camellia128-cts-cmac
default_tgs_enctypes= aes256-cts-hmac-sha1-96 camellia256-cts-cmac aes128-cts-hmac-sha1-96 camellia128-cts-cmac


===== Upgrading a MIT krb5 database to a new enctype =====
== Shannon‘s Principle of ConfusionSubstitution Cipher ==
To check if an upgrade is necessary, execute the following on the KDC in question:
root@kdc.example.com:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.COM
KVNO: 1, Enctype: des-cbc-crc, Active on: Thu Jan 01 00:00:00 UTC 1970 *


{| style="border-spacing:0;width:15.658cm;"
== Shannon‘s Principle of DiffusionTransposition Cipher ==
|- style="border:none;padding:0.049cm;"
||
|| In this case, an old unsafe enctype is in use as indicated by the star following the key line.
|-
|}
To upgrade, proceed as follows. First create a new master key for the database with the appropriate enctype. You will be prompted for a master password that can later be used to decrypt the database. A stash-file containing this encryption key will also be written.
root@kdc.example.com:~# kdb5_util add_mkey -s -e aes256-cts-hmac-sha1-96
Creating new master key for master key principal 'K/M@EXAMPLE.COM'
You will be prompted for a new database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Verify that the new master key has been successfully created. Note the key version number (KVNO) of the new master key, in this case 2.
root@kdc.example.com:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.COM
KVNO: 2, Enctype: aes256-cts-hmac-sha1-96, No activate time set
KVNO: 1, Enctype: des-cbc-crc, Active on: Thu Jan 01 00:00:00 UTC 1970 *
Set the new master key as the active master key by giving its KVNO. The active master key will be indicated by an asterisk in the master key list.
root@kdc.example.com:~# kdb5_util use_mkey 2
root@kdc.example.com:~# kdb5_util list_mkeys
Master keys for Principal: K/M@EXAMPLE.COM
KVNO: 2, Enctype: aes256-cts-hmac-sha1-96, Active on: Wed May 13 14:14:18 UTC 2015 *
KVNO: 1, Enctype: des-cbc-crc, Active on: Thu Jan 01 00:00:00 UTC 1970
Reencrypt all principals to the new master key.
root@kdc.example.com:~# kdb5_util update_princ_encryption
Re-encrypt all keys not using master key vno 2?
(type 'yes' to confirm)? yes
504 principals processed: 504 updated, 0 already current
After verifying that everything still works as desired it is possible to remove unused master keys.
root@kdc.example.com:~# kdb5_util purge_mkeys
Will purge all unused master keys stored in the 'K/M@EXAMPLE.COM' principal, are you sure?
(type 'yes' to confirm)? yes
OK, purging unused master keys from 'K/M@EXAMPLE.COM'...
Purging the following master key(s) from K/M@EXAMPLE.COM:
KVNO: 1
1 key(s) purged.


= III: Theory =
== Kryptografie ==


== Overview ==
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Angriffe auf Kryptografieen</div>
Number theorists are like lotus-eaters - having tasted this food they can never give it up.
— Leopold Kronecker
This chapter provides the necessary background information on why chapter [https://bettercrypto.org/#practicalsettings [practicalsettings]] recommended ''cipher string B''.
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].
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.
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.
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.


== Cipher suites ==
== 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“.


=== Architectural overview ===
=== Moderne Verfahren ===
This section defines some terms which will be used throughout this guide.
* Das heute im kommerziellen Gebrauch am häufigsten eingesetzte Verfahren heisst DES
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:
* DES steht für „Data Encryption Standard“
Key exchange protocol 
* Es funktioniert im Prinzip wie ein mehrfach hintereinander angewandtes Substitutionsverfahren
 
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;"
== Angriffe auf Kryptografieen ==
|- style="border:none;padding:0.049cm;"
||
|| A note on nomenclature
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.
|-
|}


=== Forward Secrecy ===
=== Chifertext-Only Angriff ===
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)
* Versucht eine Kryptografie nur bei Kenntnis des chiffrierten Textes zu lösen
* [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)
* Gößte Herausforderung für jeden Kryptoanalytiker
* [https://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html SSL: Intercepted today, decrypted tomorrow] (Netcraft)


=== Recommended cipher suites ===
=== 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.


== Recommended cipher suites ==
=== Chosen-Plaintext Attack  ===
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.
* 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


{| style="border-spacing:0;width:17cm;"
=== Adaptive Chosen-Plaintext Attack ===
|- style="border:none;padding:0.049cm;"
* Attacker can choose a series of plaintexts, basing choice on the result of previous encryption
||
* differential cryptanalysis!
|| Caution
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]].
|-
|}


=== Configuration A: Strong ciphers, fewer clients ===
=== Brute Force Angriff ===
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.
* Nacheinander werden alle möglichen Schlüssel durchprobiert
We arrived at this set of cipher suites by selecting:* TLS 1.2
* Kann bei jeder Kryptografiemethode eingesetzt werden
* Perfect forward secrecy / ephemeral Diffie Hellman
* Der Angreifer muss jedoch erkennen, wann der richtige Schlüssel gefunden wurde, daher werden diese Angriffe oft als Known-plaintext-Angriff durchgeführt
* 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;"
== Dechiffrierung verschlüsselter NachrichtenBrute Force Angriff ==
|- style="border:none;padding:0.049cm;"
* Die Brute-force Methode ist bei sehr großen Schlüsseln wirkungslos
! align=center| ID
* Dann muss sich der Gegner auf die Analyse des Chiffrats verlassen
! align=center| OpenSSL Name
* Dabei muss der Angreifer eine gewisse Vorstellung haben, um was für eine Art Ausgangstext es sich handelt
! align=center| Version
* zum Beispiel eine .exe-Datei, Word-Datei oder einen Text mit deutschem Inhalt
! align=center| KeyEx
* Oder der Gegner spekuliert auf bestimmte Muster des Klartextes
! align=center| Auth
* Word-Dateien fangen zum Beispiel immer mit dem selben Muster an
! align=center| Cipher
* Kryptoanalyse basiert auf der Ausnutzung
! align=center| MAC
* von Spuren der Struktur oder
|- style="border:none;padding:0.049cm;"
* des Musters des Klartextes
|| '''0x009F'''
* Diese bestehen auch nach Kryptografie und sind im Chiffretext zu erkennen
|| 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;"
== Exhaustive Testing ==
|- style="border:none;padding:0.049cm;"
||
|| 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 ===
=== Monoalphabetischen Substitution (Cäsar) ===
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.
* jedem Buchstaben eines Alphabets mit 27 Buchstaben (26 + ein Satzzeichen) wird ein beliebig anderen zuordnet
'''All examples in this publication use Configuration B'''.
* 27 Möglichkeiten für den ersten Buchstaben
We arrived at this set of cipher suites by selecting:* TLS 1.2, TLS 1.1, TLS 1.0
* 26 Möglichkeiten für den zweiten Buchstaben
* allowing SHA-1 (see the comments on SHA-1 in section [https://bettercrypto.org/#SHA [SHA]])
* 25 Möglichkeiten für den dritten Buchstaben
This results in the OpenSSL string:
* etc.
<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>
* Das enspricht 27 * 26 * .... * 2 * 1 = 27!
Table 15. Configuration B ciphers
* rund 1,09*10e28 Zuordnungsmöglichkeiten


{| style="border-spacing:0;width:17cm;"
== Statische Analyse ==
|- style="border:none;padding:0.049cm;"
* Angreifer nutzen die Schwachstellen der Kryptverfahren
! align=center| ID
* Dabei analysieren sie statisch den verschlüsselten Datenverkehr
! align=center| OpenSSL Name
* Im Fall der monoalphabetischen bedeutet das
! align=center| Version
* Die Häufigkeit der verschlüsselten Buchstaben bleibt gleich und kann durch einfache Häufigkeitsanalyse Rückschlüsse auf den Originaltext ziehen
! align=center| KeyEx
* Jedoch muss deren Sprache kennen bzw.&nbsp;erraten
! align=center| Auth
* Der Buchstabe „e“ tritt in der deutschen Sprache am häufigsten auf
! align=center| Cipher
* Auch Buchstabenpaare (Biagramme) treten mit unterschiedlicher Häufigkeit auf
! align=center| MAC
* Durch diese Kenntnisse können monoalphabetische Codes schnell entschlüsselt werden
|- 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
|-
|}


{| style="border-spacing:0;width:16.478cm;"
== Known oder Chosen Plaintext ==
|- style="border:none;padding:0.049cm;"
* Teilweise vorhersehbar
||
* Kryptografieen und Kryptografien zu knacken fällt einem Angreifer leichter, wenn er Teile des Klartextes bereits kennt.
|| Compatibility
* Die Header-Daten von IP Paketen lassen sich unschwer erraten/ermitteln und ermöglichen so Know-Plaintext-Attacken
Note that these cipher suites will not work with Windows XP’s crypto stack (e.g. IE, Outlook),
* 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


{| style="border-spacing:0;width:17cm;"
== MustererkennungDie Methode des wahrscheinlichen Wortes ==
|- 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).
|-
|}
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 ===
=== 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) ===


{| style="border-spacing:0;width:17cm;"
== Most Cryptoanalytic Attacks base on theRedundancy of Natural Language Texts ==
|- 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.
|-
|}


== Random Number Generators ==
== Angriffsarten ==
[[Image:Bild11.png|top|alt="A real fair random number generator"]]
* Angreifer hat mehrere Möglichkeiten
(Image license: [http://creativecommons.org/licenses/by-nc/2.5/ CC-BY-NC])
* Informationen einer verschlüsselten Nachricht zu erhalten
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.
* die vom Sender A („Alice“) an Empfänger B („Bob“) geschickt wird
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.
* Am leichtesten können Nachrichten an
* Hubs
* Switches und
* Router abgehört werden


=== When Random Number Generators Fail ===
== Kryptografie ==
Random number generators can fail – returning predictable non-random numbers – if not enough entropy is available when random numbers should be generated.
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 ==
<div style="text-align:center;margin-left:0cm;margin-right:0cm;">Kryptologische Verfahren</div>
On the choice between AES256 and AES128: I would never consider
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 ===
== Der Schlüsselaustausch ==
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).
* Sicherheitsrelevant für alle bisher kennen gelernten Verfahren ist der Schlüsselaustausch
For elliptic curve cryptography we consider key lengths below 256 bits to be inadequate for long term protection.
* muss zuvor über einen geheimen Kanal stattfinden
For symmetric algorithms we consider anything below 128 bits to be inadequate for long term protection.
* 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


=== Special remark on 3DES: ===
== Diffie-Hellman-Key-Exchange ==
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]].
* Über das Diffie-Hellman-Key-Exchange-Verfahren (DH) lassen sich kryptographische Schlüssel sicher über unsichere Kanäle aushandeln
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.
* 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


== A note on Elliptic Curve Cryptography ==
== Diffie-Hellman-Key-Exchange ==
Everyone knows what a curve is, until he has studied enough
* Sind die eingesetzten Zahlen hinreichend groß, ist es für einen Angreifer so gut wie unmöglich, den Key zu knacken
mathematics to become confused through the countless number
* Große Zahlen erfordern allerdings mehr Rechenaufwand
of possible exceptions.
* Die Größe der Zahlen bestimmt die gewählte DH-Gruppe
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]].
* Die kleinste DH Gruppe 1 hat 768 Bit und die größte definierte Gruppe 18 besitzt 8192 Bit
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]).
* Empfohlen wird derzeit der Gebrauch der Gruppe 5 mit 1536 Bit
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;"
== Diffie-Hellman ==
|- style="border:none;padding:0.049cm;"
* Vereinbarung eines gemeinsamen symmetrischen Schlüssels über einen unsicheren Kanal.
||
* Basiert auf 2 Schlüsseln
|| Warning
* Alice und Bob sind einer große Primzahl p und ein ganzahliger Wert g (Generator) frei zugänglich
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!
* 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


== A note on SHA-1 ==
== Symmetrische Kryptografieverfahren ==
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.
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.
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.


== A note on Diffie Hellman Key Exchanges ==
=== Einfachster Einsatz  ===
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]).
* basiert auf der logischen Exklusiv-Oder-Funktion
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.
* 2 XOR Verknüpfung eines A Zeichens mit einem B hat wieder das ursprüngliche Zeichen A zum Ergebnis
For convenience, we provide these parameters as PEM files on our webserver [[https://bettercrypto.org/#_footnotedef_32 32]].
* 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


== Public Key Infrastructures ==
== Symmetric Algorithms: Block Ciphers ==
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.
There are two approaches to achieve that: ''Certificate Authorities'' and the ''Web of Trust''.
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]).
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.
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).
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 ===
== Some Popular Block Ciphers ==
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.


==== Certificates From an External Certificate Authority ====
== Symmetric Algorithms: Stream Ciphers ==
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.
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.
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.
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:
$ openssl req -new -nodes -keyout <servername>.key -out <servername>.csr -newkey rsa:<keysize> -sha256
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria
Locality Name (eg, city) []:Munich
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 ====
== RC4 ==
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.
Again using OpenSSL as an example, you can set up your own CA with the following commands on a Debian system:
$ cd /usr/lib/ssl/misc
$ 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 ====
=== RC = Rivest Cipher  ===
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.
* Stromverschlüsselungsverfahren
With OpenSSL, you can self-sign a previously created certificate with this command:
* Basiert auf XOR-Verknüpfung
$ openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
* Sehr schnell und einfach
You can also create a self-signed certificate in just one command:
* Eignet sich gut in Software
$ openssl req -new -x509 -keyout privkey.pem -out cacert.pem -days 1095 -nodes -newkey rsa:<keysize> -sha256
* Der Algorythmus macht aus dem eingegebenen Schlüssel S einen langen, pseudo-zufälligen internen Schlüssel P
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.
* Dieser wird zur Chiffrierung des Klartextes verwendet
* RC4 Speichert 258 verschiedene Zusatzinformationen
* 256 sind Permutationen von 0-255 und somit gleich verteilt


=== Hardening PKI ===
== DES ==
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 ===
=== Familie der Blockchiffren ===
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.
* Teilt eine Nachricht in 64 Bit große Datenblöcke
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.
* 3 bearbeitungsschritte werden benötigt, um den Klartext wieder herzustellen.
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.
* Am weitesten verbreiteter Algorythmus, auch wenn nicht mehr ganz Zeitgemäß
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.
* Nachfolger: 3DES
* Wird in Finanzdienstleistungen eingesetzt und führt die Kryptografie 3 mal hintereinander aus


==== Configuration of CAA records ====
== Data Encryption Standard (DES)Sicherheit von DES ==
BIND supports CAA records as of version 9.9.6.
* DES
A CAA record can be configured by adding it to the zone file:
* erlaubt mit 56 Bit Schlüssellänge
$ORIGIN example.com
* 72 Billiarden mögliche Schlüssel
      CAA 0 issue "ca1.example"
* ist heute nicht mehr ausreichend
      CAA 0 iodef "mailto:security@example.com"
* per Brute-Force in 5 Tagen (?) geknackt
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 ====
== Permutation ==
Once a CAA record is deployed, it can be validated using the following dig query:
* DES besteht aus 3 Bearbeitungsschritten
$ dig CAA google.com
* Initiale Permutation
<nowiki>; <<>> DiG 9.10.3-P4-Debian <<>> CAA google.com</nowiki>
* Ver-/Entschlüsselung in mehreren Runden
<nowiki>;; ANSWER SECTION:</nowiki>
* finale Permutation
google.com.          3600 IN  CAA  0 issue "symantec.com"
* DES wurde in den 70er Jahren zur Implementation in Hardware entwickelt
On older versions of Dig, which do not support CAA records, you can query the record type manually:
* durch die damals noch kleinen CPU Register
$ dig +short -t TYPE257 google.com
* Finale Permutation = Inverse der initialen Permutation
\# 19 0005697373756573796D616E7465632E636F6D
* Nach der Durchführung der initialen und finalen Permutation, steht ein Bit wieder an ursprünglicher Stelle


== TLS and its support mechanisms ==
== 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]


=== HTTP Strict Transport Security (HSTS) ===
== Kryptografie ==
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]]
* DES teilt den Klartext in 64 Bit Blöcke und
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.
* splittet sie nochmal in 2 32 Bit lange Bestandteile (L[n] und R[n]).
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.
* R[n] wird über eine Mangler-Funktion ,mittels tabellenbasierter Umrechnung auf Grundlage der Eingangsvariable R[n] und des Schlüssels K[n], vermischt.
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.
This prevents unencrypted HTTP access (SSL striping, mistyped HTTPS URLs, etc.) when the server is accessed later by the client.
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 ====
== Genügen 128 Bit? ==
HSTS header can be parametrized by two directives:* max-age=<number-of-seconds>
* IDEA
* includeSubdomains
* International Data Encryption Algorithm
''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).
* arbeitet mit 128 Bit Schlüssellänge, sonst ähnlich wie der DES
''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''.
* 3.43669 * 1038
* knacken benötigt etwa 1012 Jahre
* Daher gilt der IDEA heute als sicher


==== HSTS Client Support ====
== Asymmetrische Kryptografieverfahren ==
HSTS is supported [[https://bettercrypto.org/#_footnotedef_37 37]] by these web browsers:* Firefox version >= v4.0
* Chrome version >= 4.0
* Android Browser >=4.4
* Opera version >= 12.0
* Opera mobile >= 16.0
* Safari >= 7.0
* Microsoft Internet Explorer >= 11 (with update provided 09. June 2015)
* Microsoft Edge >= 12


==== HSTS Considerations ====
=== Setzen auf 2 unterschiedliche Schlüssel ===
Before enabling HSTS it is recommended to consider following:* Is it ''required'' to serve content or services over HTTP?
* Privater Schlüssel (privat key) [Dechiffriert-Algorythmisch]
* Enabling ''includeSubdomains'' and SSL certificate management.
* Öffentlicher Schlüssel (public key) [Chiffriert-Algorythmisch]
* Proper value of ''max-age''.
* Es lässt sich nicht vom public key auf den private key schließen
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.
* Der public key kann von Dritten zur Kryptografie von Informationen genutzt werden
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).
* die der Besitzer des private keys nur entschlüsseln kann
Finally HSTS should be tested with lower ''max-age'' values and deployed with higher ''max-age'' values.


==== Testing HSTS ====
=== Bekanntester Vertreter ===
HSTS can be tested either using locally or through the Internet.
* RSA-Algorythmus
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.
* Die Multiplikation 2er Zahlen stellt eine einfache Operation dar
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.
* während der umgekehrt Vorgang eine enorme Rechenleistung bedeutet


==== References ====
== RSA ==
* 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]
* 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]
* HSTS Browser Compatibility List: [https://caniuse.com/stricttransportsecurity https://caniuse.com/stricttransportsecurity]
* 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]


=== HTTP Public Key Pinning (HPKP) ===
=== Basiert auf folgenden 4 Schritten ===
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.
* 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


==== HPKP Header Directives ====
== RSA ==
HPKP provides two different types of headers:* Public-Key-Pins
* Public-Key-Pins-Report-Only
HPKP header can be parametrized by following directives:* pin-sha256="<YOUR_PUBLICKEY_HASH⇒"
* max-age=<number-of-seconds>
* includeSubdomains
* report-uri="<[https://YOUR.URL/TO-REPORT%3E https://YOUR.URL/TO-REPORT>"]
'''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:
$ 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 ====
=== Algorithmus bei der Kryptografie ===
HPKP is supported [[https://bettercrypto.org/#_footnotedef_41 41]] by these web browsers:* Firefox version >= 35
* Alice verschlüsselt
* Chrome version between version 38 and 72
* ihren Klartext m gemäß c = m^e mod n und
* Android Browser >= 44
* sendet ihn an Bob.
* Opera version >= 25
* In diesem Fall ist [e,n] der öffentliche Schlüssel von Bob
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.
* 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


==== HPKP Considerations ====
== RSA ==
Before enabling HPKP it is recommended to consider following:* Which Public-Keys to use for Pinning (Certificate + Backup-Certificate, CAs, Intermediate-CAs)
* Der Empfänger führt bei der Entschlüsselung die gleiche Operation wie der Sender bei der Kryptografie durch
* Proper value of ''max-age''. Start testing with a short Period, increase Period after deployment.
* Algorythmus zur Erzeugung und Überprüfung von Signaturen
* Be careful when using ''includeSubdomains'', are all your subdomains covered by the defined Public-Key-Hashes?
* Alice sendet eine signierte Nachricht, indem sie s = m^d mod n erzeugt und überträgt
The administrators are advised to watch for expiration of the SSL certificate and handle the renewal process with caution.
* [d,n] = Privater Schlüssen von Alice
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).
* 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


==== Testing HPKP ====
== Advanced Encryption Standard ==
HPKP can be tested either using locally or through the Internet.
* Nachfolgestandard für DES
There is a handy bash-script which uses OpenSSL for doing several SSL/TLS-Tests available at [https://testssl.sh/ https://testssl.sh/]
* 3DES mit 128 Bit gilt noch als sicher
$ wget -q https://testssl.sh/testssl.sh
* wegen der Dreifachverschlüsselung deutlich langsamer als AES
$ wget -q https://testssl.sh/mapping-rfc.txt
* AES unterstützt 128, 192 und 256 Bit lange Schlüssel
$ chmod 755 ./testssl.sh
* Beispiel Hamachi
$ ./testssl.sh https://example.com
* AES mit 256 Bit Schlüssellänge
<nowiki># Sample Output, just HSTS and HPKP Section (Full report is quite long!):</nowiki>
* im Modus Cipher-Block-Chaining
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 ====
== Advanced Encryption Standard (AES)http://www.nist.gov/aes ==
* 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]
* DES is nearly 25 years old!
* HPKP Browser Compatibility List: [https://caniuse.com//#feat=publickeypinning https://caniuse.com/\#feat=publickeypinning]
* Triple DES with a 168 bit key is the current Federal Information Processing Standard FIPS 46-3 (renewed in October 1999).
* 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]
* 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


= IV: Appendix =
== 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


== Tools ==
== Cipher Block Chaining (CBC) ==
This section lists tools for checking the security settings.
* 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


=== SSL & TLS ===
== Advanced Encryption Standard ==
Server checks via the web
[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.
SSL Server certificate installation issues [https://www.sslshopper.com/ssl-checker.html https://www.sslshopper.com/ssl-checker.html]
Check SPDY protocol support and basic TLS setup [http://spdycheck.org/ http://spdycheck.org/]
XMPP/Jabber Server check (Client-to-Server and Server-to-Server) [https://xmpp.net/ https://xmpp.net/]
Luxsci SMTP TLS Checker [https://luxsci.com/extranet/tlschecker.html https://luxsci.com/extranet/tlschecker.html]
DNSsec and DANE support of your domain and e-mail server? [https://dane.sys4.de/ https://dane.sys4.de]
[http://checktls.com/ http://checktls.com] is a tool for testing arbitrary TLS services.
[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 ===
=== CBC-Mode Entstehung von Mustern ===
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].
* Rückschlüsse auf den Klartext
Check Browsers SSL/TLS support and vulnerability to attacks: [https://www.howsmyssl.com/ https://www.howsmyssl.com]
* 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


=== Command Line Tools ===
== Vergleich: AES und 3DES ==
[https://sourceforge.net/projects/sslscan https://sourceforge.net/projects/sslscan] connects to a given SSL service and shows the cipher suites that are offered.
[http://www.bolet.org/TestSSLServer/ http://www.bolet.org/TestSSLServer/] tests for BEAST and CRIME vulnerabilities.
[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 ===
== IDEA ==
[http://www.keylength.com/ http://www.keylength.com] comprehensive online resource for comparison of key lengths according to common recommendations and standards in cryptography.


=== Random Number Generators ===
=== Familie der Blockchiffrierung ===
[http://www.fourmilab.ch/random/ ENT] is a pseudo random number generator sequence tester.
* jedoch wendet er 128 Bit Schlüssel auf 64 Bit Datenpakete des Klartextes an
[http://www.phy.duke.edu/~rgb/General/dieharder.php Dieharder] a random number generator testing tool.
* Basiert auf einer Mischung 3 mathematischen Funktionen
[http://www.cacert.at/random/ CAcert Random] another random number generator testing service.
* 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


=== Guides ===
== Hybride Kryptografieverfahren ==
See: [https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf].


== Links ==
=== Vorteile aus asymmetrischen und symmetrischen Kryptografie  ===
[https://www.iana.org/assignments/tls-parameters/tls-parameters.txt IANA official list of Transport Layer Security (TLS) Parameters]
* Hohe Effizienz
[https://www.imperialviolet.org/2010/12/04/ecc.html Elliptic curves and their implementation (04 Dec 2010)]
* gesteigerte Sicherheit
[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]
* Flexibilität
[https://github.com/ioerror/duraconf Duraconf, A collection of hardened configuration files for SSL/TLSservices (Jacob Appelbaum’s github)]
* Austausch der erforderlichen Schlüssel
[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]
* erfolgt über ein asymmetrisches Verfahren
[https://www.eff.org/https-everywhere/deploying-https EFF How to deploy HTTPS correctly]
* Kryptografie größerer Datenmengen
[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)]
* kommen symetrische Algorythmen zum Einsatz
[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 ==
== Vergleich Klassisch - Modern ==
This section contains suggested reading material.
Cryptography Engineering: Design Principles and Practical Applications, Ferguson, N. and Schneier, B. and Kohno, T. (ISBN-13: 978-0470474242)
Security Engineering: A Guide to Building Dependable Distributed Systems, Anderson, R.J. (ISBN-13: 978-0470068526)
Applied cryptography: protocols, algorithms, and source code in C, Schneier, B. (ISBN-13: 978-0471117094)
Guide to Elliptic Curve Cryptography, Hankerson, D. and Vanstone, S. and Menezes, A.J. (ISBN-13: 978-0387952734)
A Introduction To The Theory of Numbers, Godfrey Harold Hardy, E. M. Wrigh (ISBN-13: 978-0199219865)
Malicious Cryptography: Exposing Cryptovirology, Young A., Yung, M. (ISBN-13: 978-0764549755)


== Cipher Suite Name Cross-Reference ==
=== Sowohl die klassischen Verfahren wie Vigenère als auch die modernen Verfahren wie IDEA… ===
This table shows the cipher suite names as IANA defined them, the names OpenSSL uses, and the respective codes.
* …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)


{| style="border-spacing:0;width:17cm;"
== Fazit ==
|- style="border:none;padding:0.049cm;"
! align=center| Code
! align=center| IANA Name
! align=center| OpenSSL Name
|- style="border:none;padding:0.049cm;"
|| <tt>0x00,0x00</tt>
|| <tt>TLS_NULL_WITH_NULL_NULL</tt>
||
|- 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 ==
=== Die Geschichte der Kryptografie ist ein Wettbewerb  ===
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.
* zwischen Kryptografiespezialisten und Kryptoanalysten
Table 16. Further Protocols
* 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


{| style="border-spacing:0;width:14.018cm;"
== Kryptografie ==
|- style="border:none;padding:0.049cm;"
|| DNSSec (mention BCPs)
|| DANE
|| Tor
|- style="border:none;padding:0.049cm;"
|| S/Mime (check are there any BCPs? )
|| TrueCrypt, LUKS, FileVault
|| AFS
|- style="border:none;padding:0.049cm;"
|| Kerberos
|| NNTP
|| NTPs tlsdate
|- style="border:none;padding:0.049cm;"
|| Moxa , APC, und co…​ ICS
||
||
|- style="border:none;padding:0.049cm;"
|| rsyslog
|| tftp
|| (s)ftp(s)
|- style="border:none;padding:0.049cm;"
|| haproxy
||
||
|-
|}
Table 17. Further Protocols (Network centric)


{| style="border-spacing:0;width:9.917cm;"
<div style="text-align:center;margin-left:2cm;margin-right:0cm;">Geschwindigkeit</div>
|- style="border:none;padding:0.049cm;"
|| IPv6 security
||
||
|- style="border:none;padding:0.049cm;"
|| Wi-Fi, 802.1x
|| SIP
|| SRTP
|- style="border:none;padding:0.049cm;"
|| Kerberos
|| NNTP
|| NTPs tlsdate
|- style="border:none;padding:0.049cm;"
|| BGP / OSPF
|| LDAP
|| seclayer-tcp
|- style="border:none;padding:0.049cm;"
|| RADIUS (RADSEC)
|| racoon
|| strongswan
|- style="border:none;padding:0.049cm;"
|| l2tp
||
||
|- style="border:none;padding:0.049cm;"
|| Ethernet to serial
|| DSL modems
||
|- style="border:none;padding:0.049cm;"
|| UPnP, natPmp
||
||
|- style="border:none;padding:0.049cm;"
|| HTTP Key Pinning (HTKP)
||
||
|- style="border:none;padding:0.049cm;"
|| Monitoring: SNMPv3
||
||
|-
|}
Table 18. Further Applications


{| style="border-spacing:0;width:7.853cm;"
== Geschwindigkeit ==
|- style="border:none;padding:0.049cm;"
|| Lync
|| Tomcat
||
|- style="border:none;padding:0.049cm;"
|| Microsoft SQL Server
|| Microsoft Exchange
||
|- style="border:none;padding:0.049cm;"
|| IBM HTTP Server
||
||
|-
|}
Commerical Network Equipment Vendors
Other ideas:
SAML federated auth providers [[https://bettercrypto.org/#_footnotedef_42 42]]
Elastic Load Balancing (ELB)[[https://bettercrypto.org/#_footnotedef_43 43]]


=== 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“