2010-02-08 33 views
2

我正在嘗試編寫一個可以用S/MIME簽名電子郵件的小程序。Java中沒有JCE的S/MIME

顯然我想用一個只需要的東西做一個小罐子。很明顯,Java的做法涉及到一個巨大的神聖簽名的Bouncy Castle JCE jar。

問題是:什麼是最簡單的方式獲取S/MIME而不觸及JCE並且抱怨「驗證」「提供者」?也許有一個不依賴於JCE的S/MIME實現?也許有可能使用輕量級API使用Bouncy Castle S/MIME而不觸碰JCE?也許有其他方法嗎?

對我來說,顯而易見,無論Sun是否同意,沒有任何東西可以阻止純Java開源加密算法的工作,所以這不是理論上的可能性問題,而是:哪種方式最不痛苦?

當然,通過抓住Bouncy Castle pure-java JCE的實現,將它的包重命名爲java.security1,並進行所需的更改,我可以早早地醜陋 - 但這種方式現在看起來太痛苦了。

UPDATE我現在的問題直接使用充氣城堡:我嘗試從密鑰庫,其中包括使用SecretKeyFactory,這反過來又拒絕我的充氣城堡建造加載項。

回答

1

在不使用JCE的情況下對消息進行簽名非常簡單。 真正的問題是讀取PKCS#12密鑰。

我這樣做了: *拷貝了JDKPKCS12KeyStore類。 *在其中的任何位置,用bcProvider.getService()。newInstance()替換Security.getInstance()(它返回Spi-s) *在那些Spi-s中(公元來源)使所需的方法公開而不是受保護。

它看起來像一個黑客,但似乎實際工作。

2

不列顛哥倫比亞省的S/MIME是通過CMS軟件包編寫的,所以這個問題真的可以用來修改CMS軟件包,所以所有的加密都是使用輕量級類來完成的。

對於Bouncy Castle的.NET版本,已經做了類似的事情,或多或少成功了。我們正在嘗試(重申這是一個緩慢的過程)重構Java版本,以便CMS的東西可以使用JCE或輕量級。同樣的問題也會影響BC API的其他部分PKCS#12密鑰庫內置於JCE提供程序中,OpenPGP軟件包寫入JCE等。這些.NET端口也將它們重寫爲輕量級API。

雖然您的問題可能比一般情況下更簡單。推測你只需要CMSSignedDataGenerator和支持類。您可能不需要addSigner的所有無數變體或生成。如果您只是預先決定了摘要/簽名算法,那麼所有提供者的東西都將很容易被硬編碼調用替換爲特定的輕量級實現。

而不是一個密鑰庫,也許你可以擺脫一個私人密鑰存儲在一個PKCS#8文件(也許是PEM編碼)。同樣的證書。

+0

是的,我可以輕鬆地簽署消息,而無需使用JCE。 真正的問題是讀取PKCS#12密鑰。 我會在那裏描述它。 – alamar 2010-02-16 14:46:24