S/MIME на Java без JCE

Question

Я пытаюсь написать апплет, который будет подписывать e-mail с S/MIME.

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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