S / MIME em Java sem JCE

Question

Eu estou tentando escrever um applet que iria assinar e-mail com o S / MIME.

Obviamente, eu quero fazer uma pequena jarra com somente o material necessário. Obviamente a maneira Java de fazer isso envolve ter um enorme sagrado assinado Bouncy Castle JCE jar ao redor.

A pergunta é: Qual é a maneira mais fácil de obter S / MIME sem tocar JCE e tê-lo queixar-se "de autenticação" "provedores"? Talvez haja uma implementação S / MIME que não depende de JCE? Talvez seja possível usar Bouncy Castle S / MIME usando sua API leve sem tocar JCE? Talvez haja alguma outra maneira?

É óbvio para mim que nada pode impedir um puro-java open source de criptografia algoritmos de trabalhar independentemente de Sun aprova, por isso não é uma questão de possibilidade teórica, em vez: que caminho é o menos dolorosa

?

É claro, posso sempre ir feio cedo, agarrando Bouncy Castle implementação da JCE puro-java, renomeando seus pacotes para java.security1, e fazer quaisquer alterações que eu quero - mas desta forma parece certo muito doloroso agora

.

Atualização Meu problema atual com o uso de Bouncy Castle diretamente:. Tento chaves de carga de armazenamento de chaves, que envolve o uso SecretKeyFactory, que por sua vez rejeita meu construir Bouncy Castle

Answer 1

É bastante simples para assinar mensagens sem usar JCE. O verdadeiro problema estava lendo PKCS # 12 chaves.

Eu fiz isso: * Copiado JDKPKCS12KeyStore classe sobre. * Em todo ele, substituído Security.getInstance () com bcProvider.getService (). NewInstance () (que retorna Spi-s) * Em aqueles Spi-s (em fontes BC) feita métodos necessários público em vez de protegido.

Parece que um hack, mas parece realmente trabalho.

Answer 2

BC S / MIME está escrito sobre o pacote CMS, então a questão realmente recai para modificar o pacote CMS por isso toda a criptografia é feita usando as classes de peso leve.

Algo semelhante já foi feito, mais ou menos sucesso, para a versão .NET de Bouncy Castle. Estamos tentando (reconhecidamente é um processo lento) refatorar a versão Java para que o material CMS pode trabalhar com qualquer JCE ou leve. O mesmo problema afeta outras partes do API BC também por exemplo o PKCS # 12 keystore é construído no provedor de JCE, o pacote OpenPGP é escrito para JCE, etc. As portas .NET destes reescreveu-los para a API leve também.

Seu problema é provavelmente mais simples do que o caso geral embora. Provavelmente, você só precisa do CMSSignedDataGenerator e classes de suporte. Você provavelmente não precisa de todos os inumeráveis ??variações de addSigner ou gerar. Se você acabou de decidir sobre suas digest / algoritmos de assinatura na frente, em seguida, todo o material provedor vai ser fácil de substituir com chamadas codificado para implementações leves específicos.

Em vez de um armazenamento de chaves, talvez você poderia começar afastado com apenas armazenar uma única chave privada em um arquivo PKCS # 8 (PEM codificado talvez). Da mesma forma para o certificado.