Pergunta

É Bouncy Castle API Thread-Safe ?Especialmente,

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

Eu estou planejando escrever um singleton Primavera de feijão para o nível básico de suporte para criptografia em meu aplicativo.Uma vez que é uma aplicação web, há maiores chances de múltiplas threads acessando este componente de cada vez.Para banda de rodagem de segurança é essencial aqui.

Por favor, deixe-me saber se você vem através de tais situações, usando Bouncy Castle.

Foi útil?

Solução

Realmente não importa se o API/Código seja thread-safe.CBC criptografia em si, não é thread-safe.Algumas terminologias -

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.

Uma verdade simples CBC implementação pode parecer com:P1, P2, P3 = mensagens de texto sem formatação

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.

Como você pode ver, o resultado do sistema de encriptação de P1, P2 e P3 (nessa ordem) é diferente do sistema de encriptação de P2, P1 e P3 (nessa ordem).

Assim, em um HEMOGRAMA implementação, a ordem é importante.Qualquer algoritmo onde a ordem é importante, não pode, por definição, ser thread-safe.

Você pode fazer um Singleton fábrica que fornece criptografia de objetos, mas você não pode confiar neles seja thread-safe.

Outras dicas

O J2ME versão não é thread-safe.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top