Ist der Bouncy Castle API-Thread sicher?

Question

Ist Hüpfburg-API Threadsicher?Besonders,

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

Ich plane, eine Singleton-Spring-Bean für die grundlegende Kryptografieunterstützung in meiner App zu schreiben.Da es sich um eine Webanwendung handelt, ist die Wahrscheinlichkeit größer, dass mehrere Threads gleichzeitig auf diese Komponente zugreifen.Trittsicherheit ist hier also unerlässlich.

Bitte lassen Sie mich wissen, wenn Sie beim Einsatz von Hüpfburg auf solche Situationen gestoßen sind.

Answer 1

Es spielt wirklich keine Rolle, ob die API/der Code threadsicher ist.Die CBC-Verschlüsselung an sich ist nicht threadsicher.Einige Terminologie -

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.

Eine wirklich einfache CBC-Implementierung kann wie folgt aussehen:P1, P2, P3 = Klartextnachrichten

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.

Wie Sie sehen, ist das Ergebnis der Verschlüsselung von P1, P2 und P3 (in dieser Reihenfolge) ein anderes als das Ergebnis der Verschlüsselung von P2, P1 und P3 (in dieser Reihenfolge).

Daher ist bei einer CBC-Implementierung die Reihenfolge wichtig.Jeder Algorithmus, bei dem die Reihenfolge wichtig ist, kann per Definition nicht threadsicher sein.

Sie können eine Singleton-Fabrik erstellen, die Verschlüsselungsobjekte bereitstellt, aber Sie können nicht darauf vertrauen, dass sie Thread-sicher sind.

Answer 2

Die J2ME-Version ist nicht threadsicher.