bc java
1.0.0
Le package Bouncy Castle Crypto est une implémentation Java d'algorithmes cryptographiques, il a été développé par la Légion du Château Bouncy, une organisation caritative australienne enregistrée, avec un peu d'aide ! La Légion et les dernières avancées concernant ce package peuvent être consultées sur https://www.bouncycastle.org.
La Légion reconnaît également avec gratitude les contributions apportées à ce dossier par d'autres (voir ici pour la liste actuelle). Si vous souhaitez contribuer à nos efforts, n'hésitez pas à nous contacter ou à visiter notre page de dons, à parrainer un travail spécifique ou à acheter un contrat de support via Crypto Workshop (qui fait désormais partie de Keyfactor).
Le package est organisé de manière à contenir une API légère adaptée à une utilisation dans n'importe quel environnement (y compris le nouveau J2ME) avec l'infrastructure supplémentaire nécessaire pour conformer les algorithmes au framework JCE.
Sauf indication contraire, ce logiciel est distribué sous une licence basée sur la licence MIT X Consortium. Pour consulter la licence, voir ici. La bibliothèque OpenPGP comprend également une bibliothèque BZIP2 modifiée sous licence Apache Software License, version 2.0.
Remarque : cette arborescence source n'est pas la version FIPS des API - si vous êtes intéressé par notre version FIPS, veuillez nous contacter directement à [email protected].
Le fichier bc_maven_public_key.asc contient la clé publique utilisée pour signer nos artefacts sur Maven Central. Vous devrez utiliser
gpg -o bc_maven_public_key.gpg --dearmor bc_maven_public_key.asc
retirer la clé avant utilisation. Une fois cela fait, un fichier peut être vérifié en utilisant :
gpg --no-default-keyring --keyring ./bc_maven_public_key.gpg --verify file_name.jar.asc file_name.jar
Remarque : le ./ est requis devant le nom du fichier de clé pour indiquer à gpg de rechercher localement.
Ce projet peut désormais être construit et testé avec JDK21.
Si le script de build détecte BC_JDK8, BC_JDK11, BC_JDK17, il ajoutera à la tâche de test habituelle une dépendance sur les tâches de test qui utilisent spécifiquement les JVM adressées par ces variables d'environnement. Le script s'appuie sur JAVA_HOME pour récupérer Java 21 s'il est utilisé.
Nous prenons en charge les tests sur des JVM spécifiques car c'est le seul moyen de garantir la compatibilité de la bibliothèque.
Les variables d'environnement suivantes peuvent éventuellement pointer vers JAVA_HOME pour chaque version de JVM.
export BC_JDK8=/path/to/java8 export BC_JDK11=/path/to/java11 export BC_JDK17=/path/to/java17
Le projet utilise désormais gradlew qui peut être invoqué par exemple :
# 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
Le script Gradle s'efforcera de vérifier leur existence mais pas l'exactitude de leur valeur.
Certains sous-projets produisent des pots multi-versions et ces pots peuvent être testés spécifiquement sur différentes versions de JVM.
Si les variables d'environnement sont définies :
export BC_JDK8=/path/to/java8 export BC_JDK11=/path/to/java11 export BC_JDK17=/path/to/java17
Si seul un JDK Java 21 est présent, la tâche de test normale et test21 sont exécutés uniquement.
La salle blanche JCE, à utiliser avec JDK 1.1 à JDK 1.3 se trouve dans le répertoire jce/src/main/java. À partir du JDK 1.4 et des versions ultérieures, le JCE est livré avec la JVM, la source des JDK ultérieurs suit les progrès réalisés dans les versions ultérieures du JCE. Si vous utilisez une version ultérieure du JDK fournie avec une installation JCE, veuillez ne pas inclure le répertoire jce comme fichier source car il entrerait en conflit avec l'API JCE installée avec votre JDK.
Le module principal fournit toutes les fonctionnalités des API légères.
Le module prov fournit toutes les fonctionnalités du fournisseur JCA/JCE.
Le module util héberge le code utilisé par d'autres modules qui n'ont pas besoin d'être dans prov. Pour le moment, il s'agit en grande partie de classes ASN.1 pour le module PKIX.
Le module pkix héberge le code pour la génération de certificats X.509 et les API pour les normes qui s'appuient sur ASN.1 telles que CMS, TSP, PKCS#12, OCSP, CRMF et CMP.
Le module de messagerie fournit une API S/MIME construite sur CMS.
Le module pg héberge le code utilisé pour prendre en charge OpenPGP.
Le module tls héberge le code utilisé pour une API TLS générale et un fournisseur JSSE.
Les scripts de build fournis avec la distribution complète permettent la création des différentes versions en utilisant les différentes arborescences sources tout en excluant les classes qui ne sont pas appropriées et en copiant les classes de compatibilité requises à partir des répertoires contenant les classes de compatibilité appropriées pour la distribution.
Si vous souhaitez essayer de créer une build pour vous-même, en utilisant votre propre environnement, la meilleure façon de le faire est de commencer par la build de la distribution qui vous intéresse, de vous assurer qu'elle est buildée, puis de modifier vos scripts de build pour effectuer le build. exclusions et copies de fichiers requises pour votre configuration, sinon vous risquez d'obtenir des exceptions de classe introuvable. La dernière mise en garde est que, comme la distribution j2me inclut certaines classes de compatibilité commençant dans le package Java, vous devez utiliser un obfuscateur pour modifier les noms des packages avant de tenter d'importer un midlet à l'aide de l'API BC.
Important : Vous devrez également extraire le référentiel bc-test-data au même niveau que le référentiel bc-java si vous souhaitez exécuter les tests.
Pour voir quelques exemples, regardez les programmes de test dans les packages :
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
Il existe également des exemples de programmes spécifiques pour gérer SMIME et OpenPGP. On les retrouve dans :
org.bouncycastle.mail.smime.examples
org.bouncycastle.openpgp.examples
Pour ceux qui sont intéressés, il existe 2 listes de diffusion pour participer à ce projet. Pour vous abonner, utilisez les liens ci-dessous et incluez le mot « abonnez-vous » dans le corps du message. (Pour vous désabonner, remplacez abonnement par désabonnement dans le corps du message)
[email protected]
Cette liste de diffusion est réservée aux annonces de nouvelles versions, les abonnés généraux ne peuvent pas y publier de messages.
[email protected]
Cette liste de diffusion est destinée à discuter du développement du package. Cela inclut les bugs, les commentaires, les demandes d’améliorations, les questions sur l’utilisation ou le fonctionnement.
REMARQUE : Vous devez être abonné pour envoyer du courrier à la liste de diffusion ci-dessus.
Si vous souhaitez fournir des commentaires directement aux membres de la Légion , veuillez utiliser [email protected]. Si vous souhaitez aider ce projet à survivre, veuillez envisager de faire un don.
Pour les rapports/demandes de bogues, vous pouvez signaler les problèmes ici sur github, ou via feedback-crypto si nécessaire. Nous accepterons également les demandes d'extraction basées sur ce référentiel, mais uniquement à la condition que tout code inclus puisse être distribué sous la licence Bouncy Castle.
Apprécier!
