bc java
1.0.0
Das Bouncy Castle Crypto-Paket ist eine Java-Implementierung kryptografischer Algorithmen. Es wurde von der Legion of the Bouncy Castle, einer eingetragenen australischen Wohltätigkeitsorganisation, mit ein wenig Hilfe entwickelt! Die Legion und die neuesten Entwicklungen in diesem Paket finden Sie unter https://www.bouncycastle.org.
Die Legion würdigt auch dankbar die Beiträge anderer zu diesem Paket (die aktuelle Liste finden Sie hier). Wenn Sie zu unseren Bemühungen beitragen möchten, nehmen Sie bitte Kontakt mit uns auf oder besuchen Sie unsere Spendenseite, sponsern Sie eine bestimmte Arbeit oder erwerben Sie einen Supportvertrag über Crypto Workshop (jetzt Teil von Keyfactor).
Das Paket ist so organisiert, dass es eine leichtgewichtige API enthält, die für den Einsatz in jeder Umgebung (einschließlich der neu veröffentlichten J2ME) geeignet ist, mit der zusätzlichen Infrastruktur, um die Algorithmen an das JCE-Framework anzupassen.
Sofern nicht anders angegeben, wird diese Software unter einer Lizenz vertrieben, die auf der MIT X Consortium-Lizenz basiert. Die Lizenz finden Sie hier. Die OpenPGP-Bibliothek enthält auch eine modifizierte BZIP2-Bibliothek, die unter der Apache Software License, Version 2.0, lizenziert ist.
Hinweis : Dieser Quellbaum ist nicht die FIPS-Version der APIs – wenn Sie an unserer FIPS-Version interessiert sind, kontaktieren Sie uns bitte direkt unter [email protected].
Die Datei bc_maven_public_key.asc enthält den öffentlichen Schlüssel, der zum Signieren unserer Artefakte auf Maven Central verwendet wird. Sie müssen verwenden
gpg -o bc_maven_public_key.gpg --dearmor bc_maven_public_key.asc
den Schlüssel vor Gebrauch zu entwerten. Sobald dies erledigt ist, kann eine Datei wie folgt überprüft werden:
gpg --no-default-keyring --keyring ./bc_maven_public_key.gpg --verify file_name.jar.asc file_name.jar
Hinweis: Das ./ ist vor dem Namen der Schlüsseldatei erforderlich, um gpg anzuweisen, lokal zu suchen.
Dieses Projekt kann jetzt mit JDK21 erstellt und getestet werden.
Wenn das Build-Skript BC_JDK8, BC_JDK11, BC_JDK17 erkennt, fügt es der üblichen Testaufgabe eine Abhängigkeit von Testaufgaben hinzu, die speziell die JVMs verwenden, die von diesen Umgebungsvariablen angesprochen werden. Das Skript verlässt sich auf JAVA_HOME, um Java 21 abzurufen, wenn es verwendet wird.
Wir unterstützen Tests auf bestimmten JVMs, da nur so sichergestellt werden kann, dass die Bibliothek kompatibel ist.
Die folgenden Umgebungsvariablen können optional für jede JVM-Version auf JAVA_HOME verweisen.
export BC_JDK8=/path/to/java8 export BC_JDK11=/path/to/java11 export BC_JDK17=/path/to/java17
Das Projekt verwendet jetzt gradlew , das beispielsweise aufgerufen werden kann:
# from the root of the project # Ensure JAVA_HOME points to JDK 21 or higher JAVA_HOME or that # gradlew can find a java 21 installation to use. ./gradlew clean build
Das Gradle-Skript wird versuchen, ihre Existenz zu überprüfen, nicht jedoch die Richtigkeit ihres Werts.
Einige Teilprojekte produzieren Multi-Release-JARs und diese JARs können speziell auf verschiedenen JVM-Versionen getestet werden.
Wenn die Umgebungsvariablen definiert sind:
export BC_JDK8=/path/to/java8 export BC_JDK11=/path/to/java11 export BC_JDK17=/path/to/java17
Wenn nur ein Java 21 JDK vorhanden ist, werden nur die normale Testaufgabe und test21 ausgeführt.
Das Reinraum-JCE zur Verwendung mit JDK 1.1 bis JDK 1.3 befindet sich im Verzeichnis jce/src/main/java. Ab JDK 1.4 und höher wird das JCE mit der JVM ausgeliefert. Die Quelle für spätere JDKs folgt den Fortschritten, die in den späteren Versionen des JCE erzielt wurden. Wenn Sie eine spätere Version des JDK verwenden, die mit einer JCE-Installation geliefert wird, schließen Sie das JCE-Verzeichnis bitte nicht als Quelldatei ein, da es mit der JCE-API, die mit Ihrem JDK installiert wurde, in Konflikt gerät.
Das Kernmodul bietet alle Funktionen der Lightweight-APIs.
Das Modul prov stellt die gesamte Funktionalität des JCA/JCE-Anbieters bereit.
Das util -Modul ist die Heimat für Code, der von anderen Modulen verwendet wird, die nicht in prov enthalten sein müssen. Im Moment handelt es sich dabei größtenteils um ASN.1-Klassen für das PKIX-Modul.
Das pkix- Modul ist die Heimat des Codes für die Generierung von X.509-Zertifikaten und der APIs für Standards, die auf ASN.1 basieren, wie z. B. CMS, TSP, PKCS#12, OCSP, CRMF und CMP.
Das Mail -Modul stellt eine S/MIME-API bereit, die auf dem CMS aufbaut.
Das pg -Modul ist die Heimat des Codes, der zur Unterstützung von OpenPGP verwendet wird.
Das TLS- Modul ist die Heimat für Code, der für eine allgemeine TLS-API und einen JSSE-Anbieter verwendet wird.
Die mit der vollständigen Distribution gelieferten Build-Skripte ermöglichen die Erstellung verschiedener Versionen unter Verwendung der verschiedenen Quellbäume, wobei nicht geeignete Klassen ausgeschlossen und die erforderlichen Kompatibilitätsklassen aus den Verzeichnissen kopiert werden, die für die Distribution geeignete Kompatibilitätsklassen enthalten.
Wenn Sie versuchen möchten, unter Verwendung Ihrer eigenen Umgebung einen Build für sich selbst zu erstellen, beginnen Sie am besten mit dem Build für die Distribution, an der Sie interessiert sind, stellen Sie sicher, dass Builds erstellt werden, und ändern Sie dann Ihre Build-Skripte, um dies zu tun Erforderliche Ausschlüsse und Dateikopien für Ihr Setup, andernfalls werden Sie wahrscheinlich Ausnahmen vom Typ „Klasse nicht gefunden“ erhalten. Die letzte Einschränkung hierbei besteht darin, dass Sie, da die j2me-Distribution einige Kompatibilitätsklassen enthält, die im Java-Paket beginnen, einen Obfuscator verwenden müssen, um die Paketnamen zu ändern, bevor Sie versuchen, ein Midlet mithilfe der BC-API zu importieren.
Wichtig : Sie müssen auch das bc-test-data-Repository auf derselben Ebene wie das bc-java-Repository auschecken, wenn Sie die Tests ausführen möchten.
Um einige Beispiele anzuzeigen, schauen Sie sich die Testprogramme in den Paketen an:
org.bouncycastle.crypto.test
org.bouncycastle.jce.provider.test
org.bouncycastle.cms.test
org.bouncycastle.mail.smime.test
org.bouncycastle.openpgp.test
org.bouncycastle.tsp.test
Für den Umgang mit SMIME und OpenPGP gibt es auch einige konkrete Beispielprogramme. Sie sind zu finden in:
org.bouncycastle.mail.smime.examples
org.bouncycastle.openpgp.examples
Für Interessierte gibt es 2 Mailinglisten zur Teilnahme an diesem Projekt. Um sich anzumelden, verwenden Sie die untenstehenden Links und fügen Sie das Wort „abonnieren“ in den Nachrichtentext ein. (Um sich abzumelden, ersetzen Sie „subscribe“ durch „unsubscribe“ im Nachrichtentext.)
[email protected]
Diese Mailingliste ist nur für Ankündigungen neuer Veröffentlichungen gedacht, allgemeine Abonnenten können dort keine Posts posten.
[email protected]
Diese Mailingliste dient der Diskussion über die Entwicklung des Pakets. Dazu gehören Fehler, Kommentare, Verbesserungswünsche, Fragen zur Nutzung oder Bedienung.
HINWEIS: Sie müssen angemeldet sein, um E-Mails an die oben genannte Mailingliste senden zu können.
Wenn Sie den Mitgliedern von The Legion direkt Feedback geben möchten, verwenden Sie bitte [email protected]. Wenn Sie diesem Projekt zum Überleben verhelfen möchten, denken Sie bitte über eine Spende nach.
Für Fehlerberichte/Anfragen können Sie Probleme hier auf Github oder bei Bedarf über Feedback-Crypto melden. Wir akzeptieren auch Pull-Anfragen, die auf diesem Repository basieren, jedoch nur auf der Grundlage, dass der enthaltene Code unter der Bouncy Castle-Lizenz verbreitet werden darf.
Genießen!
