Est-ce que Bouncy Castle API est sécuritaire?

Question

Est-ce que Bouncy Castle API Fil sécuritaire? Surtout,

org.bouncycastle.crypto.paddings.PaddedBufferedBlockCipher 
org.bouncycastle.crypto.paddings.PKCS7Padding 
org.bouncycastle.crypto.engines.AESFastEngine 
org.bouncycastle.crypto.modes.CBCBlockCipher 

Je prévois d'écrire un singleton grain de printemps pour le soutien de la cryptographie de niveau de base dans mon application. Comme il s'agit d'une application Web, il y a plus de chances que plusieurs threads accèdent à ce composant à la fois. La sécurité de la bande de roulement est donc essentielle ici.

S'il vous plaît laissez-moi savoir si vous avez rencontré de telles situations en utilisant Bouncy Castle.

Answer 1

Peu importe si l'API/Code est thread-safe. Le chiffrement CBC en lui-même n'est pas sécurisé. Quelques termes -

E(X) = Enctrypt message X 
D(X) = Dectrypt X. (Note that D(E(X)) = X) 
IV = Initialization vector. A random sequence to bootstrap the CBC algorithm 
CBC = Cipher block chaining. 

Une implémentation CBC vraiment simple peut ressembler à: P1, P2, P3 = messages texte brut

1. Generate an IV, just random bits. 
2. Calculate E(P1 xor IV) call this C1 
3. Calculate E(P2 xor C1) call this C2 
4. Calculate E(P3 xor C2) call this C3. 

Comme vous pouvez le voir, le résultat du chiffrement P1, P2 et P3 (dans cet ordre) est différent de crypter P2, P1 et P3 (dans cet ordre). Ainsi, dans une implémentation CBC, l'ordre est important. Par conséquent, dans une implémentation CBC, l'ordre est important. Tout algorithme où l'ordre est important ne peut, par définition, être thread safe.

Vous pouvez créer une fabrique Singleton qui fournit des objets de chiffrement, mais vous ne pouvez pas leur faire confiance pour les threads.

Answer 2

La version J2ME n'est pas adaptée aux threads.