uthrasri/openssl_g2.5_newOpen-Source-Toolkit nach Industriestandard, das die SSL/TLS-Protokolle implementiert und eine umfassende Kryptographie-Bibliothek für Verschlüsselung, Entschlüsselung, Hashing, digitale Signaturen und Zertifikatsverwaltung bereitstellt.
OpenSSL 1.0.1g 7 Apr 2014
Copyright (c) 1998-2011 The OpenSSL Project Copyright (c) 1995-1998 Eric A. Young, Tim J. Hudson Alle Rechte vorbehalten.
Das OpenSSL-Projekt ist eine gemeinschaftliche Initiative zur Entwicklung eines robusten, kommerziell nutzbaren, voll ausgestatteten Open-Source- Toolkits, das die Protokolle Secure Sockets Layer (SSL v2/v3) und Transport Layer Security (TLS v1) sowie eine vollwertige Allzweck-Kryptografiebibliothek implementiert. Das Projekt wird von einer weltweiten Gemeinschaft freiwilliger Helfer geleitet, die das Internet nutzen, um zu kommunizieren, zu planen und das OpenSSL-Toolkit und die zugehörige Dokumentation zu entwickeln.
OpenSSL basiert auf der hervorragenden SSLeay-Bibliothek, die von Eric A. Young und Tim J. Hudson entwickelt wurde. Das OpenSSL-Toolkit ist unter einer Doppellizenz (die OpenSSL-Lizenz plus die SSLeay-Lizenz) lizenziert, was im Grunde bedeutet, dass es Ihnen freisteht, es zu beschaffen und für kommerzielle und nicht-kommerzielle Zwecke zu verwenden, solange Sie die Bedingungen beider Lizenzen erfüllen.
Das OpenSSL-Toolkit umfasst:
libssl.a: Implementierung von SSLv2, SSLv3, TLSv1 und des erforderlichen Codes zur Unterstützung von SSLv2, SSLv3 und TLSv1 in einem einzigen Server und Client.
libcrypto.a: Allgemeine Verschlüsselungs- und X.509-v1/v3-Bestandteile, die von SSL/TLS benötigt werden, aber logisch nicht wirklich dazugehören. Es enthält Routinen für Folgendes:
Cipher
libdes - EAYs libdes-DES-Verschlüsselungspaket, das einige Jahre
im Netz kursierte und dann von ihm als Teil von SSLeay neu
lizenziert wurde. Es enthält 15 'Modi/Variationen' von DES
(1-, 2- und 3-Schlüssel-Versionen von ecb, cbc, cfb und
ofb; pcbc und eine allgemeinere Form von cfb und ofb),
darunter desx im cbc-Modus, ein schnelles crypt(3) und
Routinen zum Lesen von Passwörtern von der Tastatur.
RC4-Verschlüsselung,
RC2-Verschlüsselung - 4 verschiedene Modi: ecb, cbc, cfb und ofb.
Blowfish-Verschlüsselung - 4 verschiedene Modi: ecb, cbc, cfb und ofb.
IDEA-Verschlüsselung - 4 verschiedene Modi: ecb, cbc, cfb und ofb.
Digests
MD5- und MD2-Message-Digest-Algorithmen, schnelle Implementierungen,
SHA- (SHA-0) und SHA-1-Message-Digest-Algorithmen,
MDC2-Message-Digest. Ein auf DES basierender Hash, der auf
Smartcards beliebt ist.
Public Key
RSA-Verschlüsselung/-Entschlüsselung/-Generierung.
Es gibt keine Begrenzung der Anzahl der Bits.
DSA-Verschlüsselung/-Entschlüsselung/-Generierung.
Es gibt keine Begrenzung der Anzahl der Bits.
Diffie-Hellman-Schlüsselaustausch/-Schlüsselgenerierung.
Es gibt keine Begrenzung der Anzahl der Bits.
X.509v3-Zertifikate
X509-Kodierung/-Dekodierung in/aus binärem ASN1 und eine auf PEM
basierende ASCII-Binär-Kodierung, die die Verschlüsselung mit
einem privaten Schlüssel unterstützt. Programm zur Erzeugung
von RSA- und DSA-Zertifikatsanforderungen und zur Erzeugung
von RSA- und DSA-Zertifikaten.
Systeme
Die üblichen Digital-Envelope-Routinen und die Base64-Kodierung.
Zugriff auf Cipher und Digests auf höherer Ebene über ihren Namen.
Neue Cipher können zur Laufzeit geladen werden. Das BIO-IO-System,
das eine einfache nicht-blockierende IO-Abstraktion darstellt.
Derzeit unterstützte Methoden sind Dateideskriptoren, Sockets,
Socket-Accept, Socket-Connect, Speicherpuffer, Pufferung,
SSL-Client/Server, Dateizeiger, Verschlüsselung, Digest,
Nichtblockierungs-Tests und Null.
Datenstrukturen
Ein dynamisch wachsendes Hash-System
Ein einfacher Stack.
Ein Konfigurationslader, der ein Format ähnlich den MS-.ini-Dateien
verwendet.
openssl: Ein Kommandozeilenwerkzeug, das verwendet werden kann für: Erzeugung von RSA-, DH- und DSA-Schlüsselparametern Erzeugung von X.509-Zertifikaten, CSRs und CRLs Berechnung von Message Digests Ver- und Entschlüsselung mit Ciphern SSL/TLS-Client- und Server-Tests Verarbeitung von S/MIME-signierter oder -verschlüsselter E-Mail
An verschiedenen Orten der Welt halten verschiedene Unternehmen Patente auf verschiedene Algorithmen. SIE sind dafür verantwortlich, dass Ihre Verwendung von Algorithmen legal ist, indem Sie prüfen, ob es in Ihrem Land Patente gibt. Die Datei enthält einige der Patente, von denen wir wissen oder von denen gemunkelt wird, dass sie existieren. Dies ist keine vollständige Liste.
RSA Security besitzt Softwarepatente auf den RC5-Algorithmus. Wenn Sie diesen Cipher verwenden möchten, müssen Sie sich wegen der Lizenzbedingungen an RSA Security wenden. Deren Webseite ist http://www.rsasecurity.com/.
RC4 ist eine Marke von RSA Security, daher sollte diese Bezeichnung möglicherweise nur mit Genehmigung von RSA Security verwendet werden.
Der IDEA-Algorithmus ist von Ascom in Österreich, Frankreich, Deutschland, Italien, Japan, den Niederlanden, Spanien, Schweden, der Schweiz, Großbritannien und den USA patentiert. Ascom sollte kontaktiert werden, wenn dieser Algorithmus verwendet werden soll; deren Webseite ist http://www.ascom.ch/.
NTT und Mitsubishi besitzen Patente und angemeldete Patente auf den Camellia-Algorithmus, erlauben jedoch die Nutzung ohne Gebühr, ohne dass eine ausdrückliche Lizenzvereinbarung erforderlich ist: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html
Um dieses Paket unter einem Unix-Derivat zu installieren, lesen Sie die Datei INSTALL. Für eine Win32-Plattform lesen Sie die Datei INSTALL.W32. Für OpenVMS-Systeme lesen Sie INSTALL.VMS.
Lesen Sie die Dokumentation im Verzeichnis doc/. Sie ist recht grob, listet aber die Funktionen auf; Sie werden wahrscheinlich in den Code schauen müssen, um herauszufinden, wie man sie verwendet. Schauen Sie sich die Beispielprogramme an.
Für einige Plattformen gibt es bekannte Probleme, die den Benutzer oder den Anwendungsautor betreffen können. Wir versuchen, diese in doc/PROBLEMS zu sammeln, zusammen mit aktuellen Überlegungen, wie sie in einer zukünftigen Version von OpenSSL gelöst werden sollten.
Einzelheiten dazu, wie Sie kommerziellen technischen Support erhalten, finden Sie auf der OpenSSL-Website www.openssl.org.
Wenn Sie Probleme mit OpenSSL haben, führen Sie bitte zunächst die folgenden Schritte aus:
- Laden Sie den aktuellen Snapshot von ftp://ftp.openssl.org/snapshot/
herunter, um zu sehen, ob das Problem bereits behoben wurde
- Entfernen Sie die ASM-Versionen der Bibliotheken
- Entfernen Sie Compiler-Optimierungsflags
Wenn Sie einen Fehler melden möchten, nehmen Sie bitte die folgenden Informationen in jeden Fehlerbericht auf:
- Auf Unix-Systemen:
Selbsttestbericht, erzeugt mit 'make report'
- Auf anderen Systemen:
OpenSSL-Version: Ausgabe von 'openssl version -a'
Betriebssystemname, -version, Hardwareplattform
Compiler-Details (Name, Version)
- Anwendungsdetails (Name, Version)
- Problembeschreibung (Schritte, die das Problem reproduzieren, falls
bekannt)
- Stack-Traceback (falls die Anwendung einen Core-Dump erzeugt)
Melden Sie den Fehler an das OpenSSL-Projekt über den Request Tracker (http://www.openssl.org/support/rt.html) per E-Mail an:
Beachten Sie, dass der Request Tracker NICHT für allgemeine Hilfe- oder Supportanfragen verwendet werden sollte. Nur weil etwas nicht so funktioniert, wie Sie es erwarten, bedeutet das nicht unbedingt, dass es ein Fehler in OpenSSL ist.
Beachten Sie, dass E-Mails an [email protected] in der öffentlich lesbaren Request-Tracker-Datenbank aufgezeichnet und an eine öffentliche Mailingliste weitergeleitet werden. Vertrauliche E-Mails können an [email protected] gesendet werden (PGP-Schlüssel auf den Schlüsselservern verfügbar).
Die Entwicklung wird über die Mailingliste openssl-dev koordiniert (Informationen zum Abonnieren finden Sie unter http://www.openssl.org). Wenn Sie einen Patch einreichen möchten, senden Sie ihn an [email protected] mit dem Text "[PATCH]" im Betreff. Bitte geben Sie unbedingt eine textliche Erklärung dessen an, was Ihr Patch bewirkt.
Wenn Sie nicht sicher sind, ob ein Feature für die allgemeine OpenSSL-Community nützlich sein wird, besprechen Sie es bitte zuerst auf der Mailingliste openssl-dev. Möglicherweise arbeitet bereits jemand an derselben Sache, oder es gibt einen guten Grund, warum dieses Feature nicht implementiert ist.
Patches sollten so aktuell wie möglich sein, vorzugsweise relativ zum aktuellen Git oder zum letzten Snapshot. Sie sollten dem Codierungsstil von OpenSSL folgen und ohne Warnungen kompilieren. Einige der Entwickler-Targets des Kernteams können zu Testzwecken verwendet werden (debug-steve64, debug-geoff usw.). OpenSSL kompiliert auf vielen verschiedenen Plattformen: Versuchen Sie sicherzustellen, dass Sie nur portable Features verwenden.
Hinweis: Aus rechtlichen Gründen können Beiträge aus den USA nur angenommen werden, wenn eine TSU-Meldung und eine Kopie des Patches an [email protected] (ehemals BXA) gesendet werden, mit einer Kopie an den ENC Encryption Request Coordinator; nehmen Sie sich bitte etwas Zeit, um die Details unter http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html [sic] und http://w3.access.gpo.gov/bis/ear/pdf/740.pdf (EAR Abschnitt 740.13(e)) anzusehen. Wenn "Ihr Verschlüsselungsquellcode zu groß ist, um als E-Mail-Anhang zu dienen", kann er stattdessen gern per Fax eingereicht werden; hoffentlich haben Sie einen günstigen Ferngesprächstarif.
Unser bevorzugtes Format für Änderungen ist die "diff -u"-Ausgabe. Sie können sie folgendermaßen erzeugen: