うるふブログ

この一連のブログでは、wolfSSLの新しいSP Math All 演算ライブラリについての詳細な情報をお伝えしています。これまでの３回で、SP Math All 実装の導入、従来のInteger実装とTFM実装との比較について紹介してきました。そして今回はOpenSSLとの比較を行ってみました。SP Math All実装はOpenSSLライブラリより優れているのでしょうか？

OpenSSLは、デフォルトビルドでは速度優先最適化、コードサイズ大となります。それと比べて、wolfSSLの新しいバージョンではデフォルトでSingle Precision最適化コードが組み込まれるようになっていて、同等またはそれ以上の性能が得られます。OpenSSLでアセンブラコードを使わない場合もwolfSSLのほうが良い結果となります。

以下は、OpenSSLとwolfSSLの両者ともアセンブラコードを使わず、かつwolfSSLは’–enable-sp-math-all=small’ オプションの指定で作成したSP Math All 実装を使っての比較結果です。

全てでwolfSSLの方が勝っています！ではコードサイズでどうでしょうか？カスタムアプリを書かない限りOpenSSLのコードサイズを正確に得るのは難しいのですが、B N関係の構造体のサイズでみるとOpenSSLはwolfSSLの倍のサイズであるといえます。

皆さんが、メモリ制限のある組み込み機器開発やモバイルアプリ開発を行われているかによらず、新しいSP Math All実装はそれらの全ての要求に完全に適します。また、Single Precision実装はRSAとECCアルゴリズムを特定のサイズで実装し、モバイル、デスクトップ、サーバーアプリを目もくらむ程高速に実行し、SP Math All実装と共存できることを忘れないで下さい。

シリーズ第一回：wolfSSLの新たな Multi-Precision 演算ライブラリ

シリーズ第二回目：wolfSSL SP Math All実装とInteger実装

シリーズ第三回目：wolfSSL SP Math All実装とTFM実装

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文：https://www.wolfssl.com/wolfssl-sp-math-openssl/

これまでのブログでは従来実装である演算ライブラリとwolfCryptに新規に導入されたSP Math All実装をご紹介してきました。 前回のブログでは、従来実装であるInteger実装との改善比較を行いました。この比較結果は皆さんにとって、新SP Math All実装に乗り換えるのに十分な説得材料となったはずです。

加えて、今回は新たなSP Math All実装が従来のTFM実装に比べてどれ程高速になるのかを見ていきます。（SP Math Allライブラリは”–enable-sp-math-all=huge”コンフィギュアオプション指定で生成し、TFM実装は”–ensable-fasthugemath”オプションを指定して生成しました)

楕円曲線アルゴリズムでは常にCPUアーキテクチャによらず（x64でおおよそ50％、Aarch64でおおよそ100％の速度向上）高速です。RSAとDHではバラつきがみられますが、RSA署名では顕著に高速です。これは改良されたアセンブリコードを使った乗算とべき乗演算を使った結果です。

次はコードサイズの比較です。

TFMヒュージビルドは多倍長乗算にCombaの方法を取り入れていますが、一方SP Math Allは顕著に小さいカラツバ法の実装を取り入れています。これにより、コードサイズを抑えながら速度を向上できました。

SP Math All実装はTFM実装の全ての面で優れていることは明白です！

次回のブログではSP Math All実装とOpenSSLのパフォーマンス比較について紹介します。

シリーズ第一回：wolfSSLの新たな Multi-Precision 演算ライブラリ

シリーズ第二回目：wolfSSL SP Math All実装とInteger実装

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文：https://www.wolfssl.com/wolfssl-sp-math-tfm-implementations/

前回のブログでは、wolfCryptにおけるSP Math All実装の機能比較をご紹介しました。今回は新たなSP Math All実装と従来のInteger実装のパフォーマンス比較を行ってみます。

SP Math AllライブラリはWOLFSSL_SP_SMALLマクロあるいは”–enable-sp-math-all=small”コンフィギュアオプション指定でビルドすることにより生成できます。サイズは小さくてやや低パフォーマンスを示しますが、組み込み機器用には適したライブラリとなります。一方、”–disable-fastmath”オプションを指定して生成するInteger実装は高速でコードサイズも小さいライブラリになります。

では、SP Math All実装が従来のInteger実装に比べてどのくらい速いか見てみましょう。（注：SP Math All実装は”–enable-sp-math-all=small  –disable-asm C_EXTRA_FLAGS=-DWC_NO_HARDEN”で、Integer実装は”–disable-fastmath”のコンフィギュアオプション指定でビルドしています）

楕円曲線アルゴリズムでは常にCPUアーキテクチャによらず（x64でおおよそ50％、Aarch64でおおよそ100％の速度向上）高速です。RSAとDHではバラつきがみられますが、RSA署名では顕著に高速です。これは最適化されたべき乗演算の実装によってもたらされました。

コードサイズは速度に比べてそれ以上ではないですが同じくらい重要な比較要素です。ではARM Cortex M4を例にとって比較してみましょう。

すべてのビルドで最大25%のコードサイズ削減となっており、それに高速です！同様の傾向が他のCPUでも見られました。次回はsp_int.cとtfm.cのパフォーマンス比較を紹介します。

シリーズ第一回：wolfSSLの新たな Multi-Precision 演算ライブラリ

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文：https://www.wolfssl.com/wolfssl-sp-math-integer-implementations/

wolfSSLはあらゆる点で改善された、マルチプレシジョン演算ライブラリを導入しました。この実装はsp_int.cにありWOLFSSL_SP_MATH_ALLの定義あるいはコンフィギュレーション時オプション”–enable-sp-math-all”の指定で利用可能になります。以前はinteger.cかもしくはtfm.cの実装のいずれかを選択していました。

従来のInteger実装

従来のsmallあるいはInteger実装と呼んでいる実装は、”–disable-fastmath”オプションを指定して有効にします。この実装は、単純でコードサイズを小さく使用メモリ量も少なくなるように記述されています。そしてそれは本当に素晴らしい仕事をしてくれます！シンプルで小さなアルゴリズムを使用し、数値を保持するメモリサイズを動的に変更することで組み込み機器用のコードとして完璧になります。特定の業界では、動的メモリアロケーションを持たないというコーディング標準のため、静的メモリアロケーションなしでは、この実装が適さない場合があることも事実です。また、この実装ではサイドチャネル攻撃への耐性が高くありませんが、外部から計測可能な暗号化操作を行わない組み込み機器では問題とはなりません。

従来のTFM実装

従来のfastあるいはTFM実装と呼んでいる実装は、”–enable-fastmath”オプションかUSE_FAST_MATHマクロ、”–enable-fasthugemath”オプションかUSE＿FAST_MATH,TFM_SMALL_SET,TFM_HUGE_SETマクロによって有効にできます。この実装はTomsFastMathと呼ばれるパブリックドメインのラージインテジャ算術ライブラリを基にしています。この実装は高速ですが、複雑でコード量が多く、特定のケースに特化した実装になっています。コードはサイドチャネル攻撃耐性を強化し（TFM_TIMING_RESISTANTマクロで有効化)、より広い用途で使えます。この実装は比較的多くのメモリを搭載した組み込み機器アプリあるいはモバイルアプリ向けに最適です。半面、外部のコードを基にした実装であるため欠点もあります。我々のコードを更新する都度、オリジナルのコードから乖離し、それらの更新を取り込むのに長い時間がかかるといった点です。

既に、この様な2つの実装を備えているのに、なぜ新し実装が必要になるのでしょうか？新実装では両者の良いとこどり-小さくて速い-ができているのです。また、この実装はスクラッチから我々の手で記述しています。つまり、我々が必要としているもの全てが一ヶ所にあるのです。おっと、integer.cあるいはtfm.cより小さくかつ高速になるようにコンパイルできると言ってましたっけ？

新しいSP Math All 実装

この新たなSP Math All実装は”小さくて高速”か”非常に高速だが巨大”を選択してコンパイル可能です。TFM実装と同様に、数値を格納するためのデータサイズは固定で、動的メモリ（リ）アロケーションは使いません。小さいコードサイズ用にコンパイルすると基本的な操作用に単純なアルゴリズムのみが含まれますが犠牲になるスピードははるかに少なくなります。1024ビット以上のようなより大きな数のために特別にコードを含む巨大なオプションに含まれている高速な実装もあります。 コードをできるだけ速く実行するために、アセンブリコードのスニペットが使用されます。 x64、x86、Aarch64、ARM32、Cortex-M4、PPC64、PPC、MIPS64、MIPS、RISCV64、RISCV32、S390Xなどの幅広いプラットフォームがサポートされています。 SP Mathすべてのコードは、デフォルトでサイドチャネルに対して強化された実装を使用します。

各実装の差異を示します：

次回のブログではSP Math All実装とInteger実装のパフォーマンス比較を行います。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文：https://www.wolfssl.com/wolfssl-new-multi-precision-math-library/

暗号機能に要望を持つLinuxカーネルモジュール開発者にとってのビッグニュースです！ wolfCryptとwolfSSLはLinuxカーネルのモジュールとしてロード可能になり、libwolfssl API全体を他のカーネルモジュールにネイティブに提供します。 Linuxで初めて、TLSプロトコルスタック全体がモジュールとしてロードできるようになり、カーネル内のハンドシェイクで完全にカーネルに常駐するTLS / DTLSエンドポイントが利用可能になります。

コンフィギュレーションとビルドは、新しく追加された”–enable-linuxkm”オプションを指定するだけで行え、更にオプションで、ロード時の暗号化セルフテスト（POST）用に構成することも可能です。ライブラリビルドと同様に、カーネルモジュールは、ターゲットの機能と制限内にとどまりながら、アプリケーションの要件を満たすように詳細に構成できます。特に、開発者は、低レベルの暗号化アルゴリズムのwolfCryptスイートのみにリンクすることを選択するか、TLS1.3をサポートする完全なTLSプロトコルスタックを含めることができます。 AES-NIアクセラレーション用に構成されている場合、モジュールは1サイクルあたり1バイトを超える速度でAES256-GCM暗号化/復号機能を提供します。

カーネルモジュールの構成は、最先端のパフォーマンスとサイドチャネル攻撃に対する耐性を備えた、新しい機能を備えた完全な「single precision」bignum実装を活用しています。このブログに注目しておいてください。新しいbignum実装の多くの利点についてさらに詳しく説明していく予定です。

概念実証として、Linux WireGuardカーネルモジュールを再ターゲットして、すべての暗号化に完全な相互運用性を備えたwolfCryptを使用するようにしました。まもなく、これらの結果についてさらに共有する予定です。 libwolfsslのカーネルモジュールビルドはwolfSSLリリース4.6でサポートされ、メインラインのgithubリポジトリですぐに利用でき、x86-64で3.x、4.x、および5.xLinuxバージョンラインをサポートします。

ご質問は、info@wolfssl.jpまでお問い合わせください。テクニカルサポートについては、support@wolfssl.comにお問い合わせください。

原文：https://www.wolfssl.com/loading-wolfssl-into-the-linux-kernel/