S / MIME на Java без JCE

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

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

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

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

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

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


java bouncycastle smime jce
person alamar    schedule 08.02.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

person Peter Dettman    schedule 13.02.2010
comment
Да, я могу легко подписывать сообщения без использования JCE. Настоящая проблема заключалась в чтении ключей PKCS # 12. Я бы описал это там. - person alamar; 16.02.2010

arrow_upward
1
arrow_downward

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

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

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

person alamar    schedule 16.02.2010