web-dev-qa-db-ja.com

Unseen.is独自の特許取得済み「xAES」アルゴリズムで再検討された暗号化の主張

昨年、Webサービス https://unseen.is による暗号化の主張について質問しました。 「軍レベルの暗号化を超えた」、「4096ビットキー」などの主張があったサービスとまったく同じです。これは、サポートからの応答です。

  1. IKE v1とv2は使用しません。署名もありません。これが鍵を交換する方法です:

イニシエータは、指定されたセキュリティ強度に対して、ランダムな一時的なNTRU公開/秘密鍵ペアを生成します。イニシエーターはNTRU公開鍵をレスポンダーに送信します。レスポンダはランダムな秘密を生成し、それをNTRU公開鍵で暗号化します。レスポンダは暗号化されたシークレットをイニシエータに送信します。イニシエーターは、NTRU秘密キーを使用して暗号化を解除し、シークレットを抽出します。次に、イニシエーターとレスポンダーの両方がシークレットsを使用して計算します。

  1. xAES(拡張AES)は、AESに基づく当社の特許取得済みの暗号化アルゴリズムですが、Gray-SboxまたはSboxを柔軟に(ステップSubBytesで)使用して、より大きなキーサイズ(最大8192ビット)、より複雑で長い多項式(ステップMixColumn) 、およびその他のいくつかのセキュリティ変更(塩、キー拡張など)。

  2. JavaScriptデバッガを使用して、受信メッセージと送信メッセージを表示し、メッセージペイロードをチェックして暗号化テキストを確認できます。これは、SSLトンネル内の完全なエンドツーエンドの暗号化です。


更新:2015年10月8日

xAESは、AESのベースから抜け出すための指数的に困難なレベルです。 AESのキーサイズは265ビット以上に制限されており、xAESはすべてのAES制限を克服するために開発されました。 xAESの場合、サイズは16kbit(AESの約2 ^ 64倍)にすることができます。これは、量子コンピューターを使用して破壊する場合でも、非常に困難です。


暗号化のスペシャリストは、この応答についてどう思いますか。特に、独自の「特許取得済み」の暗号化アルゴリズムである「xAES」をどのように評価しますか?ユーザーが「特許取得済みの独自の暗号化」を使用しているサービスの背後にユーザーの通信を配置する価値は何ですか。少なくとも、第三者からのチェックやテストを受けた痕跡は何も見つかりませんでした。

更新:2018年3月7日

特許の番号は 20160142208 で、タイトルはMULTI-DIMENSIONAL ENCRYPTIONです。

11
Harry Greenwald

あなたが説明することから、彼らは何をするかというと、SSLでデータをトンネルしますが(これは妥当です)、Javascriptに追加の暗号化レイヤーを追加します(これはではありません妥当です)。全体の推論は誤りです。実際、どちらのSSLも送信のセキュリティを保証します。その場合、追加のレイヤーは単に役に立たなくなります。または、SSLは送信のセキュリティを保証しませんので、攻撃者は送信されたJavascriptコードを変更できるため、その追加の暗号化から得られることが期待されるセキュリティ上の利点をすべて無効にすることができます。

実際には、SSLが十分でない場合は、すでに運命にあります。 SSL接続を傍受できる方法は基本的に2つあります。

  • 攻撃者は、クライアントマシンに自分の管理下にある追加のルートCA証明書を仕掛けることができます。次に、攻撃者が制御するCAで署名されたサーバーの偽の証明書をオンザフライで生成することにより、 中間者攻撃 を実行します。この方法は、Blue Coatの ProxySGアプライアンス などの製品を使用して、一部の大規模組織で一般的に適用されています。

  • 攻撃者は、クライアントブラウザーで使用されるSSLライブラリにフックするソフトウェアをクライアントマシンに埋め込み、ソースから直接データを読み取ることができますbefore暗号化される前(またはその後)着信データの場合、復号化されます)。

最初の方法は、うるさいが正直なシステム管理者が行うことです。拡張性が高く、ブラウザのアップグレードに対して堅牢です。また、ユーザーは常に南京錠アイコンをクリックし、見かけ上のサーバー証明書チェーンを見て、余分なルートCAに気付くことができるため、2番目の方法より目立たなくなります。

どちらの方法もクライアントマシンへの同じ種類の初期アクセスを必要とするため、攻撃者が1つを使用できる場合、攻撃者はもう1つも同様に使用でき、あなたは賢くありません。簡単に言うと、SSLが十分でない場合、マシンは危険にさらされており、抵抗は無駄です。 SSLを突破できる人は誰でも、そしておそらくもっと簡単に、キーロガーをマシンに植え付けるだけで、SSLに煩わされることさえありません。


"xAES"は独自のセクションに値します。

まず、「特許取得済みの独自アルゴリズム」などはありません。特許はパブリケーションであり、それも存在理由です。特許は、その使用のための一時的な独占と引き換えに、発明が公開される契約です。発明者が秘密に頼ってから亡くなったために、発明全体が失われるのを防ぐことが全体のアイデアでした。ソフトウェアの特許が「機能する」かどうかはオープンな(そして過酷な)議論ですが、基本的な特性は残ります。特許を取得したものも定義により公開されます。

したがって、アルゴリズムが実際に特許を取得している場合は、特許が存在し、その参照(特許番号)を送信できるはずです。しかし、何の言及もなく、特許が存在しない可能性があると想定する必要があります。これは、特許が嘘をついていることを意味します(信頼を築くための優れた方法)。

それでは、いくつかの詳細を見てみましょう。 [〜#〜] aes [〜#〜] は、代数的性質のいくつかの基本コンポーネント上に構築された正確な定義を持つアルゴリズムです。これらのコンポーネント間の相互作用は過去15年間に渡って詳細に研究されており、主題に関する圧倒的なコンセンサスは、これらのことは微妙であり、特定の定義が適切なレベルのセキュリティを保証することを確認することは容易ではないということです。したがって、単一の変更はセキュリティにとって非常に有害であり、そのような発生を検出する明白な方法はありません。

「より複雑でより長い多項式(ステップMixColumnで)」を使用するという概念は意味がありません。そのステップは AES標準 で定義され、GF(256)[X]の多項式として取られる列の定数多項式[〜の乗算に対応します。 #〜] p [〜#〜]、特定の次数4の多項式を法として[〜#〜] m [〜#〜]。列には4バイトがあるため、[〜#〜] m [〜#〜]のみが次数4を持つことができます。他に選択肢はありません。そして、演算は[〜#〜] m [〜#〜]を法として行われるため、[〜#〜] p [〜 #〜]は3を超えることはできません。したがって、「より長い多項式」を使用しても意味がありません。

(または、おそらくもっと悪いことに、それらはdoこれが同等であることを認識せずに、より大きな次数で多項式P 'を乗算しますモジュロ[〜#〜] m [〜#〜]を実行したときに3次以下の多項式で乗算する

AESでのMixColumns変換の役割は、いくつかの 雪崩効果 を確実にすることです。単純化した見方では、「なだれが多い」方が良いと考えられますが、そのためには、まず標準のMixColumnsに欠陥があることが必要です。これは根拠のない主張です。さらに、より強いなだれ効果は、人間の目には「より複雑」に見える多項式と実際には相関しません。

もちろん、8192ビットのキーサイズは非常に笑えます。 128ビットは すでに十分 であり、そのため 強い理由 があります。鍵のサイズは、対称暗号アルゴリズムの弱点ではありません。ディスコが目新しさだったときには、以前は弱点でした。なぜなら、本当に短いキー(特に [〜#〜] des [〜#〜] )を使用する広範なアルゴリズムがあったためです。しかし、状況は変わり、対称キーは、既存のハードウェアからだけでなく、近い将来に発明されるハードウェアからもブルートフォース攻撃から安全になるように拡張されました。

誰かが「8192ビットの対称キーを使用している」と言うと、「暗号化とは何なのかわかりませんが、大きな数字が大好きです」と聞こえます。

最後に重要なことですが、過去10年間の暗号研究における共通のテーマは サイドチャネル攻撃 が懸念される可能性があることであり、暗号アルゴリズムの実装では注意が必要です。一定時間のビットスライス実装を促進するために、特にAES S-boxの最適化された回路ベースの記述(例 this one )について、その主題について多くの研究が行われてきました。アルゴリズム要素を変更することにより、それらは単にそのすべての研究を放棄します。


概要:次の理由により、この製品は避けることをお勧めします。

  • それらは、バックアップされていない、または意味をなさないクレームを作成します(たとえば、秘密にされている特許取得済みのアルゴリズム)。
  • 彼らが主張することを本当に実行する場合、彼らは基本的に外部レビューのすべての試みを破棄しました。これは問題ですall暗号化アルゴリズムのセキュリティは外部レビューに由来します。
  • セキュリティモデルは維持されません。むしろ、追加のカスタム暗号がすべてセキュリティに具体的な影響を与えるセキュリティモデルについては説明していません。
  • 暗号化アルゴリズムの説明には、通常、暗号化スキルの完全な欠如と相関する流行語がたくさんあります。
  • いずれにせよ、これらすべては次のように要約されます。貴重なデータをこれらの人々に送信し、彼らがそれで何をするかを知る方法はありません。すべての暗号通信は転送中のセキュリティに関するものですが、実際の弱点は常にエンドポイントにあります。彼らは彼らのウェブサイトで、一般的な「私たちはアイスランドに拠点を置いている」という懸念に対処しています。活火山の上に正確に住むこと、または漁業が盛んになることで、データのセキュリティがどの程度改善されると考えられているかは、明らかにされていません。
19
Thomas Pornin

適切な暗号分析がなければ、明確に言うことは多くありませんが、これは多くの警鐘を鳴らします。

まず、鍵交換アルゴリズム。シークレットは平文で送信されることはありません。これは良いことですが、ネットワーク経由で送信されるのは悪いことです。ネットワークを介して決して送信されない秘密を、両方の当事者が共有する方法があります。たとえば、 Diffie-Hellman 。または 楕円曲線 を使用したバージョンです。短命な鍵を使用するのは良いことですが、 MITM攻撃 に対する保護はありますか?

第二に、通信キー。クライアントが生成したようです。そして、クライアントの 疑似乱数ジェネレータ に依存しています。コンピューターは、乱数の生成とJavaScript( 番号エントロピーを集める可能性のあるOSへのより困難なアクセス)はさらに悪いことです。したがって、通信の鍵は、1つの、おそらく貧弱な疑似乱数ジェネレータにのみ依存します。悪い、それはクライアントとサーバーの両方に依存する可能性があります。

第三に、xAES。彼らがいくつかの改良を加えた可能性はありますが、それはありそうもありません。より可能性が高いのは、フェーズ間の必要な相互作用をわずかに妨害し、結果の安全性を大幅に低下させたことです。実際にはそのような試みが数多くあり、それらのほとんどは元の(かなりすぐにクラック可能)よりもかなり悪いです。

4番目に、xAESキーの長さ。これはそれ自身の段落に値する。一般に、キーサイズの方が多い方が良いですが、このための8192キーサイズは不合理に聞こえます。このような鍵サイズは、はるかに長い鍵サイズを必要とする非対称アルゴリズムで一般的です(例 https://crypto.stackexchange.com/questions/6236/why-does-the-recommended-key-size-betweenを参照)。 -symmetric-and-asymmetric-encryption-di )(公開鍵と秘密鍵が相互接続されているため)、対称型ではありません。一般的に使用されているキーよりも10倍以上長いキーをお持ちですか?魚のように聞こえます。または、8192という数値はkeysizeとして頻繁に表示されるため、正しいキーの長さの値を使用していると人々に信じさせましょう。それだけはそのキーサイズではありません。

全体:具体的な証拠はありませんが、私はそれを検討します snake-oil


質問の更新後:

私は米国特許制度について知識がなく、何も学びたいと思っていません(私は米国出身ではないので、いつ特許が有効になったかはまだわかりません)。私はまた、暗号学の専門家ではありませんが、平均的な人よりも多くのことを知っており、学問的な知識や趣味さえ持っています。

重大な暗号化の本/コース/すべては、独自の審査されていない暗号アルゴリズムから警告を発しますが、それには十分な理由があります。システムを完全に不安定にする小さなミスを犯すことは非常に簡単です。それがより安全であることを保証する唯一の方法は、次の方法は、多くの独立したレビューとそれを破ろうとする多くの暗号学者を持つことです。そのアルゴリズムについて何かを考えようとしたが、実際に成功しなかった多くの出版物がある場合、このアルゴリズムが安全であることをpretty確認できます。あなたが言う限りでは、xAESアルゴリズムにはそのようなレビューはありません。これは安全ではないとは言いません。それが安全であることを確認することを誰も気にしなかったと言っています。それはAESと同じくらい安全かもしれません、それはより安全かもしれません、それはCAESAR暗号より安全でないかもしれません、あなたがそれを知っているならすべてを読むことを可能にするバックドアを持っているかもしれません。安全な未レビューのアルゴリズムはありますが(AESはある時点で未レビューのアルゴリズムでした)、オッズはかなりそれに対して反対です。

著者を知らないという事実は役に立たない。もちろん、既知の名前が優れたアルゴリズムを生み出すという保証はありません。これらの何千ものアルゴリズムが安全でない理由を彼らが知っているため、可能性はより大きくなります。出版記録のない人から?匿名の誰かから?それは良いかもしれませんが、それは単なる乱暴な推測です。

TL; DR:アルゴリズムがなく、熟練した人がいくらか時間をかけてそれを解読しなければ、それは乱暴な推測です。これはセキュリティであり、私たちはワイルドな推測を信じていません。

そして、再びキーの長さを取得します。新しいものは何も追加できません。それが良くなることを除いて-以前彼らは8kbitの鍵を主張しましたが、現在は16kbitです。おかしい、数日、使用されるキーの最大数は2倍になりますか?これは固定されたアルゴリズムですか、それとも私たちが話すように更新するだけですか?繰り返しますが、そのサイズのキー(8または16キロビット)は、対称アルゴリズムには不合理です。比較するには:私のブラウザには多くのセキュリティ証明書がインストールされています。これらはさまざまなCAからのものです。それらのほとんどは2048キーを持っています。 xAESキーサイズの最初の図より4倍小さい。ここでは、対応する対称キー(xAES)が対称キーである場合よりも少なくとも10倍大きくなる傾向がある非対称キーについて説明します。教えてください:コミュニティは妥当なサイズがxであると信じています。 32倍あることを伝え、xだけでは不十分だと考える理由はありません。そして今では、さらに少ない理由で64倍になります。

256ビットのキーは安全であり、32倍のサイズのキーはリソースの無駄遣いであるか、そうでないと信じる理由があります。その場合、その理由を確認します。キーサイズを大きくしても、量子暗号化はうまくいきません。それは完全に異なる獣です(すべてのキーを一度に試行するマシンを想像してください。正しいものを実現する多数の並列ユニバースの一種です)。

最後に、彼らの引用に戻り、少し分析しましょう:

xAESは、AESのベースから抜け出すための指数的に困難なレベルです。

2倍の大きさの鍵を取り、アルゴリズムが安全であると想定すると、アルゴリズムは2倍困難になります。ですから、そうです、もしあなたが指数的に大きな鍵を持っているなら、あなたは指数的に難しい暗号を持っています。一種の理にかなっています。しかし、私はassume the algorithm is secure部分の証明を見たいのですが。

AESのキーサイズは> 265ビットに制限されており、xAESはすべてのAES制限を克服するために開発されました。

265ビットはタイプミスだと思います。AESは128、192、または256ビットのキーを使用します。

XAESの場合、サイズは16kbit(〜264 回AES)、

16384が2であることを説明してください64 256を超える時間? 16384/256 = 64。キーは64倍大きいです。キースペース(可能なキーの数)は264 倍大きい。これは紛らわしい用語です。

これは、量子コンピューターを使って壊しても非常に困難です。

上記を参照。

xAES(拡張AES)は、AESに基づく当社の特許取得済みの暗号化アルゴリズムですが、Gray-SboxまたはSboxを柔軟に(Step SubBytesで)使用して、より大きな鍵サイズ(最大8192ビット)、より複雑で長い多項式(MixColumnで)を備えています。 、

Thomas Porninの答えに追加することはあまりありません。しかし:より複雑な多項式とは何ですか?多項式は単純です。より長い多項式はより長く、より複雑ではありません。 100000は100よりも複雑であると言えます。

そして、いくつかのより多くのセキュリティ修正(塩、キー拡張など)。

セキュリティを低下させるセキュリティ修正は非常に簡単で、セキュリティを向上させるセキュリティ修正は非常に困難です。非常に微妙な相互接続がたくさんあります。マシンのギアを2倍の速さで動かすことができますが、他のすべてのギアが以前の速度で動くマシンでは大混乱を引き起こします。

ソルト:一方向関数(「ハッシュ」)に使用されるランダムなデータで、通常は秘密ではありません。 https://en.wikipedia.org/wiki/Salt_(cryptography) を参照してください。 padding として理解できます。これは、データを(ランダムまたは確定的)に追加して、ブロックを埋めるか、メッセージの「ランダムさ」を増やします。対称暗号の一部ではなく、その使用方法です。

キー拡張:必要に応じてさまざまなプロパティを使用して、小さいキーを持ち、それから大きいキーまたはキーセットを生成するプロセス。以降の対称暗号のラウンドのキーを生成するプロセスは、(ラウンドで使用されるいくつかのサブキーにキーを拡張するため)呼ばれることがあります。そのため、AESにはすでにこれがあります。

ああ、私たちはいくつかの派手な暗号用語を詰め込んでいます。別のコンテキストからはあまりにも悪い。

彼らの最高経営責任者(CEO)は、彼が何について話しているのか見当がつかないようです。そして、彼はそれぞれの答えでますますそれを鳴らします。ここで得点はありません。

PGPの作成者であるPhill Zimmermannを引用します。

解読不可能な暗号化スキームを考案したと思う人は誰でも、信じられないほど珍しい天才か、素朴で経験の浅い人です。残念ながら、私は、独自の設計の暗号化アルゴリズムを追加することによってPGPを「改善」したいと考えている暗号学者に対処しなければならないことがあります。

私は、1991年にNSAの上級暗号学者であるBrian Snowとの会話を覚えています。彼は、最初にコードを解読するのに多くの時間を費やして「骨を稼いだ」わけではない誰かによって設計された暗号化アルゴリズムを決して信用しないと彼は言った。それは非常に理にかなっています。私は、暗号化の商業世界の誰もこの基準に適格ではないことに気付きました。 「はい」と彼は自信をもって笑顔で言った、「それで私たちの仕事はNSAではるかに簡単になります。」ぞっとするような考えでした。

https://www.philzimmermann.com/EN/essays/SnakeOil.html

ブルース・シュナイアーのヘビ油チェックリストを見てみましょう: https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil 。私の意見では、ポイント1、3、4、5、7は完全に適合します。 9のうち5です。

4
Torinthiel