S / MIME на Java без JCE - PullRequest
Новая
       79

S / MIME на Java без JCE

2 голосов
/ 08 февраля 2010

Я пытаюсь написать апплет, который будет подписывать электронную почту с помощью S / MIME.

Очевидно, я хочу сделать одну маленькую баночку только с необходимым материалом. Очевидно, что Java-способ заключается в том, чтобы вокруг была огромная священная банка JCE Bouncy Castle.

Вопрос в том, какой самый простой способ получить S / MIME, не касаясь JCE и не жаловавшись на «аутентификацию» «провайдеров»? Может быть, есть реализация S / MIME, которая не зависит от JCE? Может быть, можно использовать Bouncy Castle S / MIME, используя их легкий API, не касаясь JCE? Может быть, есть другой способ?

Для меня очевидно, что ничто не может помешать работе криптоалгоритмов с открытым исходным кодом на чистой Java независимо от того, одобряет ли Sun, поэтому вопрос не в теоретической возможности, а в том, какой путь наименее болезнен?

Конечно, я всегда могу пойти ужасно рано, схватив реализацию JCE Bouncy Castle с чисто java, переименовав ее пакеты в java.security1, и сделав любые изменения, которые я захочу, - но сейчас этот способ выглядит слишком болезненным.

ОБНОВЛЕНИЕ Моя текущая проблема с непосредственным использованием Bouncy Castle: я пытаюсь загрузить ключи из хранилища ключей, которое включает использование SecretKeyFactory, которое, в свою очередь, отклоняет мою сборку Bouncy Castle.

Ответы [ 2 ]

2 голосов
/ 13 февраля 2010

BC S / MIME записывается поверх пакета CMS, поэтому вопрос действительно сводится к модификации пакета CMS, чтобы все крипто было сделано с использованием легких классов.

Нечто подобное уже было сделано более или менее успешно для .NET-версии Bouncy Castle. Мы пытаемся (по общему признанию, это медленный процесс) реорганизовать версию Java, чтобы CMS мог работать с JCE или облегченным. Та же проблема затрагивает и другие части API BC, например, хранилище ключей PKCS # 12 встроено в JCE-провайдер, пакет OpenPGP записан в JCE и т. д. Порты .NET этих устройств также переписали их в облегченный API.

Ваша проблема, вероятно, проще, чем общий случай. Предположительно, вам нужен только CMSSignedDataGenerator и поддерживающие классы. Вам, вероятно, не нужны все бесчисленные варианты addSigner или генерировать. Если вы просто заранее решите свои алгоритмы дайджеста / подписи, тогда все компоненты провайдера будет легко заменить жестко закодированными вызовами конкретных легких реализаций.

Вместо хранилища ключей, возможно, вам не помешает просто сохранить один закрытый ключ в файле PKCS # 8 (возможно, в кодировке PEM). Аналогично для сертификата.

1 голос
/ 16 февраля 2010

Довольно просто подписывать сообщения без использования JCE. Настоящей проблемой было чтение ключей PKCS # 12.

Я сделал это: * Скопирован класс JDKPKCS12KeyStore. * Везде в нем заменили Security.getInstance () на bcProvider.getService (). NewInstance () (который возвращает Spi-s) * В тех Spi-s (в источниках до н.э.) обнародованы обязательные методы вместо защищенных.

Это похоже на взлом, но, кажется, на самом деле работает.

...