自堕落な技術者の日記

自堕落な技術者の日記 : OATH関連でごにょごにょと、、、(その2) - livedoor Blog（ブログ）

OATH関連でちょっとPOCをやっていたんですが、昨晩、やはりというか、案の定というかまったく問題なくワンタイムパスワードが作れてしまった。カウンタの値もわかってしまう（−−；改めて共通鍵の配布の仕方ってホント需要なんだなぁと再認識した次第、、、、

ソフトウェアトークンみたいなもんですね、、、、、う〜〜〜む、どうしたものか、、、、(謎)

POCはJavaだったけど、C#でもAESやHMACやXML扱えるので書き直してツール仕立てにするかな、、、、

自堕落な技術者の日記 : OATH関連でごにょごにょと、、、 - livedoor Blog（ブログ）

サンプルのトークンの鍵群コンテナから共通鍵は取り出せて、MACも一致したので、まぁ、、、大丈夫なのかな、、、と、、、、

取り出し方は2フェーズで

(1)別途提供される鍵群コンテナ全体のAES256bit共通鍵とイニシャルベクタ(IV)で復号して、トークンの共通鍵を取り出す。その際、アルゴリズムは"AES256-CBC"とだけ示されてるんですが、Java JCEのアルゴリズムを指定する際、"AES/CBC/NoPadding"じゃダメで"AES/CBC/PKCS5Padding"でなければいけませんでした。これは、RSA BSAFE ShareでもBouncyCastleでも同じ事、、、、

(2)取り出したトークンの共通鍵が正しく復号されているかどうか、指定されているMACで一致確認を行う。平文のトークン共通鍵に対して鍵群全コンテナ全体の秘密鍵を用い"HMAC-SHA1"でMAC値を得て、これが記載内容と合致すれば正しく復号できていることになる。JCEアルゴリズム名はBouncyCastleでは"Hmac-SHA1"だがRSA BSAFE Shareではこれではダメで"HmacSHA1"である。

というわけで、トークン個別の共通鍵は無事取り出せました。にょほほ、、、

【今日の愚痴というか提言（−−；】
幾つかのJCEプロバイダを触ってみてJCEアルゴリズム名が実装によって微妙に違うのは止めにして欲しい。ちょっと名前が違うだけでエラーになっちゃいます（Ｔ＿Ｔ）これは是非標準化をお願いしたいところです。実装によってはaliasを使ってHmac-SHA1==HmacSHA1==HMACwithSHA1みたいにしているものもあるんですが、実装によって完全に同じではありません。私は正規化された名称が一つあればそれで十分だと思います。
例えば
- AES (= Rijndael) これはまぁ、わかるんだけど
- RC4 (= ARC4 = ArcFour) これは同じだとは全く気づかなかった

次はオクラ関数だな(謎)

今日の夜はOATH関連でちょっと実験君をしています。

OATH(initiative for Open AuTHentication)は、(私はそれでいいと思うのだけど)とかくプロプライエタリになりがちなワンタイムパスワードトークンのアルゴリズムやインタフェースの標準化を行っている団体です。

HMACを使ったワンタイムパスワードのアルゴリズムが既にRFCになっていたりもします。

これらのワンタイムパスワードは、基本的には共通鍵暗号を使っていて鍵(とイニシャルベクター)をどうやって渡すかが肝なんですが、複数のトークン毎の共通鍵を受け渡しするためのフォーマットがOATHのメンバ企業が主体となってIETF KEYPROV WG (Provisioning of Symmetric Keys)で標準化されようとしており、インターネットドラフトが出ています。

その一つが「Portable Symmetric Key Container (PSKC)」なんだそうです。IETFなんですがフォーマットはXMLになっているという、、、、、

この実装で、ちょっと気になるところがあって、例によって BouncyCastle と Jython で「6. Protection of Keys and Related Data」のところをテストコード書いて試してたりするんですが、MACのところは一致したのだけど、鍵の計算がわからんぞ〜〜〜〜。そもそも、イニシャルベクター(IV)を示してないと例としては不適なのでは？？？と、悶々としています。

ちょっと今はごにょごにょだし、成果もでるかどうかわからないんですが、報告できそうならそのうちしたいと思います。

前回からいい感じに回数が開きましたが、またRSA BSAFE Shareの話を、、、、

PKIX CertPathBuilderはかなり良い感じ

前回はNIST PKITSを使ってRSA BSAFE ShareのPKIX CertPathValidator(パス検証)を試してみましたが、今回はPKIX CertPathBuilder(パス構築)の方をためしてみました。

RSA BSAFE ShareのPKIX CertPathValidatorはSUNと比べてエラーの理由がわからんとダメ出しをしてしまい、同様にSUNのPKIX CertPathBuilderにも失敗の原因がさっぱりわからん！！！とダメ出しをしているですが今度はどうかな、、、、、

結果的に言うとBSAFEのPKIX CertPathBuilderは失敗の理由がバッチリわかるのでSUNなんかより良いです。

テストに使うパスは昔つかったスイカ型メッシュモデル風のパスです。



RSA BSAFEのCertPathBuilder、CertPathValidatorの困ったところは"-Djava.security.debug=cerpath"フラグを使ってもデバッグメッセージを全く吐かないところです。中の動きが見えにくいし、、、、、

一応デバッグフラグをつけておくと、SunのX509CertSelectorのログだけは出力されます。でデバッグ出力からパスの繋ぎ方を見る方法ですが、

certpath: X509CertSelector.match(SN: 証明書シリアル
Issuer: 発行者DN
Subject: 主体者DN)
certpath: X509CertSelector.match returning: true

の行があれば、この証明書がパス構築に使われたことを示します。それをログの上から順に見ていきます。

で、そのスイカ型モデルでパス検証をしてログを見てると、こんな感じの順序で証明書を使っているのがわかります。





つまり、RSA BSAFE Share for JavaのPKIX CertPathBuilder実装は：
・SUNと同じエンドエンティティからルートに向けた構築
・SUNと同じ深さ優先探索
であることがわかります。

図のGGGから辿るパスは3通りあるわけですが、SUNの場合には2本辿ってダメで次に成功だったわけですが、RSAの場合には1回失敗した後で成功のパスを辿っています。

CollectionStoreの格納元にはArrayListを使っていたんですが、その格納順序で3本中のどれを選ぶかが変わるのかなと思って試してみましたが、どうもそうではないようです。

で、私の気になっているパス構築失敗時のエラーメッセージですが、ちゃんとエラーメッセージ出力するんですよ。当たり前だけど、それがSUNではできてないので、エライじゃないですか（＾＾ｖ先ほどのスイカモデルで途中の証明書をなくしておいて失敗するように設定してみると、、、、

■有効なパス中のROOT→CCCの証明書を削った場合：
　java.security.cert.CertPathBuilderException:
　　Sat May 02 10:26:08 JST 2009 is before Sun Jan 02 09:00:00 JST 2000
　　ちゃんと有効期限のエラーが表示されます。
■上からさらにROOT→AAAの証明書を削った場合：
　java.security.cert.CertPathBuilderException:
　　Expected a CA certificate.
　　基本制約cAフラグのエラーっぽい感じがしますよね。

■SUNの場合ならいずれも全く無意味な以下の例外（−−；
　sun.security.provider.certpath.SunCertPathBuilderException:
　　unable to find valid certification path to requested target
　　こりゃなんの事かさっぱりわからん

Java実装のSSLのクライアントで「繋がんね〜〜〜」とか悩んでいる場合には、SUNのはやめてRSA BSAFEを使うよう優先して調べるといいんじゃないっすかね。

前回に引き続きRSA BSAFE Share for Javaのお話を、、、、

NIST PKITSをやってみると

BSAFE Shareには"JsafeJCE"という名前のJCE(Java Cryptography Extension)プロバイダがあって、その中で証明書が信頼するルート証明書から辿って有効であることを検証する認証パスの構築や検証の実装が含まれています。

証明書のパス検証については米国標準技術局(NIST)がPKITSというテストケースとデータのセットを公開していてSUNのJCEプロバイダだとどうなんだ？みたいな話は4月13日に書きました。

じゃぁ、JsafeJCEプロバイダのCertPathValidatorのPKIXアルゴリズムの実装はどうなんだろうって、、、、気になりますよねぇ、、、ならないか、、、、

個人的に気になったのでやってみました。で、結果は、、、、、、

：
：
：
（−−；

拍子抜けというか、期待が大きかっただけにがっかりというか、実装に問題があったとかそういうのではなく結果としてSUN JCEの実装と殆どサポート範囲も含めてうり二つなんです。(だから、ブログに書きにくい、、、、結果が違ってたのはDeltaCRLのテスト1つだけ)

NIST PKITSのテスト結果からSUNとJsafeJCEのJCEプロバイダには以下のような共通の特徴があります。
・あるCAが証明書とCRLの発行を別の鍵(と証明書)で行う事の非サポート
・NewWithOldのテストの不具合(詳細は見てない)
・IndirectCRLの非サポート
・DeltaCRLの非サポート
間違ったテストも全く同じなので同じ開発元が作ってるのかな？とさえ思えてしまいます。

SUNよりもJsafeJCEの方が例外のメッセージも不親切気味なので、エラーが起きたときの原因の究明には手間取るかもしれません。以下が同じテストケースにおける例外メッセージの例です。

SUN: signature check failed: Signature does not match.
JsafeJCE: Certificate verify failed!
SUN: timestamp check failed: NotBefore: Jan 01 2047
JsafeJCE: Apr 29 2009 is after Jan 01 2047 (これは互角)
SUN: CA key usage check failed: keyCertSign bit is not set
JsafeJCE: Certificate verify failed!

どうです？「Certificate verify failed!」の一言で片付けられちゃうケースが多くて微妙な感じですよね（＾＾；CertPathValidatorに関しては、積極的にこれを利用する理由がいまひとつ見えてきませんでした。

楕円暗号の鍵生成ができない？！

RSA BSAFE Share for Javaでは楕円暗号の署名や証明書の検証、鍵交換(ECDSAやECDH)なんかができるんですが、JCEのサポートアルゴリズムのリストを見た限りでは楕円の鍵生成機能を提供していないようです。

楕円の証明書発行要求もできないのでは？！と思うんですが、どうでしょう、、、、


今日は、休日なんでこの辺で、、、、（−−；

＜お詫びと訂正 2009.04.29 17:48＞
私がアルゴリズム名を集計した表に誤りがありJsafeJCEでもちゃんと楕円の鍵生成はできます。混乱させてしまい申し訳ありませんでした。

今日は、その他雑多なわかった事、前に書き忘れていた事をつらつらと書いてみたいと思います。

サンプルのビルド

そういえば、サンプルプログラムのビルドについて説明してませんでしたね。

結構豊富なサンプルが用意されています。

サンプルのビルドはEclipseで行います。サンプルが使用するデータファイルのパスが絶対パスで"/data/..." だったりするようなので、Unix系でないとサンプルが動かないかもしれないです。(面倒なので試してない、、、)

Eclipseのメニューから「ファイル＞インポート」を選びウィザードで「一般＞既存プロジェクトをワークスペースへ」でできたと思います。

サンプルのビルドは同じくメニューから「プロジェクト＞プロジェクトのビルド」でビルドできたと思います。

なんでAntじゃないんだろう、、、プンプン、、、、

FIPS 140-2 Level1認定は無い

RSA BSAFE ShareはFIPS 140-2 Level1認定は無いそうで、これが必要ならば商用ライセンスが必要なんだそうです。RSA BSAFE ShareでもFIPSモードみたいなのはあるみたいなんですが、これを設定するとエラーになったりするんでしょうか。

時間がある時、調べてみたいと思います。

そもそもDevelopper's Guideは読め

さすが基本的にちゃんとした商用ライブラリなんでIAIKやBouncyCastleなんかと違ってドキュメントは充実してました。まずはDevelopper's Guide("doc/dev_guide/index.html")を読むべきでしたね。

SSLのCipherSuiteやサポートする暗号アルゴリズム、鍵長なんかもちゃんと記載されています。(JCEのアルゴリズム名はありませんが、、、)

TLSv1.2用のSuite-B AES-GCMを使ったCipherSuiteもちゃんとサポートされていました。(疑ってゴメンよ)

ちなみに、このガイドはdoxygenを使って書かれてるみたいです。

パス検証でEV証明書のチェッカーも付属

HTTPSで接続したときブラウザのアドレスバーが緑色になるEV(Extended Validation)証明書であるかどうかチェックするためのAPIもついていました。EV Guidelineで規定された証明書プロファイルに準拠しているか(アルゴリズム、鍵長も含めて)チェックしているみたいです。

ASN.1、CMS、PKCS#7なんかは無い

RSA BSAFE Share for Javaは

・暗号プリミティブ(暗号,署名,ハッシュ,メッセージ認証,乱数)
・SSL/TLS通信
・証明書検証

のためのライブラリであって

・CMS署名/暗号フォーマット
・PKCS#7署名/暗号フォーマット
・XML署名/暗号
・ASN.1
・証明書拡張の情報の取得

は守備範囲外みたいです。

CMS、PKCS#7はわかりますが、証明書ポリシのpolicyQualifierとか証明書の拡張を取り出して中身を見るには別のライブラリを使う必要があります。

JavaのJurisdiction Policyのチェック

ちょっとオモシロイと思ったので、これも紹介、、、、

Sun Javaは暗号ライブラリを含みワッセナー条約の輸出規制にかかるため、配布時点では管轄ポリシー(jurisdiction policy)ファイルで制限されています。

規制の対象外の殆どの国では、このポリシーファイル(jre/lib/security/{local,US_export}_policy.jar)を無制限強度(unlimited strength)のものに置き換えることで、鍵の長い強固な暗号を使えたりします。

BSAFEではこのポリシーのチェックのためのクラスがあって

# Jythonでスンマソン
from com.rsa.jsafe.crypto import *
print PolicyChecker.JurisdictionPolicyLevel.getJurisdictionPolicyLevel()

を実行してみると "UNLIMITED" と表示されたりします。

ちゃんとこれをプログラムでチェックできるのは本当にいいですよね。Java関係のいろんな製品のサポートとかでもJurisdiction Policyファイルを入れ替えてなかったせいでエラーや動かなかった報告はよく聞きますから、、、、

なんか、脈絡なくてごめんなさいね。今日は、この辺で、、、、、、

前回はRSA BSAFE Share for Javaを使えるように、プロバイダの設定や簡単なサンプルなんかを紹介しました。

前回、手持ちのJCEプロバイダで実装しているアルゴリズムの一覧表を作っていて、RSA BSAFE Shareについても加えてみたっていう話をしましたが、他のJCEプロバイダと比較してみて、各インタフェースクラスのRSA BSAFE Share for Java JCEプロバイダ実装の特徴をまとめるとこんな感じ、、、、

・署名/Signature: 代表的なものはカバー、SHA2、楕円もサポート
・暗号/Cipher: 代表的なものはカバー、珍しいとこではECIESwith*
・ハッシュ/MessageDigest: SHA2を含め代表的なものはカバー。RIPEMDは160のみ。
・安全な乱数生成器/SecureRandom: 他プロバイダと比較できない程種類が多い
・パス構築/CertPathBuilder: 他プロバイダには無いPKIX-SuiteB*, X.509V1をサポート
・パス検証/CertPathValidator: 他プロバイダには無いPKIX-SuiteB*, X.509V1をサポート
・メッセージ認証/Mac: HmacMD*, HmacSHA* などメジャーどこは全てカバー
・SSL通信内容/SSLContent: SSL*, TLSv1 など主要はサポート。TLSv1.2がある。
・SSL用トラストアンカ管理/TrustManagerFactory: PKIX-SuiteB*ある。

というわけで、暗号アルゴリズムはメジャーどこは全て押さえてあり、そつがない印象で幅広いケースで安心して使えるJCEライブラリになっています。

SecureRandomは種類が多いのはイイですが、優れたものが一つあれば十分で、交換したり、生成、検証したりしないので相互運用性が問題になることも無く、多かろうが少なかろうが、まぁ、あまり問題ではないかなと、、、、

やはり注目すべきなのは、他のJCEプロバイダにはない、パス構築・検証でのSuite-Bのサポートだと思います。

Suite-Bとは？

最近ちょっと話題になりつつある「Suite-B」とは、米国国家安全保障局(NSA)で定められた官民双方で利用できる一般的な機密保護のための仕様の公開された暗号アルゴリズムのセットです。さらに重要性の高い用途のためにNSAで開発された仕様非公開のアルゴリズムによる「Suite-A」というセットもあります。

・Suite-A
　・よりセンシティブな機密情報を扱うための暗号アルゴリズムのセット
　・NSAにより開発され仕様の公開されていない暗号アルゴリズムで構成される
　・ブロック暗号(Juniper)、非対称鍵暗号(MayFly)など
・Suite-B
　・一般的な機密情報を扱うための暗号アルゴリズムのセット
　・仕様の公開されている現在強度の高いとされる暗号アルゴリズムにより構成される

Suite-B は以下のパラメータの暗号アルゴリズムにより構成されています。

・共通鍵暗号: 鍵長128bitか256bitのAES-GCM暗号
・電子署名: ECDSA (楕円)
・鍵共有: ECDH (楕円Diffie-Hellman)
・ハッシュ関数: SHA-256とSHA-384

インターネットの標準であるRFCでは最近、IPsecでSuiteBを使うためにRFC 4969が出ていたり、S/MIME暗号メールでSuiteBを使うためのRFCが出ていたりします。

Windowsでは、Vista以降のCryptoAPIの後継であるCNGでSuiteBをサポートしていたり、Outlook2007でSuiteBしか使わないグループポリシにしたり、IPsecでSuiteBを使うようにしたり、認証局の証明書テンプレートでSuiteBを使うようにしたりできるようです。

BSAFE Shareのパス検証のSuiteB対応

指定された時刻に証明書のチェーンが正しく繋がっていて、失効しておらず、有効期限内であるかを確認するためにパス構築・検証を行います。

パス構築・検証でSuiteBの暗号しか使わないってことは、署名はSHA2と楕円暗号を使ったSHA256withECDSA or SHA384withECDSA署名アルゴリズムしか使えないってことになります。

鍵共有や共通鍵暗号についてはパス検証においては関係ありません。

ハッシュ関数については署名以外で直接的に使うところはあまり無いのですが、以下はSuiteBじゃなくてもいいんでしょうか、、、
・KeyIdentifierを生成する際、SHA-1のみしか使えないのは仕様なので仕方ない
・OCSPの識別名のハッシュを使う際SHA-1のみしか使えないのも仕方ない
・パス構築でCRLやOCSPを取得する際にHTTPS、LDAPSであった場合
　　TLSがSuiteBの暗号のみであることを必要とするのか？！
、、、んん〜〜っ、どうなんでしょうね、教えてエライ人（＾＾；


BSAFE Share for Javaではパス構築(CertPathBuilder)とパス検証(CertPathValidator)のために複数のアルゴリズムを提供しており、これは他のJCEプロバイダには無いところです。JCEアルゴリズム名の一覧は以下の通り。

・PKIX: RFC 3280に基づく証明書のパス構築・検証
・PKIX-SuiteB: 上記でSuiteBの暗号のみを使用
・PKIX-SuiteBTLS: TLS暗号化通信のパス構築・検証でSuiteBを使用
・X.509V1: X.509V1で規定されたパス構築・検証(証明書拡張が無い)

SuiteBかどうかは、パス検証後に署名アルゴリズムだけちゃちゃっとチェックすれば同じことのような気もしますが、JCEのアルゴリズムとして明示的に指定でき自動でやってくれちゃうっぽい、っていうのはスゴイところです。

SuiteBのTLSは？

暗号通信 TLS で SuiteB を使う時に、ハッシュやMacはまぁいいとして、共通鍵暗号として AES-GCM(Galois/Counter Mode)っていうのを使わなきゃいけないと思うんですが、BSAFEとか他のJCEプロバイダも含めてAES-GCMの対応ってどうなんでしょうか、、、単にAESのアルゴリズムパラメータで指定できるのかな、、、、

ここら辺は今後調査してみます。

BSAFE Share for Javaで足りないところ

BSAFE Share for Javaのサポートアルゴリズムの一覧をざっと見て思ったのは、RC2何とかやDES、TripleDESなんとかなど主要なものは一部ありますが、その派生のアルゴリズムでサポートしてないものが結構多いな、、、と感じました。後方互換性をバッサリ切っちゃうみたいなところはあるかと思います。

例えばこんなケースでサポートできなくて困らないかな、、、と心配します。

・PKCS#12形式の暗号化された秘密鍵
　　古い暗号アルゴリズムが使われており、鍵が取り出せないなんてことが
　　あるかもしれない。
・S/MIME暗号メールのメッセージ
　　古い暗号アルゴリズムが使われていて、メッセージを復号して見られない
　　なんてことがあるかも、、、

古いアルゴリズムのサポートに関してはIBMのJavaであるIBM J9に付いてくるJCEがかなり優秀だと思っていて古いものの扱いに困った時には、コレを使うといいと思います。S/MIMEは仕方ないですが、PKCS#12の方は、古いアルゴリズムが使われていたら新しい汎用的なアルゴリズムを使うように移行(マイグレーション)を考えておいた方がいいかもしれませんね。

というわけで、今回はBSAFE Share for JavaのSuiteB暗号スイート関連の話題を中心にサポートされている暗号アルゴリズムの紹介をしてみました。

ううむ、、、今回もマニアックな感じでしたね。すみません。

週末、RSA BSAFE Share for Javaをダウンロードしてみたので、いろいろ試してみました。

どんなアルゴリズムを実装しているか

JCEプロバイダの実装をゲットしたら、そのプロバイダがどんなアルゴリズムを実装しているのかを調べたくなるのが人情ってもの、、、、

製品紹介ページにアルゴリズムの一覧が書いてあったとしても、実際どうなの、、、とか、アルゴリズムの参照名がどうなっているの、、とかは気になりますし、それを知っとかないと後でアルゴリズム名が間違っているために障害起きたりして痛い目にあうので、日ごろからJCEプロバイダとアルゴリズム名の表はまめ手を入れて管理するようにしています。

現状手元にあるのが、
・IAIK JCE
・BouncyCastle
・Entrust Toolkit
・IBM J9 J2SE 1.6.0
そして新しく加わった
・RSA BSAFE Share

プロバイダ設定して、アルゴリズム一覧を出力するプログラムを使ってリストを出し、Excelで地味に表を更新します。

表を公開できればなぁ、、、とも思うんですが、26列×436行というHTMLでテーブル書くにはデカすぎるので、ちょっと出し方を考えておきます。

JCEプロバイダ毎にクセやら傾向があったりするんで、その辺りもいつかまとめて紹介したいと思います。

まず最初、プロバイダの設定

まず、2つのjarファイル、"lib/shareCrypto.jar"と"lib/shareTLS.jar"をJavaのクラスパスに入れてからRSA BSAFE ShareのJCEプロバイダを使えるようにするために方法が2つあります。

・設定ファイルに登録する方法
・動的に読み込む方法

利用できるJCEプロバイダは

$JAVA_HOME/jre/lib/security/java.security

のファイルの

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
　：以下略

に登録しておけば使えます。番号が小さいほど優先して使われるので、

security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider
　：以下略

のようにBSAFE Shareのものを先頭にもってきておき、他のは番号ずらしておけばBSAFEが優先して使われるようになります。

プログラムから動的にJCEプロバイダを使えるようにするにはプログラム中以下のような呼び出しをすれば、RSAのプロバイダが優先的に使えるようになります。

import java.security.Security;
import com.rsa.jsafe.provider.JsafeJCE;
import com.rsa.jsse.JsseProvider;

　：中略
try {
Security.insertProviderAt(new JsafeJCE(), 1);
Security.insertProviderAt(new JsseProvider(), 2);
} catch (Exception ex) { ex.printStackTrace(); }
　：中略

ここで注意しとかないといけないのが、JCEプロバイダ名とクラス名が合っていないところです。

・プロバイダ名："JsafeJCE" (こっちはクラス名と一致で安心。暗号関連の実装)
・プロバイダ名："RsaJsse" (こっちは違うので注意。SSLのためのプロバイダ)

例えばプロバイダを明示的に指定してSignatureオブジェクトをゲットしたい場合には、

import java.security.Signature;
Signature sig = Signature.getInstance("SHA1withRSA", "JsafeJCE");

先ほどRSA BSAFEを優先して登録したはずなので

Signature sig = Signature.getInstance("SHA1withRSA");

とプロバイダ指定しなくてもRSA BSAFEが使われます。

それでは、"JsafeJCE"プロバイダの"RIPEMD160"ハッシュアルゴリズムを使って文字列"aaa"に対するハッシュ値を計算してみましょう。

import java.math.*;

import java.security.*;

import com.rsa.jsafe.provider.*;

public class RipeTest1 {

  public static void main(String[] args) {

    try {

      MessageDigest md = MessageDigest.getInstance("RIPEMD160", "JsafeJCE");

      byte[] hash = md.digest("aaa".getBytes());

      System.out.println(new BigInteger(hash).toString(16));

    } catch (Exception ex) { ex.printStackTrace(); }

  }

}

ちなみにRSA BSAFE Share for Javaは JDK 1.4.x では使えないみたいで、

実行しようとすると

Exception in thread "main" java.lang.UnsupportedClassVersionError: RipeTest1 (Unsupported major.minor version 50.0)

コンパイルしようとすると

RipeTest1.java:7: com.rsa.jsafe.provider.JsafeJCE にアクセスできません。クラスファイル shareCrypto.jar(JsafeJCE.class) は不正です。
クラスファイルのバージョン 49.0 は不正です。48.0 であるべきです。
削除するか、クラスパスの正しいサブディレクトリにあるかを確認してください。

のようなエラーが出てしまいます。

今日は、初回なんでこの辺で、、、、

次回はRSA BSAFE Share for Javaの特徴みたいなところを紹介できれば、、、、と思っています。